DC and DS in load modules? 
Author Message
 DC and DS in load modules?

There was a question some time ago about when the bytes get
filled in for DS.

I am pretty sure that they don't get written into the object module,
but I don't know any more, or maybe it was never decided, if they
got filled in by the linker before writing the object module.

The question came up over the efficiency of initializing static vs.
automatic varaibles.  How much work does program fetch have to do
when initializing a static variable (DC) with DS on either side?

I decided to post here first, instead of ibm-main.

thanks,

-- glen



Mon, 03 Mar 2003 03:00:00 GMT  
 DC and DS in load modules?
I looked this up a long time ago and discovered that the
loader (via exec pgm=) puts a piece at a time from disk
to memory, leaving appropriate spaces for the DS areas.
They don't exist on disk, nor do they get "filled in."
Whatever was there before is what is left for you to
reference via those DS labels, those offsets from your
base register. (At the time, this was a major military
concern: from a security standpoint, memory had to be
zeroed before the next program could be loaded there.)


Quote:

>There was a question some time ago about when the bytes get
>filled in for DS.

>I am pretty sure that they don't get written into the object module,
>but I don't know any more, or maybe it was never decided, if they
>got filled in by the linker before writing the object module.

>The question came up over the efficiency of initializing static vs.
>automatic varaibles.  How much work does program fetch have to do
>when initializing a static variable (DC) with DS on either side?

>I decided to post here first, instead of ibm-main.

>thanks,

>-- glen

--
Alex Vrenios, kx9i
1998 PC800: Kazesan
HRCA MBR # HM726120
PCRC Registry #1002


Mon, 03 Mar 2003 03:00:00 GMT  
 DC and DS in load modules?
glen writes ...

Quote:
>There was a question some time ago about when the bytes get
>filled in for DS.

>I am pretty sure that they don't get written into the object module,
>but I don't know any more, or maybe it was never decided, if they
>got filled in by the linker before writing the object module.

>The question came up over the efficiency of initializing static vs.
>automatic varaibles.  How much work does program fetch have to do
>when initializing a static variable (DC) with DS on either side?

Glen, I think the object code for DS's simply leaves gaps. That is, when a DS
is encountered, a new text record is started specifying the beginning offset as
the first non-DS location after the DS (or series of DS) instruction(s).
However, I seem to recall running some experiments where the behavior depended
on the size of the unitialized field. That is, there was some minimal size of
gap required before you would actually see this behavior (and this minimum size
varied by language, I also seem to recall). But it may be only faulty memory
here.

At program load time, the fetch routine skips over the gaps; whatever was there
before is there now. So no special work is required. I also believe that the
first time a virtual page is obtained for a task, it is initialized to binary
zeros, but that afterwords no resetting occurs; so the odds seem high DS's get
initialized to binary zeros, but there are no guarantees.

Note that the program binder has a FILL option that applies to program objects,
which can fill the gap fields at fetch time with a character you specify at
bind time.

Hope this helps. I also hope it's reasonably accurate.

Regards,

Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com

256-B S. Monaco Parkway
Denver, CO 80224
USA



Tue, 04 Mar 2003 03:00:00 GMT  
 DC and DS in load modules?

Quote:

>I looked this up a long time ago and discovered that the
>loader (via exec pgm=) puts a piece at a time from disk
>to memory, leaving appropriate spaces for the DS areas.
>They don't exist on disk, nor do they get "filled in."
>Whatever was there before is what is left for you to
>reference via those DS labels, those offsets from your
>base register. (At the time, this was a major military
>concern: from a security standpoint, memory had to be
>zeroed before the next program could be loaded there.)

So if you did something like:

   DC C' '
   DS C
   DC C' '
   DS C
   DC C' '
   DS C
   DC C' '
   DS C
   DC C' '

The load module would contain a separate record for each DC?
That would be the only way it could leave the DS alone.  Otherwise
they would have to be filled in by the link editor (or binder) before
writing the load module.  

The overhead for generating a separate record for the load module
for each would seem pretty large.

Quote:


>>There was a question some time ago about when the bytes get
>>filled in for DS.

>>I am pretty sure that they don't get written into the object module,
>>but I don't know any more, or maybe it was never decided, if they
>>got filled in by the linker before writing the object module.



Tue, 04 Mar 2003 03:00:00 GMT  
 DC and DS in load modules?
