Discussion:
UserKEY CSA/Dataspace scope=common Remdiation
(too old to reply)
Jousma, David
2018-05-15 16:52:10 UTC
Permalink
Raw Message
Ok, quick eye-ball verification from the guru's that are better ASM programmer than I...

SMF30 RAXFLAGS is kicking out the a module for which I selectively pulled out the DSPSERV code for allocating USERKEY SCOPE=COMMON Data space. Is it possible that this line "DSPSERV DC A(*+4+X'80000000')" is what is setting the storage key just prior to execution? i.e. KEY 8? I didn't create the code, I'm just trying to understand it.

MODESET MODE=SUP SET TO SUPERVISOR STATE
L R15,DSPSERV INSURE 31 BIT MODE
BSM 0,R15 SET 31 BIT MODE
DSPSERV DC A(*+4+X'80000000')
*
DSPSERV CREATE, CREATE A DATA SPACE
STOKEN=DSPSTOKN, PUT STOKEN HERE
NAME=DSPNAME, USE THIS NAME
ORIGIN=DSPORIGN, PLACE ORIGIN ADDRESS HERE
SCOPE=COMMON, COMMON DATA SPACE
BLOCKS=(DSPBLCKS,DSPBLCKS) THIS MAX AND INITIAL
*
ST R15,RETCODE SAVE THE RETURN CODE
ST R0,REASCODE SAVE THE REASON CODE
MODESET MODE=PROB SET TO PROBLEM PROGRAM STATE


Alternatively, I know the DataSpace names that are being allocated from a D A,stcname. Again, this is territory I don't tread into often, but is there an easy way to determine the storage key of them?

Thanks, Dave
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

This e-mail transmission contains information that is confidential and may be privileged.
It is intended only for the addressee(s) named above. If you receive this e-mail in error,
please do not read, copy or disseminate it in any manner. If you are not the intended
recipient, any disclosure, copying, distribution or use of the contents of this information
is prohibited. Please reply to the message immediately by informing the sender that the
message was misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jousma, David
2018-05-15 17:48:44 UTC
Permalink
Raw Message
Nevermind on this. I found an old Jim Mulder posting to this group that indicates that all SCOPE=COMMON Data space allocations will fail on V2.4 and has nothing to do with VSM ALLOWUSERKEYCSA(YES/NO). For some reason in my mind I was trying to tie this all together...

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

From: Jousma, David
Sent: Tuesday, May 15, 2018 12:54 PM
To: IBM-Main (ibm-***@listserv.ua.edu) <ibm-***@listserv.ua.edu>
Subject: UserKEY CSA/Dataspace scope=common Remdiation

Ok, quick eye-ball verification from the guru's that are better ASM programmer than I...

SMF30 RAXFLAGS is kicking out the a module for which I selectively pulled out the DSPSERV code for allocating USERKEY SCOPE=COMMON Data space. Is it possible that this line "DSPSERV DC A(*+4+X'80000000')" is what is setting the storage key just prior to execution? i.e. KEY 8? I didn't create the code, I'm just trying to understand it.

MODESET MODE=SUP SET TO SUPERVISOR STATE
L R15,DSPSERV INSURE 31 BIT MODE
BSM 0,R15 SET 31 BIT MODE
DSPSERV DC A(*+4+X'80000000')
*
DSPSERV CREATE, CREATE A DATA SPACE
STOKEN=DSPSTOKN, PUT STOKEN HERE
NAME=DSPNAME, USE THIS NAME
ORIGIN=DSPORIGN, PLACE ORIGIN ADDRESS HERE
SCOPE=COMMON, COMMON DATA SPACE
BLOCKS=(DSPBLCKS,DSPBLCKS) THIS MAX AND INITIAL
*
ST R15,RETCODE SAVE THE RETURN CODE
ST R0,REASCODE SAVE THE REASON CODE
MODESET MODE=PROB SET TO PROBLEM PROGRAM STATE


Alternatively, I know the DataSpace names that are being allocated from a D A,stcname. Again, this is territory I don't tread into often, but is there an easy way to determine the storage key of them?

