You are currently on IBM Systems Media’s archival website. Click here to view our new website.

MAINFRAME > Administrator > Workload Management

REXX Functions to Process DCOLLECT Data: A Working Example

The first of two parts, “Leverage DCOLLECT Data With (or Without) REXX,” outlined a basic understanding of the DCOLLECT record header and the various methods to view individual DOCLLECT records. Part one examined the IBM IDCAMS utilities and introduced a few manual techniques for translating the header fields into a more human-understandable format.

This installment introduces a few REXX building blocks and provides a general working example that displays various DCOLLECT record fields.

REXX Functions

The REXX functions to process DCOLLECT records are almost exactly the same as those used to process SMF records (see “REXX Offers Tools for Automated Processing of SMF Data”).

This article described a few REXX functions that would be useful in processing SMF records. In a nutshell, these consisted of:

  • The data format conversion functions:
    • BINARY_D: Extract a field that’s documented as being BINARY, beginning at a particular offset (per the OFFSET() function) for the specified documented length in bytes and return the extracted field in decimal format
    • BINARY_X: Similar to the BINARY_D() function except that the extracted field is returned in hexadecimal format
    • BINARY_B: Similar to the BINARY_D() and BINARY_X() functions, the BINARY_B() function returns the extracted field in binary bit vector format
    • EBCDIC: Returns the extracted field as-is from the formatted dump output record
  • The time and date conversion functions:
    • SMFTIME: Converts timestamp fields containing a binary value that represents the time since midnight, in hundredths of seconds. Part one of this series showed how to decompose each component of the DCUTME time field. The SMFTIME() function internalizes that algorithm and returns the extracted field in the format of hh:mm:ss.
    • SMFJDATE: The DCUDATE field in the standard DCOLLECT record header is in the specific form of 0cyydddF. The SMFJDATE() function can be used to help parse the extracted field and return it in a more usable Julian date format of yyyy.ddd (e.g. Dec. 31, 2015, would translate to 2015.365 in Julian format)

Per the previous SMF article, these functions can be used as-is. The only difference is the OFFSET function.

With DCOLLECT records, because the IDCAMS PRINT utility doesn’t include the record length and segment descriptor fields in its output, what appears at offset 0 in the IDCAMS formatted dump is actually defined at offset 1 per the defined DCOLLECT record header (unlike with the SMF record header where the actual offset was 4).

From a coding and maintenance perspective, the OFFSET function is intended to make the code much cleaner, handling offset differences without having to worry about the "offset math" each time you wanted to examine a particular field. Given this, the REXX OFFSET() function does the following:

 Function: OFFSET
 Input: Field offset (decimal) 
 Output: Input offset minus three
 To get the correct physical offset into the DCOLLECT input line, add one
  parse arg this_offset
  return (this_offset+1)

As you can see, the actual code is relatively simple but this abstraction will help to prevent confusion down the road.

A Working Example

Figure 1 shows the sample Job Control Language (JCL), with a few annotations, to run the REXX DCOLLECT parsing exec named DCOLL02 under the IKJEFT01 Terminal Monitor Program (TMP)— i.e., the time-sharing option (TSO) TMP initialization utility. The JCL source can be found in code sample 1.

In addition, the REXX source code for the DCOLL02 exec is provided in code sample 2.

The fourth article in the previous SMF series described the general flow and logic of the @IBMR304 exec. The flow of the DCOLL02 exec is virtually the same except for two new subroutines: process_active_dataset_info() and process_volume_info(). These subroutines are provided to demonstrate examples of processing DCOLLECT subtype "D" (active dataset) and subtype "V" (volume) information records.

Getting Started With DCOLLECT

This DCOLLECT articles covered a few concepts and topics to get started with manipulating DCOLLECT data using REXX. As shown, processing DCOLLECT records is almost the same as processing SMF records with a few, minor differences.

You now have the basic tools from which to move forward, and with this final article, you have a working example to use as a code baseline or as a reference to turn to if you get stuck. To further reinforce and develop your knowledge of DCOLLECT parsing, try to expand on what you have learned by building parsers for some other DCOLLECT record types such as "A" for VSAM Association information, or "SG" for Storage Group construct information.

If you have any questions or comments about the content in this article series, please contact me at

George Ng is a senior certified I/T managing consultant for IBM Systems and Technology Group Lab Services at IBM Poughkeepsie. His areas of focus include z/OS Parallel Sysplex, High Availability and Performance.

Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

What’s Really Driving Peak CPU Usage?

In many cases, batch processing accounts for as much as 40 percent


Leverage DCOLLECT Data With (or Without) REXX

Four-Star Advantage

The Polaris Workshop maps out a custom platform strategy

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters