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/
