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

Thanks
-Paul

Paul Raulerson wrote:[color=blue]
> 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.
>[/color]

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

Paul Raulerson wrote:[color=blue]
> 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
>
>[/color]

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.

Paul Raulerson wrote:[color=blue]
> 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
>
>[/color]

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.

On 08/22/07 17:02, Jan-Erik Söderholm wrote:[color=blue]
> Paul Raulerson wrote:[color=green]
>> 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
>>[/color]
>
> 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"...[/color]

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!

In article <46CC9FA4.7040403@comcast.net>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:[color=blue]
> Paul Raulerson wrote:[color=green]
>> 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.[/color][/color]
[color=blue]
> 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.[/color]

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.

Hi John,
[color=blue]
> 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.[/color]

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?)

[url]http://h71000.www7.hp.com/doc/82final/6393/6393pro_contents.html[/url]

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" <john.reagan@hp.com> wrote in message
news:fahuqe$toi$1@usenet01.boi.hp.com...[color=blue]
> Paul Raulerson wrote:[color=green]
> > 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[/color][/color]
all of which much be rolled back, which would normally be easily handled by
the above COBOL construct.[color=blue][color=green]
> >
> > Suggestions have ranged from using RMS Journaling, to the HP transaction[/color][/color]
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.[color=blue][color=green]
> >
> > Does anyone have a rough idea just how much cost the RMS or transaction[/color][/color]
manager solution adds to the end user on a small machine? Assuming I pass it
on to the end-user directly "at cost."[color=blue][color=green]
> >
> > Or if John R. is reading this - any plans to add transaction management[/color][/color]
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.[color=blue][color=green]
> >[/color]
>
> 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[/color]

[color=blue]
> -----Original Message-----
> From: Richard B. Gilbert [mailto:rgilbert88@comcast.net]
> Sent: Wednesday, August 22, 2007 3:42 PM
> To: [email]Info-VAX@Mvb.Saic.Com[/email]
> Subject: Re: COBOL Transactions?
>
> Paul Raulerson wrote:[color=green]
> > 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[/color]
> or all of which much be rolled back, which would normally be easily
> handled by the above COBOL construct.[color=green]
> >
> > Suggestions have ranged from using RMS Journaling, to the HP[/color]
> 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.[color=green]
> >
> > Does anyone have a rough idea just how much cost the RMS or[/color]
> transaction manager solution adds to the end user on a small machine?
> Assuming I pass it on to the end-user directly "at cost."[color=green]
> >
> > Or if John R. is reading this - any plans to add transaction[/color]
> 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.[color=green]
> >
> > I'm also open to "sneaky tricks" from the past on how to do this[/color]
> safely without the added expense. <grin>[color=green]
> >
> > Thanks
> > -Paul
> >
> >[/color]
>
> 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.[/color]

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

[color=blue]
> -----Original Message-----
> From: John Reagan [mailto:john.reagan@hp.com]
> Sent: Wednesday, August 22, 2007 1:19 PM
> To: [email]Info-VAX@Mvb.Saic.Com[/email]
> Subject: Re: COBOL Transactions?
>
> Paul Raulerson wrote:[color=green]
> > 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[/color]
> or all of which much be rolled back, which would normally be easily
> handled by the above COBOL construct.[color=green]
> >
> > Suggestions have ranged from using RMS Journaling, to the HP[/color]
> 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.[color=green]
> >
> > Does anyone have a rough idea just how much cost the RMS or[/color]
> transaction manager solution adds to the end user on a small machine?
> Assuming I pass it on to the end-user directly "at cost."[color=green]
> >
> > Or if John R. is reading this - any plans to add transaction[/color]
> 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.[color=green]
> >[/color]
>
> 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[/color]

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

-Paul

[color=blue]
> -----Original Message-----
> From: Jan-Erik Söderholm [mailto:jan-erik.soderholm@telia.com]
> Sent: Wednesday, August 22, 2007 5:03 PM
> To: [email]Info-VAX@Mvb.Saic.Com[/email]
> Subject: Re: COBOL Transactions?
>
> Paul Raulerson wrote:[color=green]
> > 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[/color]
> or all of which much be rolled back, which would normally be easily
> handled by the above COBOL construct.[color=green]
> >
> > Suggestions have ranged from using RMS Journaling, to the HP[/color]
> 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.[color=green]
> >
> > Does anyone have a rough idea just how much cost the RMS or[/color]
> transaction manager solution adds to the end user on a small machine?
> Assuming I pass it on to the end-user directly "at cost."[color=green]
> >
> > Or if John R. is reading this - any plans to add transaction[/color]
> 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.[color=green]
> >
> > I'm also open to "sneaky tricks" from the past on how to do this[/color]
> safely without the added expense. <grin>[color=green]
> >
> > Thanks
> > -Paul
> >
> >[/color]
>
> 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.[/color]

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

