Re: LOAD with ADDR

[Paul Gilmartin]

(I assume you're quoting me without attribution.)

On Sat, 28 Aug 2021 10:20:17 -0400, Peter Relson wrote:

>
>If all callers access the GLOBAL module using LINK or ATTACH, CSV should  be 
>able
>to maintain use count and clean up when it reaches 0.
>
>
IOW, "GLOBAL" isn't entirely global.  I suppose that's a good thing..
If I were able to publish my own code as IEFBR14 GLOBAL I would
have the same power as if I could modify authorized libraries.

I could imagine allowing another address space to use my GLOBAL
module only if that job had the library from which I did the LOAD GLOBAL
first in its search order.  Too complicated.  (But that's akin to the
way UNIX shell builtins work.)

>The case of LINK or ATTACH is uninteresting because that had to come from 
>the address space (and jobstep) that did the LOAD in order to use the copy 
>that was loaded to global. 

>The "automatic cleanup" will happen after the 
>task issuing LINK or ATTACH has terminated (or at the very tail end of 
>that termination).
>The GLOBAL module is represented by a CDE on the loader's job pack queue. 
>There is no "global" use count that could be accessed from some other 
>address space. Such a global use count exists only for modules in LPA. And 
>that use count is "useless"; it has no intrinsic meaning (since LPA 
>modules can be "used" without LOAD). 
>
>
>A programmer must not cause an object to be fetched with LINK then BALR to 
>it in a concurrent thread.
>
>
>This is good advice but there are protocols that could be used if that 
>(for some bizarre reason) was needed.
>The same could be said to be true with LOAD for a thread that is not a 
>subtask of the loading task.
>It is the programmer's responsibility to make sure that the "owner task" 
>does not terminate while there could still be a "user task".

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Peter Relson]

If all callers access the GLOBAL module using LINK or ATTACH, CSV should 
be able
to maintain use count and clean up when it reaches 0.


The case of LINK or ATTACH is uninteresting because that had to come from 
the address space (and jobstep) that did the LOAD in order to use the copy 
that was loaded to global. The "automatic cleanup" will happen after the 
task issuing LINK or ATTACH has terminated (or at the very tail end of 
that termination).
The GLOBAL module is represented by a CDE on the loader's job pack queue. 
There is no "global" use count that could be accessed from some other 
address space. Such a global use count exists only for modules in LPA. And 
that use count is "useless"; it has no intrinsic meaning (since LPA 
modules can be "used" without LOAD). 


A programmer must not cause an object to be fetched with LINK then BALR to 
it in a concurrent thread.


This is good advice but there are protocols that could be used if that 
(for some bizarre reason) was needed.
The same could be said to be true with LOAD for a thread that is not a 
subtask of the loading task.
It is the programmer's responsibility to make sure that the "owner task" 
does not terminate while there could still be a "user task".

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Charles Mills]

It invites the possibility ...

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, August 27, 2021 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOAD with ADDR

On 8/27/2021 1:18 PM, Charles Mills wrote:
>> The BALR hazard exists even in the simple, non-GLOBAL case
> Yes, but it is isolated. There is one address space, and the owner of an 
> address space is always totally responsible for what goes on there. GLOBAL 
> is, well, global.

GLOBAL=YES does not imply more than one address space will be using the 
module, but that is a common case...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Ed Jaffe]

On 8/27/2021 1:18 PM, Charles Mills wrote:

The BALR hazard exists even in the simple, non-GLOBAL case

Yes, but it is isolated. There is one address space, and the owner of an 
address space is always totally responsible for what goes on there. GLOBAL is, 
well, global.


GLOBAL=YES does not imply more than one address space will be using the 
module, but that is a common case...


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



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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Charles Mills]

> The BALR hazard exists even in the simple, non-GLOBAL case

Yes, but it is isolated. There is one address space, and the owner of an 
address space is always totally responsible for what goes on there. GLOBAL is, 
well, global.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, August 27, 2021 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOAD with ADDR

On Fri, 27 Aug 2021 10:43:31 -0700, Charles Mills wrote:

>MVS provides no such serialization. 
>
>A GLOBAL=YES object "just is." It could be entered any way one chose: BALR, or 
>LINK, or ATTACH, or its data could be referenced with L and MVC.
>
>Here is the problem @Peter is referring to: once you make the code available 
>"globally" there is no general, supported way to put the toothpaste back into 
>the tube. You never know when some task is going to call the code, and 
>frankly, you don't know but what some task has called the code and halfway 
>through using it has become "not dispatched" but might wake up at any time and 
>continue using it.
>
If all callers access the GLOBAL module using LINK or ATTACH, CSV should be able
to maintain use count and clean up when it reaches 0.

