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
"IBM Mainframe Assembler List" 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
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
"IBM Mainframe Assembler List" 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
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
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
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
