OpenVMS COBOL: Transactions? (Commit/Rollback)

[Paul Raulerson]

Well, these two particular verbs seem to missing from the current version of HP COBOL on VMS. :)

Of course, there is a transaction management system available, but it adds significant cost to the deployed application, and I would prefer to avoid that cost.

I'm open to recommendations on how to synchronize and rollback multi-file transactions. :)

Thanks for any pointers!
-Paul

[Hein van den Heuvel]

OpenVMS Cobol file IO is build on top of RMS.

RMS offers OPTIONAL, for fee, Recovery-Unit Journalling aka 'Run Unit Journalling' (RUJ) to provide consistent transactions involving multiple files.
This is FULLY integrated into OpenVMS.
For example, check out HELP SET.

You start and commit or rollback transactions from Cobol through standard provided system services.

The performance for RUJ is normally pretty good, but extra design attention is recommended. (Contact me! :-). AIJ obviously has significant storage overhead.

Check out the quote from the OpenVMS SPD below.


http://h18000.www1.hp.com/info/xav12x/xav12xpf.pdf

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting



"HP RMS Journaling for OpenVMS Alpha and Integrity servers is available as layered products and as a part of the Enterprise Operating Environment (EOE) on Integrity
servers. Journaling enables a system manager, user, or application to maintain the data integrity of RMS files in the event of a number of failure scenarios. These journaling products protect RMS file data from becoming lost or inconsistent.
RMS Journaling provides the following three types of journaling:
â ¢ After-image journaling. Allows users to reapply modifications that have been made to a file. This type of journaling allows users to recover files that are inadvertently deleted, lost, or corrupted.
â ¢ Before-image journaling. Allows users to reverse modifications that have been made to a file. This type of journaling allows users to return a file to a previously known state.
â ¢ Recovery-unit journaling. Allows users to maintain transaction integrity. A transaction can be defined as a series of file updates on one or more files. If any
failure occurs during the transaction, recovery-unit journaling rolls back the partially completed transaction
to its starting point.

The binary kit for RMS Journaling ships with the OpenVMS Alpha and Integrity server distribution kits. To run the software, customers must purchase a license and documentation. Refer to the RMS Journaling for OpenVMS Software Product Description (SPD 27.58.xx) for more information."

hth,
Hein.

[John Gillings]

Paul,

I don't think COMMIT and ROLLBACK are part of the COBOL Standard. There may be implementations of COBOL that have this capability as language extensions, but OpenVMS COBOL isn't one of them.

As Hein has pointed out, RMS Journalling should be able to do what you want. "synchronize and rollback multi-file transactions" is a succinct description of Run Unit Journalling (RUJ), though the code might not look quite as clean as COMMIT and ROLLBACK verbs.

[Hoff]

Depending on what you are up to, DECdtm distributed transaction manager system service calls or a bog-standard transactional database can potentially be used. Writing a DECdtm recovery manager isn't particularly documented, but -- with the source listings -- likely feasible. A database with an embedded pre-processed SQL (or a similar sort of callable API) is obviously an easy approach.

If you should seek to avoid the costs of purchasing a package, you'll pay to build and maintain what RMS journaling or a database would provide. TANSTAAFL, after all. And I expect you'll pay more.

As for the cheapest approaches, dig around for ProgreSQL port or look at and tune how MySQL works (its defaults often aren't what you might want, and there are folks around that abhor MySQL), or pay for a commercial supported database package. If paying for a commercial db, the Oracle Rdb database is rather well tailored to and suited to OpenVMS.

[Paul Raulerson]

Oh boy - this could be a real
>> train-wreck <<
for me. Most COBOL implementations provide a

BEGIN TRANSACTION
COMMIT/ROLLBACK

construct just for this purpose. In this particular case, there are several files that all need to be updated sucessfully or else all rolled back.

Any idea just how much cost the RMS solution adds? Or the transaction monitor product from HP? Speaking of the cost to the end user here, and assuming I pass it on to them directly "at cost."

I'm not thrilled with moving to a database because of the overhead and the expense.

Or, if anyone has any solutions they used in the past, I'm open to that. This is really the first and only thing I have found in the COBOL compiler that seems to be inadequate.

Or - are there transaction locks available in Pascal, Fortran, or Basic? I could proabably write the update code in another language if necessary, although that is somewhat undesirable.

Thanks
-Paul

[Hein van den Heuvel · Accepted solution]

Paul,

I think Hoff's reply needlessly confused you. To create your own 'recovery manager' is a rather silly suggestion imho.

The DECdtm mentioned comes free with OpenVMS

RMS (and RDB) use DECdtm to implement Journalling (and their recovery managers)

RMS Journalling is paid-for, optional product included in the top level OpenVMS license.

If your customer want RMS Journalling in a non-enterrpise OpenVMS setting, then just make them pay for it.

In the mean time your code can and should already be calling SYS$START_TRANS(W) where you would use "BEGIN TRANSACTION" and call SYS$END_TRANS(W) for "COMMIT" and SYS$ABORT_TRANS(W) for "ROLLBACK".

Those calls are free and no-ops when the underlying files are not marked for journalling.

As soon as they are marked, then the open will fail if no license is present, but that would be your customers choice.

You MIGHT want to conditionalize the TRANS(W) calls, or provide a thin jacket in a shareable library to minimize the overhead when not actually in use, as well as a nice hook for performance counters/timers.

See system service reference manuals for details on the calls:
http://h71000.www7.hp.com/doc/83FINAL/4527/4527PRO.HTML

And you may also want to glance over the RMS Journalling information:
http://h71000.www7.hp.com/doc/72final/4454/4454pro.html

Cheers,
Hein.

[Richard J Maher]

Hi,

FWIW, see my reply in comp.os.vms.

In summary,

Buy RMS Journalling
Buy Rdb (with precompilers if you have to)
Buy Oracle
(or if you insist on a native COBOL verbs)
Buy Oracle's pre-loved COASYL DBMS

DECdtm calls are necessary for 1. (and I'm not sure if there's a DECdtm XAB that you can't get at from COBOL easily if you wish to participate in other than the default transaction Hein?) and are optional for 2, 3, and 4.

Cheers Richard Maher

[Paul Raulerson]

Well, it looks like it's either the RMS transaction processing or else I figure out some other clever solution.

Thank you for all the advice. I am listening if anyone comes up with any other ideas. :)

-Paul

[Hoff]

>>>I think Hoff's reply needlessly confused you. To create your own 'recovery manager' is a rather silly suggestion imho.<<<

If you're messing with DDTM (sorry, glitched on the DECdtm name), you may well end up writing a recovery manager on your own.

If you acquire RMS journaling or other such or a database that's already tied into DDTM, you get an appropriate recovery manager. When I looked at this stuff last, it looked like I was going to have to write one if I chose the DDTM route. Silly, yes. And a task that's been discussed before, too.

MySQL is not without its own and various issues.

Off-hand, I've not seen a ProgreSQL port in recent times.