Mainframes 360
The one stop destination for System Z professionals

Tuesday, June 30, 2009

IBM’s place in Cloud Computing – Cloud z

Cloud computing is the in-thing in Computers today. A large group of powerful servers
can be used for computational problem solving. More importantly, for clients, the cloud
computing model appears to be very lucrative, since it adopts pay-as-you-go strategy, and gives a good Return-on-Investment(ROI).

Nevertheless, cloud services providers can make good revenues, only when they service large volumes of customers. To be a successful, Cloud Service Provider, you must be able to keep the operational efficiency of your cloud high. Clouds are expected to have a high degree of Reliability, Availability and Serviceability – terms which are usually associated with IBM Mainframes.

Mainframe's place in the Cloud
Every cloud on the Internet has a data-center. Out of total cost of running a cloud, most of the expenses are from the operational side. A whopping 44 percent (huge chunk) of the cost goes into maintaining man-power at the data-center. To achieve operational efficiency, the Cloud Computing Providers make use of automation and virtualization. Virtualization is the forte of IBM Mainframes. Ever since the inception of the Virtualization idea by IBM in 1979, most other computer firms have made huge benefits out of it.

Building cloud services with a Mainframe will allow automation¸ to an extent that, data-centers will be able respond to huge variations in workload, in real-time, moment-to-moment without any manual intervention, thereby allowing a small team to manage and operate the equivalent of hundreds of Intel and RISC Servers.

IBM Mainframes are comparatively inexpensive. If you have a distributed system, with many customers, and millions of users, imagine the cost of salary of the IT staff and administrators, and their benefits. Using Mainframes with just a few Mainframe Administrators, can cut down the costs drastically.

Energy efficiency is another important advantage. This is one feature which IBM's high end Mainframe Servers (System z and Power Systems Servers) boast off. Indeed, IBM is moving its workload from 3,900 mid-range servers to just 30 Mainframes, and resulting in great energy savings(upto 80 percent) and saving of floor space.

Though Cloud Computing is new, many of its ideas, have its roots in IBM Mainframes. The following similarity between Cloud Computing and Mainframes makes it clear.. IBM Mainframes have been running multi-tenancy(multiple users on a single machine on a single application) for decades and decades. Its basically a Mainframe model, where number of things run together on a single machine, but in isolation. You need Reliability, Availability, Security, Auditing, Privacy, Data Integrity.

Indeed, the ultimate goal of Mainframes has been Shared Computing. It has been supporting Multi-tenancy ever since, the TSO(Time Sharing Option) was introduced in 1962.

It remains to be seen if this is the next BIG THING, or just a fad.

Monday, June 29, 2009

DD Statement for Reading Datasets

Q. What is the DD Statement used for?
Hook-up an electrical appliance, a grinder-mixer, a microwave oven, a Television to any plug-point, and it’ll work. If you wanna feed Inputs to your COBOL Programs, or store the data results they produce, you’ve gotta use the Inlets and Outlets – that the COBOL Program offers. Every inlet or outlet point is referred to by a short symbolic name like INFILE, OUTFILE, SYSUT1, SYSUT2 and so on. You need to hook up or plug-in real physical Mainframe Files like SYSADM.INPUT.FILE and SYSADM.OUTPUT.FILE into the INFILE and OUTFILE points, to run the Program and process the Data.   COBOL Programs refer to files by a short symbolic-name. At the time of running the Program, when you type a job, you code a DD Statement to attach, or hook-up an actual physical Mainframe File to these mere symbolic names. Get things straight, if a COBOL Program accesses 5 files, to run the Program, the job's got to have 5 DD Statements. Each DD Statement falls into one of these categories: 1. Reading a Dataset
2. Sending output to the Spool(Output queue)
3. Writing Output to a Dataset
In this article, I’ll show you what you need to know, to code DD Statements for reading Datasets.
Q. What is the simplest DD Statement for reading?
You can code the simplest and the most common DD Statement for reading from a Mainframe File like this :


