On May 23, 2005, at 6:57 AM, Peter Hunkeler wrote:
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.
What is the purpose of moving the parm to an internal field? That just
strikes me as broken as designed (BAD). You cannot change the value,
it is truly input only. It also strikes me as more effort than just
using the parm inplace in this age of reentrent and reusable code
styles.
All I'm saying is that it takes two objects to create this error. Your
production program must do things incorrectly today AND your production
JCL must change. If it works today, then only a change to one of these
two (hopefully) controlled objects can break it.
Unless you just let your production JCL be changed willy-nilly you are
at no risk of exposure.
[EMAIL PROTECTED]
The most effective type of birth control is learning Cobol. -DT
----------------------------------------------------------------------
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
