COBOL Transactions? - VMS

This is a discussion on COBOL Transactions? - VMS ; 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 ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 52

Thread: COBOL Transactions?

  1. COBOL Transactions?

    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.

    Thanks
    -Paul




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


    Yep, I'm reading this (as well as the ITRC discussion). No, we don't
    have any COMMIT like feature in our compilers. No current plans for
    adding them.

    The underlying RMS journalling and/or DDTM services are probably the
    best you are going to get. If we were to add some COMMIT feature to
    COBOL those are the services we'd use.

    --
    John Reagan
    OpenVMS Pascal/Macro-32/COBOL Project Leader
    Hewlett-Packard Company

  3. 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.
    >
    > Thanks
    > -Paul
    >
    >


    This sounds a hell of a lot like "two phase commit" which was added to
    RMS about 13 years ago as I recall. IIRC it writes the transaction
    details to a journal first, then updates the files and finally erases
    the journal entry or marks it "done" or some such.

    For further details, RTFM.


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

  5. Re: COBOL Transactions?

    On 08/22/07 17:02, Jan-Erik Söderholm wrote:
    > 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.
    >> 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"...


    But costs US$20K (I think) per CPU, I think, not including discounts.

    The question to ask John Reagan, I think, is if COBOL file semantics
    can work in harmony with low-level RMS/DTM 2PC API calls.

    --
    Ron Johnson, Jr.
    Jefferson LA USA

    Give a man a fish, and he eats for a day.
    Hit him with a fish, and he goes away for good!

  6. Re: COBOL Transactions?

    In article <46CC9FA4.7040403@comcast.net>, "Richard B. Gilbert" writes:
    > 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.


    > This sounds a hell of a lot like "two phase commit" which was added to
    > RMS about 13 years ago as I recall. IIRC it writes the transaction
    > details to a journal first, then updates the files and finally erases
    > the journal entry or marks it "done" or some such.
    >
    > For further details, RTFM.


    I do not believe this is a case of Read The Fine Manual. As I read
    the discussion the issues is than other Cobol implementations embed
    transaction handling in the language, while VMS Cobol does not.

    Likely this is something that would have to be done by User Open
    routines (I presume VMS Cobol has those) combined with explicit
    calls to RMS Journaling.

    It would be nicer if it were just a matter of compile-and-go, but
    I do not know to what extent the syntax shown above is in the Cobol
    standard.

    Of course John Reagan is quite experienced with implementing things
    before they make it into a standard, and has experience with what
    happens when the standard goes in a different direction, along with
    the standards committee politics that can force it in a different
    direction as a result of some vendors having implemented it one way.

  7. Re: COBOL Transactions?

    Hi John,

    > Yep, I'm reading this (as well as the ITRC discussion). No, we don't
    > have any COMMIT like feature in our compilers. No current plans for
    > adding them.


    If Paul is hell bent on using COBOL verbs for transactions, isn't there
    always DBMS? Oracle still support (and probably even sell it). If on the
    other hand, you/ve moved on to Relational Databases then SQL does seem to be
    the most popular DML with the usual crappy precompilers for most languages.
    (Does Orrible Oracle support the SQL Module language?)

    http://h71000.www7.hp.com/doc/82fina..._contents.html

    Still if you insist on being really cheap and pretend that you were in UNIX
    ISAM-land then you could use mySQL and forget that transactions ever
    existed. I mean, as if anything could go wrong between updates to two
    different tables hey? As if that's ever gonna happen :-( Yep ACID eh; what's
    it all about? Certainly those in HP that are now forcing the Waste of
    Substantial Investment in Technology down your throats don't give a Monkey's
    about it. But WS-AT was never really meant to accurately model the brave new
    world of the Net now was it? Yep Business Activity transactions (and trying
    stuff the genie back in the bottle) are right up UNIX's street!

    But too answer your question, you could: -

    1) Buy RMS jounalling (I agree it should've been bundled)
    2) Buy Rdb
    3) Buy Oracle

    Obviously 2 and 3 have their own transactions but with DECdtm you can
    encompass updates to all three data sources within the ACID properties of a
    true 2PC. And with hotTIP you can use Microsoft's MTS/DTC as the coordinator
    to steatch that 2PC transaction to Oracle or SQL Server on a Windows domain.
    Also, thanks in no small part to moi, the DECdtm Branch Management services
    are now documented with VMS and allow you to achive parallelism with
    different transactions branches in different processess and pssibly
    machines. (Rdb engineering (it's Mugabe-esque leadership anyway) thinks
    this is crap and has refused to update their Guide to Distributed
    Transactions)

    Yep, Microsoft think transactions are pretty important for some reason, and
    have spent a lot of money on their DECdtm-copy :-( While Digital said "Piss
    off Jim Johnson, Steve Lionel et al, we don't need your kind here with your
    silly transactions. Go to Microsoft and see what we care! We've forced a
    succession of failed products (Rally, DECForms, DECAdmire, ONC/RPC, DCE/RPC,
    COM, ACMSxp, BridgeBloodyWorks, Forte (and now it's WSIT and AXIS and Tomcat
    and making VMS quack like a penguin)) down the throats of our long-suffering
    VMS client base and yet somehow managed to keep our jobs! Yep, we're feeling
    pretty invulnerable at the moment, so bugger the lot of ya!

    Cheers Richard Maher

    "John Reagan" wrote in message
    news:fahuqe$toi$1@usenet01.boi.hp.com...
    > 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.
    > >

    >
    > Yep, I'm reading this (as well as the ITRC discussion). No, we don't
    > have any COMMIT like feature in our compilers. No current plans for
    > adding them.
    >
    > The underlying RMS journalling and/or DDTM services are probably the
    > best you are going to get. If we were to add some COMMIT feature to
    > COBOL those are the services we'd use.
    >
    > --
    > John Reagan
    > OpenVMS Pascal/Macro-32/COBOL Project Leader
    > Hewlett-Packard Company




  8. RE: COBOL Transactions?



    > -----Original Message-----
    > From: Richard B. Gilbert [mailto:rgilbert88@comcast.net]
    > Sent: Wednesday, August 22, 2007 3:42 PM
    > To: Info-VAX@Mvb.Saic.Com
    > 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.
    > >
    > > Thanks
    > > -Paul
    > >
    > >

    >
    > This sounds a hell of a lot like "two phase commit" which was added to
    > RMS about 13 years ago as I recall. IIRC it writes the transaction
    > details to a journal first, then updates the files and finally erases
    > the journal entry or marks it "done" or some such.
    >
    > For further details, RTFM.


    So new? No wonder it isn't in the compilers!
    -Paul



  9. RE: COBOL Transactions?



    > -----Original Message-----
    > From: John Reagan [mailto:john.reagan@hp.com]
    > Sent: Wednesday, August 22, 2007 1:19 PM
    > To: Info-VAX@Mvb.Saic.Com
    > 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.
    > >

    >
    > Yep, I'm reading this (as well as the ITRC discussion). No, we don't
    > have any COMMIT like feature in our compilers. No current plans for
    > adding them.
    >
    > The underlying RMS journalling and/or DDTM services are probably the
    > best you are going to get. If we were to add some COMMIT feature to
    > COBOL those are the services we'd use.
    >
    > --
    > John Reagan
    > OpenVMS Pascal/Macro-32/COBOL Project Leader
    > Hewlett-Packard Company


    Well, that will have to do. I am just hoping it does not add very
    significant cost to the
    delivered product. Sometimes it seems like every dime added to
    the cost means
    10 less sales. (*sigh*)

    -Paul




  10. RE: COBOL Transactions?



    > -----Original Message-----
    > From: Jan-Erik Söderholm [mailto:jan-erik.soderholm@telia.com]
    > Sent: Wednesday, August 22, 2007 5:03 PM
    > To: Info-VAX@Mvb.Saic.Com
    > 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.
    > >
    > > 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



  11. RE: COBOL Transactions?


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

    >
    > But costs US$20K (I think) per CPU, I think, not including discounts.
    >
    > The question to ask John Reagan, I think, is if COBOL file semantics
    > can work in harmony with low-level RMS/DTM 2PC API calls.
    >
    > --
    > Ron Johnson, Jr.
    > Jefferson LA USA


    Drat -which is of course why Hoff suggested mySQL. $20K/processor is just
    too much additional overhead
    for the majority of the market I want to target. I need to be able to
    deliver a low end solution in the
    under $10K market - and base the profit on annual support and customization
    costs.

    At the other end of the market by the way, the software is running on 50K
    user installations. Where they constantly scream at me to keep the processor
    cycles low and could I kindly keep the DASD usage as small
    as possible please? (*sigh*)

    You can't win!

    -Paul


  12. RE: COBOL Transactions?



    > -----Original Message-----
    > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > Sent: Wednesday, August 22, 2007 6:11 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >
    > Hi John,
    >
    > > Yep, I'm reading this (as well as the ITRC discussion). No, we don't
    > > have any COMMIT like feature in our compilers. No current plans for
    > > adding them.

    >
    > If Paul is hell bent on using COBOL verbs for transactions, isn't there
    > always DBMS? Oracle still support (and probably even sell it). If on
    > the
    > other hand, you/ve moved on to Relational Databases then SQL does seem
    > to be
    > the most popular DML with the usual crappy precompilers for most
    > languages.
    > (Does Orrible Oracle support the SQL Module language?)
    >


    I'm hell bent on porting 678,000+ lines of code from a mainframe and/or
    AS/400 environment to VMS. That SLOC count seems to keep growing as I busy
    myself porting away at it. The small parts in Assembler and RPG I have not
    even tried to address yet. They pretty obviously won't port. (*sigh*)

    It was startling to not find transaction support built into the language
    under VMS, yes. Sort of like walking into a house you want to buy and
    finding they forgot to include a bathroom. Very much so given the overall
    very high quality of the compiler in question. (And there is no doubt about
    it, it *is* a high quality compiler.)

    I admit to having IBM COBOL tunnel vision sometimes; IBM COBOL is just so
    darn convenient, unless of course, you need to directly twiddle bits around.
    Then just give up and drop into assembler to do it!

    Not being bundled is understandable though; I assume the RMS Dectm stuff is
    owned by another department than the compiler department. Just odd when
    viewed through COBOL tinted lenses is all.


    I tend to agree with a lot of your other comments, snipped for brevity in
    this particular reply.

    -Paul


  13. Re: COBOL Transactions?


    "Paul Raulerson" wrote in message
    news:005801c7e51f$06a4d0c0$13ee7240$@com...


    > -----Original Message-----
    > From: Jan-Erik Söderholm [mailto:jan-erik.soderholm@telia.com]
    > Sent: Wednesday, August 22, 2007 5:03 PM
    > To: Info-VAX@Mvb.Saic.Com
    > 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.
    > >
    > > 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. We use it with C, but there is a precompiler for COBOL.

    You might also want to look at Ingres (http://www.ingres.com). It should
    work out cheaper than Oracle or Rdb. You can download a copy from that
    site.

    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



  14. RE: COBOL Transactions?

    In article <005301c7e51e$472eaf90$d58c0eb0$@com>, "Paul Raulerson" writes:

    >> -----Original Message-----
    >> From: John Reagan [mailto:john.reagan@hp.com]
    >> Sent: Wednesday, August 22, 2007 1:19 PM


    >> The underlying RMS journalling and/or DDTM services are probably the
    >> best you are going to get. If we were to add some COMMIT feature to
    >> COBOL those are the services we'd use.


    > Well, that will have to do. I am just hoping it does not add very
    > significant cost to the
    > delivered product. Sometimes it seems like every dime added to
    > the cost means
    > 10 less sales. (*sigh*)


    If I were the one making the third party business decision, I would
    have the code work either with or without RMS Journaling and tell
    the customers they can decide what level of reliability they want.

  15. RE: COBOL Transactions?


    [SNIP SNIP SNIP]
    > -----Original Message-----
    > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > Sent: Wednesday, August 22, 2007 6:11 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: COBOL Transactions?
    >

    [SNIP]

    Hey Richard, do you have a pointer to how to turn this DDTM *on*?
    I have found:
    DDTM$XA_SHUTDOWN.COM;1 DDTM$XA_STARTUP.COM;1
    DDTM$XG_START_SERVER.COM;1 DECDTM$SHUTDOWN.COM;1
    DECDTM$STARTUP.COM;1

    and ran the DECDTM$STARTUP.com script, which seems to have succeeded. Also
    ran the DDTM$XG_START_SERVER.com
    script, and they *seem* to be running.

    Marked a test file with SET FILE/RU_JOURNAL and it seems to report itself
    correctly.

    Constantly get back a failure code, 933B.

    Ran the example script, created the files and still get the same error code.
    I do not know if it is a license thing or not. Show license finds the
    following lines, so I think it is licensed.

    DTM DEC 0 0 100 0.0 (none)
    31-JUL-2008
    RMSJNL DEC 0 0 100 0.0 (none)
    31-JUL-2008

    I cannot find any startup files or stuff with *RMS* in the name to run or
    whatever.

    I did scan through the manuals I could find, and the RMS Journal manual was
    clear that DECdtm has to be
    running first, but ... not really working. Advice? Pointers? Thanks -Paul



  16. RE: COBOL Transactions?

    In article <005a01c7e521$39dc7860$ad956920$@com>, "Paul Raulerson" writes:

    > Not being bundled is understandable though; I assume the RMS Dectm stuff is
    > owned by another department than the compiler department. Just odd when
    > viewed through COBOL tinted lenses is all.


    Actually, RMS journaling has always been owned by the operating system
    group. But it is separately licensed since it is a lot of extra work
    to develop it and they want to have it paid for by the customers who
    need that level of reliability, rather than raising the base VMS price
    for those who don't care.

    In recent memory there was an add-on product (POSIX) that was "free".
    When the time came to trim costs, they could not find out who was
    using it (if anyone) and it was dumped for future versions of VMS
    (although some features are now included in the C Runtime Library).

  17. RE: COBOL Transactions?

    > -----Original Message-----
    > From: Paul Raulerson [mailtoaul@raulersons.com]
    > Sent: August 22, 2007 9:02 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: RE: COBOL Transactions?
    >
    >
    >
    > > -----Original Message-----
    > > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
    > > Sent: Wednesday, August 22, 2007 6:11 PM
    > > To: Info-VAX@Mvb.Saic.Com
    > > Subject: Re: COBOL Transactions?
    > >
    > > Hi John,
    > >
    > > > Yep, I'm reading this (as well as the ITRC discussion). No, we

    > don't
    > > > have any COMMIT like feature in our compilers. No current plans

    > for
    > > > adding them.

    > >
    > > If Paul is hell bent on using COBOL verbs for transactions, isn't

    > there
    > > always DBMS? Oracle still support (and probably even sell it). If on
    > > the
    > > other hand, you/ve moved on to Relational Databases then SQL does

    > seem
    > > to be
    > > the most popular DML with the usual crappy precompilers for most
    > > languages.
    > > (Does Orrible Oracle support the SQL Module language?)
    > >

    >
    > I'm hell bent on porting 678,000+ lines of code from a mainframe and/or
    > AS/400 environment to VMS. That SLOC count seems to keep growing as I
    > busy
    > myself porting away at it. The small parts in Assembler and RPG I have
    > not
    > even tried to address yet. They pretty obviously won't port. (*sigh*)
    >


    Paul,

    You might be interested in the following ..

    http://www.migrationspecialties.com/Migration-RPG.html
    http://www.migrationspecialties.com

    Bruce Claremont (site owner) is a good porting resource that may be able toassist you.

    Bruce has good Mainframe to OpenVMS porting experience.

    [snip]

    Regards


    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.




  18. Re: COBOL Transactions?

    On Aug 22, 6:41 pm, Kilgal...@SpamCop.net (Larry Kilgallen) wrote:
    > In article <46CC9FA4.7040...@comcast.net>, "Richard B. Gilbert" writes:

    :
    > > For further details, RTFM.

    >
    > I do not believe this is a case of Read The Fine Manual. As I read
    > the discussion the issues is than other Cobol implementations embed
    > transaction handling in the language, while VMS Cobol does not.


    Agreed.

    > Likely this is something that would have to be done by User Open
    > routines (I presume VMS Cobol has those) combined with explicit
    > calls to RMS Journaling.


    Disagree. RU Journalling specifically spans mutliple file. Single file
    is sort of easy to do. A useropen does not cut it. One needs a larger
    'context' know to all files partitipating. RMS RU Journaling offers
    that in cooperation with the system service [$start/$end/$abort]_trans
    and file attributes to indicate which file participates or not.

    > It would be nicer if it were just a matter of compile-and-go, but
    > I do not know to what extent the syntax shown above is in the Cobol
    > standard.


    It almost is. But there are implementation details, notably record
    lock being held until transaction end.

    Cheers,
    Hein.


  19. Re: COBOL Transactions?

    On 22 Aug, 18:53, "Paul Raulerson" wrote:
    > 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."



    RMS Journaling is included in the NET-APP-SUP-400 license bundle on
    Alpha, this came with or was an option with some Alphas.

    On Itanium, it's included in the EOE (Enterprise) and MCOE (Mission
    Critical) operating enviornments. With the real entry level FOE
    (Foundation) operating environment it can be added on it's own as an
    extra, on I64 I do not believe the RMSJNL license would be a big cost.

    Alex


  20. Re: COBOL Transactions?

    On 23 Aug, 04:03, "Paul Raulerson" wrote:
    > and ran the DECDTM$STARTUP.com script, which seems to have succeeded. Also
    > ran the DDTM$XG_START_SERVER.com
    > script, and they *seem* to be running.
    >
    > Marked a test file with SET FILE/RU_JOURNAL and it seems to report itself
    > correctly.
    >
    > Constantly get back a failure code, 933B.
    >
    > Ran the example script, created the files and still get the same error code.
    > I do not know if it is a license thing or not. Show license finds the
    > following lines, so I think it is licensed.
    >
    > DTM DEC 0 0 100 0.0 (none)
    > 31-JUL-2008
    > RMSJNL DEC 0 0 100 0.0 (none)
    > 31-JUL-2008
    >
    > I cannot find any startup files or stuff with *RMS* in the name to run or
    > whatever.
    >
    > I did scan through the manuals I could find, and the RMS Journal manual was
    > clear that DECdtm has to be
    > running first, but ... not really working. Advice? Pointers? Thanks -Paul


    You might not have a log file, "$mc lmcp help create_log *"

    Alex


+ Reply to Thread
Page 1 of 3 1 2 3 LastLast