For whatever its worth, the latest COBOL Standard offers the following syntax, which I believe meets this requirement at the language level:
SELECT file-name-1 ASSIGN USING data-name-1. "3) The ASSIGN clause specifies the association of the file connector referenced by file-name-1 to a physical file identified by device-name-1, literal-1, or the content of the data item referenced by data-name-1. 3b) When the USING phrase of the ASSIGN clause is specified, the file connector referenced by file-name-1 is associated with a physical file identified by the content of the data item referenced by data-name-1 in the runtime element that executes the OPEN, SORT, or MERGE statement." Someone want to open an RFE? Frank ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of David W Noon <[email protected]> Sent: Tuesday, January 10, 2017 1:18 PM To: [email protected] Subject: Re: "task level" TIOT & XTIOT? A crazy thought? On Tue, 10 Jan 2017 13:06:14 -0600, Paul Gilmartin ([email protected]) wrote about "Re: "task level" TIOT & XTIOT? A crazy thought?" (in <[email protected]>): [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] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* [email protected] (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
