Variable-Length Parameter List Attributes

[Dave Clark]

I have a definition such as the following.

SHVPARMB DS 5F

However, the program I am calling will actually accept 4, 5, or 6
parameters in this list. So, I believe that T' will return F and L' will
return 4, but is there any attribute that will return the 5 in the above
definition? I ask, because I would rather not hardcode the following to
set the end flag for the list.

OI SHVPARMB+(5*4-4),X'80'


Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331



*********************************************************************************************
This email message and any attachments is for use only by the named
addressee(s) and may contain confidential, privileged and/or proprietary
information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message and all
copies. All unauthorized direct or indirect use or disclosure of this
message is strictly prohibited. No right to confidentiality or privilege
is waived or lost by any error in transmission.
*********************************************************************************************

[Tom Harper]

Dave,

Why not use the CALL macro with the VL parameter to mark the end of the list?

Sincerely,

Tom Harper
Phoenix Software International

Sent from my iPhone

> On Oct 18, 2023, at 11:53 AM, Dave Clark <dlc...@winsupplyinc.com> wrote:
>
>  I have a definition such as the following.

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
10/18/2023 11:56:55 AM:

> Why not use the CALL macro with the VL parameter to mark the end of the
list?

Because I don't appreciate the in-line parameter list it
generates.

[Paul Gilmartin]

On 10/18/23 09:53:35, Dave Clark wrote:
> SHVPARMB DS 5F However, the program I am calling will actually accept 4, 5, or 6 parameters in this list. So, I believe that T' will return F and L' will return 4, but is there any attribute that will return the 5 in the above definition? I ask, because I would rather not hardcode the following to set the end flag for the list. OI SHVPARMB+(5*4-4),X'80'
>

I'd code:
SHVPARMB DS 5F Is this hard coded?
endPARMB EQU *
Then:
OI ENDPARMB-4,X'80'

--
gil

[Farley, Peter]

Execute version of the CALL macro with MF=(E,parm_area_name) can fix that.

From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Dave Clark
Sent: Wednesday, October 18, 2023 12:09 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Variable-Length Parameter List Attributes


"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU<mailto:ASSEMBL...@LISTSERV.UGA.EDU>> wrote on

10/18/2023 11:56:55 AM:

> Why not use the CALL macro with the VL parameter to mark the end of the

list?





Because I don't appreciate the in-line parameter list it

generates.





Sincerely,



Dave Clark

--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
10/18/2023 12:15:12 PM:

> Execute version of the CALL macro with MF=(E,parm_area_name) can fix
that.

Well, the other issue is performance. I potentially call this
program hundreds of times. So, I can build the parameter list just once
and call it as follows:

LA R1,SHVPARMB
L R15,ARXEXCOM
BALR R14,R15

Or I can call it as follows -- much less desireable. Note that
the program address is not supplied by a V-con but by an external program
vector list from REXX. That is why I have to preload R15 rather than
puting it in the CALL statement. But, I still wouldn't want a V-con
inserted into the middle of my instructions by the CALL with a branch
around it.

L R15,ARXEXCOM
CALL (15),(SHVPARM1,SHVPARM2,SHVPARM2,SHVBLOCK,SHVPARM5), X
MF=(E,SHVPARMB)
DS 0H
LA 1,SHVPARMB
LA 0,SHVPARM1
ST 0,0(0,1)
LA 0,SHVPARM2
ST 0,4(0,1)
LA 0,SHVPARM2
ST 0,8(0,1)
LA 0,SHVBLOCK
ST 0,12(0,1)
LA 0,SHVPARM5
ST 0,16(0,1)
OI 16(1),X'80
BALR 14,15

[Seymour J Metz]

I would use CALL MF=E but you can always define a label for the OI into the last word of the list.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Dave Clark <dlc...@WINSUPPLYINC.COM>
Sent: Wednesday, October 18, 2023 11:53 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Variable-Length Parameter List Attributes

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
10/18/2023 01:04:43 PM:

> I would use CALL MF=E but you can always define a label for the OI
> into the last word of the list.

OK, so you're suggesting the following? ...and there isn't an
attribute to retrieve the replication factor?

SHVPARMB DS 5F
SHVPLAST EQU *-4


OI SHVPLAST,X'80'

[Ed Jaffe]

On 10/18/2023 9:48 AM, Dave Clark wrote:
>
> Well, the other issue is performance. I potentially call this
> program hundreds of times. So, I can build the parameter list just once

I have used CALL to build a parameter list and do nothing else in a
manner similar to:

