I'm all for that since VSAM for z/VM has been removed from marketing. -----Original Message----- From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Mike Noel Sent: Wednesday, August 08, 2012 1:39 PM To: [email protected] Subject: Re: porting kicks
Actually I meant porting sqlite to CMS in z/VM. I think sqlite is already available in zLinux isn't it? On Wed, Aug 8, 2012 at 9:34 AM, Mike Noel <[email protected]> wrote: > 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/ ---------------------------------------------------------------------- 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/
