<[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > In a recent note, Peter Hunkeler said: > > > Date: Mon, 23 May 2005 12:21:44 +0200 > >
> > you mentioned isn't too different *but* the architectural limit > > (still) is 100 bytes not 50, not 16, programs are expected to reserve > > 100 bytes for the PARM. 50 instead of 16 bytes would not overwrite > > data outside of the 100 byte variable. > > > can you cite a source for "programs are expected to reserve 100 > bytes for the PARM"? Shouldn't programs expect possibly to be > invoked through any of the programming interfaces which have never > imposed a 100 byte limit? > > In fact, in: > > Title: z/OS V1R4.0 MVS Assembler Services Guide > Document Number: SA22-7605-04 > > .., I see: > > 2.8 Conventions for Passing Information Through a Parameter List > 2.8.1 Program in Primary Mode > > ... two-byte length field on a halfword > boundary. The length field contains a binary count of the > number of bytes in the PARM field, which immediately follows > the length field. If the PARM field was omitted in the EXEC > statement, the count is set to zero. To prevent possible > errors, always use the count as a length attribute in acquiring > the information in the PARM field. > > It's quite clear that the length field is two bytes, and that > called programs are required to use the length field as the > length of the parameter. It does not permit using only the > low byte (assumed length<256), nor permit assuming the PARM > length is <=100. It is more complicated: 1. what was in the manual 10, 20 and 30 years ago, when the current potentially hurt tools were developped? You don't get away with a doc-change here. 2. the source you are looking for is there: Book 1 states: the first halfword of the parmfield contains the length. Book 2 states: the parmfield of the JCL is limited to 100 bytes. Add the two and you know what the world looks like for a tool that handles JCL parms, that is, until some breaks the above rules. In that case he should realize which previous truths-of-life he is going to violate. This change is equivalent to changing the lengthfield to 4 bytes for example, the only difference merely being that more tools are effected then by changing the 100-byte limit. However you can imagine the shockwave this will cause... I did a quick scan on the sources of our tools and found several that move the parmarea, using its length field, to a 100 byte area. Kees. ********************************************************************** 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. ********************************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
