What? Who? Why? How?

26th July 2008.
Saturday.
WTF.
Friday evening I decided to complete my presentation on saturday and on saturday evening I am writing my blog.
Well, I have to give the presentation on JCL(JOB CONTROL LANGUAGE)....thats where the title comes from:
1) What the f***!
2)Who made JCL?
3)Why he/they made JCL?
4)How could he do such a blunder?

Today, saturday morning I got up early bought myself some biscuts and a copy of Times Of India and went to company(for a record I reached company earlier than I do on working days). I began googling JCL and got some pages to read and then something happened(well nothing happened as such....just my mind arrogantly took over my thoughts and threw jcl in a dustbin) and now having played some computer games, i am writing this blog. WTF. Am I a idiot on loose, sitting in my office with a couple of guys listening to music and doing their work.

I thougt this blog is going to of no purpose so i may add something that might bore you more.....some jcl stuff....infact i am not going to give you jcl dose....I will give you JES dose.....that will be better for guys and gals reading this blog.

The below mentioned docs are not original. They are taken from the IBM site(the link of which I will give you at the end of presentation):

What is batch processing?
Jobs that can run without end user interaction, or can be scheduled to run as resources permit, are called batch jobs. Batch processing is for those frequently used programs that can be executed with minimal human interaction.
A program that reads a large file and generates a report, for example, is considered to be a batch job.
The term batch job originated in the days when punched cards contained the directions for a computer to follow when running one or more programs. Multiple card decks representing multiple jobs would often be stacked on top of one another in the hopper of a card reader, and be run in batches.
As a historical note, Herman Hollerith (1860-1929) created the punched card in 1890 while he worked as a statistician for the United States Census Bureau. To help tabulate results for the 1890 U.S. census, Hollerith designed a paper card with 80 columns and 12 rows; he made it equal to the size of a U.S. dollar bill of that time. To represent a series of data values, he punched holes into the card at the appropriate row/column intersections. Hollerith also designed an electromechanical device to "read" the holes in the card, and the resulting electrical signal was sorted and tabulated by a computing device. (Mr. Hollerith later founded the Computing Tabulating Recording Company, which eventually became IBM®.)
There is no direct counterpart to z/OS® batch processing in PC or UNIX® systems. Batch jobs are typically executed at a scheduled time or on an as-needed basis. Perhaps the closest comparison is with processes run by an AT or CRON command in UNIX, although the differences are significant. You might also consider batch processing as being somewhat analogous to the printer queue as it is typically managed on an Intel-based operating system. Users submit jobs to be printed, and the print jobs wait to be processed until each is selected by priority from a queue of work called a print spool.
To enable the processing of a batch job, z/OS professionals use job control language (JCL) to tell z/OS which programs are to be executed and which files will be needed by the executing programs. JCL allows the user to describe certain attributes of a batch job to z/OS, such as:
Who you are (the submitter of the batch job)
What program to run
Where input and output are located
When a job is to run
After the user submits the job to the system, there is normally no further human interaction with the job until it is completed.

What does an initiator do?
An initiator performs several functions to ensure that multiple jobs run at the same time, without conflicts.
To run multiple jobs asynchronously, the system must perform a number of functions:
Select jobs from the input queues (JES does this).
Ensure that multiple jobs (including TSO users and other interactive applications) do not conflict in data set usage.
Ensure that single-user devices, such as tape drives, are allocated correctly.
Find the executable programs requested for the job.
Clean up after the job ends and then request the next job.
Most of this work is done by the initiator, based on JCL information for each job. The most complex function is to ensure there are no conflicts due to data set utilization. For example, if two jobs try to write in the same data set at the same time (or one reads while the other writes), there is a conflict. This event would normally result in corrupted data. The primary purpose of JCL is to tell an initiator what is needed for the job.
The prevention of conflicting data set usage is critical to z/OS® and is one of the defining characteristics of the operating system. When the JCL is properly constructed, the prevention of conflicts is automatic. For example, if job A and job B must both write to a particular data set, the system (through the initiator) does not permit both jobs to run at the same time. Instead, whichever job starts first causes an initiator attempting to run the other job to wait until the first job completes.