CALL (15),(parm1,parm2,...parmn),VL,MF=(E,plist)
ORG   *-2
.
. (continue on -- no call is performed)
.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

[Tony Harminc]

On Wed, 18 Oct 2023 at 12:48, Dave Clark <dlc...@winsupplyinc.com> wrote:

> [...]

The CALL macro is smart enough to load the addresses into some range of
R14-R1, and then issue an STM to put up to four values into the arg list.
If there are more than four then it starts over.

Tony H.

[Seymour J Metz]

Yes. I was going to suggest N' but I looked it up and it's not valid on ordinary symbols.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Dave Clark <dlc...@WINSUPPLYINC.COM>

Sent: Wednesday, October 18, 2023 1:08 PM

To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Variable-Length Parameter List Attributes

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

[Farley, Peter]

Build the parameter list once using this form:

CALL (15),(PARM1,PARM2,PARM2,BLOCK,PARM5),VL,MF=(E,PARMB), X
LINKINST=NOPR,LINKOP='0'

Which generates this code:

+ DS 0H
+ LA 1,PARMB LOAD PARAMETER REG 1
+ LA 0,PARM1 PICKUP PARAMETER
+ ST 0,0(0,1) STORE INTO PARAM. LIST
+ LA 0,PARM2 PICKUP PARAMETER
+ ST 0,4(0,1) STORE INTO PARAM. LIST
+ LA 0,PARM2 PICKUP PARAMETER
+ ST 0,8(0,1) STORE INTO PARAM. LIST
+ LA 0,BLOCK PICKUP PARAMETER
+ ST 0,12(0,1) STORE INTO PARAM. LIST
+ LA 0,PARM5 PICKUP PARAMETER
+ ST 0,16(0,1) STORE INTO PARAM. LIST
+ OI 16(1),X'80' SET LAST WORD BIT ON @G860P40
+ NOPR 0

The only extra cost is the “NOPR 0” at the end, but since you do it only once that shouldn’t be an issue.

Then you can use your 3-instruction sequence to actually do the CALL as many times as you need.

Peter

From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Dave Clark
Sent: Wednesday, October 18, 2023 12:48 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Variable-Length Parameter List Attributes

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU<mailto:ASSEMBL...@LISTSERV.UGA.EDU>> wrote on

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Tony Harminc]

On Wed, 18 Oct 2023 at 13:11, Ed Jaffe <edj...@phoenixsoftware.com> wrote:

> On 10/18/2023 9:48 AM, Dave Clark wrote:
> >
> > Well, the other issue is performance. I potentially call this
> > program hundreds of times. So, I can build the parameter list just once
>
> I have used CALL to build a parameter list and do nothing else in a
> manner similar to:
>
> CALL (15),(parm1,parm2,...parmn),VL,MF=(E,plist)
> ORG *-2
> .
> . (continue on -- no call is performed)
>

CALL actually has two keyword operands to control what link instruction is
generated - LINKINST and LINKOP. So you could presumably add LINKINST=NOPR,
and LINKOP=0 or the like. Just so you aren't assuming that CALL is always
generating a BALR 14,15 as the very last instruction. Or to be perverse,
LINKINST=ORG,LINKOP=*-2 . :-)

Tony H.

[Tom Harper]

I’m betting you would not see any difference in performance. Modern z machines will likely execute most of those instructions in parallel since there are no dependencies after the first LA.

However, if you’re still concerned, I would code it this way:

> L R15,ARXEXCOM
> CALL (15),(SHVPARM1,SHVPARM2,SHVPARM2,SHVBLOCK,SHVPARM5), X
> MF=(E,SHVPARMB)
> DS 0H
> LA 1,SHVPARMB
> LA 0,SHVPARM1
> ST 0,0(0,1)
> LA 0,SHVPARM2
> ST 0,4(0,1)
> LA 0,SHVPARM2
> ST 0,8(0,1)
> LA 0,SHVBLOCK
> ST 0,12(0,1)
> LA 0,SHVPARM5
> ST 0,16(0,1)
> OI 16(1),X'80
> BALR 14,15

ORG-2 Back up over the BALR

For building your CALL list, and then use

> LA R1,SHVPARMB
> L R15,ARXEXCOM
> BALR R14,R15

For subsequent invocations.

Tom Harper

Phoenix Software International

Sent from my iPhone

> On Oct 18, 2023, at 12:48 PM, Dave Clark <dlc...@winsupplyinc.com> wrote:
>
> "IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

[Bill Hitefield]

