'Re: ICH70007I from batch job but not from online TSO'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: ICH70007I from batch job but not from online TSO
From:       Lennie Dymoke-Bradshaw <00000e14a09f4428-dmarc-request () LISTSERV ! UGA ! EDU>
Date:       2023-11-22 11:04:53
Message-ID: 000201da1d33$b8d36410$2a7a2c30$ () ntlworld ! com
[Download RAW message or body]

Rob,

Now tested online (using the method suggested by Philippe Richard - many thanks, \
Philippe) and we get the same results. Online access granted.
Batch we get ICH70007I.

However, not sure if using the JES2 $VS method is equivalent to issuing MGCR/MGCRE. \
Suspect the command may be issued from JES2 addres space. Do you know?

We are looking further for an MGCR/MGCRE approach.

Lennie

-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Lennie \
                Dymoke-Bradshaw
Sent: 21 November 2023 16:33
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: ICH70007I from batch job but not from online TSO

Rob,
We have tested using a command issued via $VS submitted via an internal reader and \
get the same results in batch. More tricky to test online. I will see if it can be \
done.

However, I am coming round to think that maybe the problem is that the TSO access \
should NOT have been granted. This is my conclusion from reading the text of \
ICH70007I (which is duplicated in the RACF msgs & codes manual).

Lennie

-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Rob Scott
Sent: 21 November 2023 15:30
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: ICH70007I from batch job but not from online TSO

Lennie

To rule out SDSF involvement, have you tried executing the command using other means \
(eg your own MGCRE-issuing program) ?

You could also use the "ISFSECTR" ddname allocation to force SDSF security trace \
records to appear in ULOG (and job output) to see if there are any differences.

Rob Scott
Rocket Software

From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Lennie \
                Dymoke-Bradshaw
Sent: Tuesday, November 21, 2023 2:04 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: ICH70007I from batch job but not from online TSO

EXTERNAL EMAIL



Philippe,
Actually I think I disagree. Or maybe we have crossed wires. I did not mention JES2. \
I still do not think it is involved. The MVS commands manual defines the ROUTE \
command as routing the command to 'sysname' NOT an NJE node or JES2 name. \
https://www.ibm.com/docs/en/zos/2.5.0?topic=rc-syntax-6<https://www.ibm.com/docs/en/zos/2.5.0?topic=rc-syntax-6>
 Perhaps it would have been easier if I had said the following below, At SYSNAME1 tso \
user USER01 issues RO SYSNAME2,'command' via SDSF REXX and it works. At SYSNAME1 \
batch job under user USER01 issues RO SYSNAME2,'command' via SDSF REXX and it fails \
with ICH70007I.

In both my cases the ROUTE command is the same. The only difference is that one is \
issued from batch, the other from a TSO session. The only involvement with JES2 is \
the initiation of the batch job. Once it starts executing, it is executing IKJEFT01, \
just like the online session and that is used to invoke the REXX exec which uses the \
SDSF interface to issue the ROUTE command with a target of SYSNAME2. Lennie

-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>> \
                On Behalf Of Philippe RICHARD
Sent: 21 November 2023 13:03
To: RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>
Subject: Re: ICH70007I from batch job but not from online TSO

Lennie,
you are confusing a little bit JES2 nodes with system names.
When you issue the ROUTE command in your REXX exec, you are using a target system \
name, which use XCF console services to route the command for execution and obtain \
the reply from the executing system. In your example NODE1 is not a JES2 NODE but a \
system name. In that case JES2 is not involved.
In your second example, when you submit a job, it is executed on a JES2 node \
'NODE01', and this job executes a ROUTE command to invoke a command for execution on \
a remote system (NODE02 is not the system name, but the JES nodename of the remote \
system). In this case JES2 is involved, thus the necessity to trust the node.

Racf class RACFVARS is active and the &RACLNDE profile does not contain the Local \
JES2 Node. If you need submit the command from batch you will have to make the \
definitions.

