RE: COBOL Transactions?



-----Original Message-----
From: Jan-Erik Söderholm [mailto:jan-erik.soderholm@xxxxxxxxx]
Sent: Wednesday, August 22, 2007 5:03 PM
To: Info-VAX@xxxxxxxxxxxx
Subject: Re: COBOL Transactions?

Paul Raulerson wrote:
I posted this question in another, but I figured someone here might
have a good idea they were willing to share.


Most COBOL implementations provide a
BEGIN TRANSACTION
COMMIT/ROLLBACK
construct.

I have a need to update several files, all of which much be sucessful
or all of which much be rolled back, which would normally be easily
handled by the above COBOL construct.

Suggestions have ranged from using RMS Journaling, to the HP
transaction manager, to using a database for transaction managemen. All
of these suggestions would mostly likely work, but they add cost. I
have no idea of the magnitude of that cost though. I'm also trying to
avoid adding a database because of the overhead (physcial and
management) as well as the cost.

Does anyone have a rough idea just how much cost the RMS or
transaction manager solution adds to the end user on a small machine?
Assuming I pass it on to the end-user directly "at cost."

Or if John R. is reading this - any plans to add transaction
management directly into the compiler? Or is there transaction
management built into Pascal or Fortran that I can use to manage this?
This cannot be an unusual situation, especially with VMS being used in
financial markets.

I'm also open to "sneaky tricks" from the past on how to do this
safely without the added expense. <grin>

Thanks
-Paul



As close to everyone as you can get that is those needs, are
probably running a proper database, preferable Rdb, of course :-)

The nice thing about Rdb is that for moderataly small databases,
it's mostly a set-n-forget process. Rdb lives happily without
a lot of "baby sitting"...

Jan-Erik.

I suppose I will look at RDB; it really is just another layer of complexity and another cost item, though I will have to compare costs between that and RMS journaling.

Databases invariably seem to add overhead I just don't want to deal with. One more piece to keep up to date,
patched, licensed, maintenance, etc. It makes a huge difference in the SMB market I want to target.

-Paul


.

Relevant Pages

  • Re: COBOL Transactions?
    ... Subject: COBOL Transactions? ... transaction manager, to using a database for transaction managemen. ... of these suggestions would mostly likely work, but they add cost. ...
    (comp.os.vms)
  • RE: COBOL Transactions?
    ... Subject: COBOL Transactions? ... transaction manager, to using a database for transaction managemen. ... of these suggestions would mostly likely work, but they add cost. ...
    (comp.os.vms)
  • Re: COBOL Transactions?
    ... Most COBOL implementations provide a BEGIN TRANSACTION ... transaction manager, to using a database for transaction managemen. ... All of these suggestions would mostly likely work, but they add cost. ...
    (comp.os.vms)
  • RE: COBOL Transactions?
    ... Subject: COBOL Transactions? ... transaction manager, to using a database for transaction managemen. ... of these suggestions would mostly likely work, but they add cost. ...
    (comp.os.vms)
  • Re: Transactions and sub Procedures
    ... In a complex transaction, where many components are involved, like ... transaction manager that will commit or rollback each components ... If all the modifications occur in a single database, ... I'd like to include the sub procedures, ...
    (microsoft.public.access.formscoding)