OPS/MVS

Hi, did anybody test/try the new NOLOG option in the OPSECURE() call?

I can detect no difference whatsoever in examining the SYSLOG/OPSLOG if I specify OPSECURE('R','OPERCMDS','MVS.CANCEL','R','Y') or OPSECURE('R','OPERCMDS','MVS.CANCEL','R','N')

It will always log the dreadful ICH408I message. Or is the Nolog implying some other logging?

Regards,

Marcel van Ek

No one?

Marcel,  the way it is implemented it would only work from a REQUEST or TOD rule.

Thanks Dan, etsted in OPSREQ rule and looks good.

Now I wanted to actually test this on DATASET access, so used this:

opsecure('R','SYSX.SOME.DATA.SET','R','N') and seem to always get an abend as result:

It appears to work fine on GENERIC DATASET PROFILES though.

Marcel

.. missed something there...

used OPSECURE('R','DATASET','SYSX.SOME.DATA.SET','R','N')

Marcel,  let me code up a correction.   (ptf)   This was intended to function without actual access.

ok, it only fails on explicit dataset access. Even if I DO have access.

Marcel

Marcel,  I'm sending you a 12.2 test fix... 

Great  Dan.

Dan I verified, but the doc does not mention any restriction to )TOD or )REQ rules for this form of opsecure().

Please have that added to the Command and Function Guide (CH4 p 536)

Marcel, with the fix on,  the restriction of the )TOD or )REQ rule no longer exists. 

You should be able to use any OPSECURE('R',,,,'N')  and not see the messages logged whether  from a command rule,  ops/rexx etc.  

Ok, got the ptf, need to plan some time to apply an d test it.

Meanwhile i can open an issue with support for the 282-018 abend I guess...

But I'll test first

Dan applied your fix, did the LLA refresh and reload of OPSCFU but still the RACHECK abends keep occurring when accessing a fully qualified dataset profile. (As said: generics go ok)

(OPSAEX was also involved acc. our sysprogs btw)

I don’t think you are using the correct version.   You are using the NOLOG (‘n’)  fifth argument correct?

Marcel.  with the nolog option you won't get the S282 .   With the log option the racroute used appears as an access attempt, thus the s282, whereas the racroute used with the nolog option and the ptf does not. 

Marcel,

This is Cesar Molina from Customer Support at CA Technologies.

I have discusssed with Dan briefly about this Communities thread and we think it will be best for you today if we cut a ticket so we can help you further.

We do not want the entire community to be posted on this case and since we did provided you with a PTF we would like to track it in our Customer Support systems.

Dan and myself will be helping you with the issue via the ticket number.

Either open the case or let me know your Site Id so I can get you one open.

LEt me know if this sounds a good idea to you as well.

Regards, Cesar

Cesar, agreed, issue opened.

Marcel

Marcel, thanks for doing it.

Found Case 00066825 and I just took it form the Spain based technican who had it.

Also sent you via email a side question we have about your setup so feel free to respond it via the ticket when time permits.

Again thanks.

Regards, Cesar