Ok, this is one thing; needs probably some claryfying from IBM.
But, as Frank mentioned in the other post:
I think the high order bit is really needed in the PLITDLI case,
because the number of parameters is not fixed and cannot be
derived from the other parameters in every case (I guess, the number
of SSAs is really variable on the GET request, and the high order bit on
the last SSA marks the end of the list - only speculating; I know almost
nothing about IMS).
So we here have a design where the API relies heavily on the OS/360
high order bit mechanism. Languages that do not set the high order bit
on the last parm address must prefix the address list with the parmcount,
so that the DLI interface knows the number of the parameters.
My opinion is: there are languages that even don't support variable length
parameter lists. But you always find a way to overcome this restriction;
for example: you could pass an array of SSAs as a single parameter
in the case of the IMS GET request (together with a number of entries).
This is what I would normally do in C - starting address of the array and
number of elements, two parameters. You don't really need variable
length parameter lists - they are comfortable sometimes, like with
printf etc, but you can live without them.
Kind regards
Bernd
Am 11.04.2012 01:07, schrieb Paul Gilmartin:
On Wed, 11 Apr 2012 00:48:33 +0200, Bernd Oppolzer wrote:
I would not blame PL/1 for this.
It is not OK IMHO to request the caller to set the
high order bit on the last parameter, when the number of the parameters is fixed
(see also my GDDM example on the other post). This is not required by
any OS convention,
at least that's my understanding.
It's inconsistently deprecated. In:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a7b0/5.1.8
5.0 ATTACH and ATTACHX -- Create a new task
Subtopics:
* 5.1 Description
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 to be
set to 1; the bit can be checked to find the end of the list.
Note the word "only". But this admonition appears for ATTACH, but not
for CALL. Is there any rationale for this difference, or is an RCF in order?
(I haven't checked LINK nor XCTL; they're in a different volume.)
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