The BALR hazard exists even in the simple, non-GLOBAL case.  A programmer must
not cause an object to be fetched with LINK then BALR to it in a concurrent 
thread.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Paul Gilmartin]

On Fri, 27 Aug 2021 10:43:31 -0700, Charles Mills wrote:

>MVS provides no such serialization. 
>
>A GLOBAL=YES object "just is." It could be entered any way one chose: BALR, or 
>LINK, or ATTACH, or its data could be referenced with L and MVC.
>
>Here is the problem @Peter is referring to: once you make the code available 
>"globally" there is no general, supported way to put the toothpaste back into 
>the tube. You never know when some task is going to call the code, and 
>frankly, you don't know but what some task has called the code and halfway 
>through using it has become "not dispatched" but might wake up at any time and 
>continue using it.
>
If all callers access the GLOBAL module using LINK or ATTACH, CSV should be able
to maintain use count and clean up when it reaches 0.

The BALR hazard exists even in the simple, non-GLOBAL case.  A programmer must
not cause an object to be fetched with LINK then BALR to it in a concurrent 
thread.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Charles Mills]

MVS provides no such serialization. 

A GLOBAL=YES object "just is." It could be entered any way one chose: BALR, or 
LINK, or ATTACH, or its data could be referenced with L and MVC.

Here is the problem @Peter is referring to: once you make the code available 
"globally" there is no general, supported way to put the toothpaste back into 
the tube. You never know when some task is going to call the code, and frankly, 
you don't know but what some task has called the code and halfway through using 
it has become "not dispatched" but might wake up at any time and continue using 
it.

