Re: Opinions on approach, please...

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.

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'.

Don't worry about locks. The database's defai;ts are usually what you want. Do SELECTs
without "for update". 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.
.

Relevant Pages

  • Re: Opinions on approach, please...
    ... Controlled by database permissions, not the application. ... for failure to support new ones. ... illogical call sequences if I recognise it and doing so costs me nothing. ... recommend doing a COMMIT every 10th or 100th transaction. ...
    (comp.lang.cobol)
  • Re: TIP#308: Last serial column value generated (and a note on transactions)
    ... primitives that all the database interfaces must support. ... though I'm less sure about not having commit and rollback primitives ... In case it's useful to have another datapoint, the Tcl DB interface I ...
    (comp.lang.tcl)
  • Re: What so special about PostgreSQL and other RDBMS?
    ... That's exactly the link the licence agreement for the database points to when it ... comes to what wecan expect for paying support. ... > "Oracle may provide additional releases or versions of its programs ... If the requirements are volatile I'd do a long term contract detailing what ...
    (comp.lang.php)
  • Re: What so special about PostgreSQL and other RDBMS?
    ... > the porting to another database won't be significantly eased. ... not terribly significant and the abstraction can be kept very light ... >> If they where a credible provider of support and development for this ... >> services, exactly like Oracle does, but without trapping you into a ...
    (comp.lang.php)
  • RE: Repairing / modyfing Exchange
    ... Customer Service and Support for more immediate assistance. ... This service gives you access to Microsoft technical support engineers who ... database by using the old Server's database files, ... >> up with the First Storage Group, so you would like to delete it and then ...
    (microsoft.public.windows.server.sbs)