Issue with CR+ catalog backup job.

Praveen Kumar Kolar · New User Joined: 18 Mar 2021 Posts: 31 Location: India

Hi Team,

This is regarding the CR+ catalog backup job failure. I didn't find any relevant sub group to post it so I am posting it in the JCL and VSAM sub group.

We have a CR+ catalog backup job running 5 times a day and few times the job will complete successfully without any issues and few times it will fail with the below error code.

1 BACKUP BCS(ICFCATA1) -
2 OUTDATASET(MST.Q1KQ.ICFCATA1.CRP) -
3 ACCEPTDIAGNOSE(W) -
4 EXAMINE(DATATEST) -
5 DISPOSITION(SHR) -
6 DIAGNOSEBCS

MCR02144W No READ DSN authority for BCS=ICFCATA1
MCR02133E No DSNs meet specifications for BACKUP
MCR02009I BACKUP function complete. Return code 8

I worked with ACF2 team regarding the access and they confirmed that the catalog has all the required access.

Any suggestions would be really appreciated.

Rohit Umarjikar · Posted: Tue Mar 30, 2021 8:27 pm

What does MCR02133E tells you ?

Praveen Kumar Kolar · New User Joined: 18 Mar 2021 Posts: 31 Location: India

Hi Rohit,

MCR02133E NO DSNS MEET SPECIFICATIONS FOR BACKUP

Explanation: After processing the BACKUP command, no catalogs were
selected for backup.

User Response: Ensure the names are specified correctly. At least
catalog must be backed up with the BACKUP command.

Willy Jensen · Posted: Wed Mar 31, 2021 2:27 am

Could it have run on an lpar with different catalog and/or security setup?

Praveen Kumar Kolar · New User Joined: 18 Mar 2021 Posts: 31 Location: India

it work's fine with other catalog's except few. Nothing has changed from ACF2 security team. not able to trace the reason behind it.

Joerg.Findeisen · Posted: Thu Apr 01, 2021 12:00 pm

Is it that only Single Level UCATs fail?

Pete Wilson · Posted: Thu Apr 01, 2021 12:56 pm

This seems very clear to me, there is no matching catalog of the name specified. What I suspect is that this Usercatalog needs to be IMPORT CONNECTed to other LPAR's that are running on different Mastercatalogs that do not have this catalog defined in them. That would explain why it works sometimes and not others. If you look at the failed jobs and identify what LPAR it ran on then you can check what Mastercatalog it's using and if this Usercatalog is defined by running a LISTC ENT(usercat.name) VOLUME CAT(mastercat.name) for it on the LPAR that had the failure to see if it is defined. If all LPAR's are part of the same plex they generally should all be using a Mastercatalog that has all the same usercatalogs defined. so you should check all the different mastercatalogs for the presence of this usercatalog.
MCR02133E No DSNs meet specifications for BACKUP.

In the Joblog there should be other ACF2 messages if it is actually an access issue. MCR02144W is only a Warning from CR+ itself, not from ACF2. Perhaps it would be better to clarify that with the vendor Rocket Software.

Joerg.Findeisen · Posted: Thu Apr 01, 2021 1:10 pm

@Pete: The CR+ could experience difficulties to detect single level UCATs. Certainly your assumption is the most likely one.

Pete Wilson · Posted: Thu Apr 01, 2021 1:13 pm

Praveen Kumar Kolar · New User Joined: 18 Mar 2021 Posts: 31 Location: India

Hi Team,

This user catalog ICFCATA1 is defined on all system in the plex with different master catalog.
On SY2:

USERCATALOG --- ICFCATA1
IN-CAT --- SY2.MASTER.CATLG
VOLUMES
VOLSER------------CTLGAF

On SY1:

USERCATALOG --- ICFCATA1
IN-CAT --- SY1.MASTER.CATLG
VOLUMES
VOLSER------------CTLGAF

On SY3:

USERCATALOG --- ICFCATA1
IN-CAT --- SY3.MASTER.CATLG
VOLUMES
VOLSER------------CTLGAF

The job run's on SY2 system and here is the output of the list cat command.

1IDCAMS SYSTEM SERVICES TIME: 08:00:4
0
LISTC ENT(ICFCATA1) -
VOLUME CAT(SY2.MASTER.CATLG)
1IDCAMS SYSTEM SERVICES TIME: 08:00:4
- LISTING FROM CATALOG -- SY2.MASTER.CATLG
0USERCATALOG --- ICFCATA1
HISTORY
RELEASE----------------2
VOLUMES
VOLSER------------CTLGAF DEVTYPE------X'3010200F'
1IDCAMS SYSTEM SERVICES TIME: 08:00:4
- LISTING FROM CATALOG -- SY2.MASTER.CATLG
0 THE NUMBER OF ENTRIES PROCESSED WAS:
AIX -------------------0
ALIAS -----------------0
CLUSTER ---------------0
DATA ------------------0
GDG -------------------0
INDEX -----------------0
NONVSAM ---------------0
PAGESPACE -------------0
PATH ------------------0
SPACE -----------------0
USERCATALOG -----------1
TAPELIBRARY -----------0
TAPEVOLUME ------------0
TOTAL -----------------1
0 THE NUMBER OF PROTECTED ENTRIES SUPPRESSED WAS 0

