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