What I am about to say is not IBM's supported position, but here goes. If you 
totally "control" (it's your code, in other words) all of the potential 
callers, then you could have some globally accessible (outside the module in 
question) "switch" that says "stop using the affected module." You -- the 
management code -- could set that switch and then wait "a little while." How 
long? Two seconds might be enough. Five seconds might be better. And then 
delete the module.

Here is the rub, and here is where IBM's position is different than what I 
wrote. Notice that I say "might." There is NO WAY OF KNOWING. Maybe you wait 
five seconds, and for some reason one of the using tasks gets delayed by six 
seconds and continues or starts referencing the module after it is deleted. 
With good luck it gets a S0C4. With bad luck -- or clever enough malice -- 
there is now some other code at that address and who knows what happens.

That is why *ever* deleting a "common" module is a system integrity violation. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, August 27, 2021 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOAD with ADDR

On Fri, 27 Aug 2021 08:36:10 -0400, Peter Relson wrote:

>
>LOAD with GLOBAL=YES also performs the same function flawlessly -- and 
>comes with the additional feature of automatic cleanup at termination 
>time (assuming that's the behavior you want).
>
>
>The "automatic cleanup at termination" is in almost 100% of cases 
>considered a system integrity error (or at least a RAS error) since it 
>requires a lot of care to be certain that no code can be executing within 
>that address range at the time of your termination ...
>
Could the GLOBAL=YES object be entered by LINK?  If so, should
CSV have a use count preventing cleanup?

"that address range" should include temporarily leaving that range
by CALL, etc.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Michael Stein]

On Fri, Aug 27, 2021 at 08:36:10AM -0400, Peter Relson wrote:
> 
> LOAD with GLOBAL=YES also performs the same function flawlessly -- and 
> comes with the additional feature of automatic cleanup at termination 
> time (assuming that's the behavior you want).
> 
> 
> The "automatic cleanup at termination" is in almost 100% of cases 
> considered a system integrity error (or at least a RAS error) since it 
> requires a lot of care to be certain that no code can be executing within 
> that address range at the time of your termination (and the accompanying 
> automatic cleanup). If the program within there is not currently 
> dispatched (or even if it is, but less likely), then the storage is reused 
> for "something else", upon re-dispatch results are (at best) 
> unpredictable. If you are lucky it will blow up.
> 
> So think very carefully before using LOAD with GLOBAL=YES.

Which is why UCLA/IPC used LOAD ADDR= back in 1984 with MVS/SP1.3.0.

https://cbttape.org/uclamail/ipcinst.txt

Also, for those who aren't using the new features for module loading
(nice), it can be helpful to do a BLDL before getting the storage.
This allows page alignment and other attributes to be checked and/or used
(as well as getting the module length).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Mike Hochee]

Wow! Who woulda thunk it, unless you actually been there?  Good to know. Thank 
you! 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Friday, August 27, 2021 8:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOAD with ADDR

Caution! This message was sent from outside your organization.


LOAD with GLOBAL=YES also performs the same function flawlessly -- and comes 
with the additional feature of automatic cleanup at termination time (assuming 
that's the behavior you want).


The "automatic cleanup at termination" is in almost 100% of cases considered a 
system integrity error (or at least a RAS error) since it requires a lot of 
care to be certain that no code can be executing within that address range at 
the time of your termination (and the accompanying automatic cleanup). If the 
program within there is not currently dispatched (or even if it is, but less 
likely), then the storage is reused for "something else", upon re-dispatch 
results are (at best) unpredictable. If you are lucky it will blow up.

So think very carefully before using LOAD with GLOBAL=YES.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Paul Gilmartin]

On Fri, 27 Aug 2021 08:36:10 -0400, Peter Relson wrote:

>
>LOAD with GLOBAL=YES also performs the same function flawlessly -- and 
>comes with the additional feature of automatic cleanup at termination 
>time (assuming that's the behavior you want).
>
>
>The "automatic cleanup at termination" is in almost 100% of cases 
>considered a system integrity error (or at least a RAS error) since it 
>requires a lot of care to be certain that no code can be executing within 
>that address range at the time of your termination ...
>
Could the GLOBAL=YES object be entered by LINK?  If so, should
CSV have a use count preventing cleanup?

"that address range" should include temporarily leaving that range
by CALL, etc.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Peter Relson]

LOAD with GLOBAL=YES also performs the same function flawlessly -- and 
comes with the additional feature of automatic cleanup at termination 
time (assuming that's the behavior you want).


The "automatic cleanup at termination" is in almost 100% of cases 
considered a system integrity error (or at least a RAS error) since it 
requires a lot of care to be certain that no code can be executing within 
that address range at the time of your termination (and the accompanying 
automatic cleanup). If the program within there is not currently 
dispatched (or even if it is, but less likely), then the storage is reused 
for "something else", upon re-dispatch results are (at best) 
unpredictable. If you are lucky it will blow up.

So think very carefully before using LOAD with GLOBAL=YES.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Charles Mills]

And both solve the RLD problem, which MVCL does not.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Thursday, August 26, 2021 9:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOAD with ADDR

On 8/26/2021 9:05 AM, Charles Mills wrote:
> EXACTLY what CSVDYLPA does flawlessly.

LOAD with GLOBAL=YES also performs the same function flawlessly -- and 
comes with the additional feature of automatic cleanup at termination 
time (assuming that's the behavior you want).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Ed Jaffe]

On 8/26/2021 9:05 AM, Charles Mills wrote:

EXACTLY what CSVDYLPA does flawlessly.


LOAD with GLOBAL=YES also performs the same function flawlessly -- and 
comes with the additional feature of automatic cleanup at termination 
time (assuming that's the behavior you want).


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



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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Ed Jaffe]

On 8/26/2021 7:03 AM, Peter Relson wrote:

Regardless, if you are doing a LOAD with ADDR you don't typically do a
LOAD to get the length to obtain (or a CSVQUERY after a LOAD). That is
very inefficient. You use the information in the directory entry returned
by BLDL or DESERV.


I discovered some years ago (the hard way with 0C4s and such  ) that 
the lengths returned by LOAD vs BLDL/DESERV can differ substantially (by 
the amount required to round up to a 4K boundary).


Specifically, it has to do with the settings of the [NO]PACK and 
[NO]PRIME binder options when accessing program objects from PDSE.


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



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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Charles Mills]

EXACTLY what CSVDYLPA does flawlessly.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Wednesday, August 25, 2021 7:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOAD with ADDR

I need these programs to be addressable from every address space 

BTW I checked and didn’t have 2 copies of that program which gave me a 
different length 

> On Aug 25, 2021, at 10:08 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Wed, 25 Aug 2021 22:01:17 -0400, Joseph Reichman wrote:
>>   ...
>> And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
>> to the area I wanted to load the proram) when I got the program OPENFILE
>> which had returned X'4000'  it now returned the correct length in R1 X'6A6'
>> multiply by 8
>> 
> How much are you saving by doing this?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Tom Brennan]

