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.

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. 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.

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 //LINK    EXEC PGM=IEWL,COND=(4,LT,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 - //GO      EXEC PGM=*.LINK.SYSLMOD, //  COND=((4,LT,COMPILE),(4,LT,LINK)) 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 - COND=(value,operator,step-name) 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.

Q. What is COND=EVEN and COND=ONLY?

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 //STEP070 EXEC PGM=IEFBR14,COND=EVEN 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 - //STEP070 EXEC PGM=IEFBR14,COND=ONLY 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.

EXEC Statement

Q. What is the EXEC Statement in JCL used for?

The EXEC Statement in JCL, represents one step. You would code one EXEC Statement in your Job, for each step. If your job has a dozen steps, you must code a dozen EXEC Statements in your JCL.  One step executes(runs) one Program. A Program consumes data from Input Files and produces results data to be written to Output Files. In JCL, you code a DD Statement to refer to Input Files or Output files. Buckle up you seatbelts now..  One EXEC Statement runs a Program, DD Statements tell you what input/output files this Program uses. And then comes the second EXEC Statement, that runs another Program, followed by corresponding DD Statements that refer to the files used by the second Program, and then the third EXEC Statement, followed by its corresponding DD Statements(files) and so on.. //   EXEC program-1 //   DD file-1 //   DD file-2 //   EXEC program-2 //   DD file-1 //   DD file-2 //   EXEC program-3 //   DD file-1 //   DD file-2 ...

Q. Well, I got what EXEC Statement does? Could you show me how to code it in a real Job? That would be like awesome!

Just like all JCL Statements, an EXEC Statement has got to begin with a name. You can assign a name of up to eight characters, with the first letter as an Alphabet. The names of steps are also important, because this is how the MVS Operating System refers to them. A job may have gazillions of steps, how do you distinguish them, tell one step apart from the other – by assigning a unique name to each step. In the above JCL, I have assigned the step-name //STEP010. A popular convention is to often use meaningful step-names, by looking at which you could easily figure out, what the step does. For example, if in a particular step you use the IBM’s ready-made program IEBGENER, to copy the contents of 1 file to another, you can give the name //COPYSTP to this step. The simplest EXEC Statement is the one that has a name and uses either a PGM= or PROC=. PROC= is used to execute Catalogued Procedures. If you don’t code a PGM= or a PROC=, by default it assumes that you are trying to run a Catalogued Procedure.

Q. What happens when you code an EXEC PGM=?

The PGM= parameter is used to run a Program. This is the Binary Machine Language Program or Load Module. You can run IBM supplied free Programs such as IEBGENER, SORT, IEFBR14, IEBPTPCH, IEBCOPY and more. Apart from these ready-made programs that IBM supplies, you can also run your very own programs which you have written. Every program or Load Module that you run, is stored as a member of Partitioned Dataset(PDS) or Folder(Library). A Partitioned Dataset(PDS) that houses Load Modules is called Load Library. Code an EXEC PGM= Statement in JCL, and the MVS Operating System tries to find, where the program/Load Module to be run is stored. The question is, how does the Mainframe Computer know the location of the program to be run? In other words, how does the Mainframe know in which library your program is kept? Well, when you are executing a ready-made programs supplied by IBM like IEBGENER or SORT(like on Windows, you run Notepad and Paint), you don’t have to tell the Mainframe Computer where these programs are housed. If you don’t tell anything, the Mainframe computer looks up the default Load library(PDS) or folder. The default Load Library on Mainframes is SYS1.LINKLIB.   Your project or your installation may define additional such libraries to the MVS Operating System. The default libraries like the one above apply to these ready-made pre-written COBOL programs like IEBGENER or SORT. But what about the COBOL programs that you have custom-written? How does the Mainframe computer know, in which Load Library to look for them?  Well, the first thing that you do, is to create your very own Load Library – a place where the Load Modules of all COBOL programs you write would go. Like, I have created one for my Loads – AGY0157.DEMO.LOADLIB. Once, you've put your Load Module into your Load Library, you must tell the Mainframe computer, about your personal Load Library. You can specify your own Personal Load Libraries in the //JOBLIB or //STEPLIB file while writing a job. I've shown this below. I want to run my own custom COBOL Program(Load) PROGRAM1, the Load is housed in my Personal Load Library AGY0157.DEMO.LOADLIB.

Q. How do you code TIME Parameter on the EXEC Statement?

When you code a TIME on an EXEC Statement, you are specifying an upper bound, an upper limit on the amount of CPU time a program gets. For example, if you specify TIME=6 seconds, you are telling Mainframe Computer, the maximum time for which this program is allowed to run on the CPU is 6 seconds. Thus, TIME Parameter allows you to specify the maximum CPU Time, for which a Program can run. Remember, that on a real Mainframe, 6 seconds a lot of time pal! A Mainframe can process a huge volume of data in 6 CPU Seconds. But then, you might wonder, what good is it to set an upper time limit? Imagine, that you have written a program that contains a serious fault. Sometimes, the program runs into an endless loop. This is where TIME parameter helps you big-time. If the program goes into a bad loop, and exceeds its maximum time-limit, it is automatically terminated. The TIME Parameter has this syntax – TIME=(min,sec). Check it out below, the way I’ve done for my step.   What happens, when a program exceeds its maximum allotted CPU time limit? The Step leaves behind a System Complete Code 322, commonly known as S322. S322 code implies that the step failed, because it exceeded the upper CPU time limit.

Q. How do you code REGION Parameter on the EXEC Statement?

When you code a REGION Parameter on the EXEC Statement, you are specifying an upper limit on the amount of Memory Space, that the program can use. Take a look at the following example : K stands for Kilobytes. In the above job, I have set an upper limit of 2048 Kilobytes of memory, for my step to run. On the same lines, M stands for Megabytes.   If you don’t code a REGION Parameter, mostly your project or installation will have defined a default value like 1024K. If you code REGION on the JOB Statement and on EXECs, the JOB limit overrides any REGIONs which are larger. In the earlier days, it was common to code a REGION parameter to avoid Programs from hogging over excess Memory Space. Coding REGION parameter had relevance only before 1973, when Virtual Storage had not been introduced. If a program exceeds the upper boundary of the memory, set by you, it leaves behind a System Completion code 804 or 80A.

Basics of JCL Simplified

Q. What is a Job?

PROC(Procedure) 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.

Technorati

jbsx6mkhpi

What is Mainframe Computer?

Q. What is a Mainframe Computer?

A Mainframe-Computer is a big computer. IBM builds Mainframe Computers. Today, a Mainframe refers to IBM's zSeries computers. Big companies; Banks, Insurance Companies, Travel and Retail Sector, Telecom Companies employ Mainframes for processing their Business-Data. Today, thousands of people around the globe book flights, do Electronic Money Transfers, swipe their credit-cards for purchases. These transactions are processed on-the-fly in a snap by a Mainframe Computer.

Q. Why do big companies rely on Mainframes? Aren't Mainframes dead yet?