[color=blue][color=green]
> > 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"...[/color]
>
> 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[/color]

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

[color=blue]
> -----Original Message-----
> From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
> Sent: Wednesday, August 22, 2007 6:11 PM
> To: [email]Info-VAX@Mvb.Saic.Com[/email]
> Subject: Re: COBOL Transactions?
>
> Hi John,
>[color=green]
> > 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.[/color]
>
> 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?)
>[/color]

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

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

[color=blue]
> -----Original Message-----
> From: Jan-Erik Söderholm [mailto:jan-erik.soderholm@telia.com]
> Sent: Wednesday, August 22, 2007 5:03 PM
> To: [email]Info-VAX@Mvb.Saic.Com[/email]
> Subject: Re: COBOL Transactions?
>
> Paul Raulerson wrote:[color=green]
> > 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[/color]
> or all of which much be rolled back, which would normally be easily
> handled by the above COBOL construct.[color=green]
> >
> > Suggestions have ranged from using RMS Journaling, to the HP[/color]
> 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.[color=green]
> >
> > Does anyone have a rough idea just how much cost the RMS or[/color]
> transaction manager solution adds to the end user on a small machine?
> Assuming I pass it on to the end-user directly "at cost."[color=green]
> >
> > Or if John R. is reading this - any plans to add transaction[/color]
> 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.[color=green]
> >
> > I'm also open to "sneaky tricks" from the past on how to do this[/color]
> safely without the added expense. <grin>[color=green]
> >
> > Thanks
> > -Paul
> >
> >[/color]
>
> 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.[/color]

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 ([url]http://www.ingres.com[/url]). 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

In article <005301c7e51e$472eaf90$d58c0eb0$@com>, "Paul Raulerson" <paul@raulersons.com> writes:
[color=blue][color=green]
>> -----Original Message-----
>> From: John Reagan [mailto:john.reagan@hp.com]
>> Sent: Wednesday, August 22, 2007 1:19 PM[/color][/color]
[color=blue][color=green]
>> 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.[/color][/color]
[color=blue]
> Well, that will have to do. I am just hoping it does not add very
> significant cost to the
> delivered product. <grimace> Sometimes it seems like every dime added to
> the cost means
> 10 less sales. (*sigh*)[/color]

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.

[SNIP SNIP SNIP][color=blue]
> -----Original Message-----
> From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
> Sent: Wednesday, August 22, 2007 6:11 PM
> To: [email]Info-VAX@Mvb.Saic.Com[/email]
> Subject: Re: COBOL Transactions?
>[/color]
[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

In article <005a01c7e521$39dc7860$ad956920$@com>, "Paul Raulerson" <paul@raulersons.com> writes:
[color=blue]
> 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.[/color]

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

> -----Original Message-----[color=blue]
> From: Paul Raulerson [mailto:paul@raulersons.com]
> Sent: August 22, 2007 9:02 PM
> To: [email]Info-VAX@Mvb.Saic.Com[/email]
> Subject: RE: COBOL Transactions?
>
>
>[color=green]
> > -----Original Message-----
> > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
> > Sent: Wednesday, August 22, 2007 6:11 PM
> > To: [email]Info-VAX@Mvb.Saic.Com[/email]
> > Subject: Re: COBOL Transactions?
> >
> > Hi John,
> >[color=darkred]
> > > Yep, I'm reading this (as well as the ITRC discussion). No, we[/color][/color]
> don't[color=green][color=darkred]
> > > have any COMMIT like feature in our compilers. No current plans[/color][/color]
> for[color=green][color=darkred]
> > > adding them.[/color]
> >
> > If Paul is hell bent on using COBOL verbs for transactions, isn't[/color]
> there[color=green]
> > 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[/color]
> seem[color=green]
> > to be
> > the most popular DML with the usual crappy precompilers for most
> > languages.
> > (Does Orrible Oracle support the SQL Module language?)
> >[/color]
>
> 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*)
>[/color]

Paul,

You might be interested in the following ..

[url]http://www.migrationspecialties.com/Migration-RPG.html[/url]
[url]http://www.migrationspecialties.com[/url]

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.

On Aug 22, 6:41 pm, Kilgal...@SpamCop.net (Larry Kilgallen) wrote:[color=blue]
> In article <46CC9FA4.7040...@comcast.net>, "Richard B. Gilbert" <rgilber...@comcast.net> writes:[/color]
:[color=blue][color=green]
> > For further details, RTFM.[/color]
>
> 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.[/color]

Agreed.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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

Cheers,
Hein.

On 22 Aug, 18:53, "Paul Raulerson" <p...@raulersons.com> wrote:[color=blue]
> 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."[/color]


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

On 23 Aug, 04:03, "Paul Raulerson" <p...@raulersons.com> wrote:[color=blue]
> 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[/color]

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

Alex