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:
- A report on any record with an invalid packed decimal in the Account Limit field
- 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?
- Substring Comparison Tests
- Bit Logic Tests
- Date Comparisons
- Numeric Test
- Relational Conditions
- 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
- Starting Position (p)
- Length (m)
- Format (f)
- EQ - Equal to
- NE - Not equal to
- GT - Greater than
- GE - Greater than or equal to
- LT - Less than
- LE - Less than or equal to
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:
- Edit z#####.jcl partitioned data set and select, s, a new member name, sort003
- Copy 'zos.public.toolbag(sort003)' into z#####.jcl(sort003)
- Modify JCL job to reference ZOS.PUBLIC.BBRI.CLIENTS as the input client data set name
- 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
- Submit and review output
Max-RC with CC 00012 is expected
- 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
- 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.
- Edit z#####.jcl partitioned data set and select, s, a new member name, sort004
- Copy 'zos.public.toolbag(sort004)' into z#####.jcl(sort004)
- Modify JCL job to use ZOS.PUBLIC.BBRI.CLIENTS as the client master file input
- 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
- Submit and review output
- The "BAD" record report needed by business analysts is written to Z#####.P3.OUTPUT(#03)
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.