>In order for you to receive the errors you fear, you will need to
>change your JCL to pass more bytes than your programs are expecting.
>This is always a problem -- for 100 bytes or 65535 bytes.
That's what I said *but* a program will not get control today because
of the JCL error you get. It will, however, get control with the
suggested change.
>The fix is simple. Just don't pass more than a program is expecting.
Sure, don't make a mistake and there will be no error ;-(
>Today, that is a certain error (JCL error), tomorrow it will still be
>an error (program not expecting error). Either way it is an error.
>Nothing in this change can break a program that is currently working
>correctly today.
How about the code sniplet below? Sure it would be better to also
verify the upper bound, i.e. 100 bytes, but is it really necessary,
especially if the program was written when batch was the way to run
programs? I would not count on the fact it was always done.
And before someone else points at it: Yes, this program will not
correctly handle the case when it is ATTACHed, LINKed, called from
TSO, etc., etc. with a PARM longer than 100 bytes. The program was
defined to run in batch.
GetParm DS 0H
L R1,0(,R1) Get address of PARM field
LH R5,0(,R1) Get length of PARM data specified
LTR R5,R5 Anything specified?
BZ NoParm None received
BCTR R5,0 Adjust length for MVC
EX R5,MoveParm Move PARM data to internal field
...
...
MoveParm MVC ParmData(0),2(R1)
...
...
ParmData DS CL100
AjustmentFactor DC H'17' Used in converting "X" to "Y"
According to the principle of least astonishment, we should not
incompatibly change the rules to benefit a few programs.
Peter Hunkeler
Senior IT Specialist, IBM zSeries Technical Sales Support, Switzerland
----------------------------------------------------------------------
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
