CMNBATCH succeed with PassTicket failure ...

Hi all,

This is my problem ...
In spite of Pass Ticket failure when request to SERNET connection, CMNBATCH still logs to CMNDELAY file ... this obviously represente a problem from my point of view.
I've tested this with zMF V8R1M4.
Can anyone help me on this one, please ?

Thanks in advance
Joao

#ChangeManZMF

Hello Joao,

How exactly is this causing you a problem?

Realistically, if you are running users or jobs on a ‘remote’ LPAR (i.e. an LPAR that does not host the ZMF Server task) then you will need to enable PassTicket support. It is mandatory in this situation. If the job were running on the ‘local’ LPAR (i.e. the one hosting the ZMF Server task to which the user or batch job is connecting), the connection request should switch to Cross Memory Services (XMS) when the PassTicket generation fails and the request will be executed immediately. Hence that should not be a problem.

It is probably worth noting that my understanding is that this is in response to a PassTicket generation failure on the remote LPAR. This is not in response to a 'user denied'-type access failure or a failed user impersonation attempt which work differently.Let me know if I have misunderstood in any way.

Thanks and best regards,

Steve

Hi all,

This is my problem ...
In spite of Pass Ticket failure when request to SERNET connection, CMNBATCH still logs to CMNDELAY file ... this obviously represente a problem from my point of view.
I've tested this with zMF V8R1M4.
Can anyone help me on this one, please ?

Thanks in advance
Joao

#ChangeManZMF

Hi Steve :) ,

Thanks for your answer on my question ... I agree with you. Maybe I didn't explain myself well the first time.

Let's take the following scenario:
LOCAL LPAR (Hosting zMF STC) with own RACF (RACFA)
REMOTE LPAR (Doesn't host any zMF STC) with own RACF (RACFB)
Shared DASDs

Now my testing:

1. Execute the remote zMF JCL with no changes at remote site:
This is the behauvior of CMNBATCH:
" ... Attempting to initiate dialog with ChangeMan zMF subtask
Unable to generate a PassTicket (Name=SerNet.Pticktok RC=4) RC=08 ..."
Bellow these messages comes the logging to the DELAY FILE ... (From my point of view it shouln't).

2. Execute the remote zMF JCL with SERSET utility executed at remote site:
Again, this is the behauvior of CMNBATCH:
" ... Attempting to initiate dialog with ChangeMan zMF subtask
PassTicket generation failed RCVTPTGN RC=08 RC=08 ..."
Bellow these messages comes the logging to the DELAY FILE ... (From my point of view it shouln't).
In this 2nd example the problem is that PTKTDATA class doesn't have SERNET profile defined at RACFB.

3. Execute the remote zMF JCL with SERSET utility executed and SERNET profile defined at PTKTDATA RACF Class (RACFB) at remote site with a user defined at RACFB:
Fails due to the fact that the user isn't defined at RACFA where zMF is hosted (Local LPAR). Nevertheless CMNBATCH still logs the changes to the DELAY FILE ... again, from my point of view it shouldn't happen ...

Of course when we ShutDown and StartUp zMF all the changes in the Delay file will be executed by Changeman.

This is what I was trying to say the first time.
Available for any clarification, and keep in mind that this was a TEST.

Cheers
Joao Rolinho

Hi all,

This is my problem ...
In spite of Pass Ticket failure when request to SERNET connection, CMNBATCH still logs to CMNDELAY file ... this obviously represente a problem from my point of view.
I've tested this with zMF V8R1M4.
Can anyone help me on this one, please ?

Thanks in advance
Joao

#ChangeManZMF

Hi Joao,

Many thanks for the update and yes, I agree. The CMNBATCH transactions associated with such scenarios should not be logged or processed. We will report this behaviour and have the issue resolved.

Best regards,

Steve

Hi Joao,

Many thanks for the update and yes, I agree. The CMNBATCH transactions associated with such scenarios should not be logged or processed. We will report this behaviour and have the issue resolved.

Best regards,

Steve

Thanks a lot Steve ... Would you like me to open an Incident @ MFocus ?
Cheers

Joao Rolinho

Hi Joao,

Many thanks for the update and yes, I agree. The CMNBATCH transactions associated with such scenarios should not be logged or processed. We will report this behaviour and have the issue resolved.

Best regards,

Steve

It can affect my client in a really bad way ....