BM® provides two kinds of job entry subsystems: JES2 and JES3. In many cases, JES2 and JES3 perform similar functions, but most installations use JES2.
Both JES2 and JES3 read jobs into the system, convert them to internal machine-readable form, select them for processing, process their output, and purge them from the system.
Some principle differences between the two JES systems include:
* In a mainframe installation that has only one processor, JES3 provides tape setup, dependent job control, and deadline scheduling for users of the system, while JES2 in the same system would require its users to manage these activities through other means. In an installation with a multiprocessor configuration, there are noticeable differences between the two, mainly in how JES2 exercises independent control over its job processing functions. That is, within the configuration, each JES2 processor controls its own job input, job scheduling, and job output processing.
* In cases where multiple z/OS® systems are clustered (a sysplex), it is possible to configure JES2 to share spool and checkpoint data sets with other JES2 systems in the same sysplex. This configuration is called Multi-Access Spool (MAS). In contrast, JES3 exercises centralized control over its processing functions through a single global JES3 processor. This global processor provides all job selection, scheduling, and device allocation functions for all of the other JES3 systems.
* With JES3, installations may decide whether the global JES3 or z/OS base control program will handle device allocation. With JES2, only the z/OS base control program handles device allocation.
Short for Hardware Management Console, HMC is an acronym frequently used to describe the IBM technology for managing and monitoring IBM mainframe (System z) or IBM UNIX (system p) servers. The HMC uses its network connections to one or more servers or frames to perform various management functions. As defined by IBM, Hardware Management Console technology provides a standard user interface for configuring and operating partitioned and SMP systems. The HMC enables a system administrator to manage configuration and operation of partitions in a system, as well as to monitor the system for hardware problems.
For every job that you submit, you need to tell z/OS® where to find the appropriate input, how to process that input, and what to do with the resulting output. You use job control language (JCL) to convey this information to z/OS through a set of statements known as job control statements.
While application programmers need some knowledge of JCL, the production control analyst must be highly proficient with JCL, to create, monitor, correct and rerun the company's daily batch workload.
The set of job control statements is quite large, which allows 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. Once you become familiar with the characteristics of the jobs you typically run, you may find that you need to know the details of only some of the control statements.
The following JCL example represents a job that performs the same functions as the TSO commands outlined in Figure 3.
//MYJOB JOB 1
//MYSORT EXEC PGM=SORT
//SORTIN DD DISP=SHR,DSN=ZPROF.AREA.CODES
//SORTOUT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD *
SORT FIELDS=(1,3,CH,A)
/*
Each JCL DD statement is equivalent to the TSO ALLOCATE command. Both are used to associate a z/OS data set with a ddname, which is recognized by the program as an input or output. The difference in method of execution is that TSO executes the sort in the foreground while JCL is used to execute the sort in the background.
When submitted for execution:
MYJOB
Is a jobname the system associates with this workload.
MYSORT
Is the stepname, which instructs the system to execute the SORT program.
SORTIN
On the DD statement, SORTIN is the ddname. The SORTIN ddname is coded in the SORT program as a program input. The data set name (DSN) on this DD statement is ZPROF.AREA.CODES. The data set can be shared (DISP=SHR) with other system processes. The data content of ZPROF.AREA.CODES is SORT program input.
SORTOUT
This ddname is the SORT program output.
SYSOUT
SYSOUT=* specifies to send system output messages to the Job Entry Subsystem (JES) print output area. It is possible to send the output to a data set.
SYSIN
DD * is another input statement. It specifies that what follows is data or control statements. In this case, it is the sort instruction telling the SORT program which fields of the SORTIN data records are to be sorted.
"The Big Three" JCL statements: JOB, EXEC, and DD
All jobs require the three main types of JCL statements: JOB, EXEC, and DD. A job defines a specific workload for z/OS to process. A job is a separately executable unit of work defined by a user, and run by a computer. This representation of a unit of work consists of one program or a set of programs, files, and control statements.
Some z/OS users use the older term JCL card instead of JCL statement, because JCL used to be submitted to the system in the form of punched cards. Now JCL resides in storage (data sets) rather than on punched cards.
Because JCL was originally designed for punched cards, the details of coding JCL statements can be complicated. However, the general concepts are quite simple, and most jobs can be run using a very small subset of these control statements.
JCL has three basic statements:
JOB
Labels the unit of work that you want the system to perform, by providing a name (jobname). The JOB statement can optionally include accounting information and parameters that apply to the entire job.
A job stream, or input stream, consists of one or more jobs that are submitted to the system in a sequence. You can submit jobs to z/OS through either TSO or ISPF.
EXEC
Provides the name of an application program or JCL procedure (sometimes called a "proc") that the system is to run (or execute). A single job may contain multiple EXEC statements. Each EXEC statement within the same job is a job step.
DD
Identifies input and output to the program or procedure on the EXEC statement. Each DD (data definition) statement links a data set or other I/O device or function to a name (ddname) coded in the program. DD statements are associated with a particular job step.
Two special DD statements, JOBLIB DD and STEPLIB DD, identify the location of the program or procedure on the EXEC statement. z/OS automatically searches standard system libraries, so you need to code these special DD statements in your JCL only when your program or procedure resides in a private library.
JCL (job control language) is a language for describing jobs (units of work) to the MVS, OS/390, and VSE operating systems, which run on IBM's S/390 large server (mainframe) computers. These operating systems allocate their time and space resources among the total number of jobs that have been started in the computer. Jobs in turn break down into job steps. All the statements required to run a particular program constitute a job step. Jobs are background (sometimes called batch) units of work that run without requiring user interaction (for example, print jobs). In addition, the operating system manages interactive (foreground) user requests that initiate units of work. In general, foreground work is given priority over background work.
One IBM manual compares a set of JCL statements to a menu order in a restaurant. The whole order is comparable to the job. Back in the kitchen, the chefs divide the order up and work on individual dishes (job steps). As the job steps complete, the meal is served (but it has to be served in the order prescribed just as some job steps depend on other job steps being performed first).
JCL statements mainly specify the input data sets (files) that must be accessed, the output data set to be created or updated, what resources must be allocated for the job, and the programs that are to run, using these input and output data sets. A set of JCL statements for a job is itself stored as a data set and can be started interactively. MVS and OS/390 provide an interactive menu-like interface, ISPF, for initiating and managing jobs.
In MVS and OS/390, the part of the operating system that handles JCL is called the Job Entry Subsystem (JES). There are two versions, JES2 and a later version with additional capabilities, JES3.
ADYSETxx Parameters that control dump analysis and elimination (DAE) processing.
ALLOCxx Parameters that control installation defaults for allocation values.
APPCPMxx Parameters that define or modify the APPC/MVS configuration.
ASCHPMxx Parameters that define scheduling information for the ASCH transaction scheduler.
BLSCECT Parameters that control dump formatting performed by IPCS, and by the system (through the ABEND and SNAP macros).
BLSCUSER Parameters that specify IPCS customization.
BPXPRMxx Parameters that control the OS/390 UNIX System Services environment and the hierarchical
file system (HFS). The system uses these values when initializing the OS/390 UNIX System
Services kernel.
CLOCKxx Parameters that control operator prompting to set the TOD clock, specifying the difference
between the local time and GMT, and ETR usage.
CNGRPxx Parameters that define console groups as candidates for switch selection if a console fails.
CNLcccxx Defines how translated messages are to be displayed at your installation.
COFDLFxx Allows a program to store DLF objects that can be shared by many jobs in virtual storage
managed by Hiperbatch.
COFVLFxx Allows an authorized program to store named objects in virtual storage managed by VLF.
COMMNDxx Commands to be issued by the control program immediately after initialization. JES
commands may not be included.
CONFIGxx Allows the installation to define a standard configuration that is compared with the current
configuration and to reconfigure processors, storage, and channel paths.
CONSOLxx Parameters to define an installations console configuration, initialization values for
communications tasks, the default routing codes for all WTO/WTOR messages that have none
assigned, and the characteristics of the hardcopy message set. CONSOLxx also contains
parameters that define the hardcopy medium and designate the alternate console group for
hardcopy recovery
COUPLExx Describes the systems complex (sysplex) environment for the system.
CSVLLAxx Allows an installation to list the entry point name or LNKLST libraries that can be refreshed
by the MODIFY LLA, UPDATE=xxcommand.
CSVRTLxx Defines the run-time library services (RTLS) configuration. CSVRTLxx can be used to specify
names of libraries to be managed, as well as storage limits for caching modules from the
libraries.
CTncccxx Specifies component trace options.
DEVSUPxx Allows an installation to specify whether data will be stored in a compacted format on a 3480
or 3490 tape subsystem with the Improved Data Recording Capability feature
DIAGxx . Contains diagnostic commands that control the common storage tracking and
GETMAIN/FREEMAIN/STORAGE (GFS) trace functions
EXITxx Allows an installation to specify installation exits for allocation decisions.
EXSPATxx Allows an installation to specify actions taken to recover from excessive spin conditions
without operator involvement.
GRSCNFxx Configuration parameters for systems that are to share resources in a global resource
serialization complex.
GRSRNLxx Resource name lists (RNLs) that the system uses when a global resource serialization
complex is active
GTFPARM Parameters to control GTF.
IEAABD00 Default parameters for an ABEND dump when a SYSABEND DD statement has been specified.
IEAAPFxx Names of authorized program libraries.
IEAAPPxx Names of authorized installation-written I/O appendage routines.
IEACMD00 IBM-supplied commands that are processed during system initialization.
IEADMCxx Parameters for DUMP command.
IEADMP00 Default parameters for an ABEND dump when SYSUDUMP DD statement has been specified.
IEADMR00 Default parameters for an ABEND dump when SYSMDUMP DD statement has been specified.
IEAFIXxx Names of modules to be fixed in central storage for the duration of the IPL.
IEAICSxx Parameters of an installation control specification that associate units of work (transactions)
with performance groups. Performance groups are used by the system resources manager to
control and report on transactions.
IEAIPSxx Parameters of an installation performance specification that control the Workload Manager of
the System Resources Manager.
IEALPAxx Names of reenterable modules that are to be loaded as a temporary extension to the PLPA.
IEAOPTxx Parameters that control resource and workload management algorithms in the System
Resources Manager.
IEAPAKxx “Pack List” names of groups of modules in the LPALST concatenation that the system will
load between page boundaries to minimize page faults.
IEASLPxx Contains valid SLIP commands.
IEASVCxx Allows the installation to define its own SVCs in the SVC table.
IEASYMxx Specifies, for one or more systems in a multisystem environment, the static system symbols
and suffixes of IEASYSxx members that the system is to use. One or more IEASYMxx
members are selected using the IEASYM parameter in the LOADxx parmlib member.
IEASYSxx System parameters that are valid responses to the SPECIFY SYSTEM PARAMETERS
message. Multiple system parameter lists are valid. The list is chosen by the operator SYSP
parameter or through the SYSPARM statement of the LOADxx parmlib member.
IECIOSxx Parameters that control missing interrupt handler (MIH) intervals and update hot I/O
detection table (HIDT) values.
IEFSSNxx Parameters that identify what subsystems are to be initialized.
IFAPRDxx Parameters that define a product enablement policy.
IGDDFPKG One or more statements that specify which DFSMS/MVS functional components and
separately orderable features are licensed for use on a particular MVS system or across a
sysplex.
IGDSMSxx Initialize the Storage Management Subsystem (SMS) and specify the names of the active
control data set (ACDS) and the communications data set (COMMDS).
IKJPRMxx TIOC parameters that control TSO/TCAM time sharing buffers.
IKJTSOxx For TSO/E, specifies authorized commands and authorized programs, programs that are
authorized when called through the TSO service facility, commands that may not be issued in
the background, and defaults for SEND and LISTBC processing.
IPCSPRxx Parameters that are used during an IPCS session.
IVTPRM00 Sets Communications Storage Manager (CSM) parameters.
LNKLSTxx List of data sets to be concatenated to form the LNKLST concatenation. You can also use
PROGxx to define the concatenation.
LOADxx Specifies data sets MVS uses to configure your system.
LPALSTxx List of data sets to be concatenated to SYS1.LPALIB from which the system builds the
pageable LPA (PLPA).
MMSLSTxx Specifies information that the MVS message service (MMS) uses to control the languages
that are available in your installation.
MPFLSTxx Parameters that the message processing facility uses to control message processing and display.
MSTJCLxx Contains the master scheduler job control language (JCL) that controls system initialization
and processing.
NUCLSTxx Specifies members of SYS1.NUCLEUS to be included in, or excluded from, the nucleus region
at IPL-time.
PFKTABxx Parameters contain the definitions for program function key tables (PFK tables).
PROGxx Contains statements that define the format and contents of the APF-authorized program
library list, control the use of installation exits and exit routines, define the LNKLST
concatenation, and specify alternate data sets for SYS1.LINKLIB, SYS1.MIGLIB, and
SYS1.CSSLIB to appear at the beginning of the LNKLST concatenation and SYS1.LPALIB to
appear at the beginning of the LPALST concatenation.
SCHEDxx Provides centralized control over the size of the master trace table, the completion codes to
be eligible for automatic restart, and programs to be included in the PPT.
SMFPRMxx Parameters that define SMF options.
TSOKEYxx VTIOC parameters that are used by TSO/VTAM time sharing.
VATLSTxx Volume attribute list that defines the mount and use attributes of direct access volumes.
XCFPOLxx Specifies the actions that a system in a sysplex on PR/SM is to take when another system in
the sysplex becomes inactive.
Notes:
1. These parameters can be listed at IPL: APF, DUMP, FIX, ICS, MLPA, SYSP, and OPT.
2. The only mandatory parameter is PAGE. Other parameters have coded defaults.
3. Performance-oriented parameters in IEASYSxx: APG, CMD, FIX, IPS, MLPA, OPT, REAL, RSU,
WTOBFRS, WTORPLY.
4. System symbols in COMMNDxx and MSTJCLxx are processed differently than system symbols in
other parmlib members. See the descriptions of COMMNDxx and MSTJCLxx in this book for
details.
A mainframe (also known as "big iron") is a high-performance computer used for large-scale computing purposes that require greater availability and security than a smaller-scale machine can offer. Historically, mainframes have been associated with centralized rather than distributed computing, although that distinction is blurring as smaller computers become more powerful and mainframes become more multi-purpose. Today, IBM emphasizes that their mainframes can be used to serve distributed users and smaller servers in a computing network.
The mainframe is sometimes referred to as a "dinosaur" not only because of its size but because of reports, going back many years, that it's becoming extinct. In 1991 Stewart Alsop, the editor of InfoWorld, predicted that the last mainframe would be retired by 1996. However, in February 2008 IBM released a new mainframe, the z10. Steve Lohr wrote about the mainframe as "the classic survivor technology" in The New York Times ("Why old technologies are still kicking"):
I.B.M. overhauled the insides of the mainframe, using low-cost microprocessors as the computing engine. The company invested and updated the mainframe software, so that banks, corporations and government agencies could still rely on the mainframe as the rock-solid reliable and secure computer for vital transactions and data, while allowing it to take on new chores like running Web-based programs.
The original mainframes were housed in room-sized metal frames, which is probably where the name derives from. In the past, a typical mainframe might have occupied 2,000 - 10,000 square feet. Newer mainframes are about the same size as a large refrigerator.
World premiere at Geneva Motor Show from 5 to 15 March 2009 GUMPERT Sportwagenmanufaktur GmbH will be presenting an even faster apollo speed. (Altenburg)
GUMPERT Sportwagenmanufaktur GmbH will be presenting the apollo speed at the 79th Geneva Motor Show. The racer made in Germany has earned his name, and rightly so. For any speed limit is pointless! Whereas optimum performance for racetracks, lateral acceleration and grip in all situations are the focus of apollo, apollo sport and apollo race, the apollo speed is aimed at an exclusive high speed clientele. Its domain is the mastery of highest speeds. Thanks to polished aerodynamics the drive side values of the speed are far above those of the competition.
Form follows Function
The appearance of apollo speed is now even more classy and aggressive. His striking two tone paint emphasises the racers compact appearance, at 1,105mm being lower that his brothers at 1,114mm.
A good look from the front reveals the changed design around the wheel arches. A low restrict induction system rounds off the snappy appearance and provides fresh air to the engine. Further modifications have been made to the rear end of this super sports car: The redesigned tail lights concisely show where the apollo is headed to, before it vanishes from the sight of its pursuer. The two-seater also has a small adjustable spoiler to lend it the required drive side for its
intoxicating speed.
With a fully enclosed CAS underbody (carbon / aluminium sandwich) and wheel caps (fixed at the front and rotating at the back) the speed takes Formula 1 to the road and is just asking for a challenge to a sprint.
The powerful 8 cylinder Biturbo of apollo speed provides an optional 650 / 700 / 800 HP and a torque of
850 / 875 / 900 Nm. His performance is top class: The car can go from standing still to 100 km/h in 3.0 seconds.
A speed of 200 km/h is reached in just 8.9 seconds. His maximum speed is over 360 km/h. (Depending on equipment, country-related specifications, gear ratio and engine power) The racer impresses by its sportive, elegantly equipped interior.
It is available with either leather or Alcantara, and provides a whole panoply of details, such as air conditioning and a DVD moniceiver. The removable steering wheel makes it easy to get in. Embedded in the monocoque and held in by 4 point seat belts, the driver becomes one with the apollo. An intense bond!
Get to know the new, extroverted super sports car by GUMPERT.
We look forward to welcoming you to our press conference at our booth 2045 at 11am on 4 March 2009. GUMPERT Sportwagenmanufaktur GmbH will be showcasing its super sports cars at the Geneva Motor Show for the fourth time.