On 29 Oct 2009 03:17:25 -0700, in bit.listserv.ibm-main 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? > >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.
Back in the dark ages when I was programming, I checked the parm length field to be sure that it was values that I was expecting (zero being just one of the values). I would never have considered just using the Parm length field to determine the size of a move to a work area. I also would not have used an arbitrary size value for any operation on the parm field since the parm could be either missing or shorter than expected. Either case could cause mysterious things to happen. Since my recollection of the size field being a halfword seems to be correct, then what is the problem with a parm field over 100 bytes since any using program should be testing the size and making sure that any overwrite isn't occurring anyway (or that an overly short field isn't being passed)? > >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 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
