Re: Opinions on approach, please...



"Robert" <no@xxxxxx> wrote in message
news:jcbk34dakcb3044qf3vd317916m3srru4b@xxxxxxxxxx
On Mon, 26 May 2008 11:26:24 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

"Robert" <no@xxxxxx> wrote in message
news:bnvi34t7b26e2c9bp49ub9aieor2o65qj8@xxxxxxxxxx

Here's the current definition of the interface block:

001711 01 MOST-interface-block.
001712 12 MOST-reserved. *> Do NOT change these fields
001713 *> once this block has been
001714 *> returned by MOST
001715 15 MOST-SQLSTATE pic x(5).
001716 15 MOST-SQLMsg pic x(512).
001717 15 MOST-file-status pic xx.
001718 15 MOST-access-mode pic x.
001719 88 MOST-sequential value '0'.
001720 88 MOST-random value '1'.
001721 88 MOST-dynamic value '2'.

Not necessary. Assume all are dynamic. Sequential is just a null WHERE
clause.

I make no assumptions. The interface block covers ALL possibilities. If I
find later that some of it is never used I have lost nothing.

001722 15 MOST-open-mode pic x.
001723 88 MOST-input value '0'.
001724 88 MOST-output value '1'.
001725 88 MOST-I-O value '2'.
001726 88 MOST-extend value '3'.

Controlled by database permissions, not the application.

The application can currently open its ISAM files in one of these
modes.The
application is not currently governed by database permissions because it
isn't accessing a database. Knowing what mode it is using allows me to
monitor what calls it can make.

Conversion requires fluency in the new paradigm, not the old one. After
the conversion is
done, no one will fault you for failure to support obsolete ideas, but
they will fault you
for failure to support new ones. In other words, don't think in Cobol,
think in database.


I try to think in whichever one is appropriate.

Open mode is a Cobolese irrelevance that has no counterpart in database.
Any time you
spend supporting it is wasted. Permissions control whether you can update
a table, not the
'open mode'.

It decides what actions can be issued. In other words, I can detect
illogical call sequences if I recognise it and doing so costs me nothing.



Don't worry about locks. The database's defai;ts are usually what you
want. Do SELECTs
without "for update".

Yes, I already decided that and responded to Frederico with a sequence that
showed it.

The only thing you DO need to worry about are COMMIT points. I
recommend doing a COMMIT every 10th or 100th transaction. Of course, the
application
needs a way to reatart at a commit point.

No I don't. I commit after every update action, exactly as they do with the
current ISAM. They will not be doing batch updates with this system.
Obviously batch reading doesn't require COMMITs. Frederico raised this point
and I thought it all through again. I'm happy with immediate COMMIT. If it
proves to incur a performance hit, I'll address that when it happens.

Thanks for the thoughts, Robert.

I think the major remaining concern is the WHERE conditional in START. I'm
loooking at it but it seems like dynamic SQL will need to be used.

I have modified the interface to try and support it, but it is a worry...
Here's the new interface:


001711 01 MOST-interface-block.
001712 12 MOST-reserved. *> Do NOT change these fields
001713 *> once this block has been
001714 *> returned by MOST
001715 15 MOST-SQLSTATE pic x(5).
001716 15 MOST-SQLMsg pic x(512).
001717 15 MOST-file-status pic xx.
001736 15 MOST-instance-stamp pic x(15). *> Do not pass this
*> block to any
001737 *> instance of MOST
001738 *> OTHER THAN the one
001739 *> which created it.
001718 15 MOST-access-mode pic x.
001719 88 MOST-sequential value '0'.
001720 88 MOST-random value '1'.
001721 88 MOST-dynamic value '2'.
001722 15 MOST-open-mode pic x.
001723 88 MOST-input value '0'.
001724 88 MOST-output value '1'.
001725 88 MOST-I-O value '2'.
001726 88 MOST-extend value '3'.
12 MOST-app-settings. *> These are set up by the application
*> BEFORE invoking MOST.
001727 15 MOST-action pic x. *> remove this after RW comment?
001728 88 MOST-read value '0'.
001729 88 MOST-write value '1'.
001730 88 MOST-rewrite value '2'.
001731 88 MOST-start value '3'.
001732 88 MOST-delete value '4'.
001733 15 MOST-start-conditions.
* The START condition can be compounded. Up to 3 conditions may be
* combined, using Boolean connectors.
18 MOST-condition occurs 3
indexed by MOST-x1
21 MOST-which-key pic 99.
88 MOST-primary value 1.
88 MOST-alternate value 2 thru 16.
001734 21 MOST-relation pic XX.
001735 21 MOST-rel-data pic x(100).
21 MOST-bool-conn pic 9.
88 MOST-AND value 1.
88 MOST-OR value 2.
88 MOST-NOT value 4.

001740 12 MOST-states. *> internal states &
18 filler pic x(32) *> object references
*> reserved for MOST
001741
12 MOST-data-buffer pic x(7000).

I can detect which key field is being used, I can detect the relation, I can
get the data for the condition, and I can probably handle up to 3 connected
conditions, but I still don't havea clear idea of how I'll get this into
MOST... :-)

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages