Good point about prefacing the environment ddnames with *something* to ensure they don't conflict with other environment names. I also appreciate your mentioning the z/os open environment; I'd forgotten about it. I'm supposing a port to that world would not be too difficult after I had a running zLinux implementation, but I wonder if there would be any interest given that KICKS already works well for TSO in z/os? VSAM is of course a whole different issue. I consider a major piece of my KICKS to Linux port to be providing vsam functionality in that world and I'm presenting thinking to base my 'vsam' on sqlite. I understand several people are working to port sqlite to zLinux; hopefully they will 'beat' me!
On Wed, Aug 8, 2012 at 6:04 AM, McKown, John <[email protected]> wrote: >> -----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/ ---------------------------------------------------------------------- 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/
