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. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Bernd Oppolzer > Sent: Wednesday, April 11, 2012 9:28 AM > To: [email protected] > Subject: Re: PL/I with variable PLISTs (was: LE C calling HLASM) > > I understand your motivation to do this; > our site specific CALL macro also sets the high order bit on every > parameter address list (even fixed length), although nobody checks it; > it's merely for dump reading purposes. > > But: if you recall the posting of the ATTACH macro description, > you are (and we are) in conflict with the recommendation of IBM, > which says that the VL bit should only be set on variable length > parameter lists. But even the IBM recommendations are not very > consistent, as the other poster pointed out ... > > Kind regards > > Bernd > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