Thanks, Dave
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

This e-mail transmission contains information that is confidential and may be privileged.
It is intended only for the addressee(s) named above. If you receive this e-mail in error,
please do not read, copy or disseminate it in any manner. If you are not the intended
recipient, any disclosure, copying, distribution or use of the contents of this information
is prohibited. Please reply to the message immediately by informing the sender that the
message was misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jousma, David
2018-05-15 17:55:27 UTC
Permalink
Raw Message
One more time.... All *user-key SCOPE=COMMON dataspaces.

Jim Mulder

Apr 5

Re: [EXTERNAL] Re: UA94606
VSM ALLOWUSERKEYCSA(NO)

only prevents obtaining user key CSA.
It does not prevent creating a user key CADS, or using CHANGKEY
to change the key of subpool 247 or 248 (DREF SQA) storage to
user key.

The health check and the new SMF 30 field report all three of those
types of security issues, and all three will be disallowed in the next
release after z/OS 2.3.

So I would think that you would want to keep the health check enabled.


_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

From: Jousma, David
Sent: Tuesday, May 15, 2018 1:50 PM
To: IBM-Main (ibm-***@listserv.ua.edu) <ibm-***@listserv.ua.edu>
Subject: RE: UserKEY CSA/Dataspace scope=common Remdiation

Nevermind on this. I found an old Jim Mulder posting to this group that indicates that all SCOPE=COMMON Data space allocations will fail on V2.4 and has nothing to do with VSM ALLOWUSERKEYCSA(YES/NO). For some reason in my mind I was trying to tie this all together...

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

From: Jousma, David
Sent: Tuesday, May 15, 2018 12:54 PM
To: IBM-Main (ibm-***@listserv.ua.edu<mailto:ibm-***@listserv.ua.edu>) <ibm-***@listserv.ua.edu<mailto:ibm-***@listserv.ua.edu>>
Subject: UserKEY CSA/Dataspace scope=common Remdiation

Ok, quick eye-ball verification from the guru's that are better ASM programmer than I...

SMF30 RAXFLAGS is kicking out the a module for which I selectively pulled out the DSPSERV code for allocating USERKEY SCOPE=COMMON Data space. Is it possible that this line "DSPSERV DC A(*+4+X'80000000')" is what is setting the storage key just prior to execution? i.e. KEY 8? I didn't create the code, I'm just trying to understand it.

MODESET MODE=SUP SET TO SUPERVISOR STATE
L R15,DSPSERV INSURE 31 BIT MODE
BSM 0,R15 SET 31 BIT MODE
DSPSERV DC A(*+4+X'80000000')
*
DSPSERV CREATE, CREATE A DATA SPACE
STOKEN=DSPSTOKN, PUT STOKEN HERE
NAME=DSPNAME, USE THIS NAME
ORIGIN=DSPORIGN, PLACE ORIGIN ADDRESS HERE
SCOPE=COMMON, COMMON DATA SPACE
BLOCKS=(DSPBLCKS,DSPBLCKS) THIS MAX AND INITIAL
*
ST R15,RETCODE SAVE THE RETURN CODE
ST R0,REASCODE SAVE THE REASON CODE
MODESET MODE=PROB SET TO PROBLEM PROGRAM STATE


Alternatively, I know the DataSpace names that are being allocated from a D A,stcname. Again, this is territory I don't tread into often, but is there an easy way to determine the storage key of them?

Thanks, Dave
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

This e-mail transmission contains information that is confidential and may be privileged.
It is intended only for the addressee(s) named above. If you receive this e-mail in error,
please do not read, copy or disseminate it in any manner. If you are not the intended
recipient, any disclosure, copying, distribution or use of the contents of this information
is prohibited. Please reply to the message immediately by informing the sender that the
message was misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Vernooij, Kees - KLM , ITOPT1
2018-05-16 06:44:53 UTC
Permalink
Raw Message
So: '2.4' is not equal to 'the next release after 2.3'?
Come on, when will you reveal the name of the new baby? (I just became grandpa, I love babies again).

