CSVQUERY OUTLENGTH that "The length returned is the number
of bytes used to contain the module. This size can be different depending
on whether the module was loaded from a PDS or a PDSE." That doesn't sound
like the number I need to put on a STORAGE OBTAIN. I need the length of
the
module *as
; From: "Seymour J Metz"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/09/2019 02:32 PM
> Subject: Re: LOADing a module into common storage
> Sent by: "IBM Mainframe Discussion List"
>
> When did that change? It used to be that MLPA was subject to pageout.
>
&
@LISTSERV.UA.EDU
Subject: Re: LOADing a module into common storage
Stores into unfixed static PLPA/MLPA are lost if a frame is stolen,
because RSM
recognizes the address ranges of static PLPA/MLPA and treats them
differently.
Dynamic LPA processing loads the modules into ordinary CSA storage. RSM
knows
Stores into unfixed static PLPA/MLPA are lost if a frame is stolen,
because RSM
recognizes the address ranges of static PLPA/MLPA and treats them
differently.
Dynamic LPA processing loads the modules into ordinary CSA storage. RSM
knows nothing about Dynamic LPA, so stores into Dynamic
are irrelevant for a directed load.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Tony Harminc
Sent: Thursday, August 8, 2019 6:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOADing a module
On Thu, 8 Aug 2019 at 07:35, Peter Relson wrote:
> Roughly forever, the way to do this has not been to do two LOADs. It had
> been to do a BLDL, extract the length information (and the RMODE
> information and the Page boundary information) from the directory entry,
> do a suitable storage
PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LOADing a module into common storage
Roughly forever we've loaded modules into 24- or 31-bit CSA by first
LOADing the module normally into private storage, obtaining the actual
length from the LOAD, DELETEing the module, getting the necessary CSA
storage
-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, August 8, 2019 7:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOADing a module into common storage
Roughly forever, the way to do this has not been to do two LOADs. It had
been
Subject: Re: LOADing a module into common storage
Roughly forever, the way to do this has not been to do two LOADs. It had
been to do a BLDL, extract the length information (and the RMODE
information and the Page boundary information) from the directory entry,
do a suitable storage obtain, then do
Roughly forever, the way to do this has not been to do two LOADs. It had
been to do a BLDL, extract the length information (and the RMODE
information and the Page boundary information) from the directory entry,
do a suitable storage obtain, then do a LOAD with ADDR (or even, more
recently,
On Wed, Aug 07, 2019 at 06:55:53PM -0400, Tony Harminc wrote:
> Roughly forever we've loaded modules into 24- or 31-bit CSA by first
> LOADing the module normally into private storage, obtaining the actual
> length from the LOAD, DELETEing the module, getting the necessary CSA
> storage, and
Roughly forever we've loaded modules into 24- or 31-bit CSA by first
LOADing the module normally into private storage, obtaining the actual
length from the LOAD, DELETEing the module, getting the necessary CSA
storage, and finally using LOAD with ADDR=. This works fine, but seems
unduly
12 matches
Mail list logo