in IBM Master the Mainframe 2018, Mainframe

IBM MTM: Part Three – Challenge #03

Hi there!

I feel like I’m progressing really fast, that’s good! I’m also very motivated because I’m expecting to get my IBM Digital Badge soon! I want the Part 3 badge really bad so I’ll do my best to solve all of its challenges. However, I guess the blog posts will slow down as the challenges get harder.

I’m lacking in humor lately, I don’t know why that is. You guys know of any good comedy movies? I need some sources of inspiration.

Also quick note, you’re now able to unsubscribe via the e-mail you receive. All your data gets removed. Good!

Sort Utility Capabilities Continued

IBM Master the Mainframe Part Three – Challenge #03

Today we got data from another company and we need to validate the data because we can’t trust that the data records are valid from the get go. I need to make another report on the data validity of the account limit and balance fields. Let’s check the data set first.

Mr. Peabody told me the SORT utility can perform a validity check on packed decimal data fields. He also asked me to observe the Account Limit packed decimal field that starts in position 9 for a length of 5 and the Account Balance packed decimal field that starts in position 14 for a length of 5.

I’m told I should use the more advanced features of SORT and ICETOOL with logical expressions. Let’s not go too deep into the theorem right now, I’ll check out the challenge assignment first.

First let’s edit Z30163.JCL and make a new member called sort003. Then copy ‘zos.public.toolbag(sort003)’ into Z30163.JCL(sort003). Same way we did last time, using the COPY primary command.

This is what I have now. Now modify the JCL job reference to ZOS.PUBLIC.BBRI.CLIENTS. Next up is to modify the ICETOOL control statement replacing both P,M,F. One for each packed decimal field with the appropriate starting position P, length M and data format F for Account Limit and Account balance.

We need to get our P,M,F from the table above. They said for each packed decimal position, we have those don’t we? Let’s just take a look at the formats and adjust the ON(P,M,F) fields.

Let’s submit and review our output, it should throw Max-RC with CC 00012.

JOB SORT003(JOB06280) SUBMITTED 
15.04.54 JOB06280 $HASP165 SORT003 ENDED AT SVSCJES2 MAXCC=0012 CN(INTERNAL)
***

Yup! Got the MAXCC=0012! Now let’s the system for all the information available of JOB06280 and check OUTDD. “If the Account Limit or Account Balance fields have a string of asterisks, then a bad packed decimal field was detected.”

You see those two rows of asterisks? Holy cow, asterisks is a difficult word to spell. All is ok! Now let’s check TOOLMSG and check the report. It should report invalid HEX VALUE.

Yup it reports two invalid HEX VALUES. Mr. 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.

Let’s create the rapport for the analysts. Again, I’ll create a new JCL member called sort004COPY ‘zos.public.toolbag(sort004)’ into it and modify the JCL its client master file input.

Those are a lot of parameters! WOW! Again, I’ll change the SETVAR and modify the control statements P,M,F for each packed decimal field.

  • 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

So what do we actually have to change here? I guess just the PMF for both packed decimals. Actually when you look at the statements it’s pretty easy! ‘INCLUDE=(P,M,F,EQ,NUM,AND,P,M,F,EQ,NUM)’ Include everything from starting position P for a length of M that has the format F and it should EQUAL type NUM AND same thing for everything from starting position P for a length of M that has the format F and it should EQUAL type NUM.

I guess it’s just copy paste the same P,M,F from last JCL. I though we needed the position of that specific record? It doesn’t feel right to just write the same PMF as last time. I’d really like to understand what I’m doing.

JOB SORT004(JOB06359) SUBMITTED
15.25.29 JOB06359 $HASP165 SORT004  ENDED AT SVSCJES2  MAXCC=0000 CN(INTERNAL)

Hmm…

There’s no BAD output I can xdc to Z30163.P3.OUTPUT(#03). Or do I literally have to check P3.OUTPUT and see if it’s there? Let’s have a look!

Yup it’s here! As I said earlier, I don’t really fully understand what I’m doing. I don’t think I can write my own ICETOOL script just yet. I might do this challenge again.

Mr. Peabody told me that another challenge is anticipated where the SORT utility and companion ICETOOL utility is the best way to complete the assignment. Next challenge is about COBOL though! Finally!

I probably won’t write my own COBOL just yet, but I’ll atleast get to smell it. Challenge #04 looks pretty easy, yay 🙂

COBOL

COBOL looks really cool! I’m genuinly interested in the language. I might buy Murach’s Mainframe COBOL whenever I setup my own mainframe emulator using Hercules-390 and some open-source operating system like the MVS 3.8J Operating System.

Also… I wrote this blog after a long day at work, let the hunt for spelling mistakes begin!

On a different note, what are you genuinly interested in?

Share this:

Write a Comment

Comment