The DD-name that you code on the DD-Statement, should match the symbolic-name, that the program expects. The DD-name should start with an Alphabet, and can be upto eight characters long. It may contain @,#,$ or numbers as well. The ready-made IBM Software IEBGENER expects to read Input records from SYSUT1 File. Hence, I have coded the DD-name SYSUT1 on the DD Statement.

assigns an Mainframe file-name value – SYSADM.DEMO.INPUT to the mere symbolic file-name SYSUT1, that the IEBGENER Program refers to. The DSN or DSNAME parameter specifies the actual Mainframe File-name Value. DSN stands for "Dataset-name". Putting it altogether, when you look at the //SYSUT1 DD Card, you can tell IEBGENER software would read the data from SYSADM.DEMO.INPUT Mainframe File.

The only additional thing, you need to code on a DD Statement is DISP. DISP Keyword stands for "Disposition". DISP can take several inputs, but when you’re reading data from a Mainframe-File, you can code either DISP=SHR, or DISP=OLD.
Q. What DISP=SHR means?
When you code DISP=SHR, you are telling the OS that you need Shared Access on the file. You do not want to lock or reserve the dataset exclusively for you use. You are okay and do not care if someone-else is already reading from the Dataset, which is of-course acceptable.

DISP=SHR is the most preferred way, of coding the DISPosition, when you want read from the Datasets. At a time, upto 127 jobs can read from the dataset.
Q. What DISP=OLD means?
DISP=OLD is opposite to coding a DISP=SHR. If you code DISP=OLD, on a DD-Statement for reading a dataset, it means you are locking the file exclusively for your use. When you read a Dataset, with a DISP=OLD, it reserves the Dataset exclusively only for you. Any other job cannot access the data-set at the same time, and will keep on waiting for your job to complete. With DISP=OLD, only 1 job can read the dataset at a time.

For reading datasets, coding a DISP=OLD on a dataset to lock it exclusively for your job, is a very selfish strategy. Here’s why, coding a DISP=OLD to read from a Dataset is a bad idea :
- DISP=OLD denies access to data-set to any other jobs, so long as your job is reading from it.
- DISP=OLD can delay your job, if there are any other jobs currently reading the dataset, and your job needs exclusive-access to it.

Look at the below Job(JCL). I have coded DISP=OLD on the //SYSUT1 DD Card. //SYSUT1 File points to the SYSADM.DEMO.INPUT Dataset. This implies, when the IEBGENER Program runs, it’ll try to acquire exclusive access to the file and lock the SYADM.DEMO.INPUT file. 


Now, I am gonna keep the SYSADM.DEMO.INPUT Mainframe file open in TSO-Edit Mode for reading in the ISPF Editor.


Here’s the contents of the SYSADM.DEMO.INPUT file, when I open the dataset in Edit-mode in ISPF Editor.


Look what happens, when I try to hit SUBMIT on the Job, that tries to read the data from SYSADM.DEMO.INPUT in DISP=OLD(Exclusive) access mode, with the file open in TSO-Edit Mode. Recall, that only one job can have Exclusive access to a dataset at a time.


So, the Log-report of the SYSADMB job in the Spool shows the following messages.


As you can see OLD requires exclusive-access to the Dataset SYSADM.DEMO.INPUT. In this case, the dataset I am trying to read is already opened in TSO-Edit mode. The system-messages indicate that the job is waiting on the dataset to become free and available for exclusive-access. SHR doesn’t suffer from this problem. Always use DISP=SHR for reading from Datasets!
Q. What's the problem if I omit the DISP Parameter, when reading a Dataset?
The first sub-parameter of DISP could  be OLD, SHR, NEW or MOD. Essentially, the last two -  NEW and MOD are applied, when you want to create New Datasets. If you don't code DISP at all, it defaults to NEW. Because of the error messages MVS uses, this can be quite a confusing problem.

