Re: COBOL and RPG was Welcome new members -- COBOL400-L

Yup, thats why they had such a great deal of difficulty when TPTB decided to 
switch
to 38s, glad I was not there! Over the years prior to my arrival, there were 
many
such useful additions in the drawer and when they switched from the 5k to the 6k
they were implementd.

I agree that it is not the best way to go about things, it confuses the 
bejebers out
of new folks trying to make sense out of things but, IBM has almost always 
allowed
for customer extensions (but perhaps not to that extent, and not in the 
complers),
heck all it takes is a few minutes with one of the older 360 COBOL manuals to
discover all the little grey boxes marked "IBM Extension"! Granted these 
were/are
allowable extensions under ANSI and eventually found thier way into the 
mainstream.
To bad about the Database extensions that never did make it, and I actually 
liked
Report Writer. I am seriously pleased that some things are either gone or so 
far out
of faver that they are scarce, like ALTER.

The MCP compile listing made great reading material until one rather attracive
employee became seriously offended! :-)

Jon.Paris@halinfo.it wrote:

> Oh OK - one last comment or three <grin>
>
>  >> Ok so its not a call, it looketh like a function nevertheless we are only
> limited by what the vendor allows, not by the language itself.
>
> I see your point but surely one of the benefits of a language like COBOL is 
>that
> it conforms to standards.  Heck you've quoted them in your notes.  ANSI does 
>not
> support this kind of extension and over the years IBM's internal COBOL 
>standards
> group have adhered fairly strongly to the standard. Only someone who has never
> tried to get a new function into the COBOL compiler would think that it was 
>easy
> to get permission to add non-standard function <grin> I still carry many scars
> from those battles. Most extensions that IBM have made, are in ANSI permitted
> areas or to deal with platform specific issues.
>
> You can get a notion of how difficult it can be to add function when you
> consider that when intrinsic were introduce ANSI forced the use of the keyword
> FUNCTION in front of them in order to ensure that that compilers could parse
> them correctly.  Your example by the way mentions COMPUTE which I didn't think
> entered the standard until 74 - but I may be mismembering.
>
> Even if this were added to COBOL on the 400 (and it is under consideration) it
> only addresses function invocation, not prototyping which is very valuable 
>even
> for program calls. Since OS/400 provides no inherent support for parameter
> checking, compiler support is very useful. Now that COBOL has implemented
> typedefs (and before you say it - yes it would be great to have that in RPG)
> there is hope that prototyping can be piggybacked on that.
>
> Ah MCP that takes me back - you must have worked on the version _before_
> political correctness forced them to clean up the names of some of the 
>routines.
> <VBG>
>
> +---
> | This is the COBOL/400 Mailing List!
> | To submit a new message, send your mail to COBOL400-L@midrange.com.
> | To subscribe to this list send email to COBOL400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to COBOL400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---END

+---
| This is the COBOL/400 Mailing List!
| To submit a new message, send your mail to COBOL400-L@midrange.com.
| To subscribe to this list send email to COBOL400-L-SUB@midrange.com.
| To unsubscribe from this list send email to COBOL400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---END