longpelaexpertise.com.au/ezine/UnusedCICSVSAM.php?ezinemode=printfriend

LongEx Mainframe Quarterly - November 2019

At a client site, they had a lot of VSAM datasets defined to a CICS region. We needed to find out which VSAM datasets were used, and which weren't. Then, we could remove the unused ones.

So how did we do it? And why?

CICS

Our first step was the CICS statistics, written to SMF Type 110 records by CICS.

We used IFASMFDP to strip out the SMF110 subtype 2 records from SMF dumps into a dataset:

//STEP1    EXEC PGM=IFASMFDP
//SYSPRINT DD   SYSOUT=*
//DUMPIN   DD   DISP=SHR,DSN=SMF.DUMP.DATASET
//DUMPOUT  DD   DISP=(,CATLG),DSN=SMF.TYP110.SUBTYP2.DATASET,
//         SPACE=(CYL,(1250,100),RLSE)
//SYSIN    DD   *
  OUTDD(DUMPOUT,TYPE(110(2)))
//

We took a 6-week sample with the end of the month in the middle. This covers cases where datasets weren't used every week, or only during month-end processing.

We then used Merrill MXG to process the file-related records, and put them into a CSV file for our CICS region:

%INCLUDE SOURCLIB(TYPE110);
DATA T1;
   SET PDB.CICFCR;
   IF JOB='MYCICS';
   RUN;
%DS2CSV(DATA=T1, RUNMODE=B, CSVFREF=CSV);

I love the SAS DS2CSV macro: easily converts a SAS data set to a CSV file that I can download and open with Microsoft Excel.

This job provides some great statistics for each file, including the number of reads, updates etc. Adding all of these together gave an indication of which files had any operations, which did not.

Some Gotchas

Sounds simple so far, doesn't it? Let's look at a couple of issues.

In the section above, we talked about using the CICS end of day (EOD) statistics. As you'd expect, these are cut by CICS every day, and sum up the day's activities.

But for VSAM datasets, the EOD statistics aren't enough if the VSAM datasets are dynamically allocated and deallocated during the day. And some of ours were.

Whenever a VSAM dataset is deallocated, CICS cuts another SMF 110 (subtype 2) record called 'unsolicited statistics'. We need to sum all of these together with the EOD statistics to get the total accesses for the day. The above job outputs both EOD and unsolicited statistics.

The second issue is alternate indexes. To CICS, an alternate index is just another file. However, to VSAM it's more than that. So, if our CICS statistics show a dataset with no activity, that's not the end of the story. We need to determine if there are any alternate indexes, and if they have any activity. And in some cases, we did see datasets with activity only in alternate indexes.

In our example, we got statistics from one CICS region. We could do this because none of the VSAM files were opened in other CICS regions. However, if any were RLS (or opened in multiple CICS regions as read-only), we'd need to hit the SMF 110 statistics for every CICS region where the dataset was defined as a local file.

Batch

OK, so we now know files that have not been accessed within CICS. But before we start deleting them, we also needed to know if any process outside of CICS was using them.

For this, the SMF Type 64 records give information for VSAM datasets. Here's my MXG Job:

%INCLUD SOURCLIB(TYPE64);
DATA SMF64;
  SET WORK.TYPE64(KEEP=FJCBDSNM SYSTEM JOB DDNAME RECORDS SMFTIME);
     WHERE JFCBDSNM =: 'hlq';
  FORMAT DATE 5. TIME TIME5. ;
  DATE = DATEPART(SMFTIME) + 21916;
  TIME = TIMEPART(SMFTIME);
  DROP SMFTIME;
RUN;
%DS2CSV(DATA=SMF64, RUNMODE=B, CSVFREF=CSV);

This job gives us a list of all dataset beginning with our high-level-qualifier that have been opened (or closed). But more importantly, it tells us how many records and EXCPs were transmitted: or in other words, whether datasets were actually accessed, or merely opened/closed.

You'll see that I'm converting the date to an Excel-friendly date that I can use when I open this in Excel. Again, we do this for 6 weeks for EVERY z/OS system in the Parallel Sysplex. We can compare all the files not updated in CICS with this list, to see if they were updated (or read) in batch, and if so, what did it.

So, Why Bother With SMF 110?