I have coded a Job, that runs the free IBM Software-Program IEBGENER. IEBGENER copies the contents of //SYSUT1 File to //SYSUT2 File. I have
attached(Hooked-up) the physical Mainframe file SYSADM.DEMO.INPUT to the //SYSUT1 Symbolic-name. The Mainframe-File SYSADM.DEMO.OUTPUT is assigned to the //SYSUT2 DD Card. So, IEBGENER tries to read the data from the SYSADM.DEMO.INPUT Dataset, and copy it to SYSADM.DEMO.OUTPUT File.

I have not coded the DISP Parameter, on the //SYSUT1 DD Statement for reading the Dataset.


When I Submit this job, to run the IEBGENER Software, the MVS OS complains about my JCL, and kicks it out(rejects it). Here's a snapshot of the JESMSGLG Listing.


To find out, what's wrong with the JCL, I’d see the JESYSMSG Listing. Here is a picture of the messages printed in the JESYSMSG Listing. Upon omitting the DISP, MVS defaults to DISP=NEW on the //SYSUT1 DD Statement. However, the error-message printed in the Log-Report, IEF344I says "SPACE was not specified for allocation of dataset SYSADM.DEMO.INPUT", which a really weird looking message. This does not hint at my failure to code the DISP Parameter on the //SYSUT1 DD Statement.


IBM Mainframes turn 45

IBM Mainframes turn 45

When IBM introduced the System/360 on April 7,1964, it was named after the number of degrees in a circle. It encompassed every need of every user. Contrary to what many might think, IBM System/360 was born in New York, Hudson bay and not in the Silicon Valley. The System/360 was the first to use SLT micro-circuitry. Moreover, it paved the way for the world renown Customer Information Control System(CICS).

CICS began to be used extensively for Online Transaction Processing. ATM Transactions, flight reservation systems all began using CICS. This brought the Mainframes out of the Machine room, and it began to be exploited commercially by many users. It allowed the companies to store and retrieve business data at their workplace. Today, most of the transactions of the world are handled by CICS. System/360 also featured the first Database System IMS(Hierarchical Database Management System) which was used in the Apollo 11 mission, which put the man on the moon. It also set the scene for IMS's DB2 software later.

I believe and maintain, that IBM Mainframes have always continued to evolved. They were the firsts to introduce the concept of virtualization – the notion of a virtual machine. IBM Mainframes have a huge cache memory and high performance memory systems that can be shared between many users. Mainframes have intrinsic ability to prevent memory leaks. You are reminded of this, every time you see a Blue Screen of Death on the Microsoft Windows PC.

In the year 1979, IBM also introduced the Universal Product code, which later came to be used as the Bar Code printed on all products sold in Retail Stores. Using this technology, it became easy to store information about a product name, description, its price and manufacturer and all other details at one centralised place, and could be accessed from any POS terminal.

In the 90s, IBM introduced System 390 which smashed the 1000 MIPS landmark and set a new record in computing power. Today, the z10 series server have attained record speeds of 30,000 MIPS.

Sunday, June 28, 2009

COND Parameter, Job Abend

Q. What is Return-Code(Condition Code)?
When you run COBOL Programs by typing a Job, and submitting it, how do you tell, whether the COBOL Program ran fine, or not? COBOL Programs use Code-Language to tell you about their success/failure. When a COBOL Program runs, it leaves behind a signature(trail) in the form of a 2-Digit Status Code, that indicates whether the COBOL Program completed successfully, or it completed with errors. This 2-digit number trail left behind by a COBOL Program, to indicate its success or failure is called Return-Code(Condition Code).

I’ve written a job SYSADMB that’s running the ready-made program IEFBR14 in //STEP01, and IEBGENER free program in //STEP02.


