Acquire File Naming Convention
The data produced by an Acquire COLLECT run is in text format and may be written to:
-
The //ATHDATA file
-
A USS (UNIX System Services) file system
-
Both of these places
If writing data to USS, files with names of the following form will be created:
<yyyymmddhhmmss>_asz<d><tttttttt>.<nnnn>
or if USSCOMP=Y is in effect:
<yyyymmddhhmmss>_ezz<d><tttttttt>.<nnnn>
where
<yyyymmddhhmmss> is the time of the first data record processed by the Acquire run
<d> is the data type : s for system data or d for disk occupancy data
<tttttttt> is the target number associated with this system
<nnnn> is a number that reflects the version of Acquire, e.g., 1110, although any valid number is permissible.
If writing to USS, and data from multiple systems is present in the SMFDATA file, then a separate USS file will be created for each one that has valid output. If the //ATHDATA file is used, then all data for all systems is concatenated together in a single sequential dataset.
Control Center must be able to associate an Acquire output file with the number of the Syncsort™ Capacity Management Target that it belongs to.
In order to achieve this, the Target Number appears as follows:
-
Files written to USS have the target number embedded in their name, in what is a standard Syncsort™ Capacity Management naming convention, and in 0101 records.
-
The //ATHDATA file contains the relevant target number(s) in 0101 records.
If you use the //ATHDATA output file, you must transmit the data to where Control Center can locate it, and provide it with a name that matches the definitions in System Manager. The advantage of the USS option is that files are created with the correct naming convention, and if connectivity is permissible, this data can be automatically retrieved by Control Center.
The file created by Acquire will compress very well if you have access to a compression tool such as PKMVS (which is compatible with the PC tools WINZIP and PKUNZIP). You can compress the data before transmission, then use WINZIP or PKUNZIP on the PC to return it to its original size, but this is an entirely manual process that you must manage yourself.
Data must be transmitted in such a way that the text is converted to ASCII on the Windows system that is running the Syncsort™ Capacity Management Control Center. Normally you achieve this by specifying the “ascii” command within FTP to ensure that the mainframe EBCDIC data is correctly translated.
Do not use binary transmission of uncompressed data when copying from the mainframe to a Windows environment.
Conversely, do use binary transmission if you copy compressed mainframe data to a Windows environment, for example if you set USSCOMP=Y in Acquire.
If you have a z/OS based compression tool and you compress text data yourself and send it on Control Center, you must do so as a binary transmission, and name the eventual file that Control Center processes in a way that indicates it is compressed EBCDIC data, not compressed ASCII data, that is, like this:
<yyyymmddhhmmss>_ezz<d><tttttttt>.<nnnn>
The ez in the name is what instructs Control Center to decompress the data then convert it from EBCDIC to ASCII.