From what I have seen, I think that the DS storage gets whatever was there
when the OBJ was being built.  In other words it depends on the storage at
assembly time when the assembler is generating the object module.  This may
only occur for the smaller fields as indicated in several other responses
but my observation has been that the storage at assembly time is
uninitialized and whatever was there becomes a permanent part of the object
module.

--
Christopher J Pomasl
PRF Architect
Computer Associates International, inc.


Quote:
> glen writes ...

> >There was a question some time ago about when the bytes get
> >filled in for DS.

> >I am pretty sure that they don't get written into the object module,
> >but I don't know any more, or maybe it was never decided, if they
> >got filled in by the linker before writing the object module.

> >The question came up over the efficiency of initializing static vs.
> >automatic varaibles.  How much work does program fetch have to do
> >when initializing a static variable (DC) with DS on either side?

> Glen, I think the object code for DS's simply leaves gaps. That is, when a
DS
> is encountered, a new text record is started specifying the beginning
offset as
> the first non-DS location after the DS (or series of DS) instruction(s).
> However, I seem to recall running some experiments where the behavior
depended
> on the size of the unitialized field. That is, there was some minimal size
of
> gap required before you would actually see this behavior (and this minimum
size
> varied by language, I also seem to recall). But it may be only faulty
memory
> here.

> At program load time, the fetch routine skips over the gaps; whatever was
there
> before is there now. So no special work is required. I also believe that
the
> first time a virtual page is obtained for a task, it is initialized to
binary
> zeros, but that afterwords no resetting occurs; so the odds seem high DS's
get
> initialized to binary zeros, but there are no guarantees.

> Note that the program binder has a FILL option that applies to program
objects,
> which can fill the gap fields at fetch time with a character you specify
at
> bind time.

> Hope this helps. I also hope it's reasonably accurate.

> Regards,

> Steve Comstock
> Telephone: 303-393-8716
> www.trainersfriend.com

> 256-B S. Monaco Parkway
> Denver, CO 80224
> USA



Tue, 04 Mar 2003 03:00:00 GMT  
 DC and DS in load modules?

Quote:
>From what I have seen, I think that the DS storage gets whatever was there
>when the OBJ was being built.  In other words it depends on the storage at
>assembly time when the assembler is generating the object module.  This may
>only occur for the smaller fields as indicated in several other responses
>but my observation has been that the storage at assembly time is
>uninitialized and whatever was there becomes a permanent part of the object
>module.

I am pretty sure that this can't be. One, because of the fun things you
can do with ORG.  Well, it would be easy to check if you do an ORG
backwards, and then overwrite with a combination of DC and DS.
This should be documented as an assembler feature.

I am not sure what would be required for load modules, though.  If you
do a LOAD of a load module containing DS, into a previously initialized
region, would one expect the DS regions not to overwrite what was there?

-- glen



Tue, 04 Mar 2003 03:00:00 GMT  
 DC and DS in load modules?
The question of what a load module contains for a DS defined area
 is highly dependent on the operating system, the version of the
Linkage editor/loader and possibly many other things.

Some 20 years ago when I was working with the various DOS,
DOS/VS and VSE systems I remember the load modules were
in core image format (contiguous load blocks), and the contents of
DS areas was what happened to come from the previous use of the
SYSLNK dataset on which the module was built. LNKEDT had a
special parameter (action clear) which enabled the user to specify
that the entire dataset should be cleared to low-values before linkage
started. This was a time-consuming process which I remember
was required when building a supervisor.

The various MVS systems use relocatable load modules like the OBJ
modules from the assembler which do not contain any assembled
data for DS. It is only a matter of implentation if the linker detects
(small) DS gaps and optimizes the load module by filling in (random)
data to those areas instead of breaking up the load module.

The bottom line is what is claimed in the assembler manuals: The
contents of a DS area is unpredictable.

BTW: If the same area (by means of ORG) is covered by a
number of DS and/or DC statements its final contents will be
determined from the last DC statement in question, no DS
statement will have any effect on the contents.

regards Sven


Quote:

> >From what I have seen, I think that the DS storage gets whatever was
there
> >when the OBJ was being built.  In other words it depends on the storage
at
> >assembly time when the assembler is generating the object module.  This
may
> >only occur for the smaller fields as indicated in several other responses
> >but my observation has been that the storage at assembly time is
> >uninitialized and whatever was there becomes a permanent part of the
object
> >module.

> I am pretty sure that this can't be. One, because of the fun things you
> can do with ORG.  Well, it would be easy to check if you do an ORG
> backwards, and then overwrite with a combination of DC and DS.
> This should be documented as an assembler feature.