As I said, whenever COBOL Programs complete, they set a COND CODE, to indicate if they completed successfully, or completed with errors. The log-report of the job would display the COND CODE set by the COBOL Program.

The picture below shows the JESYSMSG Listing in the Spool. //STEP01 that runs IEBR14 COBOL Program has set COND CODE = 00. This means IEFBR14 completed without errors successfully. //STEP02 that runs IEBGENER COBOL Program has set COND CODE = 00. This implies IEBGENER was able to copy the contents from //SYSUT1 file to //SYSUT2 File, without any errors successfully.


Thus, Return Code(Condition-code) is set by the COBOL Program to send out signals to the outside-world, a code 0 could be Successful Completion, a code 5 could mean completed with warnings, a code 10 could stand for Bad-Input-Data etc. In other words, Return Code(COND CODE) represents communication from the COBOL Program to the Outside-world.
Q. How do I know, what’s a good condition-code and what’s a bad one?
The COBOL Program sets the COND CODE. If you have written your own custom COBOL Program, you are the COBOL Programmer, you would set the Return-Codes in the COBOL Program. You know what each Condition-Code would mean.

But, what if you haven’t written the COBOL Program – say it’s your friend’s COBOL Program, or think of the ready-made free programs supplied to you by IBM like IEBGENER or SORT. How do you tell what’s a good acceptable Condition-code, from IEBGENER and which are bad condition-codes? Well, most Programs come along with a documentation manual, which if you read, you would know, what the Program does, and the possible COND CODE that the Program sets.

Generally IBM Software such as the free programs IEBGENER, SORT, IEFBR14, IEBPTPCH, compiler IGYCRCTL, Linkage Editor IEWL and other ready-made utility programs, follow this convention with the COND CODE Values -

COND CODE 00 – Program execution was completely successful.
COND CODE 04 – Program execution was successful, but with warnings.
COND CODE 08 – Program execution was seriously flawed, it failed.
COND CODE 12 – Program execution was very seriously flawed, severe errors.
COND CODE 16 – Program execution disastrously failed.
Q. What is COND Parameter?
In a multi-step job-stream, that contains several steps, you often wish to turn off a certain step. When you want to turn off(shut off) a step, when you don’t want to run a step in a Job(JCL), you code the COND Parameter on the EXEC Statement. Thus, COND Parameter is used to turn-off or skip a step.

I’ve written a simple ten-step Toy Job to illustrate the idea – how you can turn-off or skip steps using COND.


When you code COND Parameter on a Step, before running the step, first the COND condition is gonna be checked. If the COND Condition is true, the step is turned-off(shut off) or flushed. Only when the condition is false, then the step runs. In the above example, //STEP03 runs the ready-made free program IEFBR14. Suppose IEFBR14 completes successfully and sets COND CODE = 00. Before running //STEP05, first COND Condition is checked.
Ask yourself the question, Is 0 EQ(Equal to) STEP03’s COND CODE? As 0 EQ 00, the COND Condition is satisfied, so the //STEP05 will be turned-off or skipped off.


Why is this useful? Think about it, say you’ve written a 3-step Compile-Link-Go job, to compile your own custom COBOL Program, Link-Edit it and then run it. If your program is syntactically correct, the compiler is able to compile successfully and issues a COND CODE 00. You go ahead and Link the Program, and then run it.

But, what if your COBOL Program is faulty? The Compiler completes with errors and issues a COND CODE 08. If the compiler issues errors, there is no point in continuing with further Link-editing processing. You would want to go back and correct your COBOL Program first. So, I want to shut-off the //LINK Step, if the compiler issues severe errors, and the //COMPILE Step leaves behind a COND CODE Greater than 4(like an 08, or a 12).

Let me put it this way -
Turn-off(Do not execute) the //LINK Step,
if 4 Less Than(LT) COND CODE of //COMPILE


Makes sense doesn’t it? Let me go a step further and say, you don’t want to run the Program either if the Compiler issues errors, or if the Link-Editor fails. Look at the GO Step below -


