On Tue, 10 Jan 2017 13:06:14 -0600, Paul Gilmartin
(0000000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: "task
level" TIOT & XTIOT? A crazy thought?" (in
<2517422968801667.wa.paulgboulderaim....@listserv.ua.edu>):
[snip]
> On Tue, 10 Jan 2017 18:26:27 +0000, David W Noon 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.
>> 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?
> But environment variables are merely an additional PARM
> (see the specification of the exec() syscall) and no more transparent than
> the alternate DDNAME list (filth?) as a second 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.
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.
I view adding environment variables to COBOL as being like putting
high-octane gasoline into a diesel engine -- it might sound "way kewl"
but the results will not be pretty. 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.
> 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.
The functionally richer programming languages (PL/I, assembler) have
always allowed a program to specify the DDNAME field of a DCB or ACB at
run time. This has allowed a DDNAME to be fed in from various sources at
run time.
The missing capability here is with the COBOL language, and the
extension I recommended would be a simple and effective way of adding
it, while adhering to existing coding culture in COBOL.
Since you have written in the past that you don't write assembler, I
shall infer that you don't write PL/I either. So I will offer some
sample code in C, in the hope that your love of POSIX platforms has made
you familiar with that language.
#include <string.h>
#include <stdio.h>
void read_some_text(const char * DDN, char ** text_buffer)
{
char dd_string[16];
strcpy(dd_string, "DDNAME:");
strncat(dd_string, DDN, 8): /* DD names are at most 8 bytes. */
FILE * input_file = fopen(dd_string,"rt");
/* Process file. */
. . .
fclose(input_file);
return;
}
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.
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.
I hope you now see why environment variables are not really a workable
solution for multi-tasking address spaces.
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
