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 <[email protected]> On Behalf 
Of Schmitt, Michael
Sent: Thursday, October 19, 2023 9:50 AM
To: [email protected]
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 <[email protected]> On Behalf 
Of Jonathan Scott

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

To: [email protected]

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

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.

Reply via email to