SMS SCDS construct comparison tool

If the ACTIVATE is fully under control of an automated process that does the checking it could be useful. And just as an ad hoc check it would be useful too. But there would still be occasions where a legitimate change to a MGMTCLAS setting has to be made and be authorised somehow by someone, so there's always the potential for it to go wrong.

Changing the MGMTCLAS settings is probably the highest risk of all SMS change, especially things like reducing Expire Non-Usage and Expire Date/Days values. Once Space Management has run it's almost impossible to retrieve the deleted data, depending on your backup protocol etc. Almost all other SMS changes are reversible.

Our standard practice is to use save the ACDS to the SCDS before starting an SMS change to ensure they match 100%, including any SG or volume status change by VARY commands in the ACDS. So any construct changes have to be a very conscious decision and would be heavily scrutinised under change control.
SETSMS SAVESCDS(SCDS.NAME)
Also save the pre-change ACDS to an alternate name that could be quickly activated if necessary:
SETSMS SAVEACDS(ACDS.ALTERNATE.NAME)

At the Rabobank we need the functionality to compare the SCDS with the ACTIVE so we can safely execute changes automatically from ZOSMF without having unintended/not-activated changes be activated in a proces where human intervention is eliminated.
Also see https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=127842

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - z/OS
Component - DFSMS ISMF/Naviquest
Operating system - IBM z/OS
Source - SHARE

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - z/OS
Component - DFSMS SMS
Operating system - IBM z/OS
Source - SHARE

We have been doing this type of compare for years. We have it integrated into our automation for activating a new SMS configuration, but the actual compare can be done at any time using a batch job with three steps.

//STEP001 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//DCOUT DD DSN=DSM.DCOLLECT.ACDS.SMSDATA,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(TRK,(50,20),RLSE),
// DSORG=PS,RECFM=VB,LRECL=932
//SYSIN DD *
DCOLLECT OUTFILE(DCOUT) SMSDATA(ACTIVE)
//STEP002 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//DCOUT DD DSN=DSM.DCOLLECT.SCDS.SMSDATA,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(TRK,(50,20),RLSE),
// DSORG=PS,RECFM=VB,LRECL=932
//SYSIN DD *
DCOLLECT OUTFILE(DCOUT) SMSDATA(SCDSNAME(SMS.PROD.SCDS))
//STEP003 EXEC PGM=IKJEFT01,
// PARM='%SMSCOMPR'
//SYSEXEC DD DSN=DSM.REXX.EXEC,DISP=SHR
//ACDS DD DSN=DSM.DCOLLECT.ACDS.SMSDATA,DISP=SHR
//SCDS DD DSN=DSM.DCOLLECT.ACDS.SMSDATA,DISP=SHR
//REPORT DD DSN=DSM.SMS.CHANGES(+1)
// DISP=(NEW,CATLG,DELETE),
// DATACLAS=EXTENDED,
// SPACE=(TRK,(10,10),RLSE),
// DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=0
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSIN DD DUMMY
//SYSIN DD DUMMY

A compare of the volumes in each storage group can also be done by adding VOLUMES(*) NODATAINFO to the DCOLLECT commands (unfortunately, STORAGEGROUP(*) or STORAGEGROUP(ALL) is not allowed).

We currently do not check every field in each DATACLAS, STORCLAS, MGMTCLAS, and STORGRP, but it would be easy enough to add code to do that.

Perhaps IBM could utilize this approach to speed up the delivery of a tool everyone could use.

An idea to consider:

Build the following jobstream.

1. ACBJBAO7 - DCOLLECT against target SCDS(s)
DCOLLECT +
VOLUMES(*) +
OFILE(OUTDST) +
SMSDATA(SCDS(your.scds1))
DCOLLECT +
VOLUMES(*) +
OFILE(OUTDSP) +
SMSDATA(SCDS(your.scds2))

2. ACBJBAR2 - Generate SMS Config Report against your.scds1
Choose record type(s) to collect

3. ACBJBAR2 - Generate SMS Config Report against your.scds2
Choose record type(s) to collect

4. SuperC compare ACBJBAR2 output for scds1 & scds2