The point is: we are discussing a change of the code for eventual forwarding to IBM. If IBM accept it, there is no problem (with future changes).
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 16:09 > Till: IBM-MAIN@bama.ua.edu > Ämne: Re: A modest PARM proposal > > 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 > ---------------------------------------------------------------------- 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