Grtn,
Kees.
-----Original Message-----
Behalf Of Jousma, David
Sent: 15 May, 2018 19:57
Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation
One more time.... All *user-key SCOPE=COMMON dataspaces.
Jim Mulder
Apr 5
Re: [EXTERNAL] Re: UA94606
VSM ALLOWUSERKEYCSA(NO)
only prevents obtaining user key CSA.
It does not prevent creating a user key CADS, or using CHANGKEY
to change the key of subpool 247 or 248 (DREF SQA) storage to
user key.
The health check and the new SMF 30 field report all three of those
types of security issues, and all three will be disallowed in the next
release after z/OS 2.3.
So I would think that you would want to keep the health check enabled.
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717
From: Jousma, David
Sent: Tuesday, May 15, 2018 1:50 PM
Subject: RE: UserKEY CSA/Dataspace scope=common Remdiation
Nevermind on this. I found an old Jim Mulder posting to this group
that indicates that all SCOPE=COMMON Data space allocations will fail on
V2.4 and has nothing to do with VSM ALLOWUSERKEYCSA(YES/NO). For some
reason in my mind I was trying to tie this all together...
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717
From: Jousma, David
Sent: Tuesday, May 15, 2018 12:54 PM
Subject: UserKEY CSA/Dataspace scope=common Remdiation
Ok, quick eye-ball verification from the guru's that are better ASM programmer than I...
SMF30 RAXFLAGS is kicking out the a module for which I selectively
pulled out the DSPSERV code for allocating USERKEY SCOPE=COMMON Data
space. Is it possible that this line "DSPSERV DC
A(*+4+X'80000000')" is what is setting the storage key just prior to
execution? i.e. KEY 8? I didn't create the code, I'm just trying to
understand it.
MODESET MODE=SUP SET TO SUPERVISOR STATE
L R15,DSPSERV INSURE 31 BIT MODE
BSM 0,R15 SET 31 BIT MODE
DSPSERV DC A(*+4+X'80000000')
*
DSPSERV CREATE, CREATE A DATA SPACE
STOKEN=DSPSTOKN, PUT STOKEN HERE
NAME=DSPNAME, USE THIS NAME
ORIGIN=DSPORIGN, PLACE ORIGIN ADDRESS HERE
SCOPE=COMMON, COMMON DATA SPACE
BLOCKS=(DSPBLCKS,DSPBLCKS) THIS MAX AND INITIAL
*
ST R15,RETCODE SAVE THE RETURN CODE
ST R0,REASCODE SAVE THE REASON CODE
MODESET MODE=PROB SET TO PROBLEM PROGRAM STATE
Alternatively, I know the DataSpace names that are being allocated from
a D A,stcname. Again, this is territory I don't tread into often, but
is there an easy way to determine the storage key of them?
Thanks, Dave
_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H
p 616.653.8429
f 616.653.2717
This e-mail transmission contains information that is confidential and may be privileged.
It is intended only for the addressee(s) named above. If you receive this e-mail in error,
please do not read, copy or disseminate it in any manner. If you are not the intended
recipient, any disclosure, copying, distribution or use of the contents of this information
is prohibited. Please reply to the message immediately by informing the sender that the
message was misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
********************************************************
For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
********************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2018-05-16 11:54:47 UTC
Permalink
Raw Message
So post z/OS 2.3 only programs in system keys (0-7) will be able to access
common dataspaces? What happens if you specify FPROT=NO on DSPSERV?