Dave,
Are you trying to set/define the X'80' bit as part of the SHVPARMB definition? Or are you trying to use the assembler to tell you the byte an OI should target?

If the former, you can do either of the following, keeping in mind you would need to be sure you do not negate the X'80' when you populate the list.

SHVPARMB DC A(0,0,0,0,0+X'80000000)

If the latter, your example using SHVPLAST is what I have done at times. I have also done the following:

SHVPARMB DS 5A Parameter storage
SHVPLGTH EQU *-SHVPARMB Parameter storage length

... populate the parameters.

OI SHVPARMB+SHVPLGTH-4,X'80'

The nice thing about using the length as the EQU is you can use it elsewhere (the only thing about this approach is SHVPLGTH must be defined before SAVEPARM):

SAVEPARM DS 0F Parameter save area
ORG SAVEPARM+SHVPLGTH
DC ... continue with other data areas.

MVC SAVEPARM(SHVPLGTH),SHVPARMB

Bill Hitefield

> -----Original Message-----
> From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU>
> On Behalf Of Dave Clark
> Sent: Wednesday, October 18, 2023 1:09 PM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: Variable-Length Parameter List Attributes
>

> "IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU<mailto:ASSEMBL...@LISTSERV.UGA.EDU>>

[Tony Harminc]

On Wed, 18 Oct 2023 at 13:12, Seymour J Metz <sme...@gmu.edu> wrote:

> Yes. I was going to suggest N' but I looked it up and it's not valid on
> ordinary symbols.
>

Maybe this calls (heh) for a new attribute - perhaps R' to fetch the
duplication factor. In conditional assembly this would presumably fetch the
dup factor of the (required) underlying ordinary symbol. But all this stuff
is so fragile that I can't think anyone's going to want to fiddle around
with it in HLASM.

Tony H.

_______________________

[Ed Jaffe]

On 10/18/2023 10:14 AM, Farley, Peter wrote:
> Build the parameter list once using this form:
>
> CALL (15),(PARM1,PARM2,PARM2,BLOCK,PARM5),VL,MF=(E,PARMB), X
> LINKINST=NOPR,LINKOP='0'

Nice!

I remember when LINKINST was added (and have used it for both BASR and
BASSM).

Never thought to set it to a NOPR...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
10/18/2023 01:14:13 PM:

> Build the parameter list once using this form:
>
> CALL (15),(PARM1,PARM2,PARM2,BLOCK,PARM5),VL,MF=(E,PARMB), X
> LINKINST=NOPR,LINKOP='0'

The z/VSE CALL macro does not have those last two keywords. But,
I can just code ORG *-2 after the CALL to accomplish the same thing.
Thanks.

[Paul Gilmartin]

On 10/18/23 11:49:12, Dave Clark wrote:
> ...

> The z/VSE CALL macro does not have those last two keywords. But,
> I can just code ORG *-2 after the CALL to accomplish the same thing.
> Thanks.
>

ORG or B into code generated by a macro whose source you don't
control is genuinely dangerous.

--
gil

[Farley, Peter]

Sounds like an RFE to the new VSEn owners is in order: “Please support LINKINST and LINKOP parameters to the CALL macro like z/OS CALL”.

Hopefully they aren’t as reluctant or developer-resource-poor as IBM is about making useful enhancements.

Peter

From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Dave Clark
Sent: Wednesday, October 18, 2023 1:49 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Variable-Length Parameter List Attributes

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU<mailto:ASSEMBL...@LISTSERV.UGA.EDU>> wrote on

10/18/2023 01:14:13 PM:

> Build the parameter list once using this form:

>

> CALL (15),(PARM1,PARM2,PARM2,BLOCK,PARM5),VL,MF=(E,PARMB), X

> LINKINST=NOPR,LINKOP='0'





The z/VSE CALL macro does not have those last two keywords. But,

I can just code ORG *-2 after the CALL to accomplish the same thing.

Thanks.





Sincerely,



Dave Clark

--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

10/18/2023 01:56:58 PM:

Understood and I'm actually not going to use that method -- just
thought it would be acceptable in this situation, only. However, the
following is the solution I'm actually going with.

SHVPARMB DS 5F
SHVPLAST EQU *-4

LA R0,SHVPARM1 GET ADDRESS OF PARM 1
LA R1,SHVPARM2 GET ADDRESS OF PARM 2
LA R2,SHVPARM2 GET ADDRESS OF PARM 3
LA R3,SHVBLOCK GET ADDRESS OF PARM 4
STM R0,R3,SHVPARMB PUT IN PARM BLOCK
ST R5,SHVPLAST PUT ADDRESS OF ENV. IN PARM BLOCK
OI SHVPLAST,X'80' FLAG LAST PARM IN THE BLOCK

[Steve Smith]

You can actually set LINKINST=DC,LINKOP=0H if you really like clever.

sas

On Wed, Oct 18, 2023 at 1:37 PM Ed Jaffe <edj...@phoenixsoftware.com>
wrote:

[Farley, Peter]

That’s even more clever than my suggestion! But I would use DS instead of DC. All you really want is the alignment after all, not any actual storage.

Peter

From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Steve Smith
Sent: Wednesday, October 18, 2023 2:22 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Variable-Length Parameter List Attributes

You can actually set LINKINST=DC,LINKOP=0H if you really like clever.



sas

On Wed, Oct 18, 2023 at 1:37 PM Ed Jaffe <edj...@phoenixsoftware.com<mailto:edj...@phoenixsoftware.com>>

wrote:



> On 10/18/2023 10:14 AM, Farley, Peter wrote:

> > Build the parameter list once using this form:

> >

> > CALL (15),(PARM1,PARM2,PARM2,BLOCK,PARM5),VL,MF=(E,PARMB), X

> > LINKINST=NOPR,LINKOP='0'

>

> Nice!

>

> I remember when LINKINST was added (and have used it for both BASR and

> BASSM).

>

> Never thought to set it to a NOPR...

>

[Jeremy Nicoll]

On Wed, 18 Oct 2023, at 19:09, Dave Clark wrote:
> However, the following is the solution I'm actually going with.

> LA R0,SHVPARM1 GET ADDRESS OF PARM 1
> LA R1,SHVPARM2 GET ADDRESS OF PARM 2
> LA R2,SHVPARM2 GET ADDRESS OF PARM 3

Is that second reference to "SHVPARM2" just a typo?

--
Jeremy Nicoll - my opinions are my own.

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

10/18/2023 02:35:40 PM:

> On Wed, 18 Oct 2023, at 19:09, Dave Clark wrote:
> > However, the following is the solution I'm actually going with.
>
> > LA R0,SHVPARM1 GET ADDRESS OF PARM 1
> > LA R1,SHVPARM2 GET ADDRESS OF PARM 2
> > LA R2,SHVPARM2 GET ADDRESS OF PARM 3
>
> Is that second reference to "SHVPARM2" just a typo?

No, the documentation says the 2nd and 3rd parameters should be
the same address. Don't know why but I don't question it. ;-)

