HP3000-L Archives

January 2003, Week 2

HP3000-L@RAVEN.UTC.EDU
Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
Re: Protos, COBOL and runtimes
From:
Roy Brown <[log in to unmask]>
Reply To:
Roy Brown <[log in to unmask]>
Date:
Tue, 14 Jan 2003 15:15:08 -0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (59 lines) 
---- Original Message ----
From: "Jerry Finn" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, January 14, 2003 8:58 AM
Subject: [HP3000-L] Protos, COBOL and runtimes

> Can any one fill me in on how Protos works.

> I have a customer with some Protos generated COBOL,
> and I thought Protos was just a 4GL COBOL language
> generator.

It can be....

> The catch would be, is the generated COBOL then
> dependent on a Protos runtime, or linking to a
> Protos XL library, etc.?

Yes, but only if they used those (admittedly rather tempting) PROTOS library
calls to make it all easier.

AFAIR, if you don't explicitly use any PROTOS calls in your source, you will
get COBOL that is independent of PROTOS - it's not as if PROTOS 'wilfully'
uses its own private Image calls, or anything like that.  But PROTOS does
ensure that if you use its XL, then you are licensed for PROTOS at runtime.

> They'd like to migrate to MF COBOL but it's going
> to be a lot less straightforward if the generated
> COBOL is still dependent on other Protos runtime
> programs.


In the case I was involved with, the sticking point was the cost of PROTOS on
a larger HP3000, for a company which had a range of batch programs in PROTOS.
(Being batch, this was much more straightforward than converting interactive
programs might be, if the PROTOS calls had been used for that).

But in this case, it was a matter of identifying the use of PROTOS library
calls in the source, and providing non-PROTOS COBOL equivalents. After that,
we obtained the generated COBOL, and went through that, identifying and
eliminating any residual PROTOS calls that remained.

As what you've got is straight COBOL, there's nowhere that PROTOS could hide
any gotchas, even if it wanted to.

The net effect is that PROTOS, instead of saving you from ever having to write
explicit COBOL for all the stuff in its libraries, just defers the agony until
you want to move off it. That's where you are now :-)


--
Roy Brown

Posting with the OEnemy, tamed by OE-QuoteFix 1.17.6
http://jump.to/oe-quotefix

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2