[Info-vax] CRTL and RMS vs SSIO

[Arne Vajhøj]

On 10/16/2021 10:33 AM, Bill Gunshannon wrote:
> On 10/16/21 10:25 AM, Arne Vajhøj wrote:
>> VMS Fortran and Cobol has a lot of VMS specific language extensions.
> 
> As a very strong advocate of the continued use of COBOL (I fought
> to keep it in academia just as hard as I fought to keep VMS there!)
> I find this interesting.  Does anyone have a relatively large VMS
> COBOL program that has these extensions in it that they can and
> would be willing to share?  I would love to take a look at just
> how hard it would be to get it to compile under the current COBOL
> standard.

Well - I don't code in Cobol and I don't have any real work Cobol code.

There are actually two issues to consider:
- language extensions
- external stuff

Re language extensions then a quick scan of the reference manual finds:
* special registers with RMS stuff
* PROGRAM-ID ... WITH IDENT ...
* some stuff in FILE CONTROL SELECT ASSIGN
* RECORD DELIMITER
* POINTER-64 and BINARY-* UNSIGNED data types
* CALL ... BY DESCRIPTOR
* ARGCOUNT builtin
* a ton of CDD stuff
* something called "Hierarchical Repository" that I don't
   know what is

(note that there may be more when comparing with standard Cobol - the
above is what is in VMS Cobol compared to Tru64 Cobol)

But then there is the external stuff:
* opening files with filenames in VMS filename syntax
* calling LIB$ and SYS$ routines
* relying on Rdb (Rdb specific SQL or SQL module
   or just having an embedded SQL precompiler)
* use of Macro-32 stuff

I don't know how much this stuff is used in real world
VMS Cobol programs.

Given that when a VMS Cobol program was started back in
the 80's or 90's then:
* most likely nobody was thinking about moving off VMS in the future
* portability was not a big concern in general
* it was "Cobol programmers" not "VMS programmers"
* Cobol had the features needed for what Cobol was used for
* if some code was to do a lot of VMS calls (LIB$, SYS$ etc.) then
   it would likely be written in another language than Cobol
then my expectation are that:
* very few VMS Cobol programs will just compile on let us say
   GNU Cobol with zero changes
* many VMS Cobol programs could be ported to GNU Cobol with
   trivial effort

But I could be wrong!

Arne