> -----Original Message----- > From: Linux on 390 Port [mailto:[email protected]] On > Behalf Of Mike Noel > Sent: Tuesday, August 07, 2012 8:43 PM > To: [email protected] > Subject: porting kicks > > I'm in the initial stage of porting my TSO/CMS program (KICKS, see > kicksfortso.com) to linux, including zlinux. KICKS is mostly GCC code, > though not open source. Several people have recommended I post to this > list for some of my questions. So I've subscribed, and looked at some > past posts, and am ready to see if you can help me! > (1) first, does my quest seem appropriate for this list? and if so, my > first question: > (2) TSO & CMS provide a separation between the name of a file > internally (ddname) and the external name of the file (dsname), with > some kind of control card (DD, ALLOC, FILEDEF, etc) to be provided at > run time to connect the two. I'm considering ways to do this in a > linux environment and am presently thinking about using environment > statements. So for example if there was a user file MYFILE in the > KICKS fct, it would be matched to an external file > /home/myuser/myfile.vsam by an environment statement like > MYFILE=/home/myuser/myfile.vsam > KICKS will always be started from some kind of shell script and these > environment defines, as part of that script, seem (to me) a natural > analog to the ALLOC's and FILEDEF's used in current tso and cms clists > and execs. > Here's the question: Is this the most natural unix/linux way to > connect such internal and external names?
Well, most UNIX commands that I am familar with use "options". That is something like "command -o". If something more complicated is needed, such as in your case, I've seen things like "command --varname=varvalue" (especially in GNU Unix commands). For something with a lot of parameters, this will become basically impossible. So I would likely go with environment variables. Given that there is no such thing in non-z/OS UNIX as a "DD name", there is likely no standard. However, there are two possible "standards" in z/OS that I can find. One is used by COBOL and the other by PL/I (as documented in their language reference manuals). COBOL, in the SELECT clause, has something like "ASSIGN TO UT-S-name". The COBOL run time uses "name" as the DD name. However, if there is no such DD name allocated (in JCL or via dynamic allocation), the run time looks for an LE environment variable named "name" and parses its value to determine the z/OS dataset or z/OS UNIX file to use. ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR50/4.2.3.1 PL/I uses something similar, but instead of using "name" as the environment variable name, it prefixes "name" with "DD_". ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/i1191451/2.1.3.5 You might want to use one, or even both, of these. Along with command line switches. Why all of them? Well you could have a script set up the environment variables you need to assign the DDNAMEs. But you could then selectively override one or more via a command line switch. Personally, I prefer the PL/I use of prefixing with "DD_". Using this convention, it is easy to search each environment variable, looking for anything that starts with DD_ and "squirrelling it away for later" in a list of some sort. After this, you look at your command's parameters, looking for something like "--DD_DDNAME=" (either UPPER or lower case or maybe even both). When you find one, either add it to your list or update the existing entry's value. And perhaps is it now understandable why I like the PL/I use of a DD_ prefix. I use the same logic in the command arguments to easily see if the user meant a DD (--DD_ddname) or something else. I think that, although more wordy, it is more intuitive. And much easier for your than parsing up "--somename=" and trying to determine if "somename" is meant to be a DD name or not. I don't know if you want to support z/OS datasets and paths or not (being in the Linux-390 forum, I guess not). But if you do, then I'd use the same syntax as the one used by PL/I so you can unambiguously distinguish between them. If you only plan to support UNIX files, then you could use the simpler form in your message: kicks --DD_MYFILE=/home/myuser/myfile.vsam or export DD_MYFILE=/home/myuser/myfile.vsam kicks I guess the .vsam doesn't really mean a z/OS VSAM file, because you can't put a z/OS VSAM file in a UNIX subdirectory. Especially not in z/Linux! <grin> Wow, am I getting wordy in my old age. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
