You can’t code arbirtraty names but a common convention is to look for a key in 
a file and use the value as a filename.  Its a similar approach to DDNAMES as 
it uses an intermediary, just not as well defined for all users.  

Matt Hogstrom
PGP key 0F143BC1

> On Jan 7, 2022, at 13:37, Charles Mills <[email protected]> wrote:
> 
> FWIW yes, I go back to 
> 
> A little bit of CP/67 and OS/360 on a 360/67 in 1967 
> Hardcore DOS/360 on 360/40s and /50s starting in 1968 (My first paid
> software job.)
> Hardcore OS/360 starting around 1972 or so. No SVC 99!
> 
> And I disagree. Variables and file handles are not the same as DD names at
> all. I can hard-code a z/OS program to copy 'MYFILE1' to 'MYFILE2'. It can
> then copy any dataset to any other dataset (with many limitations, but you
> get the idea).
> 
> There is no directly equivalent function in Windows or Linux. I cannot code
> arbitrary internal names (in variables or otherwise) and then map them to
> real external names at run time. (AFAIK -- correct me if I am wrong. Yes,
> stdin and stdout come close.)
> 
> Charles
> 
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Seymour J Metz
> Sent: Friday, January 7, 2022 9:52 AM
> To: [email protected]
> Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS
> 
> I would say that what substitues for ddnames is variables and file handles.
> 
> You go back to OS/360?
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> ________________________________________
> From: IBM Mainframe Discussion List [[email protected]] on behalf of
> Charles Mills [[email protected]]
> Sent: Friday, January 7, 2022 10:16 AM
> To: [email protected]
> Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS
> 
> A file handle is basically a DCB, or rather, a pointer to a DCB. The thing
> it points to is a black box, so there are no compatibility issues comparable
> to the 24-bit addresses in DCBs.
> 
> What "substitutes" for DD name indirection in many or most non-mainframe
> systems is that "dynamic allocation" is standard. I remember the days before
> SVC 99. It was something of a hack job to write a program that decided on a
> dataset name during execution. OTOH for most non-mainframe operating systems
> the standard way to specify a file at open time is by external file name. If
> you are going to prompt the user for a file name during execution (as most
> interactive programs do) then file name indirection would be
> counterproductive.
> 
> Charles
> 
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Bob Bridges
> Sent: Friday, January 7, 2022 6:47 AM
> To: [email protected]
> Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS
> 
> Took me an embarrassingly long time to notice that what I thought was silly
> in some of the non-mainframe programming languages I'd encountered, the
> feature called a "file handle", allowed programs in those languages the same
> flexibility that DD names give in JCL.
> 
> ---
> Bob Bridges, [email protected], cell 336 382-7313
> 
> /* Democracy is the recurrent suspicion that more than half of the people
> are right more than half of the time.  -E B White */
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
> Tom Brennan
> Sent: Friday, January 7, 2022 00:13
> 
> Maybe a bigger issue is with non-mainframe folks wondering why JCL is there
> in the first place.  I started with microcomputers, programming things in
> BASIC where we were told to hard-code full filenames in the program itself.
> Already I could see how silly that would be in production, having to change
> the source code just to work with different files.  Unix solved that in
> clever ways with parameter passing, stdin, and things like that which work
> well in shell scripts.  Mainframes solved it with 8 character DD names and
> JCL redirection.
> 
> ----------------------------------------------------------------------
> 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
> 
> ----------------------------------------------------------------------
> 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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to