What is placed after the length field when it's zero ? A S0C4 trap ? Or maybe some area which always is zero today ? (Hope never dies... :) )
Regards, Thomas Berg __________________________________________ Thomas Berg Specialist IT-U SWEDBANK > -----Ursprungligt meddelande----- > Från: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] För Vernooij, CP - SPLXM > Skickat: den 29 oktober 2009 13:29 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: A modest PARM proposal > > No parm in JCL results in a parmfield with a lenghtfield of zeros. > > L R3,0(R1) ADDRESS OF PARM. > LH R2,0(R3) LENGTH OF PARM. > LTR R2,R2 LENGTH ZERO? > BZ END ==> NO PARM. > > Kees. > > "Thomas Berg" <thomas.b...@swedbank.se> wrote in message > news:<e46b4df55a5e8746855078ae31f1b180336f71d...@fspas01ev010. > fspa.myntet.se>... > > There is of course a problem if You have a program that: > > 1. Expects parm from both the JCL PARM mechanism and from common > > standard linkage/calls, and 2. Receives a parm with a length field > > value of exactly 100, and 3. Can't determine if the parm > in reality > > is longer than that or not (that is: if coming from JCL). > > and > > 4. The calling is not through JCL PARM, and 5. The calling part is > > not aware of this new possible format. > > > > The question is of course if this situation is a big problem in > > practice. Someone with knowledge has to evaluate that. > > > > > > BTW, when You omit the JCL PARM, what does the program receive ? > > A length field with value zero only ? What type of area is placed > > immediately after the length field in this case ? > > > > > > > > Regards, > > Thomas Berg > > __________________________________________ > > Thomas Berg Specialist IT-U SWEDBANK > > > > > > > > > > > > > -----Ursprungligt meddelande----- > > > Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] > > > För Vernooij, CP - SPLXM > > > Skickat: den 29 oktober 2009 11:52 > > > Till: IBM-MAIN@bama.ua.edu > > > Ämne: Re: A modest PARM proposal > > > > > > Don't think it is that simple. > > > I know how the parmfield works today. > > > If I understand the proposed new parmfield correctly, > > > > > > Today: lengthfield + parm (max 100 bytes) > > > > > > Tomorrow: lengthfield + parm (max 100 bytes) + > padding to 102 > > > the first 102 bytes will remain unchanged and additional > parms will > > > be appended to it. This means the first length field will > never be > > > more than 100. > > > How can a program determine if the data in bytes 101 and > further are > > > part of the new parmlayout and contain the lengthfield of the > > > remainder of the parm OR it is data not related to the > parm. In the > > > last case, referencing data after byte 100 can even > result in an 0C4 > > > abend. > > > > > > Kees. > > > > > > > > > "Graeme Gibson" <gra...@ase.com.au> wrote in message > > > news:<20091029111112.3a5761c...@mail.ase.com.au>... > > > > >How can new programs determine if they received the new or the > > > > >old format, i.o.w. if they can/should process the data after > > > byte 100 or > > > not? > > > > > > > > It's really quite simple Kees, the program should process > > > exactly the > > > > number of bytes that the 2-byte (halfword) length > prefix says is > > > > present, no more and no less. This has been the case for > > > > 40 years. > > > > > > > > Running a program in batch that lets me dump storage: > > > > > > > > //STEP1 EXEC PGM=DBUG,PARM='TP,L,HC,PA=(ABCDEFGH)' > > > > > > > > here's what R1 -> at the time the program receives control: > > > > > > > > L R1$ 128 /* list what R1 points at for 128 bytes > > > > 00006FE0(+000) 80006FE6 00000015 E3D76BD3 6BC8C36B > > > |::?W::::TP,L,HC,| > > > > 00006FF0(+010) D7C17E4D C1C2C3C4 C5C6C7C8 5D000000 > > > |PA=(ABCDEFGH):::| > > > > 00007000(+020) 00000000 00000000 00000000 00000000 > > > |::::::::::::::::| > > > > 00007010(+030) 00000000 00000000 00000000 00000000 > > > |::::::::::::::::| > > > > > > > > Breaking it up a bit to make it clearer: > > > > > > > > 006FE0 80006FE6 /* the parmlist (with end-of-list > bit ON) -> > > > > 006FE6 0015 /* the length prefix part of the parameter > > > > 006FE8 E3D76BD3 6BC8C36B D7C17E4D C1C2C3C4 C5C6C7C8 > 5D00 /* the > > > > string part in hex > > > > T P , L , H C , P A = ( A B C D E F G H ) > > > /* ..and > > > > in characters > > > > > > > > Now, there's NO padding out of the string buffer to 100 > characters > > > > with blanks. So, what are those "broken" programs making > > > of all those > > > > x'00' bytes that follow the actual PARM= value? Countless > > > > existing programs may well be moving an arbitrary 100 > or 102 bytes > > > of parameter > > > > to their own buffer/work area, but it seems clear that > those same > > > > programs must be taking notice of the length prefix when it > > > comes to > > > > parsing the string. Or perhaps they all regard an x'00' > > > > as indicating end of PARM= string! But then I'm not > aware of any > > > > commitment by IBM to ensure that the PARM= string is even > > > filled out > > > > with x'00' bytes. > > > > > > > > So, assuming the CI/SWA/Initiator support for PARM= was > enhanced > > > > to allow PARM= strings up to 32767 (x'7fff') characters. > > > Presumably the > > > > Initiator would continue, as it does now, to place the > > > PARM= parameter > > > > in a storage area big enough to hold the maximum size > it can be, > > > > ie > > > > 32767+2 bytes (instead of 102 bytes as at present). > Nothing would > > > > change for those existing (strictly > > > > "broken") programs that are copying an arbitrary 100 (or > > > 20, or some > > > > other number?) bytes of data into their own work areas. > > > > > > > > Of course, if a person using that program changed the PARM= > > > string to > > > > be longer than 100 characters, then all bets are off. > > > > > > > > The best outcome would be a message; like "I'm sorry > Dave, but I > > > > thought you knew that I can't handle a PARM string of more than > > > > 100 characters. Report to the airlock immediately". > > > > > > > > An abend would be ok too. > > > > > > > > Just continuing to execute with possibly unknown results > > > would be the > > > > worst outcome. > > > > > > > > I suspect that there are programs in existence which > cannot accept > > > > even 20 characters of PARM= data, because the programmer > > > assumed there > > > > would only be, say, an 8 digit date (yyyymmdd), or some > > > other tiddly > > > > bit of data in the PARM= field. > > > > > > > > > > > > Ok, it's nearly Christmas / Hannuka / Pagan Pissup (ie. > > > drinking) time > > > > again, so take care all. > > > > Graeme. > > > > > > > > > > > > At 02:47 AM 29/10/2009, you wrote: > > > > >How can new programs determine if they received the new or the > > > > >old format, i.o.w. if they can/should process the data after > > > byte 100 or > > > not? > > > > > > > > > >Kees. > > > > > > > > > > > > > > >"Thomas Berg" <thomas.b...@swedbank.se> wrote in message > > > > > > Today: lengthfield + parm (max 100 bytes) > > > > > > Tomorrow: lengthfield + parm (max 100 bytes) + > padding to 102 > > > > > bytes + newlengthfield + newparm (max 4GiB ? :) ) > > > > > > > > > > > > This of course has the limitation means that the receiving > > > > > > part > > > > > has to add 102 to get the long parm. > > > > > > But it will only affect new programs that need to > handle more > > > > > that 100 bytes parms, I think ? > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > > 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 information, services and offers, please visit our > web site: > > > http://www.klm.com. This e-mail and any attachment may contain > > > confidential and privileged material intended for the addressee > > > only. If you are not the addressee, you are notified that > no part of > > > the e-mail or any attachment may be disclosed, copied or > > > distributed, and that any other action related to this e-mail or > > > attachment is strictly prohibited, and may be unlawful. > If you have > > > received this e-mail by error, please notify the sender > immediately > > > by return e-mail, and delete this message. > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > > and/or its employees shall not be liable for the incorrect or > > > incomplete transmission of this e-mail or any attachments, nor > > > responsible for any delay in receipt. > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > > Dutch Airlines) is registered in Amstelveen, The > Netherlands, with > > > registered number 33014286 > > > > ******************************************************************** > > > ** > > > > > > > -------------------------------------------------------------------- > > > -- 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 > ********************************************************************** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may > contain confidential and privileged material intended for the > addressee only. If you are not the addressee, you are > notified that no part of the e-mail or any attachment may be > disclosed, copied or distributed, and that any other action > related to this e-mail or attachment is strictly prohibited, > and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, > and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its > subsidiaries and/or its employees shall not be liable for the > incorrect or incomplete transmission of this e-mail or any > attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM > Royal Dutch Airlines) is registered in Amstelveen, The > Netherlands, with registered number 33014286 > ********************************************************************** > > ---------------------------------------------------------------------- > 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
