Re: argv for z/OS C++ batch
Were splitting hairs here. The original question related specifically to batch processing. (I took this to mean JCL/Converter/Interpreter.) The information from the link is related to tso and the tso call facility. There is no ASIS facility within a C/C++ program. A C/C++ program will recieve parms as passed (subject to the PLIST(OS|HOST) setting) and will not change the case of the passed parameters. In fact you can send hex values (except x'00') in a parm from JCL by turing HEX ON. With the information you have provided we can see that the TSO has different rules for parm processing that JCL. Neither the TSO or JCL rules apply to program to program calls. Regards, Sam On Sun, Dec 27, 2009 at 5:38 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Sun, 27 Dec 2009 04:57:25 +, Sam Siegel wrote: For caps on/caps off, I was referring to ISPF edit. That has very little to do with how JCL passes parms, nor how C/C++ receives them, nor with any other editor the user chooses because it has less restrictive conventions. More relevant, and truly dismaying, I stumbled onto: Title: z/OS V1R10.0 XL C/C++ User's Guide Document Number: SC09-4767-07 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcug170/11.3.2 11.3.2 Passing arguments to the z/OS XL C/C++ application How the z/OS XL C/C++ program is invoked Example Case of argument By CALL command (with CALL program Args ASIS Mixed case (However, control arguments if you pass the ASISarguments entirely in upper case, the argument will be changed to lower case.) WTF!? Sheesh. ASIS should mean ASIS. Lower case is left lower _and_ upper case is left upper. This is an egregious example of not fixing breakage where it occurred, but introducing additional breakage elsewhere with the misguided and futile hope that it will offset the original. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: argv for z/OS C++ batch
So many answers! Thank you all. Let's see: - Yes, I'm clear on the difference between the restrictions imposed by PARM= (one parm, 100 chars), TSO (a tendency to convert to U/C, and yes, I agree with gil, over-compensating by converting to l/c when ASIS is specified is just brain dead), ISPF (a tendency to convert to u/c), and C argv (only one parm, possibly parsed into words). - Thank you to Sam who suggested and was kind enough to send me a sample of CEEPIPI. (Who names these things? I'm hanging out for the holidays with a four-year-old granddaughter and all I can think of is how she would find that name hilarious.) Unfortunately, the problem it solves is not the problem I have. I have a parm2 problem, not a performance on multiple assembler to C calls problem. The assembler program would be calling the C program once, or at most a few times. AND I have little control over the assembler code, only the C code. - Thank you for the suggestion of CEE3PRM which lets a downstream function find the PARM= parameter. Unfortunately, that again is not the problem I have. I've got a parm2 problem, and if necessary, I can pass it around myself. It does, however, have the side benefit of making the 100 char restriction in PARM= look generous. Who decided that 100 chars was too generous and that 80 would be more than sufficient? (In fairness, there is a version without that restriction.) - Thank you especially for the suggestion of the __R1 macro. That seems to do the job. It may have to go in the main program -- I had problems with putting it in a downstream function, but I moved it to main() and did not fully pursue getting it to work outside of main. Its companion __osplist or whatever it was called looked promising also but I got the problem solved with __R1. For anyone who is reading this thread and wants the solution, here is what is working now. (I also am compiling with PLIST(OS) but I don't *think* that is relevant.) This code could be shortened but this is what is working at the moment: // in the main() program long *r1 = (long *)__R1; // declares r1 a pointer to a long (address) char *pm1 = (char *)(*r1); // makes pm1 a char ptr for r1's 1st parm r1++;// makes r1 point to next parm address char *pm2 = (char *)(*r1); // makes pm2 a char ptr for r1's 2nd parm Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: argv for z/OS C++ batch
On Sun, 27 Dec 2009 08:56:34 +, Sam Siegel wrote: Were splitting hairs here. The original question related specifically to batch processing. (I took this to mean JCL/Converter/Interpreter.) The information from the link is related to tso and the tso call facility. There is no ASIS facility within a C/C++ program. ... even as there's no CAPS facility in JCL. It's important that these hairs be split. The programmer must be able to tell whether his data is being munged by ISPF, JCL, TSO, LE, or ??? something else. The document at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcug170/11.3.2 makes much mention of TSO, CALL, ASIS, etc. Yet it led me to believe it was describing operation of LE -- that's the title of the document. Better it should contain a cross reference to the TSO RM so the programmer could read the description in its intuitive context. However, in http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4c590/1.10.3 I read: 1.10.3 z/OS V1R10.0 TSO/E Command Reference ASIS | CAPS ASIS prevents translation of a parameter list to uppercase characters. Use ASIS for programs that accept mixed case characters in a parameter list; the CALL command will not alter the parameters in any way when the ASIS option is specified. The phrase will not alter the parameters in any way is pretty emphatic. (We must infer a reasonable exception for doubled apostrophes, etc. But that happens at a different layer.) In fact, an experiment with a non-LE utility shows that TSO CALL *(ASMA90) 'SYSPARM(ALLCAPS)' ASIS passes the entirely uppercase PARM to the program in uppercase. If the conversion to lowercase is performed it must be done by another component. LE? C/C++? I haven't the resources to perform that experiment. A C/C++ program will recieve parms as passed (subject to the PLIST(OS|HOST) setting) and will not change the case of the passed parameters. In fact you can send hex values (except x'00') in a parm from JCL by turing HEX ON. More conflation of environments. In fact: o I can send any character value in a parm from JCL without ever turning HEX ON. HEX, like CAPS, is not a JCL facility, and belongs in a discussion of some component other than JCL. o I can pass the the value of the x'00' character in a parm from JCL. Some other component (LE? C/C++ again?) may not accept it. With the information you have provided we can see that the TSO has different rules for parm processing that JCL. Neither the TSO or JCL rules apply to program to program calls. ... which is the reason we should be clear about which component we are discussing. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
