IBM Student Mainframe Challenge

Part Two
Time to complete about six to eight hours

Welcome to the Mainframe Challenge Banking Corporation!

The bank's system needs to be upgraded. You have been asked to work in a team that
is developing a prototype for the replacement to the bank's system that processes credit
card transactions. Details of credit card transactions arrive via WebSphere MQ
messages, and are processed via a CICS transaction. The CICS transaction processes
the requests and records the transaction details in a DB2 database, updating the
available credit on the card at the same time. The CICS transaction sends a reply back
for each transaction via WebSphere MQ, indicating whether it was processed
successfully.

Your colleagues have started to develop the prototype but are struggling to get it working. The aim of
this part of the challenge is to successfully complete the prototype so that you can simulate a payment
on your credit card.
We are going to use credit cards with a name instead of a 16-digit number for simplicity. Your credit
card name, and logon for the CICS system, are the same as your z/OS user id.

I'd like you to test that you can use the CICS
transaction via WebSphere MQ to simulate
a payment on your credit card. Also I have
some questions for you to answer to check your
understanding. Please send your answers to me
when you've finished the testing.

Help
You may find the following references useful when completing the tasks:

z/OS v1.11 Information Center:

http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp

CICS Transaction Server v3.2 Information Center:

http://publib.boulder.ibm.com/infocenter/cicsts/v3r2/index.jsp

WebSphere MQ v7 Information Center:

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp

The instructions for Part 1 of the Mainframe Challenge contain many useful tips as well!

INTRODUCTION TO CICS AND WEBSPHERE MQ

CICS
CICS (Customer Information Control System) Transaction Server is IBM's general-purpose transaction
processing software for z/OS. It is a powerful application server that meets the transaction-processing
needs of both large and small enterprises. It builds on z/OS and System z facilities to provide high
availability and scalability at a low cost per transaction; it supports large transaction volumes with a fast
and consistent response time.
Transaction processing is a style of computing, typically performed by large server computers, that
supports interactive applications. In transaction processing, work is divided into individual, indivisible
operations, called transactions. For example, withdrawing cash from an ATM and updating the balance
in a database. By contrast, batch processing is a style of computing in which one or more programs
processes a series of records (a batch) with little or no action from the user or operator. For example,
printing out bank statements for every account holder ready to send by mail.

Transaction processing middleware such as CICS allows application programmers to concentrate on

writing code that supports the business, by shielding application programs from the details of
transaction management:

It manages the concurrent processing of transactions.

It enables the sharing of data.

It ensures the integrity of data

It manages the prioritization of transaction execution.

When a transaction starts processing, CICS runs a program that is associated with the transaction. That
program can transfer control to other programs in the course of the transaction, making it possible to
assemble modular applications consisting of many CICS programs.
At any time, in a CICS system, many instances of a transaction can run at the same time. It would be
inconvenient to have to queue and wait for thousands of other people when buying something online.

WebSphere MQ
WebSphere MQ is IBM's premier messaging product. It can be used to send formatted data, in the
form of messages, between disparate applications via an asynchronous message delivery mechanism.
These applications might be written in different programming languages and be running on different
hardware and operating systems. Being able to connect these applications together can save customers
a lot of time and money.
Messages are placed on queues in storage, so that programs can run independently of each other, at
different speeds and times, in different locations, and without having a logical connection between
them. WebSphere MQ allows multiple and interchangeable applications to access the same, or
different, queues, which can help customers to develop a flexible and scalable infrastructure that
includes redundancy and thus reduces the risk of failure.
Many of the largest companies in the world have CICS and WebSphere MQ at the very heart of their
business.

GETTING STARTED
Before you can start this part of the contest you'll need to obtain the questions that you need to
answer along the way.
These are available in a question and answer sheet in the sequential data set called
ZOS.CONTEST3.PART2.ANSWER.SHEET.
Using ISPF take a copy of this data set, which you can complete as you progress through
the tasks.

