In a recent note, Peter Hunkeler said:
> Date: Mon, 23 May 2005 12:21:44 +0200
>
> You're assuming the program will break. I'm afraid of the case it
> doesn't break but run with incorrect data. Sure, the 16-byte case
>
I try to PMR any IBM program that quietly truncates any input
data. The easily recognized, frightening case is,
"DELETE DATA.SET.NAME(MEMBER)" getting truncated before the left
parenthesis, for example.
> 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.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
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