[Steve Thompson]

The "DS" defines storage, but does not init the content.

Steve Thompson

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
10/18/2023 02:48:17 PM:

> The "DS" defines storage, but does not init the content.

> On 10/18/2023 2:27 PM, Farley, Peter wrote:
> > That’s even more clever than my suggestion! But I would use DS
> > instead of DC. All you really want is the alignment after all,
> > not any actual storage.

Yes, the following are interchangeable because of the 0
duplication factor. But, I, too would prefer to see DS rather than DC.
;-)

DC 0H
DS 0H

[Jeremy Nicoll]

On Wed, 18 Oct 2023, at 19:39, Dave Clark wrote:
> "IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
> 10/18/2023 02:35:40 PM:
>> On Wed, 18 Oct 2023, at 19:09, Dave Clark wrote:
>> > However, the following is the solution I'm actually going with.
>>
>> > LA R0,SHVPARM1 GET ADDRESS OF PARM 1
>> > LA R1,SHVPARM2 GET ADDRESS OF PARM 2
>> > LA R2,SHVPARM2 GET ADDRESS OF PARM 3
>>
>> Is that second reference to "SHVPARM2" just a typo?
>
>
> No, the documentation says the 2nd and 3rd parameters should be
> the same address. Don't know why but I don't question it. ;-)

(Why's there no "Jeremy Nicoll ... wrote" attribution line above? I was
going to trim more of the old stuff away, above, and noticed it didn't
make sense.)

I might then have written:

LA R2,SHVPARM2 NB PARM 3 SHOULD BE SAME AS PARM 2

to reduce risk that in future someone else "corrects" the code. But maybe
you've documented that somewhere else?

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on

10/18/2023 02:53:47 PM:

> (Why's there no "Jeremy Nicoll ... wrote" attribution line above? I was

> going to trim more of the old stuff away, above, and noticed it didn't
> make sense.)

All I know is that is what my Notes client generates for replies
with an internet-style history. Apparently, Notes sees your post as
coming from the list rather than from you. Sorry. ;-)