To copy a data set, use utility 3.3 from

the ISPF primary panel. (Type =3.3 at
the command line in ISPF.)
You can also copy PDSE members from
this panel, by putting the member name
in brackets after the data set name.

Call your sequential data set <userid>.<userid>.ANSWERS

It should be allocated in tracks (TRKS)
It should have a primary quantity of 1 and secondary quantity of 1
It should have 0 directory blocks
The record format should be FB (fixed block) and the record length should be 80
The block size should be 32000
The data set name type should be blank

Ensure that the first TWO qualifiers of your data set are your user id otherwise your
answers may not be marked correctly.

If it all goes wrong, don't worry!

Delete the dataset by finding it in utility 3.4,
and typing D in the command column
on the left. Then try again!

You will be advised when you should be able to answer each of the questions, but please read the
comments at the top of the answer sheet carefully before proceeding.
Fill in your z/OS user id in the space provided above question 1.

CICS Primer
Now's a good time to give you some guidance on using CICS.
You start a CICS transaction by pressing the CLEAR* key to clear the screen, and entering
the transaction identifier, either by itself or followed by data, on the command line of the
screen. The command line is a single line, usually at the top of the screen.
You can type the transaction identifier by itself and follow the prompts until a complete
transaction command is built up, or you can type the complete transaction command on the
command line. If you do not enter enough information, or if the information you enter is
wrong, you are prompted to complete or correct your input.
For example, in the following transaction, CESF is the transaction identifier and the
additional data is GOODNIGHT.
CESF GOODNIGHT
This transaction is used to log off CICS.
When the transaction starts, it processes the additional data. At the completion of this
transaction, you get the following message:
STATUS: SESSION ENDED
After a transaction has completed, press the CLEAR* key to get a blank screen in readiness
for the next transaction.
To end a transaction use the PF3 key.

* The special 3270 CLEAR key is not on most keyboards. However, 3270 emulators either
provide this via a context (right-click) menu or allow you to map it to a key of your choice,
often Pause/Break by default.

You can find more information on CICS in the CICS Transaction Server v3.2 Information Center.

Using CICS
Open a second 3270 session but instead of entering TSO at the SELECTION ==> prompt enter
LOGON APPLID(CICSZ057) instead.
You should then be presented with the CICS sign-on screen:

Enter your user id and password and press enter (remember this is the Ctrl key).
The screen should clear except for the following message near the bottom:
DFHCE3549 Sign-on is complete (Language ENU).
Answer questions 1-5 in your <userid>.<userid>.ANSWERS data set, now that you have
successfully logged on to CICS.

USING JCL
If you think about how you might achieve any given task in the real world, you typically break it down
into one or more steps, where each step completes a particular part of the bigger picture and typically
requires the use of different resources.
Job Control Language (JCL) is how you describe this information to z/OS, whereby a job represents a
task.
For every job that you submit, you need to tell z/OS where to find the appropriate input, how to
process that input (that is, what program or programs to run), and what to do with the resulting
output. You use JCL to convey this information to z/OS through a set of statements known as job
control statements.
JCL's set of job control statements is quite large, enabling you to provide a great deal of information to
z/OS. Most jobs, however, can be run using a very small subset of these control statements.
Within each job, the control statements are grouped into job steps. A job step consists of all the control
statements needed to run one program.
If a job needs to run more than one program, the job would contain a different job step for each of
those programs.

Job Control Statements

Every job must contain:
- A JOB statement to mark the beginning of a job and assign it a name. This statement is
also used to provide certain administrative information, including security, accounting, and
identification information. Every job has one and only one JOB statement.
- At least one EXEC (execute) statement, marking the beginning of a job step, a name for
the job step, and the program or procedure to execute. You can add various parameters to
the EXEC statement to customise the way the program executes and the conditions under
which the step should be run.
Most programs require some input or generate some output and so usually also contain:
- One or more DD (data definition) statements, to identify and describe the input and
output data to be used in the step. This statement may be used to request a previously
created data set, to define a new data set, to define a temporary data set, or to define and
specify the characteristics of the output.