Thanks
Robin
-----Original Message-----
Behalf Of Jousma, David
Sent: 15 May, 2018 19:57
Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation
One more time.... All *user-key SCOPE=COMMON dataspaces.
Jim Mulder
Apr 5
Re: [EXTERNAL] Re: UA94606
VSM ALLOWUSERKEYCSA(NO)
only prevents obtaining user key CSA.
It does not prevent creating a user key CADS, or using CHANGKEY
to change the key of subpool 247 or 248 (DREF SQA) storage to
user key.
The health check and the new SMF 30 field report all three of those
types of security issues, and all three will be disallowed in the next
release after z/OS 2.3.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2018-05-16 15:39:21 UTC
Permalink
Raw Message
Post z/OS 2.3, only programs in system keys (0-7) will be able
to store into common dataspaces (and CSA). Non-fetch protected system
key SCOPE=COMMON data spaces (and non-fetch protected system
key CSA) continue to be supported.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Date: 05/16/2018 11:28 AM
Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation
So post z/OS 2.3 only programs in system keys (0-7) will be able to access
common dataspaces? What happens if you specify FPROT=NO on DSPSERV?
Thanks
Robin
-----Original Message-----
Behalf Of Jousma, David
Sent: 15 May, 2018 19:57
Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation
One more time.... All *user-key SCOPE=COMMON dataspaces.
Jim Mulder
Apr 5
Re: [EXTERNAL] Re: UA94606
VSM ALLOWUSERKEYCSA(NO)
only prevents obtaining user key CSA.
It does not prevent creating a user key CADS, or using CHANGKEY
to change the key of subpool 247 or 248 (DREF SQA) storage to
user key.
The health check and the new SMF 30 field report all three of those
types of security issues, and all three will be disallowed in the next
release after z/OS 2.3.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2018-05-17 07:03:37 UTC
Permalink
Raw Message
Jim-
Thanks for the clarification.

Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: 16 May 2018 22:41
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation

Post z/OS 2.3, only programs in system keys (0-7) will be able
to store into common dataspaces (and CSA). Non-fetch protected system
key SCOPE=COMMON data spaces (and non-fetch protected system
key CSA) continue to be supported.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Date: 05/16/2018 11:28 AM
Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation
So post z/OS 2.3 only programs in system keys (0-7) will be able to access
common dataspaces? What happens if you specify FPROT=NO on DSPSERV?
Thanks
Robin
-----Original Message-----
Behalf Of Jousma, David
Sent: 15 May, 2018 19:57
Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation
One more time.... All *user-key SCOPE=COMMON dataspaces.
Jim Mulder
Apr 5
Re: [EXTERNAL] Re: UA94606
VSM ALLOWUSERKEYCSA(NO)
only prevents obtaining user key CSA.
It does not prevent creating a user key CADS, or using CHANGKEY
to change the key of subpool 247 or 248 (DREF SQA) storage to
user key.
The health check and the new SMF 30 field report all three of those
types of security issues, and all three will be disallowed in the next
release after z/OS 2.3.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2018-05-15 19:51:06 UTC
Permalink
Raw Message
On 15 May 2018 at 12:53, Jousma, David
Post by Jousma, David
SMF30 RAXFLAGS is kicking out the a module for which I selectively pulled out the DSPSERV code for allocating USERKEY SCOPE=COMMON Data space. Is it possible that this line "DSPSERV DC A(*+4+X'80000000')" is what is setting the storage key just prior to execution? i.e. KEY 8? I didn't create the code, I'm just trying to understand it.
MODESET MODE=SUP SET TO SUPERVISOR STATE
L R15,DSPSERV INSURE 31 BIT MODE
BSM 0,R15 SET 31 BIT MODE
DSPSERV DC A(*+4+X'80000000')
*
DSPSERV CREATE, CREATE A DATA SPACE
...

The A(*+4+X'80000000') is just the address of the instruction
following the adcon (in this case whatever the DSPSERV CREATE expands
to), with the high bit on to indicate 31-bit mode. The BSM, uh
Branches and Sets Mode. These days you can just use the SAM31
instruction, but that and its friends SAM24 and SAM64 didn't come
along until zArch.

