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