I figured someone would mention pre-LOAD vs. BLDL :)  In my case the 
efficiency didn't really matter.  It was a one-time load as the STC 
initialized things soon after IPL.  Most likely I looked at LOAD vs. 
BLDL where I had to code a build list and said "why bother when I can 
LOAD to get the length with less coding".  I'm pretty lazy.


P.S. Having IBMers like you and Jim here correcting us and giving their 
opinions and help is quite amazing.  Thanks for that.  I remember many 
years ago when IBM folks were probably told not to respond here other 
than to tell people to open a PMR.  This is so much better.


On 8/26/2021 7:03 AM, Peter Relson wrote:


Regardless, if you are doing a LOAD with ADDR you don't typically do a
LOAD to get the length to obtain (or a CSVQUERY after a LOAD). That is
very inefficient. You use the information in the directory entry returned
by BLDL or DESERV.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Peter Relson]

Since the OP's goal was to have a copy available to all address spaces, 
the best option is to use dynamic LPA (CSVDYLPA).
There are few, if any, reasons still to use LOAD with ADDR for common 
storage. In neither CSVDYLPA nor LOAD with ADDR is it generally safe ever 
to free the storage. And LOAD with GLOBAL=YES is even worse.

Anyone want to place a bet on whether the system did or did not "give ... 
an erroneous length of x'4000' "? I'd place my money on "gave a correct 
length". 

Regardless, if you are doing a LOAD with ADDR you don't typically do a 
LOAD to get the length to obtain (or a CSVQUERY after a LOAD). That is 
very inefficient. You use the information in the directory entry returned 
by BLDL or DESERV. 

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Joseph Reichman]

It’s was a PDSE I got the abend under TESTAUTH 

I can get the source and the target address 
Since I was at the starting points of my program and was loading my programs 

One of them was my general recovery routine meaning I had not established

An recovery routine as yet, I just saw the message displayed by TESTAUTH 

I think the translation exception Id would be in the SDWA 

As far D DIAG

Correct if I’m wrong but to do this I would have to establish an recovery and 
in it issue 
An SDUMP and include the SDWA 

I can do this tonite 

Thank you 



> On Aug 25, 2021, at 11:34 PM, Jim Mulder  wrote:
> 
>   If you want to know what is going on, you should 
> answer the questions that the z/OS 
> diagnosis expert (me) already asked:
> 
> Was the module loaded from a PDS, or from a PDSE?
> 
> What does the D DIAG  command display (or 
> VERBX IGVDGNIP   under IPCS)? 
> 
>  What was the source address and length for the MVCL? 
> 
>  What was the target address and length for the MVCL?
> 
>  What was the Translation Exception Id?
> 
>  From a dump, what was the length and address from the 
> system trace entry for the GETMAIN which obtained the module storage?
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
> 
> "IBM Mainframe Discussion List"  wrote on 
> 08/25/2021 10:41:37 PM:
> 
>> From: "Joseph Reichman" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date: 08/25/2021 11:18 PM
>> Subject: Re: LOAD with ADDR
>> Sent by: "IBM Mainframe Discussion List" 
>> 
>> That’s what originally had until I got a s0c4 noticed the length of 
>> one of the load modules was off
>> 
>> 
>> 
>>> On Aug 25, 2021, at 10:37 PM, Tom Brennan 
>>  wrote:
>>> 
>>> My old code that loaded common executables did a LOAD without 
>> ADDR just to get the length, then a DELETE, then a GETMAIN for CSA, 
>> then a LOAD with ADDR=
>>> 
>>> Don't know if this helps or not in your situation because all my 
>> code was written in assembler.
>>> 
>>>> On 8/25/2021 7:01 PM, Joseph Reichman wrote:
>>>> Hi
>>>> I am just posting this to report the issue I had LOAD ing a program 
> named
>>>> OPENFILE (Its Metal C Im sure that's not the issue) I had posted that 
> it
>>>> gave me erroneous length of X'4000'
>>>> When I did a browse in ISPF I saw it as 3530 same as the linkmap
>>>> I subsequently re-did my coding with help of those on the listserv 
> did a
>>>> BLDL to determine the length of all the programs I wanted to move to 
> CSA.
>>>> I then did a STORAGE from SP=228
>>>> And started doing LOAD EPLOC= DCB = and more importantly ADDR= 
>> (pointing it
>>>> to the area I wanted to load the proram) when I got the program 
> OPENFILE
>>>> which had returned X'4000'  it now returned the correct length inR1 
> X'6A6'
>>>> multiply by 8
>>>> Is 3530
>>>>  Thing is something is up Contents Supervisor (CSV)
>>>> thanks
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Jim Mulder]

  If you want to know what is going on, you should 