I will try to attach the failed and successful job log.

Joerg.Findeisen · Posted: Thu Apr 01, 2021 6:45 pm

Out of curiosity, please specify the Catalog Name with dsn.** and retry.

Willy Jensen · Posted: Fri Apr 02, 2021 1:49 pm

and
LISTC ENT(ICFCATA1) CAT(ICFCAT1) ALL

Willy Jensen · Posted: Fri Apr 02, 2021 2:24 pm

Let me clarify my request for the LISTC ENT(ICFCATA1) CAT(ICFCATA1) ALL command. It retrieves information from the catalog, whereas your command LISTC ENT(ICFCATA1) VOLUME CAT(SY2.MASTER.CATLG) only shows information from the master catalog. Or in other words, adding CAT(ICFCATA1) verifies that the catalog is actually there.
Something else, you never answered if the job fails consistently in one lpar and runs consistently in other lpars.
I worked a lot with CR+ in the past and liked it lot. I also had a very good working relationship with the support people, you might want to contact them if you get totally stuck.

Praveen Kumar Kolar · New User Joined: 18 Mar 2021 Posts: 31 Location: India

Apologies for delayed response as I was on long vacation.

Hi Joerg,

you mean to run the job in the below format?

LISTC ENT(ICFCATA1) CAT(ICFCATA1.**) ALL

Hi WJ,

Here is the output of LISTC ENT() CAT() ALL command.

LISTC ENT(ICFCATA1) CAT(ICFCATA1) ALL
1IDCAMS SYSTEM SERVICES TIME: 11:25:0
- LISTING FROM CATALOG -- ICFCATA1
0CLUSTER ------- 00000000000000000000000000000000000000000000
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2004.041
RELEASE----------------2 EXPIRATION------0000.000
CA-RECLAIM---------(YES)
EATTR-------------(NULL)
BWO STATUS--------(NULL) BWO TIMESTAMP-----(NULL)
BWO---------------(NULL)
ENCRYPTIONDATA
PROTECTION-PSWD-----(NULL) RACF----------------(NO)
ASSOCIATIONS
DATA-----ICFCATA1
INDEX----ICFCATA1.CATINDEX
DATA ------- ICFCATA1
HISTORY
DATASET-OWNER-----(NULL) CREATION--------2004.041
RELEASE----------------2 EXPIRATION------0000.000
ACCOUNT-INFO-----------------------------------(NULL)
PROTECTION-PSWD-----(NULL) RACF----------------(NO)
ASSOCIATIONS
CLUSTER--00000000000000000000000000000000000000000000

Please let me know if you need complete output.

I will try to run the job from different system in the same sysplex and update you.

Joerg.Findeisen · Posted: Mon Apr 19, 2021 11:00 pm

Praveen Kumar Kolar · New User Joined: 18 Mar 2021 Posts: 31 Location: India

Hi Joerg.

I tried with ICFCATA1.** and still failed with the same error.

BACKUP BCS(
ICFCATA1.**
)
ACCEPT-DIAGNOSE(W)
ACCEPT-EXAMINE(W)
ALIAS
DIAGNOSE-BCS
DIAGNOSE-ERROR-LIMIT(16)
DISPOSITION(SHR)
EXAMINE(INDEXTEST)
EXAMINE-ERROR-LIMIT(16)
EXPLICIT-VERIFY(NO)
MESSAGE-TEXT(FULL)
OUTFILE(STEP01) MCR02100I BACKUP BCS Maintenance Level: MCR00021/REV=73 20180720 16.44

MCR02157I Print option in effect: NONE
MCR02109I Default in effect: FATAL-CATALOG-ERROR(WARNING)
MCR02116I The following DSNs/masks are to be processed during BCS processing.
ICFCATA1
MCR02144W No READ DSN authority for BCS=ICFCATA1
MCR02133E No DSNs meet specifications for BACKUP
MCR02009I BACKUP function complete. Return code 8

Pete Wilson · Posted: Tue Apr 20, 2021 1:04 pm

Are you seeing ACF2 messages in the joblog that indicate you do not have the required read access or not?

Have you tried running the job on another LPAR and had a different result? Are all these LPAR's part f the same Sysplex?

If there are no ACF2 messages then perhaps it may be that the LOADLIB for CR+ is not APF authorised on the LPAR where the job is failing.

Otherwise, why have you not involved the vendor Rocket Software? You pay for the software support so why not use that rather than an internet forum?

Praveen Kumar Kolar · New User Joined: 18 Mar 2021 Posts: 31 Location: India

Hello Pete,

Your prediction was right. Here is the update from ACF2 team. But there was nothing in the job log related to this. After a deep drive the ACF2 team identified this and corrected the issue.

"The root cause of the issue is ACF2 pre-validation exit was modified as part of S913 cleanup project, but appropriate access rules were not added. I added required access rules on all systems and the jobs completed successfully."

Thank you all for your help.

Pete Wilson · Posted: Fri Apr 23, 2021 2:11 pm

Thanks for the update Praveen, it's good that you have resolved this.

It seems a bit unhelpful if the ACF2 team are suppressing messages that indicate access issues.