On Mon, 31 Aug 2020 13:52:24 -0400, Dennis Lee Bieber wrote:

> I'm pretty certain the COBOL-74 standard provided for external modules
> to be linked -- my Xerox Sigma-6 manual is in storage so I can't confirm
>
I wrote COBOL on ICL mainframes and the 2903 office computer from about
1969 until 1977, on ICL2966/ VME/B systems 1978-1984 and a bit of deviant
Tandem NonStop S-COBOL in the '90s.

You're right about statically linked subroutines, though before around
1774 I remember calling statically linked PLAN assembler subroutines but
IIRC COBOL subroutines were not supported and there was certainly no
support for using a variable to hold the subroutine name, even if the
subroutines were all statically linked. I don't thing that was in the
CODASYL standard either, but I could be wrong about that because all my
COBOL up to then was written on ICL 1900s.

I don't recall any ability to call before 1973 in 1976/77 on the 2903 (it
ran unmodified 1900 machine code and compilers) I needed the ability to
select and run a COBOL subroutine depending on the screen image an
accounting system was required to display, i.e. I could statically link a
collection of subroutines, all using the same interface, with the main
program but the subroutine name had to be a variable. At that time the
1900 compiler would only let the subroutine name be a constant, so I had
to write the small (100 instructions or so) main loop in PLAN3 assembler
and everything else (file access, screen-specific code) was written as
COBOL subroutines.

By the time 1979 rolled round and I was still writing COBOL, but this
time on an ICL 2966 running under VME/B, that COBOL dialect did support
subroutine calls with the subroutine name in a variable, so I was able to
write a similar call structure in 100% COBOL - just as well since there
was no official assembler and the S3 system programming language was not
available to application authors.

>
>  Strangely, while I'm sure my course introduced linking separately
> compiled COBOL modules, we were NOT introduced to "COPY" statements.
>
IIRC the various mainframe dialects differed: an ICL or Burroughs COBOL
program was inlikely to compile on IBM iron without chenges and vice
versa.

> Though that is a minor problem -- since it returns the current
> date, it at least was easy to detect century wrap-around and preface
> with the correct 19 or 20.
>
Depends in the application: what you suggest works fine for the date on a
report or at the top of a screen, but becomes a problem in other cases -
I remember seeing a payroll back in the late '60s (6 digit date days)
that *HAD* to handle birth dates in the 1890s. Not altogether easy on a
system whose base date was 1/1/1900 !

My real argument with the 6 digit date is that its universal use in COBOL
meant that analysts and designers tended to forget that the century is
sometimes important - as it was during, say producing a statement for
for transactions made during December 1999 but processed and printed in
Jan 2000.

In other cases it was no problem at all: one of the more 'interesting'
systems I designed had, amongst other things, to deal with dates from 55
BC onward and with varying degrees of accuracy ranging from '14th
century' through 'Flourished 1750-1780' and 'FY91/92' to  31/18/2020.

> Not so simple is the case of data records that could span a range
> where "windowing" was not feasible.
>
Indeed, and these were almost certainly the hardest to track down and fix.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05