Home > Archive > Cobol > June 2004 > IBM (mainframe) and dynamic / static CALLs
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
IBM (mainframe) and dynamic / static CALLs
|
|
| William M. Klein 2004-06-15, 8:55 pm |
| Just because there may be some confusion - from another thread, the following is
true for IBM mainframes (slight variations exist for VSE and VM - so this is
*most* accurate for MVS, OS/390, and z/OS) *and* COBOL (other languages and
products may include additional variations)
1) The older (no longer available in current compilers) RES/NORES compiler
option determined whether internal calls to IBM supplied "run-time routines"
were resolved at link-edit or run-time. (Current compilers require that almost
all IBM supplied run-time support be accessed at run-time)
2) There are internal differences between the (more recent) BINDER and the
Linkage-Editor, but these *normally* have little or no impact on COBOL
programmers.
3) When the NODYNAM compiler option is specified,
CALL "literal" statements are resolved at linkage/binding time
CALL identifier statements are resolved at run-time
4) When the DYNAM compiler option is specified, all CALL statements are resolved
at run-time
5) The NCAL linkage editor statement can cause "normally" link-edit resolution
to be "skipped". Although this used to be used "medium-often" - its use (as far
as I know) has diminished in recent years. There may be other
Binder/Linkage-Editor control statements that can impact all of what I am saying
in this note.
6) IBM *clearly* documents that compiling with the NODYNAM compiler option
results in semantics that are NOT ANSI/ISO (any variation) conforming. This is
PRIMARILY due to the fact that CANCEL statements are ignored. OTOH, NODYNAM is
required for some IBM products such as CICS.
***
To the extent that these generalizations apply to other environments (IBM or
otherwise) depends entirely on the Operating System facilities, the compiler,
and the run-times.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Chuck Stevens 2004-06-16, 3:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:_4Izc.1443$w07.1184@newsread2.news.pas.earthlink.net...
> 6) IBM *clearly* documents that compiling with the NODYNAM compiler option
> results in semantics that are NOT ANSI/ISO (any variation) conforming.
This is
> PRIMARILY due to the fact that CANCEL statements are ignored.
That confirms my suspicion that IBM's NODYNAM functionality uses ANSI
standard IPC *syntax* to accomplish pretty much the same thing that Unisys
MCP does with USE EXTERNAL and CALL <section-name>. Just as CANCEL
<section-name> makes no sense, so does CANCEL <program-name> in a NODYNAM
environment. Neither combination reflects *standard* COBOL; I would argue
that Unisys' approach of using separate syntax is a clearer way to handle
the non-ANSI functionality.
Not that I'm really in a position to cast stones at IBM on this score;
Unisys has its own share of "overloaded syntax" in the ANSI IPC arena,
stemming from the decision some decades back to implement ANSI-74 IPC as a
proper subset of the then-new user runtime library (as distinct from user
runtime intrinsic function) mechanism on the Burroughs Large System. A
calling program may *never* know, or be able to find out, whether it's
operating within the strict confines of ANSI IPC functionality or not; the
only context in which the compiler *might* be able to find out is in the
semantics of the contents of the alphanumeric literal, and at Unisys we try
to avoid second-guessing the programmer as to the validity of those literals
(though sometimes we have no choice in the matter).
-Chuck Stevens
|
|
|
|
|