This COND is saying, "If 4 is less than the COND CODE of the //COMPILE Step, or if 4 is less than the COND CODE of the //LINK Step, in either of the cases, turn-off(shut off) the //GO Step". We wouldn’t try and //GO if either the //COMPILE or the //LINK edit failed. This is fairly easy to grasp.
Q. What is the general format of COND?
The general pattern of coding COND Parameter on the EXEC Statement is -

For example,


This tests the COND CODE of //STEP03. The mantra you would recite is,
Do NOT execute this step, if 4 is Less Than(LT) COND CODE of //STEP03.

But what if, you want to turn-off(skip) //STEP05, if any of the prior steps – either //STEP01, or //STEP02, or //STEP03, or //STEP04 fails? You do not want to test for the COND CODE of a fixed particular step, but in general you wanna test for the COND CODE of any prior(previous) step. That’s when you don’t type an explicit step-name like //STEP03, but instead leave it blank.


The COND says, Do Not Execute this step, if 4 is Less Than(LT) the
COND CODE set by any of the previous(prior) steps.

If you want to make a Compound-test(a test involving two to eight individual tests), you code COND in this way.

Q. What is a Job Abend?
When good and well-designed Programs encounter an exceptional error, they trap it, and set a non-zero return code and terminate grace-fully. Bad return codes are one thing. But, sometimes the Program attempts to execute an instruction at the machine code level, which is logically impossible to perform. The MVS OS has to kill the program. This abnormal termination of the program or crash is called an Abend. Every Abend leaves behind a System Abend-Code Sxxxx-yyy. 

There are also other problems like, Out-of-Space Issues(Too less space to create a dataset), I-O Errors while opening a dataset, the dataset not being available that cause a crash - an Abend

Look at the toy-job, in the picture below. There are ten steps in this toy job, each step runs a program. 

Each step STEP010, STEP020, STEP030, STEP040 runs the free ready-made COBOL Program IEFBR14. I have coded STEP050 to manually raise an Abend – it runs S806 program(well there’s no such program really by the name S806), so the job abends at STEP050(Load Module not found – abend code S806).

When the job abends at STEP050, the job is in a hurry(rush) to go to the Abend Exit Door. The Operating System says, "Nothing doing, you’ll be kicked out, flushed!". The job can no longer continue any further processing on the Mainframe Computer, all the remaining steps STEP060, STEP070, STEP080, STEP090 and STEP100 are flushed(skipped), and the job is kicked out to the Output Queue Area.

When I hit Submit, on the 10-step toy job, STEP010 runs successfully, STEP020 runs, STEP030 runs fine, STEP040 runs and then kaboom! At STEP050, the job abends, as the Program(Load) that you wanna run is not found – it sets an Abend-Code S806. The job is kicked out to the Output Queue,  and all the remaining steps are flushed out, skipped – no further processing can continue. So, STEP060, STEP070, STEP080, STEP090 and STEP100 everything gets flushed.

The log-report of the job, as seen in the Spool is shown in the picture below. 

As shown the job abends at STEP050 with abend-code S806, Load Module not found. In the picture below, all the successive steps STEP060, STEP070, STEP080 and so on, have been flushed.
To understand what EVEN and ONLY do, you need bear in mind, that the MVS OS "sees" every job running either in the Normal Processing Mode, or in the Abnormal Termination Mode. Of course, when you hit SUB on a job, all jobs start out in the Normal Processing Mode. If everything goes well, the job completes successfully. Sometimes, due to a fatal error, which the program is unable to handle(for example Bad Data – S0C4 Error), the program gets killed or terminated. 