[Paul Gilmartin]

On 10/18/23 13:03:27, Dave Clark wrote:
>
> All I know is that is what my Notes client generates for replies
> with an internet-style history. Apparently, Notes sees your post as
> coming from the list rather than from you. Sorry. ;-)
>

'Way back, RFC 822 specified tie From: and Sender: headers. Alas,
too many LISTSERVs and MUAs proudly break the rules.

--
gil

[Jonathan Scott]

In the past, DC 0H'0' was preferred for defining labels because
any DS, even of zero length, would cause a new TXT card to be
started in the object deck, making it larger than necessary.
The value is no longer needed, so DC 0H is allowed.

If no alignment padding is required, DC 0H and DS 0H are
equivalent, but if alignment padding is required (which would
not occur within instructions) then DC 0H will pad with a zero
byte and continue on the same object code TXT card, but DS 0H
will simply start a new TXT card at the aligned location.

Jonathan Scott, HLASM
IBM Hursley, UK

[Steve Smith]

Thanks Jonathan for the explanation... I doubt that many people care much
about the tidiness of their object decks (but I am one :-). That is only
part of the reason I insist on using DC over DS in text sections though.

The main reason is that any padding generated is shown in the listing,
which can be important. Also, even in DSECTs, I often use DC for most
fields, because you get a visual layout of the fields in the listing, not
just a bare offset. Particularly in a "control block" type DSECT, it's
useful for finding places where new fields can be tucked in without making
the block larger. No text is generated for DSECTs, so there's no cost to
using DC over DS, other than having to code a value for fields that aren't
0-length.

Long ago, DS for largeish areas was better because no text was generated in
the object deck (or load module). But in a strictly reentrant world, DS
space in a module is usually pointless. Also, the enhancement to DC 0* to
eliminate the need for the '0' value makes it a lot easier to use (and
neater).

sas

On Thu, Oct 19, 2023 at 8:42 AM Jonathan Scott <jonatha...@vnet.ibm.com>
wrote:

[Schmitt, Michael]

At my company, the standard going back at least 37 years has been to compile or assemble, then the job immediately NCAL links the object deck into an "object module" (not to be confused with PDSE "program object"). The object deck is discarded, the object module is saved.

I'm not sure *why* we do this, except that it makes it easier to link the object into composite load modules.

Is this common? Or do other groups save the object deck?

-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Jonathan Scott
Sent: Thursday, October 19, 2023 7:31 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Variable-Length Parameter List Attributes

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
10/19/2023 09:49:31 AM:

> At my company, the standard going back at least 37 years has been to
> compile or assemble, then the job immediately NCAL links the object
> deck into an "object module" (not to be confused with PDSE "program
> object"). The object deck is discarded, the object module is saved.
>
> I'm not sure *why* we do this, except that it makes it easier to
> link the object into composite load modules.
>
> Is this common? Or do other groups save the object deck?

Now I'm talking z/VSE-land here, but... Every shop I have been in
catalogs the SYSLNK object deck as an "object module" (library member type
OBJ) without doing any linkage editor step. Anytime we run the linkage
editor it is always to create a load module (library member type PHASE).

When we want to make composite load modules we can string linkage
editor INCLUDE statements of OBJ members, via SYSLNK, to feed into the
linkage editor. This step can also include a SYSLNK object deck at the
same time and if there is a single PHASE statement (in SYSLNK) then a
single load module is the result. But multiple PHASE statements can be
interspersed in SYSLNK to create multiple load modules in a single
execution of the linkage editor.

I did work in a couple of MVS/SP shops but I was not as familiar
with the compile processes there and always created only load modules.

[Farley, Peter]

This is quite a normal practice in a large shop with many shop-wide or utility subroutines used by multiple applications. When you link / bind a "main" program you want the link editor / binder to automatically find the executable code for all the subroutines you call (and all the ones that they in turn call) in the SYSLIB DD (which is usually a concatenation of many libraries). Linking / binding the subroutines means you do NOT have to code a bunch of INCLUDE statements as input to the link editor / binder for the "main" program, it will just happen automatically.

Using "NCAL" for the subroutine link / bind step is also quite normal and means that the lower-level subroutines that the application subroutines call are NOT included in the subroutine load module / program object, so you keep the size of your "executable code" library to a minimum, and all subroutine calls are resolved at link / bind time of "main" programs.

Maintaining a deck of INCLUDE statements in parallel with source code changes for "main" programs that can introduce or remove called subroutines is a maintenance headache that no one needs.

Peter

From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Schmitt, Michael
Sent: Thursday, October 19, 2023 9:50 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Variable-Length Parameter List Attributes


At my company, the standard going back at least 37 years has been to compile or assemble, then the job immediately NCAL links the object deck into an "object module" (not to be confused with PDSE "program object"). The object deck is discarded, the object module is saved.



I'm not sure *why* we do this, except that it makes it easier to link the object into composite load modules.



Is this common? Or do other groups save the object deck?



-----Original Message-----

From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> On Behalf Of Jonathan Scott

Sent: Thursday, October 19, 2023 7:31 AM

To: ASSEMBL...@LISTSERV.UGA.EDU

Subject: Re: Variable-Length Parameter List Attributes



In the past, DC 0H'0' was preferred for defining labels because

any DS, even of zero length, would cause a new TXT card to be

started in the object deck, making it larger than necessary.

The value is no longer needed, so DC 0H is allowed.



If no alignment padding is required, DC 0H and DS 0H are

equivalent, but if alignment padding is required (which would

not occur within instructions) then DC 0H will pad with a zero

byte and continue on the same object code TXT card, but DS 0H

will simply start a new TXT card at the aligned location.



Jonathan Scott, HLASM

IBM Hursley, UK

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
10/19/2023 10:58:35 AM:

> Linking /
> binding the subroutines means you do NOT have to code a bunch of
> INCLUDE statements as input to the link editor / binder for the
> "main" program, it will just happen automatically.

Yes, we generally don't have to put in our own INCLUDE statements.
We only have to do this when the entry point referred to by the caller is
not the same as the object module's name -- or when the object module
needs to be included at a specific point (such as the beginning) of the
resulting load module -- rather than letting the linkage editor include it
wherever it wants. Case in point for that last situation is the stub
routines for CICS and/or DLI/IMS.

[Steve Smith]

I agree! However, for products that are distributed and maintained with
SMP/E, keeping the object decks is generally done to facilitate building
APAR fixes and PTFs. I haven't looked into the possibilities, but I
haven't seen automatic library call used with SMP/E, except for
IBM-provided call libs like SYS1.CSSLIB.

sas

[Peter Relson]

Regarding "object modules", I'd have said that a lot of (almost all?) IBM-supplied products ship that way.
These "object modules" are in what we think of as a "distlib" or "distribution library". You will find them on your installing system.

SMP/E (or something) parses the ++MODs in a PTF into object decks that are generally individually bound as "object modules" into the distlib. Later the bind of distlib object modules (sometimes coupled with existing load modules / program objects, but often solely done with object modules) produces the requisite load module / program object.

Peter Relson
z/OS Core Technology Design

[Martin Packer]

This whole thing looks like REXX variable sharing (from “SHV” in the name).

I’m wondering if there’s a completely different way of skinning this cat.

Martin Packer (temporary host to three actual felines) 😊

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

[Dave Clark]

"IBM Mainframe Assembler List" <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
10/23/2023 09:48:29 AM:

> This whole thing looks like REXX variable sharing (from “SHV” in the
name).
>
> I’m wondering if there’s a completely different way of skinning this
cat.

Yes, it is in an external assembler REXX function that I have this
coding. Originally I had this:

SHVPARMB DS 5F

OI SHVPARMB+(5*4-4),X'80'


And now I have this:

SHVPARMB DS 5F
SHVPLAST EQU *-4

OI SHVPLAST,X'80'


You have some other suggestion for how to handle this?

[Martin Packer]

Actually, I don’t. It’s been about 20 years since I coded a REXX External Function Package – and I don’t have the code anymore. ☹

I just thought someone else might have.

Cheers, Martin

From: IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> on behalf of Dave Clark <dlc...@WINSUPPLYINC.COM>

Date: Monday, 23 October 2023 at 14:56
To: ASSEMBL...@LISTSERV.UGA.EDU <ASSEMBL...@LISTSERV.UGA.EDU>
Subject: [EXTERNAL] Re: Variable-Length Parameter List Attributes

Unless otherwise stated above:

[Jon Perryman]

On Mon, 23 Oct 2023 09:55:54 -0400, Dave Clark <dlc...@WINSUPPLYINC.COM> wrote:

>SHVPARMB DS 5F
>SHVPLAST EQU *-4
>OI SHVPLAST,X'80'
> You have some other suggestion for how to handle this?

You must have other asm programs that create parmlists. My suggestion would be to remain consistent with those programs.