On Tue, 10 Jan 2017 20:18:04 +0000, David W Noon wrote:
>On Tue, 10 Jan 2017 13:06:14 -0600, Paul Gilmartin wrote:
>>>
>>> Simply use PL/I with the TITLE() option on the OPEN statement. ...
>>>
>>> If you really are wedded to COBOL, ask for the language to offer a new
>>> facility in the ENVIRONMENT DIVISION, ...
>>>
>> No. The facility should be transparent to the attached program (no
>> code changes). Charles isn't entitled to alter FTP to meet his needs.
>
>The existing code cannot deal with a single DDNAME being used for
>multiple, distinct datasets in the same address space. The existing code
>base handles its current working practices quite adequately, but new
>functionality typically cannot be implemented without code changes.
>
>So, saying "no code changes" is rather arbitrary.
>
New function requires new support. Changes would be needed at the
system layer such as ATTACH and OPEN; not at the application layer
such as Charles's example, FTP.
It's dreadfully wasteful for each application program that needs the facility
to duplicate the code to process the alternate DDNAME list.
>>> This is far more straightforward than fiddling with multiple TIOT, SIOT,
>>> DSAB, etc. This also avoids the filth known as environment variables.
>>>
>> Why do you call a potentially effective approach that doesn't match your
>> habits "filth".
>
>How do you know what my habits are?
>
OK, then, not habits. You make your biases disturbingly clear.
I suppose the recent U.S. political campaign established a new
standard of deportment.
>> But environment variables are merely an additional PARM ...
>
>I am very familiar with environment variables and have been for over 25
>years. That still doesn't mean I particularly like them, even in
>languages used more frequently than COBOL on POSIX platforms.
>
>When writing shell scripts, environment variables are inescapable as
>every shell variable is in the shell's environment. If all you write are
>shell scripts then everything looks like an environment variable.
>
There's a distinction at least in terminology. "Exported" variables are
called "environment variables"; ohers are simply called "shell variables".
The former are available in programs forked by the shell; the latter
are not.
>The PARM field is more akin to the argv[] strings fed into a C/C++ or
>Java program. At least COBOL allows for this to be handled in the
>LINKAGE SECTION of the DATA DIVISION. However, COBOL has not
>traditionally handled environment variables and has not really needed them.
>
You don't "really need" anything other than a Universal Turing Machine.
Higher level facilities make our jobs easier.
> ... Worse still, the environment
>variables are shared by all tasks in the address space, so we are back
>with the problem of dynamically providing a name to identify an
>allocated dataset. The upshot is that an environment variable of a given
>name (i.e. hard coded in the COBOL source) will be the same for all
>tasks in the address space, just like the DDNAME in the TIOT/SIOT.
>
No. spawn() with _BPX_SHAREAS=YES (an environment variable) can
support multiple processes, each with its own environment variables
and its own TCB in a single address space. This is z/OS-peculiar;
not customary over all UNIXes.
Look at the specification of execve():
int execve(const char *path, char *const argv[], char *const envp[]);
Simply, argv[] is a list of positional arguments; envp[] is a similar list of
keyword arguments. The caller has complete control of both.
>> DDNAMEs seem to have had the noble objective of isolating a program
>> from details of external data. In the context of concurrent processing,
>> DDNAMEs "missed it by this much!"
>
>*Hard coded* DDNAMEs missed it by this much.
> ...
>Now, would you recommend that [the above] be re-coded to use an
>environment variable for its DDN parameter, instead of using a program
>variable as an argument? This would mean that all calling tasks within
>the address space would use the same environment variable's contents to
>build the parameter for fopen(), which means that all tasks would use
>the same allocation of the same dataset.
>
You misunderstand the operation of _BPX_SHAREAS.
>As coded, each calling task can choose a DDNAME, possibly returned by
>SVC99, to have the same subroutine process different datasets for
>different tasks -- possibly concurrently.
>
And where would you get the arguments to pass to SVC99? And how
would you preserve one of the aboriginal design objectives of OS/360:
the ability to ENQ all needed resources before job initiation to avoid
deadlocks.
>I hope you now see why environment variables are not really a workable
>solution for multi-tasking address spaces.
>
Single address space jobs are an anachronism. They should have vanished
with the advent of Virtual Memory and DAT, but the legacy of OS/360
through MVT perpetuated them.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