The adcon's X'80000000' has nothing to do with the key of the data space.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-05-15 21:01:17 UTC
Permalink
Raw Message
Post by Jousma, David
Ok, quick eye-ball verification from the guru's that are better ASM programmer than I...
SMF30 RAXFLAGS is kicking out the a module for which I selectively pulled out the DSPSERV code for allocating USERKEY SCOPE=COMMON Data space. Is it possible that this line "DSPSERV DC A(*+4+X'80000000')" is what is setting the storage key just prior to execution? i.e. KEY 8? I didn't create the code, I'm just trying to understand it.
MODESET MODE=SUP SET TO SUPERVISOR STATE
L R15,DSPSERV INSURE 31 BIT MODE
BSM 0,R15 SET 31 BIT MODE
DSPSERV DC A(*+4+X'80000000')
*
DSPSERV CREATE, CREATE A DATA SPACE
STOKEN=DSPSTOKN, PUT STOKEN HERE
NAME=DSPNAME, USE THIS NAME
ORIGIN=DSPORIGN, PLACE ORIGIN ADDRESS HERE
SCOPE=COMMON, COMMON DATA SPACE
BLOCKS=(DSPBLCKS,DSPBLCKS) THIS MAX AND INITIAL
*
ST R15,RETCODE SAVE THE RETURN CODE
ST R0,REASCODE SAVE THE REASON CODE
MODESET MODE=PROB SET TO PROBLEM PROGRAM STATE
Alternatively, I know the DataSpace names that are being allocated from a D A,stcname. Again, this is territory I don't tread into often, but is there an
easy way to determine the storage key of them?
What key is your program running in? The default for DSPSERV CREATE (as I read the manual) is CALLERKEY, so if it's running in key 8 that would be your problem.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jousma, David
2018-05-16 12:12:18 UTC
Permalink
Raw Message
Walt, and all...

I was misreading/misunderstanding, relearning as I go.... As Walt correctly points out, when KEY is not specified on the DSPSERV CREATE, it does default to CALLERKEY. The program in question starts in KEY(8), and since we didn’t set a KEY on the MODE=SUP statement either, it defaulted to KEY(8).

I did open a PMR with IBM, and the nice gentleman provided me with console dump instructions to dump both the address space that owns the Dataspaces in question, and RASP, and to include the DSPNAME from both asid's, and then run a RSMDATA DSPACE ASID(xx) command to get the details on the data spaces in question.

That worked beautifully, and provided the data that I needed.

_________________________________________________________________
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
***@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
Sent: Tuesday, May 15, 2018 5:03 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: UserKEY CSA/Dataspace scope=common Remdiation

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected emails**
Post by Jousma, David
Ok, quick eye-ball verification from the guru's that are better ASM programmer than I...
SMF30 RAXFLAGS is kicking out the a module for which I selectively pulled out the DSPSERV code for allocating USERKEY SCOPE=COMMON Data space. Is it possible that this line "DSPSERV DC A(*+4+X'80000000')" is what is setting the storage key just prior to execution? i.e. KEY 8? I didn't create the code, I'm just trying to understand it.
MODESET MODE=SUP SET TO SUPERVISOR STATE
L R15,DSPSERV INSURE 31 BIT MODE
BSM 0,R15 SET 31 BIT MODE
DSPSERV DC A(*+4+X'80000000')
*
DSPSERV CREATE, CREATE A DATA SPACE
STOKEN=DSPSTOKN, PUT STOKEN HERE
NAME=DSPNAME, USE THIS NAME
ORIGIN=DSPORIGN, PLACE ORIGIN ADDRESS HERE
SCOPE=COMMON, COMMON DATA SPACE
BLOCKS=(DSPBLCKS,DSPBLCKS) THIS MAX AND INITIAL
*
ST R15,RETCODE SAVE THE RETURN CODE
ST R0,REASCODE SAVE THE REASON CODE
MODESET MODE=PROB SET TO PROBLEM PROGRAM STATE
Alternatively, I know the DataSpace names that are being allocated from a D A,stcname. Again, this is territory I don't tread into often, but is there an
easy way to determine the storage key of them?
What key is your program running in? The default for DSPSERV CREATE (as I read the manual) is CALLERKEY, so if it's running in key 8 that would be your problem.

--
Walt

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

**DO NOT open attachments or click on links from unknown senders or unexpected emails**

This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.


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