Is there something changed with ADRDSSU?

[Pragya]

Hi,

We have a Job which has not been changed since 90s and was coded with COND like below. This has started coming as abend since some time. It was never flagged as abend before. Is it something that changed with ADRDSSU? We use Control-M as scheduler.

Code: Select all

//S010    EXEC PGM=ADRDSSU,COND=(04,LT)                                 
//SYSPRINT DD  SYSOUT=*                                                 
//ABC007RM DD  DSN=A.S.AW.ADRDSSU.ABCAOFL(+1),                          
//             DCB=(GDG),                                               
//             UNIT=PCART,                                              
//             DISP=(NEW,CATLG,DELETE)                                  
//SYSIN    DD  DSN=PROD.CNTLLIB(ABCDADRD),DISP=SHR                
//*                                                                     
//**********************************************************************
//S020    EXEC PGM=ABC123,COND=(04,LT)                                
//SYSOUT   DD  SYSOUT=*                                                 
//TBLABC   DD  DSN=V.ABCD.TBLBAT,DISP=SHR                               
//ERLABC   DD  DSN=V.ABCD.ERLMST,DISP=SHR                               
//ERROUT   DD  SYSOUT=*                                                 

[nicc]

Well, I don't know as you have provided some JCL but no ADRDSSU control cards, no version informatio and no details of the abend - messages with their message numbers from both ADRDSSU and the job. All these things are required to determine where the error is occurring.

We also do not know if your shop has upgraded or not and when. Only your sysprogs can tell you that.

[Robert Sample]

The answer to your question depends upon which release of z/OS you're running. There is a known difference between the z/OS 2.2 and 2.3 versions of ADRDSSU; I ran across the difference when downloading the CBT tape data. The version 2.3 ADRDSSU would not unterse whereas the version 2.2 ADRDSSU untersed with no problems.

And, as was stated, you REALLY need to talk to your site support group to find out what, if anything, was changed at your site.

[Pragya]

Well, I don't know as you have provided some JCL but no ADRDSSU control cards, no version informatio and no details of the abend - messages with their message numbers from both ADRDSSU and the job. All these things are required to determine where the error is occurring.

This is what gave Return Code 04, which was considered by operations as abend:

Code: Select all

ADR013I (001)-CLTSK(01), 2019.279 00:26:58 TASK COMPLETED WITH RETURN CODE 0004

I look for the above message but I am not sure what I'm supposed to do with that message:

https://www.ibm.com/support/knowledgece ... 000032.htm

[Pragya]

ADRDSSU control card is:

Code: Select all

DUMP DATASET(INCLUDE(V.ABCD.RMLADT.** -    
                     V.ABCD.RMLAXR.** -    
                     V.ABCD.RMLBIN.** -    
                     V.ABCD.RMLBXR.** -    
                     V.ABCD.RMLRTV.** )) - 
     OUTDDNAME( ABC007RM ) -               
     CANCELERROR -                         
     COMPRESS -                            
     OPT(3) -                              
     TOL(ENQF) -                           
     WAIT(0,0)                             

All the inputs are VSAM. Output is on Tape.

[Pragya]

The answer to your question depends upon which release of z/OS you're running. There is a known difference between the z/OS 2.2 and 2.3 versions of ADRDSSU; I ran across the difference when downloading the CBT tape data. The version 2.3 ADRDSSU would not unterse whereas the version 2.2 ADRDSSU untersed with no problems.

We're on z/OS 02.03.00.

[Robert Sample]

The ADR013I message merely means that there is a W-level (04 is warning) message somewhere in the ADRDSSU output.

And you may have run across the z/OS 2.3 issue -- how long has your site been on 2.3, and how long have you been having problems with ADRDSSU?

[Pragya]

And you may have run across the z/OS 2.3 issue -- how long has your site been on 2.3, and how long have you been having problems with ADRDSSU?

I do not know about the zOS 2.3 run time, is there a way I can know that my own? Rather asking the admin support team?

We started seeing the problem with ADRSSU recently but I think there is other part of problem. We run jobs using Control-M and RC=04 was called as abend and operations says that they have this instruction to flag RC=04 as abend. I also thought this is a warning message only.

But even that warning message does not have a solution?

[nicc]

is there a way I can know that my own?

Yes - go back in time looking at the outputs and finding when the version number changed in the output.

But even that warning message does not have a solution?

Depends what the warning message is and you have not shown that despite a request to see the (relevant parts of the) output.

[Pragya]

This is what gave Return Code 04, which was considered by operations as abend:
CODE: SELECT ALL
ADR013I (001)-CLTSK(01), 2019.279 00:26:58 TASK COMPLETED WITH RETURN CODE 0004
I look for the above message but I am not sure what I'm supposed to do with that message:

https://www.ibm.com/support/knowledgece ... 000032.htm

Hi nicc,

This is the message job is showing. Do you want to see some more messages?

[ Post made via Android ]

[Robert Sample]

This is the message job is showing. Do you want to see some more messages?

The DFDSS messages manual at https://www.ibm.com/support/knowledgece ... tm#idg9110 has well over 100 level-W messages listed. They all describe a specific problem with ADRDSSU, and most (if not all) of them suggest ways to resolve the problem. Without more messages -- especially those with a message ID ending in W -- there is nothing more we can tell you about your problem. Some of the W messages indicate problems with the execution, while others indicate something to be aware of (for example, if you use TOL(ENQF) and a data set is open when the DUMP executes, you'll get a W-level message telling you this and that the data set could not be dumped. Is this a significant message? Maybe, maybe not -- it depends upon the data set and whether or not you have to get a good dump of that particular data set.)

[Pragya]

Thanks Robert.

I think we need to talk to our Control-M team also to understand why the RC=04 was taken as something to be reported.

[Pragya]

We actually contacted Control-M Team and they said that they have instruction for ADRDSSU steps if they are returning RC=04, to be reported to application teams as abend

[Robert Sample]

We actually contacted Control-M Team and they said that they have instruction for ADRDSSU steps if they are returning RC=04, to be reported to application teams as abend

This is being very conservative. Some RC=04 ADRDSSU steps require application team action, while other RC=04 ADRDSSU steps are not indicative of any problem.