CICS/PA to save dictionary records for later use

Discussed this on a number of conference calls with Mike and CICS PA development and agreed this in not something that CICS PA needs to provide.

In case you see these answers twice, I submitted an answer to your questions earlier, but now I don't see them, so I'll answer them again:

1. Yes
2. One MCT has two resource settings (TSQUEUE=nn and FILE=nn), but the others are all the same except for USER EMP.
3. We have 7 MCTs, all include user fields, but each of the 7 have a different combination of user fields (DBCTL for the IMS regions, etc.). There are over 300+ dictionary records in our production file, then we have several other dictionary files for various environments.
4. About once a year. Here are the comments from one of the MCT tables, showing the update interval (MM/DD/YY):
03/21/18 AB Reassembled for CICS 5.4
03/21/18 AB Added Required BMC Mainview MCT entry
02/23/17 AB C2406770 Reassembled for CICS 5.3
01/23/17 AB C2406770 Removed all exclusions
04/23/14 TJH C1665419 Reassembled for CICS 5.1
09/19/12 TJH C1265842 Reassembled for CICS 4.2
11/13/10 CR968841 DRT UNEXCLUDE FIELD=82,124 TRNGRP PA WLM C
05/08/10 MFG CR858090 COMPRESS=YES
01/24/09 MFG CR717901 V320 FILES/TSQUEUE=64
10/10/08 MFG CR686118 V320 COMPRESS=NO
5. I'm not a CICS/PA user so I had to look that up. I don't think we're using it because we generate dictionary records using DFHMNDUP and put them into one dictionary file per release.
6. No, we use our own process to generate a dictionary for each region using DFHMNDUP.

The point of this requirement is that we don't want to generate dictionary records as they require someone to know to do the generate and to time the inclusion of the dictionary records when the MCT/release change is installed or backed out. The correct dictionary records are always in the SMF data, with the correct timestamp. If those can be extracted as they are being read (we generate a billion 110 records per day) and saved to a file, we can use them on days when there is no leading dictionary records. If we cycle on Sunday and process SMF each day, then we don't have dictionary records on Monday/Tuesday/etc. If the dictionary records from Sunday are collected, then we know we always have the latest. If for example, we install on Sunday, then, backout on Sunday night, which dictionary records will we be using on Monday? If we keep all of them (and purge older ones), the CICS/PA should be able to sort them and decide which to associate with the 110 data.

The requirement to age the dictionary records is not important. If the dictionary records can be written to a DD, we can manage the aging by writing to a GDG with MOD. What's important is not having to read our SMF records twice, since we have over a billion tasks on peak days. We would like to read them once, save off the dictionary, then use the saved dictionary records for the next day when there may not be any dictionary records in the SMF input.

That being said, you could age by first reading all of the dictionary records from CPADICTR, merge with what is found in the current SMF, then delete duplicates older than x days (based on a parm). The rest is written to a new DD that will be used for input on the next run.

Please provide answers to the following questions in order to allow us to better understand your requirement and provide you with a viable solution.

1. Do your dictionary records include User fields?
2. If yes, are the remainder of the dictionary record definitions the same, i.e. only the User Fields differ?
3. How many different dictionary records do you have and how many include User Fields?
4. How often are the dictionary records modified due to upgrade and other reasons?
5. Do you specify dictionary record datasets in the CICS PA Systems Definitions so that CPADICTR DD is generated in the JCL?
6. Do you use the CICS PA dictionary definition generation function to create dictionary record to include in the CPADICTR dataset?