Each job control statement has five fields:

1. An identifier field, which is typically two forward slashes (//). The entire line is treated as
a comment if the two slashes are followed by an asterisk (//*).

2. A name field, identifying the statement so that it can be referred to later

3. An operation field identifying the type of statement, i.e. JOB, EXEC, DD.
4. A parameter field
5. Anything following the parameter field is treated as a comment and ignored.

JCL statements can be coded only up to column 71. You may question why JCL has this format but it
was historically input using punch cards that had 80 columns, the last 8 of which were used for line
numbers.

JCL's layout can look a bit confusing

when you see it for the first time.
Luckily the ISPF editor can display
JCL syntax highlighting if you type
HILITE JCL (or HILITE AUTO) when
editing (not browsing) a JCL member.

For more information on JCL you can look in the JCL Reference section of the MVS book in the z/OS
Information Center.

USING SDSF
In this section, you may find yourself having to repeatedly swap between two different applications, for
example, between the answer sheet data set in the editor, and SDSF to find out the answers to the
questions. It can get frustrating to keep having to go in and out of different applications and back
again, so there is a better way to do it:
Pressing PF2 will cause the screen to "split" at your cursor, showing the two screens
separated by a horizontal dotted line. You can then press PF9 to swap between the two
screens. Press PF3 all the way back to what would be the TSO prompt to get rid of a
screen.
To maximise the available screen size, put your cursor on the very top line of the screen
before pressing PF2.

You'll never know how you lived without it!

SDSF Primer
System Display and Search Facility (SDSF) provides information that you can use to monitor,
manage and control a z/OS system.
You can use SDSF to view the system log and the status of jobs that are running
in the system or have finished running, including any held output of jobs that
have not yet been purged (discarded). Use SDSF to view the output of any jobs
you submit.
You access SDSF from the ISPF primary panel with the command S.
From there, DA can be used to view the active (running) jobs in the system, including any
started tasks, which are a special type of job.
ST can be used to view the status of jobs, those that are active, those yet to be processed,
and those that have completed.
Once you are viewing a list of jobs, at the command input prompt you can filter the list of
jobs to just those that you own by entering:
OWNER UKxxxxx
To revert back to showing all jobs enter:
OWNER *
Similarly you can filter the list of jobs by their name by entering:
PREFIX ABC*

which would show only those jobs whose names begin with the letters ABC.
To remove this filter enter:
PREFIX *
You can use both the owner and the prefix filters at the same time.
These are particularly useful because they hide jobs on the system that you are either not
interested in or not authorised to look at.
Be aware that SDSF remembers the filters that you are using. If you are not seeing a job
that you expect to see, set both filters to a single asterisk (*) so that all jobs are displayed.

In the DA and ST panels you are presented with a list of jobs. Use the PF7 and PF8 keys to
page up and down.
To view more information about a particular job you can enter S in the left-hand column
(NP) and press Ctrl.
This can provide a lot of data and so alternatively you can enter a question mark (?) instead,
which will give a listing of the various sections of the output. You can then use S to select
these sections individually.
Use the PF3 key to exit the screen that you are on and return to the previous one.

The prefix and owner filters aren't displayed

anywhere by default, so if you leave the filters
on you might end up with a blank job list! ISPF
remembers your filters between sessions, so
look in the Options menu at the top of the
screen and choose option 5 to display them.

 Answer questions 6-8 now that you are familiar with JCL and SDSF.

THE UNIT-TEST APPLICATION

Running the unit-test application
We've taken a detour around some other
mainframe facilities, so it might be worth
reviewing the initial diagram to focus back on
task testing our payment processing system.
The unit-test application developed by your
colleagues is designed to be run via a
batch job, started using some JCL.
Create a PDSE, as in part one, called <userid>.PART2.JCL.
It should be allocated in tracks (TRKS)
It should have a primary quantity of 1 and secondary quantity of 1
The record format should be FB (fixed block) and the record length should be 80
The block size should be 32000

Create a member in your JCL data set called PAYMENT, copying it from the member of the
same name in the data set called ZOS.CONTEST3.PART2.JCL.
Substitute the placeholders in the job as described you can use any monetary value and
description of your choice.
Submit the job by typing SUBMIT on the command line while editing it, and look at its
output using SDSF.

Oh no! It looks like the code isn't

ready yet even
the JCL that tells z/OS to run the
batch program didn't work!

Fix the JCL errors, using the JCL Reference section of the MVS book in the z/OS Information
Center to help you find out what is wrong and how to fix it.
Answer question 9.

Recompiling the unit-test application

Having completed the previous exercise and answered question 9 you will have found that the unit-test
application is missing.
Before you can recompile it you need to create another PDSE in which the compiled program can be
stored and from which it can be run.

The source code for the application

is in the data set ZOS.CONTEST3.PART2.C
It shouldn't take too long to compile and
run it ourselves using some different JCL.

Create another PDSE named <userid>.PART2.LOAD, defining it with the same attributes as
ZOS.CONTEST3.PART2.LOAD.
Now you need to copy another set of JCL, which you can use to compile the application, to another
member in your JCL data set.
Copy the job from the member called COMPPAY in the data set ZOS.CONTEST3.PART2.JCL
Substitute the placeholders in the job as described and compile the unit test
application - you should not encounter any errors this time.
The COMPILE step should have an RC of 0.
The PLKED step should have an RC of 4.
The LKED step should have an RC of 0.
The GO step should have an RC of 1.

Rerunning the unit-test application

Now you have recompiled the unit-test application, you can try to run it again as before.
Update your JCL so that the system looks for the program in your load library and rerun it.

Oh dear, more problems! It found the

application and ran OK this time,
but there's an error from WebSphere MQ.

Now is a good time to answer questions 10 and 11.

It looks like you might need to create (define) your reply queue.
WebSphere MQ provides ISPF panels to help you administer queue managers - these can be found on
ZEUS under IBM Products - WebSphere MQ. You should be presented with a screen as below:

The name of the queue manager (the connect name) can be found in the JCL you used to run the unittest application.
You can press the PF1 key on any panel to obtain context sensitive help (i.e. help for the field your
cursor is on).
Define your reply queue.

Your reply queue should be defined

like the SYSTEM.DEFAULT.LOCAL.QUEUE
Oh, and make sure you name it
<userid>.REPLY in UPPERCASE!

Now you have successfully defined your reply queue:

Answer question 12.

COMPLETING PART 2
You should now find that you are able to successfully run the unit-test application.
To complete this part of the Mainframe Challenge you must:
Use the unit-test application to record a transaction against your credit card so that
your current balance is not zero. You can record more than one transaction if you
wish, and the amounts and descriptions are your choice.

Submit your answers

Once you have recorded a transaction against your credit card:

Review your answers and then submit them so that they can be marked.
To do this go to option 6 (Command - Enter TSO or Workstation commands) and enter:
XMIT ZOS19.MATTK DA('<userid>.<userid>.ANSWERS')

Congratulations! You've finished all the steps for

Part Two! Thanks to you, we can deploy the
changes to our CICS system on time, and our
customers can benefit.

You've achieved a lot so far, but there's

still a way to go! Part Three builds on
what you've already learned, and gets
even more challenging you'll be using
more advanced features of WebSphere
MQ and CICS! See you there!

I'm recommending you to our corporate credit card

Team to carry on to Part Three of the contest
you'll need access to their mainframe systems.
Please send an email to your contest administrator
to request a new user ID, including in your
email your current user ID. Good luck!