On Tue, 22 Sep 2009 23:25:35 +0000, Ted MacNEIL wrote:
>
>There are standards.
>If they have the half-word in front and follow the strandard, there is nothing
>to reach for.
>
>I think you are reaching,
>
Yes, but:
#2.8.1 "z/OS V1R10.0 MVS Assembler Services Guide"
_________________________________________________
2.8.1 Program in Primary Mode
Unlike the parameter list produced for an EXEC statement, a
general parameter list can have multiple parameters, there is
no system-imposed limitation on the length of any parameter,
and no parameter has a system-defined format. Lengths and
formats of parameters are defined by the called service.
>You can call programmes with 'long, parms.
>Only PGM= has the limit!
>
Here we agree. And, in fairness, the topic goes on to say:
For a good example of how your primary mode programs
can pass parameters, consider the way the system uses
a register to pass information in the PARM field of an
EXEC statement to your program.
...
When your program receives control from the system, register 1
contains the address of a fullword on a fullword boundary in
your program's address space (see Figure 2-4). The high-order
bit (bit 0) of this word is set to 1. The system uses this
convention to indicate the last word in a variable-length
parameter list. Bits 1-31 of the fullword contain the address
of a two-byte length field on a halfword boundary. ...
You know the rest. It says "example" and "convention", not
"standard". Regardless, I'd like to see the two-byte length
followed by the PARM field preserved in any extension of a
PARM-like operand to a 65536 (it says "two-byte", not "halfword",
avoiding the implication that it's signed), or even just 32767
byte length. It's what would be most compatible with programs
that already usefully accept PARMs of several hundred characters
when called by other programs or Rexx ATTACHMVS.
And a cautionary note which would be wisely heeded:
To prevent possible errors, always use the count as a length
attribute in acquiring the information in the PARM field.
I believe that any program which malfunctions because it ignores
this admonition can rightly be considered defective.
-- 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
