Most Syncsort Capacity Management users will want to collect data from their z/OS systems so as to cover all the dates and times available. When SMF data is cut off at the end of a day there is most often some “overhang” from records which belong to the “next” RMF interval, for example, on a system with 15 minute RMF intervals:
YESTERDAY TODAY
23:45 00:00 00:15
|<RMF> |<RMF> |<RMF>
| | <SMF cutoff> |
| | V |
| C C CC CC CCC C | CI CCC CC C C | C C CCC C C
| B BB BB B B | BI BB B BB BB |B BB B B BB B BB
The vertical lines show the interval ends when RMF data is cut, C means a CICS transaction record is written and B means a batch job or step ends or a batch interval ends. The daily SMF cut off occurs at time 00:02, where the V character is, just after the 00:00 RMF interval is written to SMF covering the interval 23:45–00:00. CICS transactions and batch events continue to be written as they happen.
Acquire uses the RMF type 70 record as an end-of-interval marker. If the data for YESTERDAY was processed by Acquire then there would be RMF data up to the midnight interval, covering 23:45 - 0:00, plus some CICS and batch records that do not belong to that interval - they belong to the 0:00 - 0:15 interval, which will be in the TODAY data.
When data from TODAY is processed it will pick up data from the second and subsequent C and B items - but the first ones would be lost.
To overcome this, Acquire has some mechanisms to help you. One option is to use the DYNAGDG= or DYNADSN= facility as detailed below, to let Acquire dynamically allocate new members of a GDG. You can use part of this facility to automatically set the start date and time of the “next” run of Acquire using the //LASTGDG file, also described below. These two options should be examined and used if possible.
You will see messages in the //IPLIST file that tell you how many records have been read from the warehouse before reading SMF data, how many were processed into “this” run and how many were left over and written away once all data had been processed.
You can control how Acquire treats the warehouse file with the WHS= control card. For compatibility the default is WHS=N, and the warehouse will not be used. WHS=Y instructs Acquire to try to use the warehouse file as described above. If the //WAREHSE file is not allocated in the step’s JCL it will ignore the request and continue. If you provide a control card of WHS=R then Acquire will reset the warehouse file, effectively ignoring any data that may be there. It will still write out any overspill records to the file at the end of the run.
A DDNAME of //WAREHSE in your JCL must point to a sequential file with LRECL=4096 and RECFM=VB.
The warehouse file can be useful if you want to process data with Acquire immediately after dumping it from SMF. Traditionally, z/OS customers have a daily cut-off for SMF when they process the previous day’s data. With larger and larger systems and ever increasing data this is not always practical. Using the warehouse file allows you to create data and import it into Syncsort Capacity Management very soon after it is available, and ensure you can retain and incorporate any data falling between an SMF switch event and the next RMF interval.
An alternative, and probably better approach, is to use the DYNAGDG= parameter and/or the //LASTGDG file to allow Acquire to control what it allocates and processes, as described in the next section.