The point is: if IBM has not documented something, you cannot rely on it. It might be true for many years and can suddenly change with a new release. IBM can even legitimitely change the code you just checked how it works.
Kees. "Thomas Berg" <thomas.b...@swedbank.se> wrote in message news:<e46b4df55a5e8746855078ae31f1b180336f71d...@fspas01ev010.fspa.myntet.se>... > The point is: this is a very old interface, there could > well be that it's always have the same content. If You know > the code behind You could verify that. > > > > 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 14:06 > > Till: IBM-MAIN@bama.ua.edu > > Ämne: Re: A modest PARM proposal > > > > > > The answer is: you don't know, so you can't and shouldn't > > assume anything. > > It is not an 0C4 'trap', you should not reference storage of > > which you are not sure that you can reference it. > > > > Kees. > > > > "Thomas Berg" <thomas.b...@swedbank.se> wrote in message > > news:<e46b4df55a5e8746855078ae31f1b180336f71d...@fspas01ev010. > > fspa.myntet.se>... > > > 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 > > ********************************************************************** > > 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
