In a recent note, Peter Hunkeler said:
> Date: Mon, 23 May 2005 12:57:52 +0200
>
> 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.
>
Assuming that the preponderance of programs have been designed to
run in batch, and supposing that a load module attribute indicating
whether or not a program is capable of dealing with a PARM >100
bytes comes into being, should LINK and ATTACH enforce the limit
of PARM <=100 bytes on programs not marked as being able to deal
with longer PARMs? This would protect programs written "when batch
was the way to run programs", of which the authors never anticipated
that the programs would be run by LINK or ATTACH.
TSO CALL, as I recently ranted here:
URL: http://bama.ua.edu/cgi-bin/wa?A2=ind0505&L=ibm-main&D=1&O=D&P=99533
... deals (in a manner of speaking) with long parms by:
IKJ56003I PARM FIELD TRUNCATED TO 100 CHARACTERS
I believe this introduces the very hazards associated with PARM
truncation which have provoked such dread in this thread, and
ought to be subject to an integrity APAR. Truncation is the very
worst of choices: it neither accommodates programs capable of
dealing with long PARMs nor protects the integrity of operation
of programs not so capable.
-- 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