When a program Abends, and the job goes into Abnormal Termination Mode, it is in a hurry(rush) to go to the Abend-Exit door, and no further processing is allowed to continue, all the remaining steps are flushed out(skipped), and the job is kicked out to the Output Queue. In this rush, if you still want stick your foot out in this process, and say, "Hey wait a minute, I still want to run this step!". Ordinarily, MVS will simply flush out all the remaining successive steps, after a program fails. But, coding an EVEN or ONLY allows you to run some last-minute steps, when a job abends. 

When you code a COND=EVEN on a step, its like Force-executing a step. When you code


it reads as, even if the job abends at any of the previous steps, force-run this STEP070. Even if the job is in Abnormal Termination Mode, run this step! Abend or no-abend, doesn’t matter, always run this STEP070. No matter, whether the job is Normal-Processing Mode or Abnormal-Termination mode, always run this step, darn it! Thus, coding a COND=EVEN forces the step //STEP070 to run, even if the job is in Abnormal Termination mode, which would have otherwise flushed-out(skipped) all the remaining steps.

In the ten-step toy-job below, when I hit SUB on the job, the job blows-up(abends) at STEP050.


The Log report of the above job in Spool is shown in the picture below. At STEP050 the job abends with an Abend code S806 – Load Module Not found. STEP060, STEP080, STEP090 and STEP100 are flushed(skipped). COND=EVEN causes STEP070 to run.

When you code a COND=ONLY on a step, it runs the step ONLY when the job abends. ONLY causes a step to run, only if the job is already in Abnormal Termination Mode. For example, when I code -


It implies, run STEP070 only if the job abends at any of the previous steps. If the job is in Normal Processing mode, don’t run this step.

Neither EVEN nor ONLY do any checking on COND CODE(Return Code) Values.

Thursday, June 25, 2009

Basics of JCL Simplified

Q. What is a Job?


JOB(Batch JOB) is written to run a PROC.
Q. What is JCL ?
You need to tell the MVS Mainframe, which PROC to run, what is the input dataset, where the output dataset is stored, at the outset, right at the beginning. Hence, you must write these specifications about a JOB, before submitting the JOB to the MVS in batch mode.

A JOB is written in JOB Control Language(JCL). JCL is just like any other programming language, it tells the MVS about the Batch Job. It tells the MVS, what datasets will be needed to run the JOB, request hardware devices etc. As most books quote, JCL forms the crucial link between the application program and MVS OS. You introduce a Batch JOB to the MVS OS, using JCL.
Q. What is the basic JCL Format?

Every JCL statement has the following format.

Every statement in JCL has a name, by which it can be referred to. Every JCL statement should begin with two forward slashes //. Next, comes the operation field. Here, you specify the type of operation e.g. JOB, EXEC and DD. Then, you write the list of operands separated by commas. Finally, you have a comments field.

Q. Are there any JCL Coding Guidelines?
Yes, just as every programming language like C has its own grammar, its own syntax, JCL also has its own syntax.
1. Every JCL Statement begins with two forward slashes //.
2. JCL is case-sensitive(we always use the upper-case)
3. The name field is optional.
4. The name field must begin in column 3.
5. The operation field must begin on or before column 16.
6. The operands can continue upto column 71.
7. If the operands overflow onto the next line, they must start between columns 4-16.

As you might deduce from the above rules, JCL lays down stringent guidelines about the alignment of different fields. To check if you have written valid JCL, you can always type HI JCL on the screen, to highlight the different fields.



To many people who are thrown to work at a mainframe computer on their first job, they feel lost. Mainframe people seem to speak a completely different language and that doesn't make life easy. What's more, the books and manuals are incredibly hard to comprehend.

"What on earth is a Mainframe?" is an absolute beginner's guide to mainframe computers. We'll introduce you to the hardware and peripherals. We'll talk about the operating system, the software installed on a mainframe. We'll also talk about the different people who work on a mainframe. In a nutshell, we'll de-mystify the mainframe.

Readers based in India, can buy the e-book for Rs. 50 only or the print book. International readers based in the US and other countries can click here to purchase the e-book.