What is JES?
z/OS® uses a job entry subsystem or JES to receive jobs into the operating system, to schedule them for processing by z/OS, and to control their output processing.
JES is the component of the operating system that provides supplementary job management, data management, and task management functions such as scheduling, control of job flow, and the reading and writing of input and output streams on auxiliary storage devices, concurrently with job execution.
z/OS manages work as tasks and subtasks. Both transactions and batch jobs are associated with an internal task queue that is managed on a priority basis. JES is a component of z/OS that works on the front end of program execution to prepare work to be executed. JES is also active on the back end of program execution to help clean up after work is performed. This activity includes managing the printing of output generated by active programs.
More specifically, JES manages the input and output job queues and data.
For example, JES handles the following aspects of batch processing for z/OS:
Receiving jobs into the operating system
Scheduling them for processing by z/OS
Controlling their output processing
z/OS has two versions of job entry systems: JES2 and JES3. Of these, JES2 is the most common by far. JES2 and JES3 have many functions and features, but their most basic functions are as follows:
Accept jobs submitted in various ways:
From ISPF through the SUBMIT command
Over a network
From a running program, which can submit other jobs through the JES internal reader
From a card reader (very rare!)
Queue jobs waiting to be executed. Multiple queues can be defined for various purposes.
Queue jobs for an initiator, which is a system program that requests the next job in the appropriate queue.
Accept printed output from a job while it is running and queue the output.
Optionally, send output to a printer, or save it on spool for PSF, InfoPrint, or another output manager to retrieve.
JES uses one or more disk data sets for spooling, which is the process of reading and writing input and output streams on auxiliary storage devices, concurrently with job execution, in a format convenient for later processing or output operations. Spool is an acronym that stands for simultaneous peripheral operations online.
JES combines multiple spool data sets (if present) into a single conceptual data set. The internal format is not in a standard access-method format and is not written or read directly by applications. Input jobs and printed output from many jobs are stored in the single (conceptual) spool data set. In a small z/OS system, the spool data sets might be a few hundred cylinders of disk space; in a large installation, they might be many complete volumes of disk space.
The basic elements of batch processing are shown in
Figure 1. Basic batch flow
The initiator is an integral part of z/OS that reads, interprets, and executes the JCL. It is normally running in several address spaces (as multiple initiators). An initiator manages the running of batch jobs, one at a time, in the same address space. If ten initiators are active (in ten address spaces), then ten batch jobs can run at the same time. JES does some JCL processing, but the initiator does the key JCL work
The jobs in Basic batch flow represent JCL and perhaps data intermixed with the JCL. Source code input for a compiler is an example of data (the source statements) that might be intermixed with JCL. Another example is an accounting job that prepares the weekly payroll for different divisions of a firm (presumably, the payroll application program is the same for all divisions, but the input and master summary files may differ).
The diagram represents the jobs as punched cards (using the conventional symbol for punched cards) although real punched card input is very rare now. Typically, a job consists of card images (80-byte fixed-length records) in a member of a partitioned data set.

Job flow through the system
During the life of a job, JES2 and the base control program of z/OS® control different phases of the overall processing.
The job queues contain jobs that are waiting to run, currently running, waiting for their output to be produced, having their output produced, and waiting to be purged from the system.
Generally speaking, a job goes through the following phases:
Input
Conversion
Processing
Output
Print/punch (hard copy)
Purge
During batch job processing, numerous checkpoints occur. A checkpoint is a point in processing at which information about the status of a job and the system can be recorded (in a file called a checkpoint data set). Checkpoints allow the job step to be restarted later if it ends abnormally due to an error.
Figure 1 shows the different phases of a job during batch processing.
Figure 1. Job flow through the system
Input phase
JES2 accepts jobs, in the form of an input stream, from input devices, from other programs through internal readers, and from other nodes in a job entry network.
The internal reader is a program that other programs can use to submit jobs, control statements, and commands to JES2. Any job running in z/OS can use an internal reader to pass an input stream to JES2. JES2 can receive multiple jobs simultaneously through multiple internal readers. The system programmer defines internal readers to be used to process all batch jobs other than started tasks (STCs) and TSO requests.
JES2 reads the input stream and assigns a job identifier to each JOB JCL statement. JES2 places the job's JCL, optional JES2 control statements, and SYSIN data onto DASD data sets called spool data sets. JES2 then selects jobs from the spool data sets for processing and subsequent running.
Conversion phase
JES2 uses a converter program to analyze a job's JCL statements. The converter takes the job's JCL and merges it with JCL from a procedure library. The procedure library can be defined in the JCLLIB JCL statement, or system/user procedure libraries can be defined in the PROCxx DD statement of the JES2 startup procedure.
Then, JES2 converts the composite JCL into converter/interpreter text that both JES2 and the initiator can recognize.
Next, JES2 stores the converter/interpreter text on the spool data set. If JES2 detects any JCL errors, it issues messages, and the job is queued for output processing rather than execution. If there are no errors, JES2 queues the job for execution.
Processing phase
In the processing phase, JES2 responds to requests for jobs from the initiators. JES2 selects jobs that are waiting to run from a job queue and sends them to initiators.
An initiator is a system program belonging to z/OS, but controlled by JES or by the workload management (WLM) component of z/OS, which starts a job allocating the required resources to allow it to compete with other jobs that are already running.
JES2 initiators are initiators that are started by the operator or by JES2 automatically when the system initializes. They are defined to JES2 through JES2 initialization statements. To obtain an efficient use of available system resources, the installation associates each initiator with one or more job classes. Initiators select jobs whose classes match the initiator-assigned class, obeying the priority of the queued jobs.
WLM initiators are started by the system automatically based on performance goals, relative importance of the batch workload, and the capacity of the system to do more work. The initiators select jobs based on their service class and the order in which they were made available for execution. Jobs are routed to WLM initiators through a JOBCLASS JES2 initialization statement.
Output phase
JES2 controls all SYSOUT processing. SYSOUT is system-produced output; that is, all output produced by, or for, a job. This output includes system messages that must be printed, as well as data sets requested by the user that must be printed or punched. After a job finishes, JES2 analyzes the characteristics of the job's output in terms of its output class and device setup requirements; then JES2 groups data sets with similar characteristics. JES2 queues the output for print or punch processing.
Print/punch (hard copy) phase
JES2 selects output for processing from the output queues by output class, route code, priority, and other criteria. The output queue can have output that is to be processed locally or at a remote location. After processing all the output for a particular job, JES2 puts the job on the purge queue.
Purge phase
When all processing for a job completes, JES2 releases the spool space assigned to the job, making the space available for allocation to subsequent jobs. JES2 then issues a message to the operator indicating that the job has been purged from the system.