We don't have PL/I in our shop (I downloaded an old "trial" version of VisualAge PL/I for Windows to play with at home), but it seems to me that one MIGHT be able to do the following for PL/I to call DL/I:
declare CEETDLI entry linkage(SYSTEM); or perhaps declare CEETDLI entry(char(4), *, *, *, *, *, *, *, *, *, *) linkage(SYSTEM); Then call without passing the number of parms: call CEETDLI(ghnp, pcb-mask, i-o-area, ssa-1 ssa-2); I am assuming that LINKAGE(SYSTEM) does indeed set the high-order bit in the last parm. I used CEETDLI rather than PLITDLI because I know it can be called from "any" language (COBOL, PL/I, Assembler, maybe C and Fortran), so it can obviously(!) handle the high-order bit indicator. I would be vary curious to have someone with both PL/I and IMS test this out. Frank ----- Original Message ----- > From: Bernd Oppolzer <[email protected]> > To: [email protected] > Cc: > Sent: Tuesday, April 10, 2012 5:31 PM > Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM) > > 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 [email protected] with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