> I am not sure what would be required for load modules, though.  If you
> do a LOAD of a load module containing DS, into a previously initialized
> region, would one expect the DS regions not to overwrite what was there?

> -- glen



Wed, 05 Mar 2003 03:00:00 GMT  
 DC and DS in load modules?


Quote:
> There was a question some time ago about when the bytes get
> filled in for DS.

> I am pretty sure that they don't get written into the object module,
> but I don't know any more, or maybe it was never decided, if they
> got filled in by the linker before writing the object module.

> The question came up over the efficiency of initializing static vs.
> automatic varaibles.  How much work does program fetch have to do
> when initializing a static variable (DC) with DS on either side?

> I decided to post here first, instead of ibm-main.

> thanks,

> -- glen

The MVS linkage editor builds a series of records that contain what is
going to be loaded into memory at execution time.  If several CSECTs are
being linked together, it will put as many CSECTs on one record as it
can without exceeding the dataset blocksize or 18K (whichever is
smaller).  The only time I have ever seen it split a single CSECT into
multiple records is when the CSECT exceeds the dataset blocksize or 18K
(whichever is smaller).

It is possible that the 18K limit may have been increased since I last
investigated this.

Bob McAdams
Fambright

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 05 Mar 2003 03:00:00 GMT  
 DC and DS in load modules?

Quote:
>> [...]
>> At program load time, the fetch routine skips over the gaps;
>> whatever was there before is there now. So no special work
>> is required. [...]

The CCWs are (used to be) a string of chained reads, called
a "scatter read" that gets and positions a bunch of records
from disk into appropriately spaced locations in memory. At
load module creation time the reverse is true: chained writes
called "collect write" is used. These are good keywords for
some research into older manuals if this has changed by now.

Regards,

Alex Vrenios
Ph.D. Candidate
ASU CSE Department

--
Alex Vrenios, kx9i
1998 PC800: Kazesan
HRCA MBR # HM726120
PCRC Registry #1002



Thu, 13 Mar 2003 09:45:06 GMT  
 DC and DS in load modules?
I do not believe there was ever any such capability, at least in OS/360
or its successor systems.

Unless the load module is linked in the "scatter" format, it
consists of a chain of text blocks, generally in increasing order by
the load address of the text block, interspersed with blocks containing
some combination of address relocation information, control information
(the address and length of the next text block, for the most part),
or both types of information.

The purpose of a "scatter" format load module was to allow program fetch
to scatter the sections of a load module into non-contuguous storage
locations.  This was important in the storage constrained days of MVT
type operating systems, but the capability of program fetch to scatter
load has been eliminated for some time, even if the load module is linked
in the scatter format.  The scatter format was used mainly for the special
case load module, the nucleus, but the nucleus is not loaded by program
fetch.

Program fetch had a capability called PCI chained scheduling.  In
theory, this would allow a control record to be used to generate the
CCW for the next text record without interrupting the channel
connection.  In practice, this never worked reliably, and was eliminated
in the late 70s.  It was replaced by a variation in the load module
structure that would allow command chaining to be used to read a text
record and all related RLD and control records in a single I/O event.

The Linkage Editor never had any capability of performing "chained writes."

The only method available for the Linkage Editor to improve both its
performance, as well as the performance of program fetch, was to write text
records that are as large as possible.


[snip]

Quote:

>The CCWs are (used to be) a string of chained reads, called
>a "scatter read" that gets and positions a bunch of records
>from disk into appropriately spaced locations in memory. At
>load module creation time the reverse is true: chained writes
>called "collect write" is used. These are good keywords for
>some research into older manuals if this has changed by now.

>Regards,

>Alex Vrenios
>Ph.D. Candidate
>ASU CSE Department

>--
>Alex Vrenios, kx9i
>1998 PC800: Kazesan
>HRCA MBR # HM726120
>PCRC Registry #1002



Thu, 13 Mar 2003 11:11:02 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. what to set ds and es to after loading an exe

2. Loading code segments into DS

3. Loading code segments into DS

4. ds ds

5. Module information in load-module

6. DC - Contract - VisualWork Smalltalk, Washington DC-Principals Only

7. Off topic : D.C. in Washington D.C ?

8. PDS load module records

9. Using DB2 in a load module in MVS Batch and CICS

10. OPEN - BLDL - LOAD getting the wrong module

11. FTP of IBM load modules

12. FTP of IBM Load Modules

 

 
Powered by phpBB® Forum Software