Today, all businesses trust Mainframe Computers to process their critical Business-Data. What distinguishes a Mainframe from other line-of-computers, its close cousins such as Micro and Mini-Computers? Available : Mainframe-Computers are always available, they are up and running all the time. They just don't fail. You'll be surprised to know, once a Mainframe Computer is started and powered on(IPL'ed), they can run for 5 to 10 years, at a stretch without failing. In other words, Mainframe Computers have very good up-times. The Mean Time Between Failures(MTBF) ranges from several months to even years. Reliable : IBM boasts that you can bet all your money on A Mainframe, when it comes to Reliability. Very often, you must have seen the horrific Blue-Screen of Death(BSOD) on Desktop Computers, and they crash! A Mainframe Computer reliably processes huge volumes of Business-Data, without crashing. Serviceable : Faults can be detected early on a Mainframe Computer. When some components fail, some of IBM's systems can automatically call the IBM Service center. Repairs can be done without disrupting the day-to-day operations. The RAS(Reliability-Accessibility-Serviceability) features of a Mainframe Computer give it an edge over many other computing systems.

Q. So, Mainframe Computers are good at everything?

Well, not quite. As the saying goes, "You can’t teach an old dog, new tricks". Mainframes are not good at number-crunching. Mainframes don't do scientific calculations. A Mainframe is not a Super-computer. You wouldn’t use a Mainframe Computer to calculate the value of Pi, up to 1000-decimal Places. Mainframe-Computers are not meant for speed. They aren’t fast, rather they can process humungous data reliably. You can't play Counter-Strike or Half-Life on a Mainframe. Mainframe Computers aren’t as User-Friendly as the Household–PC running Windows. You don’t have a rosy-rosy Desktop or a Mouse to point your cursor and click at. Instead, there’s a Keyboard and Dumb-Terminal(Monitor) at your disposal, or a PC running software that pretends like a dumb-terminal. In common parlance, people call these dumb-terminals as green-screens, because back then they had green characters on a black-background.

Q. How do you connect to a Mainframe Computer?

Mainframe Servers are generally housed at a big Data-Center. People around the world connect to the Mainframe-Computer, remotely over a Network, from their work-place or home, using the Keyboard and the Dumb-Terminal. Gee, you don’t have to sit physically near a Mainframe Box to do your work. This is how the Mainframe Screen looks like, when you first connect to it -

Q. What's the OS on a Mainframe Computer?

IBM zSeries Computers run the zO/S. Although, the official product-name is now zO/S, the former name MVS is still quoted on numerous occasions. MVS is said to be the OS, that makes the world move.

Q. How did MVS OS Evolve?

In April 1964, IBM announced OS/360, to support the newer architecture S/360 Line of machines. IBM actually released three different control-programs PCP(Primary Control Program), MFT(Multi-programming with a fixed number of tasks) and MVT(Multi-Programming with Variable Tasks). PCP could run just one task at a time, in 32 KB of memory. That’s right Kilo-Bytes, not Mega-bytes! With Multi-programming, the control could be assigned to another task, while first task was waiting for I/O. In 1972, IBM announced the System/370 Architecture which had Virtual Storage. IBM released OS/VS1 and OS/VS2, but these supported a single virtual storage address space. On the MVS(Multiple Virtual Storages), each program was assigned a different range of virtual address space. When MVS was developed, some Virtual Storage was still shared between different applications. The 16 MB of Virtual Address space supported by MVS was no longer enough. In 1979, IBM announced MVS/370 which supported cross-memory. It means Data and Control-Blocks could be moved to-and-fro between Private virtual address space and shared address space. This was called Virtual Storage Constraint Relief(VSCR). In 1981, IBM announced System 370/XA - Extended Architecture.

Q. What is a Batch Job?

If you are a college student, you would have probably written a computer application in C, and executed it on your desktop PC. You run the program interactively, you type in some input data, wait for the response(output), and then you type some more input, and this cycle continues. Such programs or systems are called as Online Systems or Transaction Processing Systems. This is because, such systems are always on, they give you immediate response, and you do things interactively. Running a program in Batch Mode, is opposite to running it interactively. In Batch Mode, you tell the Mainframe System - what input data to use, what program needs to be run(which set of instructions to perform on the data), where to store the output, right at the beginning, at the outset. This is called a JOB. This is typical of batch processing. Preparing credit-card statements or generating the payroll of a company, taking a backup of all records are typically JOBS which are run in batch mode. They involve a huge volume of data – so it’s going to take a long while till the final output is generated. You simply submit the JOB to the Mainframe Server, and then forget about it, continue doing something else. When the JOB will have finished, the mainframe will notify you. These systems are called Batch Processing Systems. Earlier, once when a user started a Batch Job, no one else could use the computer, once it began as a Batch Job. However, modern day operating systems like MVS allow you to run other programs, and do other things while a Batch Job runs.

Q. Look, on Windows PC, you interact with the computer using the Windows GUI – the Desktop Icons, the Menus, Buttons etc. How do you interact with an MVS Mainframe System?

MVS offers several ways to interact with it. The 3 main ways of interacting with MVS are TSO, ISPF and CICS. TSO stands for Time Sharing Option. TSO is the part of MVS that lets you use the MVS System interactively. Just as from the DOS-Prompt, you type in commands to create a directory, remove a directory, create a new file in editor, type in data, copy files, rename files delete files, the same way, one can type commands on the TSO. When IBM first introduced TSO in 1969, interactive computing was a hot new feature, which required a large portion of the memory. This is where the O comes from : O meaning option, TSO was optional : when all jobs were run as batch jobs. Since, it allows multiple users to share time on the system concurrently, it is Time Sharing. You said, All JOBs are run as Batch JOBs. Then, what about TSO? Well, under the hood, each TSO user session is run as a Batch Job. It can specify the procedure to be executed or the command when the user LOGON occurs. It also specifies the Terminal Monitoring Program to monitor TSO User Session. It specifies the data-sets to be allocated, when the user logs on. When you write a Batch Job means, you write its JCL(What Input Data Set, What Output DataSet, Which Program to run). Who writes the JCL for TSO? The System Programmer guys who maintain TSO.

Q. What is ISPF?

ISPF stands Interactive System Productivity Facility. ISPF is more popular than TSO, because its an easier way to get things done in MVS without knowing most of the TSO Commands. Rather than typing out commands, you go through a series of menu – just like the Nokia Mobile Handset, to do tasks, like creating a new file, deleting a file, editing a file, renaming, copying, writing and submitting JOBs.