NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/unix/question/12965

Internet Message Format | 1992-11-06 | 4.2 KB

Xref: sparky comp.unix.questions:12965 alt.cobol:528 alt.folklore.computers:15854 alt.religion.computers:845 comp.lang.pascal:6358
Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!purdue!news.cs.indiana.edu!umn.edu!mmm.serc.3m.com!mmc.mmmg.com!timbuk.cray.com!shamash!jitze
From: [e-mail] (Jitze Couperus)
Newsgroups: comp.unix.questions,alt.cobol,alt.folklore.computers,alt.religion.computers,comp.lang.pascal
Subject: Re: net.views - mainframe programmers in an open systems world
Message-ID: <[e-mail]>
Date: 5 Nov 92 18:41:39 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Followup-To: comp.unix.questions
Lines: 75

[e-mail] (Don Nelson) writes:

>In article <[e-mail]> Mitch Wagner,
>[e-mail] writes:
>>
>>           Is it possible to put the skills of mainframe programmers
>>           to use in open environments? If so, how?
>>
>>
>I'm having a little trouble understanding the question.  Perhaps you
>could explain in 25 words or less why mainframe programmers differ from
>programmers in "the open world" (which is definitely not as open as some
>people think).  Most mainframe programmers work on business applications

What Don wrote is true - Cobol is essentially Cobol - no
matter whether you are on a proprietary or an "open" system.

HOWEVER - no Cobol environment is an island, and one can come
to grief due to the lack of "integration" of Cobol with its
surrounding artifacts on an "open" system because the compiler
comes from a different vendor than the ISAM engine, or the
DBMS engine, or the Screen Handling engine, the operating
system itself, the symbolic debugger,. etc etc. -

By contrast, on a "proprietary" platform there is
a better chance that somebody has ensured that all these things
work together without violating the law of least astonishment.

For example - years ago the industry discovered the benefits
of separating screen definitions from the body of the
application's code (much like separating the DDL for a database
from the DML). This is still rarely provided by the "open"
Cobol compilers, so users frequently resort to separate screen
design/handling packages (e.g. JAM from JYACC) to avoid
entangling such stuff inside the application's code itself.

And now you want to use a symbolic debugger with your program
that has embedded calls to C code that the debugger can't
handle, - not only that, the debugger thinks he is the sole
user of the "screen", but your run-time screen package is also
driving the screen, and (assuming you got this far) they
proceed to klobber each other.

Same sort of problems when (for example) embedded SQL
statements have been expanded to CALL's to C code

Even if you are using the "standard" Cobol verbs to drive
an ISAM file, it may turn out that all the other goodies
one might expect with an "integrated" ISAM solution can't
be had, because the ISAM engine came from yet another vendor.
For example, the Cobol interface to the ISAM package used
a different set of features or in a different way than did
the Fortran compiler, so you can't exchange ISAM files
between Cobol and Fortran applications.

And then there is the ability to not only handle tapes
on-line (connected directly to the SELECT...ASSIGN) but
to be able to depend on ANSI tape labels to ensure your
program is reading or writing the correct physical tape
rather than relying on a Monte Carlo distribution of the data...

Enuff said - yes Cobol is Cobol is Cobol, but as long as it
has to interface to an environment made of a collection
of artifacts from different "open" sources, there remains
the danger that the degree of integration with that environment
won't be as good as that of a single-vendor proprietary offering.

Things are improving, at least one vendor of an "open" Cobol
compiler looks like they may soon be releasing a screen design
and handling package that does "the right thing" which presumably
will work seemlessly with their full-screen symbolic debugger,
and I'm sure we can look forward to other improvements.
--
Jitze Couperus          Control Data - Silicon Valley Operations
[e-mail]       Voice [phone]  FAX [phone]