answer the questions that the z/OS 
diagnosis expert (me) already asked:

Was the module loaded from a PDS, or from a PDSE?

 What does the D DIAG  command display (or 
VERBX IGVDGNIP   under IPCS)? 

  What was the source address and length for the MVCL? 

  What was the target address and length for the MVCL?

  What was the Translation Exception Id?

  From a dump, what was the length and address from the 
system trace entry for the GETMAIN which obtained the module storage?

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
08/25/2021 10:41:37 PM:

> From: "Joseph Reichman" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/25/2021 11:18 PM
> Subject: Re: LOAD with ADDR
> Sent by: "IBM Mainframe Discussion List" 
> 
> That’s what originally had until I got a s0c4 noticed the length of 
> one of the load modules was off
> 
> 
> 
> > On Aug 25, 2021, at 10:37 PM, Tom Brennan 
>  wrote:
> > 
> > My old code that loaded common executables did a LOAD without 
> ADDR just to get the length, then a DELETE, then a GETMAIN for CSA, 
> then a LOAD with ADDR=
> > 
> > Don't know if this helps or not in your situation because all my 
> code was written in assembler.
> > 
> >> On 8/25/2021 7:01 PM, Joseph Reichman wrote:
> >>  Hi
> >>  I am just posting this to report the issue I had LOAD ing a program 
named
> >> OPENFILE (Its Metal C Im sure that's not the issue) I had posted that 
it
> >> gave me erroneous length of X'4000'
> >> When I did a browse in ISPF I saw it as 3530 same as the linkmap
> >>  I subsequently re-did my coding with help of those on the listserv 
did a
> >> BLDL to determine the length of all the programs I wanted to move to 
CSA.
> >>  I then did a STORAGE from SP=228
> >>  And started doing LOAD EPLOC= DCB = and more importantly ADDR= 
> (pointing it
> >> to the area I wanted to load the proram) when I got the program 
OPENFILE
> >> which had returned X'4000'  it now returned the correct length inR1 
X'6A6'
> >> multiply by 8
> >>  Is 3530
> >>   Thing is something is up Contents Supervisor (CSV)
> >>  thanks




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Tom Brennan]

Interesting... I never had that problem.  In fact, I think that code 
assembled and worked first time.  Just kidding... I hope that thread is 
finished now.


On 8/25/2021 7:41 PM, Joseph Reichman wrote:

That’s what originally had until I got a s0c4 noticed the length of one of the 
load modules was off




On Aug 25, 2021, at 10:37 PM, Tom Brennan  wrote:

My old code that loaded common executables did a LOAD without ADDR just to get 
the length, then a DELETE, then a GETMAIN for CSA, then a LOAD with ADDR=

Don't know if this helps or not in your situation because all my code was 
written in assembler.


On 8/25/2021 7:01 PM, Joseph Reichman wrote:
  Hi
  I am just posting this to report the issue I had LOAD ing a program named
OPENFILE (Its Metal C Im sure that's not the issue) I had posted that it
gave me erroneous length of X'4000'
When I did a browse in ISPF I saw it as 3530 same as the linkmap
  I subsequently re-did my coding with help of those on the listserv did a
BLDL to determine the length of all the programs I wanted to move to CSA.
  I then did a STORAGE from SP=228
  And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
to the area I wanted to load the proram) when I got the program OPENFILE
which had returned X'4000'  it now returned the correct length in R1 X'6A6'
multiply by 8
  Is 3530
   Thing is something is up Contents Supervisor (CSV)
  thanks
   _
  <https://home.mcafee.com/utm_medium=email_source=link_campaign=sig-e
mail_content=emailclient?utm_medium=email_source=link_campaign=s
ig-email_content=emailclient>Scanned by McAfee
<https://home.mcafee.com/utm_medium=email_source=link_campaign=sig-e
mail_content=emailclient?utm_medium=email_source=link_campaign=s
ig-email_content=emailclient>  and confirmed virus-free.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Joseph Reichman]

That’s what originally had until I got a s0c4 noticed the length of one of the 
load modules was off



