It's true: when passing 64 bit addresses, the VL bit mechanism will
not work any more, so maybe it has no future.
The C stdarg mechanism has its drawbacks, but it does not rely on
a specific platform or operating system, it is portable, and it works
with 64 bit environments, too. This is what I like about C - it is sometimes
a little bit strange, but the programs conforming to the ANSI standard
run on almost every platform and - if you do it right - need not be
changed,
even when your platform changes, for example, from 32 to 64 bit.
Kind regards
Bernd
Am 11.04.2012 19:32, schrieb McKown, John:
I had never read that. And, guess what, whomever wrote the initiator code
didn't either. Because it use ATTACH or maybe ATTACHX to run the program
specified on the EXEC PGM=. And it is documented that the parameter list has
the high bit set on in the last address. But it always and only passes one
parameter to the program (the PARM= string). However, the program being
executed may or may not accept a variable number of parms. IEFBR14 does not use
any parms. IDCAMS accepts 0 or more parms. Most COBOL main routines only accept
a single parameter. The initiator doesn't know how many parms may be accepted
by the invoked program. So the comment on ATTACH/ATTACHX macros, which is also
on LINK/LINKX macros, is ludicrous. Likely it should say something like:
You only need to specify VL=1 only if the called program can be passed a
variable number of parameters. VL=1 causes the high-order bit of the last
address parameter to be set to 1; the bit can be checked to find the end of the
list.
But having the VL=1 does no harm. IMO, the comment in the manual omits the "You only need
to" neede at the start of the first sentence. Maybe the editor needed to decrease the
manual word count?<grin>
Other interesting things that I hadn't noted: neither ATTACH[X] or LINK[X]
support above the bar PARMS; CALL doesn't have the note about VL only being for
called programs which can be passed a variable number of parameters; CALL
supports 64-bit addresses (either AMODE64 without PLIST4=YES, or not AMODE64
and PLIST8=YES). But when it uses an 8-bytes-per-entry plist, you cannot
specify VL. Which means that to pass a plist to a program which uses a variable
number of list entries, using the 8-bytes-per-entry plist format, you must pass
the number of parameters in the list to the called routine. I would think by
making the first parameter a pointer (4 or 8 bytes as needed by the called
routine) to a fullword containing the number of parameters in the list.
Given all the above facts, I wonder if it is time to abandon, in our own code,
the practice of indicating end-of-list by setting the high order bit of the
last parameter to '1'b. If, instead, we might want to pass the number of
parameters in the list either: (1) by value (fullword or doubleword pointed to
by GPR1 is the number of parameters in the rest of the list) or (2) by
reference (fullword or doubleword pointed to by GPR1 points to a fullword which
contains the number of parameters in the rest of the list). All the size of
each list entry pointed to by GPR1 would be 4 (not AMODE64 and not PLIST8=YES)
or 8 (AMODE64 and not PLIST4=YES, or PLIST8=YES regardless of AMODE). Of course
the called routine must be written to accept either one of: (1) 4
bytes-per-entry in the list, or (2) 8-bytes-per-entry in the list.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