I know what you're thinking: couldn't we have just used the SMF64 records, and not worried about the CICS statistics? Maybe.

The SMF64 records would certainly nclude statistics for the CICS regions that accessed the VSAM files. But the SMF110 give us a little more detail from a CICS perspective: number of GETs, UPDATEs etc. It includes local and remote files, which is handy. We were interested in other CICS regions function shipping requests to access these VSAM files. For this, we looked at the 110s for every CICS region with a connection to ours.

We also need to be a little careful with SMF 64 records. These are only created when a dataset is closed (or switches to a new volume, or runs out of space). So, if a CICS region is up for one month, and we only get our SMF64 records for two weeks in the middle, then any CICS 'action' won't appear in SMF 64 records (unless the datasets have been closed dynamically in that period).

There's another problem with relying solely on SMF64 records. And that's ...

The Curve Ball: IAM

IAM: Innovation Access Method. Our client had this installed and used it. Now IAM looks like a VSAM to CICS and applications, but is really a sequential dataset. So, they will appear in the SMF 110 statistics, but not the SMF64s (they're only for VSAM). We needed to check SMF Type 1415 for the IAM datasets. Here's the MXG job:

%INCLUD SOURCLIB(TYPE1415);
DATA SMF1415;
  SET WORK.TYPE1415
     (KEEP=DSNAME SYSTEM JOB DDNAME RECORDS SMFTIME EXCPCNT);
     WHERE JFCBDSNM =: 'hlq';
  FORMAT DATE 5. TIME TIME5. ;
  DATE = DATEPART(SMFTIME) + 21916;
  TIME = TIMEPART(SMFTIME);
  DROP SMFTIME;
RUN;
%DS2CSV(DATA=SMF1415, RUNMODE=B, CSVFREF=CSV);

This provides similar information to our SMF64 job.

Some Alternatives

The way we tackled this problem isn't the only way it could have been done. Here are some of the other options, and why we didn't use them.

We could have used a CICS monitor like IBM Omegamon for CICS to look at the VSAM files, and their activity. In fact, I often do this when doing a quick look at dataset activity in CICS. However, this online data is shorter term: it doesn't give us that 6-week history we want.

Most monitors will archive data, and provide batch utilities to access it. We could have used that, but different sites have different monitors: the SMF110 statistics are pretty common. I have seen sites that have used the monitor statistics, and not cut the SMF110 records. In this case, I would have used the monitor's facilities.

If you do an IDCAMS LISTCAT of a dataset, you'll see a SYSTEM-TIMESTAMP for the cluster, and all components. This is a STCK timestamp value of when the component was last closed for update. So, it won't show if the dataset was opened for a ready. It also will only show if the dataset was opened: not if any records were actually written.

We didn't need to use Merrill MXG to process the SMF110 records. There are other products such as IBM TDSz.

But It's Not Over

So, we created a list of unused VSAM datasets. But we didn't start deleting. Our job wasn't over.

We went through the list, and found some base VSAM clusters that appeared to be unused, but were accessed via alternate indexes. We found some alternate indexes that were unused, but the base clusters were. We found some VSAM datasets that were not updated in CICS, but were in batch.

We then went to the application to get their opinion. Some of these datasets were only used in emergencies: needed, but no activity. Some of the files were unused, but referenced in 'live' code, so the applications were unwilling to retire them (fair enough).

Just because nothing is opening a VSAM dataset, doesn't mean that we can delete it. We scanned JCL and found a lot of jobs that had these datasets in DD statements, but never opened them. This JCL needed to be updated to remove the reference to the dataset before it could be removed.

Conclusion

When I started writing this article, I had in mind a quick article just showing how to use Merrill MXG to access SMF 110 and 64 records to get VSAM dataset usage. But it kept getting longer as I added in other issues and gotchas.

And in many ways, this is normal for projects like this. They seem simple, but become more complex as we get deeper into them. I tend to use the term "the devil is in the details" a lot.

But the project was a success. In this case, we were converting VSAM datasets to RLS, and didn't want to convert those that weren't used. We also wanted to find out everything that accessed these datasets, to ensure there were no issues converting to RLS.

We also found a lot of VSAM datasets that weren't needed, and could be retired. Reducing the weight of the application made maintaining it application a little easier.

David Stephens