FILTER – Post process selected records to reduce output

Use the FILTER command to post process what was returned to Workload Automation Programming Language from HCL Workload Automation for Z, to selectively reduce the output actually returned by Workload Automation Programming Language.

FILTER record [segment1-comparator(count)],[segmentn-comparator(count)]

or

FILTER segment [field1-comparator(value)],[fieldn-comparator(value)]

or

FILTER record|segment OFF

Filtering can be performed at two levels:
Record level
When a record is selected, the FILTER command can include or exclude segments based on the number of segments available of each type. For example, FILTER AD ADRUN-GT(0) returns output only for AD records that contain run cycles.
Segment level
When a segment is being processed, fields within it can be checked that they match the FILTER argument.

For example, FILTER ADOP ADOPWSID(CPU1) returns only operations that use workstation CPU1. When a segment is excluded by a filter, all of its child segments are also excluded.

The FILTER command must be issued before any LIST or SELECT command. Any number of valid segment or field names can be included on a single FILTER statement, all must be true for the record or segment to be selected for output.

For example, FILTER AD ADRUN-EQ(0) ADOP-GT(1) outputs only applications with no run cycles and more than one operation.

To stop filtering for any subsequent commands use a FILTER command specifying only the record or segment name and the keyword OFF. For example, FILTER ADOP OFF turns off filtering of ADOP segments.

Combining FILTER with other commands and options can produce some complex processing, without having to write any specific REXX code. In the following example: 
INCLUDE EQQFILE(ADCOM,ADRUN)
      OPTIONS RUNSTAT(SUSPEND) POSTPROC(Y) LOADER(*) DBMODE(UPDATE) DATA(-)
      FILTER AD ADRUN-GT(0)
      LIST ADCOM ADID(AB*) SELECT(Y)
the following actions are taken:
  • The INCLUDE statement ensures that only the common segment and run cycles are output.
  • OPTIONS RUNSTAT(SUSPEND) ensures that the output Batch Loader statements for the run cycle will include In and Out of Effect dates of LOWDATE.
  • FILTER ensures that only applications with run cycles are selected for output.
  • LIST causes every application beginning with AB to be selected for output, assuming it has at least one run cycle.
  • OPTIONS LOADER(*) sends the batch loader statements to the REXX stack.
  • OPTIONS DATA(-) ensures no ILSON data is written.
  • OPTIONS POSTPROC(Y) tells Workload Automation Programming Language when it has finished processing the commands in SYSIN to process the command on the REXX stack.
  • OPTIONS DBMODE(UPDATE) tells Workload Automation Programming Language to process the generated Batch Loader statements in UPDATE mode.

The result is that these four commands change only applications with names beginning with AB that have run cycles, to set them out of effect; thereby rendering these applications ineligible for planning, but still available to be manually added to the plan. Without the FILTER command, this job would attempt to update applications that have no run cycles, thereby performing a lot of unnecessary processing.

To create batch loader to perform the “suspension” of the applications in a later job, removing POSTPROC(Y), LOADER(*) and DBMODE(UPDATE) from the OPTIONS statement would cause the statements to be written to OUTBL. They could then be processed by a later job with OPTIONS DBMODE(UPDATE) coded to set the job into UPDATE mode.