On Sat, 5 Jan 2008 15:47:33 -0000, Phil Payne wrote: > >One thing it did was a GETMAIN for the parm length and a move - and there was >at that time a >solid recommendation to do that. > Ah, but it was for the PARM length, not for 100 characters, so your macro was prepared to handle a CALL with a longer PARM.
>Thing is - I can't remember why. > >The only possible suggestion I can come up with, but feel free to shoot it >down. Under the >PCP option of OS/360, the parm field was not protected from write access by >the program. >Under the MFT option, it was. Is this a PCP-MFT compatibility issue? > Rexx LINKPGM (admittedly different from the initiator) passes the PARM(s) in writeable storage, and expects the linked program to be able to return values in that storage. For example, see 'SYS1.SAMPLIB(CSFTEST)' To protect itself, the initiator probably routinely obtains storage in a system key. Since the initiator makes no use of values the problem program might write back to the PARM area, it might be a courtesy to that program to cause a program check if it unwittingly modifies its PARM. -- gil ---------------------------------------------------------------------- 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