> On Aug 25, 2021, at 10:37 PM, Tom Brennan  wrote:
> 
> My old code that loaded common executables did a LOAD without ADDR just to 
> get the length, then a DELETE, then a GETMAIN for CSA, then a LOAD with ADDR=
> 
> Don't know if this helps or not in your situation because all my code was 
> written in assembler.
> 
>> On 8/25/2021 7:01 PM, Joseph Reichman wrote:
>>  Hi
>>  I am just posting this to report the issue I had LOAD ing a program named
>> OPENFILE (Its Metal C Im sure that's not the issue) I had posted that it
>> gave me erroneous length of X'4000'
>> When I did a browse in ISPF I saw it as 3530 same as the linkmap
>>  I subsequently re-did my coding with help of those on the listserv did a
>> BLDL to determine the length of all the programs I wanted to move to CSA.
>>  I then did a STORAGE from SP=228
>>  And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
>> to the area I wanted to load the proram) when I got the program OPENFILE
>> which had returned X'4000'  it now returned the correct length in R1 X'6A6'
>> multiply by 8
>>  Is 3530
>>   Thing is something is up Contents Supervisor (CSV)
>>  thanks
>>   _
>>  <https://home.mcafee.com/utm_medium=email_source=link_campaign=sig-e
>> mail_content=emailclient?utm_medium=email_source=link_campaign=s
>> ig-email_content=emailclient>Scanned by McAfee
>> <https://home.mcafee.com/utm_medium=email_source=link_campaign=sig-e
>> mail_content=emailclient?utm_medium=email_source=link_campaign=s
>> ig-email_content=emailclient>  and confirmed virus-free.
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Tom Brennan]

My old code that loaded common executables did a LOAD without ADDR just 
to get the length, then a DELETE, then a GETMAIN for CSA, then a LOAD 
with ADDR=


Don't know if this helps or not in your situation because all my code 
was written in assembler.


On 8/25/2021 7:01 PM, Joseph Reichman wrote:
  


Hi

  


I am just posting this to report the issue I had LOAD ing a program named
OPENFILE (Its Metal C Im sure that's not the issue) I had posted that it
gave me erroneous length of X'4000'

When I did a browse in ISPF I saw it as 3530 same as the linkmap

  


I subsequently re-did my coding with help of those on the listserv did a
BLDL to determine the length of all the programs I wanted to move to CSA.

  


I then did a STORAGE from SP=228

  


And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
to the area I wanted to load the proram) when I got the program OPENFILE
which had returned X'4000'  it now returned the correct length in R1 X'6A6'
multiply by 8

  


Is 3530

  

   

  


Thing is something is up Contents Supervisor (CSV)

  


thanks


   _

  
<https://home.mcafee.com/utm_medium=email_source=link_campaign=sig-e

mail_content=emailclient?utm_medium=email_source=link_campaign=s
ig-email_content=emailclient>Scanned by McAfee
<https://home.mcafee.com/utm_medium=email_source=link_campaign=sig-e
mail_content=emailclient?utm_medium=email_source=link_campaign=s
ig-email_content=emailclient>  and confirmed virus-free. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Joseph Reichman]

I need these programs to be addressable from every address space 

BTW I checked and didn’t have 2 copies of that program which gave me a 
different length 

> On Aug 25, 2021, at 10:08 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Wed, 25 Aug 2021 22:01:17 -0400, Joseph Reichman wrote:
>>   ...
>> And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
>> to the area I wanted to load the proram) when I got the program OPENFILE
>> which had returned X'4000'  it now returned the correct length in R1 X'6A6'
>> multiply by 8
>> 
> How much are you saving by doing this?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD with ADDR

[Paul Gilmartin]

On Wed, 25 Aug 2021 22:01:17 -0400, Joseph Reichman wrote:
>...
>And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
>to the area I wanted to load the proram) when I got the program OPENFILE
>which had returned X'4000'  it now returned the correct length in R1 X'6A6'
>multiply by 8
> 
How much are you saving by doing this?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

LOAD with ADDR

[Joseph Reichman]

 

Hi

 

I am just posting this to report the issue I had LOAD ing a program named
OPENFILE (Its Metal C Im sure that's not the issue) I had posted that it
gave me erroneous length of X'4000' 

When I did a browse in ISPF I saw it as 3530 same as the linkmap

 

I subsequently re-did my coding with help of those on the listserv did a
BLDL to determine the length of all the programs I wanted to move to CSA.

 

I then did a STORAGE from SP=228

 

And started doing LOAD EPLOC= DCB = and more importantly ADDR= (pointing it
to the area I wanted to load the proram) when I got the program OPENFILE
which had returned X'4000'  it now returned the correct length in R1 X'6A6'
multiply by 8 

 

Is 3530

 

  

 

Thing is something is up Contents Supervisor (CSV)

 

thanks


  _  

 
   Scanned by McAfee
  and confirmed virus-free.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN