Sort Utility Capabilities Continued
Part Three - Challenge #03

Background:

You will learn to validate specific field formats within a collection of data records

Programs that accept data input can help ensure field formats are valid.

When accepting data from another source or company, validating the data
is critical before trusting the data records are valid - simply referred to as data validity.

The previous challenge identified duplicate records and created a report with the
duplicate records for review by the business analysts or auditors.

Another requirement outlined in the previous challenge,
"Does the foreign client master file contain invalid field formats in the client records?"

You are asked for a specific report on the data validity of the account limit and account balance fields.


Advice from Peabody

Peabody knows what the business analysts and auditors want:

  1. A report on any record with an invalid packed decimal in the Account Limit field
  2. A report on any record with an invalid packed decimal in the Account Balance field

Peabody suggests review of record layout again


Peabody tells you the SORT utility can perform a validity check on packed decimal data fields.

Peabody asks you to observe the Account Limit packed decimal field starts in position 9 for a length of 5
and the Account Balance packed decimal field starts in position 14 for a length of 5.

Peabody tells you the key to using the more advanced features of SORT and ICETOOL starts with understanding a logical expression.


What is a Logical Expression?
Logical Expressions are used for:
  1. Comparison
  2. Substring Comparison Tests
  3. Bit Logic Tests
  4. Date Comparisons
  5. Numeric Test
  6. Alphanumeric
Logical Expressions consist of:
  1. Relational Conditions
  2. Comparison Operators

A logical expression conditional statement can have any of following forms:

  • relational_condition#1, comparison_operator, relational_condition#2
  • relational_condition#1, comparison_operator, C'constant'
  • relational_condition#1, comparison_operator, NUM
  • relational_condition#1, comparison_operator, alphanumeric_char
      where alphanumeric_char values are:
        UC - Uppercase characters (A-Z)
        LC - Lowercase characters (a-z)
        MC - Mixed case characters (A-Z, a-z)
        UN - Uppercase and numeric characters (A-Z, 0-9)
        LN - Lowercase and numeric characters (a-z, 0-9)
        MN - Mixed case and numeric characters (A-Z, a-z, 0-9)

AND or OR can be used to get the result from more than one logical expression

Relational Condition consists of:
  1. Starting Position (p)
  2. Length (m)
  3. Format (f)
      Format Types
Comparison Operators consist of:
  1. EQ - Equal to
  2. NE - Not equal to
  3. GT - Greater than
  4. GE - Greater than or equal to
  5. LT - Less than
  6. LE - Less than or equal to

Challenge:

Data Validity Report on Account Limit and Account Balance

Peabody wants you to start with an analysis of the BBRI client record Account Limit and Account Balance fields.
  where the data fields are both packed decimal.

PD is the relational condition data format type for packed decimal.

Peabody gives you the following to help gather the information:

  1. Edit z#####.jcl partitioned data set and select, s, a new member name, sort003
  2. Copy 'zos.public.toolbag(sort003)' into z#####.jcl(sort003)
  3. Modify JCL job to reference ZOS.PUBLIC.BBRI.CLIENTS as the input client data set name
  4. Modify ICETOOL control statements replacing both (P,M,F), 1 for each packed decimal field, with the appropriate starting position (P), length (M), and data format (F) for Account Limit and Account Balance
  5. Submit and review output
      Max-RC with CC 00012 is expected
  6. Check JCL JOB output DDNAME OUTDD
      If the Account Limit or Account Balance fields have a string of asterisks,
      then a bad packed decimal field was detected
  7. Check JCL JOB output DDNAME TOOLMSG
      All records with a problem packed decimal field should be reported with the invalid HEX VALUE

Peabody explains knowing the specific invalid hex values found in Account Limit and Account Balance field is needed because
while the business analyst or auditor did not request the specific hex values, once you find invalid hex values,
they may ask you for the specific hex value to help determine the correct amount.


Create Account Limit and Account Balance Data Validity Report

Peabody informs you sort JCL is available to create the report.

  1. Edit z#####.jcl partitioned data set and select, s, a new member name, sort004
  2. Copy 'zos.public.toolbag(sort004)' into z#####.jcl(sort004)
  3. Modify JCL job to use ZOS.PUBLIC.BBRI.CLIENTS as the client master file input
  4. Modify control statements replacing (P,M,F) for each packed decimal field with the appropriate
    starting position (P), length (M), and data format (F) for Account Limit and Account Balance
      Carefully study the INCLUDE statements
      -- GOOD records uses EQ comparison operator and the AND operation for checking both Account Limit and Balance
      -- BAD records uses NE comparison operator and OR operation for checking both Account Limit and Balance
  5. Submit and review output
  6. The "BAD" record report needed by business analysts is written to Z#####.P3.OUTPUT(#03)

Documentation Sources

Peabody Comment

Nice job!

Learning to use SORT utility and the companion ICETOOL utility can save you many hours of labor. Inexperienced technicians frequently write programs from scratch because they have never developed on an above average platform that contain system utilities such as SORT and ICETOOL.

Peabody anticipates based upon his previous experience that the business analysts will eventually ask for additional information such as:

  • BBRI clients with accounts at AAGI
  • Comment fields searched for specific words
  • Name and address fields containing non-printable characters

Peabody wants you to know that another assignment (challenge) is antipated where the SORT utility and companion ICETOOL utility is the best way to complete the assignment.


Successful completion is a report in Z#####.P3.OUTPUT(#03) containing records with invalid Account Limit and Account Balance packed decimal.

Next: Challenge #04