On Tue, 10 Jan 2017 12:38:22 -0600, John Mckown
(john.archie.mck...@gmail.com) wrote about "Re: "task level" TIOT &
XTIOT? A crazy thought?" (in
<caajsdjjoucft7ticw+gkj1g2j_fgrqq7pl2ee+owrhdmtns...@mail.gmail.com>):

> On Tue, Jan 10, 2017 at 12:26 PM, David W Noon <
> 0000013a910fd252-dmarc-requ...@listserv.ua.edu> wrote:
[snip]
>> If you really are wedded to COBOL, ask for the language to offer a new
>> facility in the ENVIRONMENT DIVISION, like:
>>
>>              SELECT <fd-name> ASSIGN TO <ws-variable>
>>
>> where the <ws-variable> is something like:
>>
>>        77    WS-MY-DDNAME            PIC X(8).
>>
>> This can be the target of a text unit for SVC 99, or read from input, or
>> passed in from a calling main program.
> 
> ​Already taken, but not for WORKING STORAGE or the DD name​. It can refer
> to an existing DD name. If said DD does not exist, then it is the name of
> the "environment variable" (UNIX concept) which contains information to do
> an SVC 99. But the name remains the DD name, you can't override that,
> unfortunately.

That's why I said it would be a new facility in the language. The ASSIGN
TO clause has always used the DDNAME, frequently decorated with hardware
parameters. In recent years it can be the name of an environment
variable that contains the dynalloc text for SVC 99.

What I am saying is that allowing a program variable (WORKING-STORAGE or
LINKAGE SECTION, or even a field in a file record) would extend COBOL to
have most of the PL/I facilities of its TITLE() option or the C run-time
library's fopen() call.

>> This is far more straightforward than fiddling with multiple TIOT, SIOT,
>> DSAB, etc. This also avoids the filth known as environment variables.

I cannot stress the first sentence of the above paragraph too strongly.
Adding a language facility so tightly tied to z/OS torpedoes program
portability. It won't even work on z/VM, except in a z/OS guest.

> ​too late, as stated above. Personally, I don't find environment variables
> to be "filth". But I'm a long time UNIX user too.​

In a COBOL context, environment variables are total filth; the language
has never had the syntax or semantics to handle them and has never
needed them. I don't even like them that much when I am writing C/C++ or
Python on a UNIX platform.
-- 
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

Reply via email to