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