Question: in your batch job, do you have a /*JOBPARM SYSAFF ? or /*ROUTE XEQ ?


Le 21/11/2023 Ă  13:27, Lennie Dymoke-Bradshaw a Ă©crit :
> Philippe,
> 
> Thanks for the reply.
> Firstly the commands are issued using ISFSLASH.
> The &RACLNDE does NOT have the nodes within it.
> (This is the customer's preference as the RACF DB are NOT identical. 
> The LPAR is part of the same sysplex but is a K LPAR for GDPS. The understanding is \
> that the &RACLNDE should be used only if it is the same DB. I have queried this \
> with them, with particular reference to GDPS.) Nevertheless, I am confused as to \
> why that processing would ONLY take place for a batch job and not for the TSO \
> session. Let me clarify.
> At NODE01 tso user USER01 issues RO NODE02,'command' via SDSF REXX and it works.
> At NODE01 batch job under user USER01 issues RO NODE02,'command' via SDSF REXX and \
> it fails with ICH70007I. No NJE routing occurs. It uses sysplex routing of commands \
> and responses. 
> Lennie
> 
> 
> 
> -----Original Message-----
> From: RACF Discussion List
> <RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>> On Behalf Of 
> Philippe RICHARD
> Sent: 21 November 2023 12:12
> To: RACF-L@LISTSERV.UGA.EDU<mailto:RACF-L@LISTSERV.UGA.EDU>
> Subject: Re: ICH70007I from batch job but not from online TSO
> 
> In the case of batch, then JES2 nodes comme into play.
> You submit a batch job to another node, so the remote node must trust the sending \
> node. 
> Do you have a NODE RACF class defined ?
> 
> You may want to look at &RACLNDE profile in RACVARS class Check up your RACFVARS \
> class, with the profile &RACLNDE too. 
> I assume you are running in a sysplex, and share the RACF DB.
> 
> RALTER RACFVARS &RACLNDE ADDMEM(nodexx) SETROPTS RACLIST(RACFVARS) 
> REFRESH
> 
> nodexx comes from the remote JES2 node (use $DNODE, and obtain the 
> node name where you see 'OWNNODE')
> 
> Question: are you using the CONSOLE interface in your REXX , or the SDSF ISFSLASH \
> interface ? 
> 
> Le 21/11/2023 Ă  12:38, Lennie Dymoke-Bradshaw a Ă©crit :
> > Greetings,
> > 
> > 
> > 
> > My customer has a situation where they are trying to issue a command 
> > from one LPAR to another using SDSF in REXX.
> > When the REXX is executed from the TSO session the command is 
> > executed at the remote node successfully and the response returned.
> > 
> > However, when the same REXX is issued from a batch job under the same 
> > userid, the command is denied with ICH70007I.
> > 
> > It appears that some authority (supplied in the RACI?) from the batch 
> > job differs in some way from the online session.
> > Does anyone have any clues as to what might be going on? i.e. what 
> > could be different between the online and batch address space 
> > authorities as transferred to the remote LPAR?
> > 
> > This is all z/OS 2.5.
> > 
> > 
> > 
> > 
> > 
> > Lennie Dymoke-Bradshaw
> > 
> > <https://rsclweb.com/<https://rsclweb.com>>
> > https://rsclweb.com<https://rsclweb.com>
> > 
> > 
> > 'Dance like no one is watching. Encrypt like everyone is.'
> > 
> > 

================================
Rocket Software, Inc. and subsidiaries â–  77 Fourth Avenue, Waltham MA 02451 â–  \
Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: \
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from \
Marketing Messages/Manage Your Subscription Preferences - \
http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - \
http://www.rocketsoftware.com/company/legal/privacy-policy \
================================

This communication and any attachments may contain confidential information of Rocket \
Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you \
are not the intended recipient, please notify Rocket Software immediately and destroy \
all copies of this communication. Thank you.


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic