Каковы основные свойства языка управления заданиями в windows

This article is about IBM mainframe job control language. For open systems, see job control (Unix). For general term, see job control.

Job Control Language (JCL) is a name for scripting languages used on IBM mainframe operating systems to instruct the system on how to run a batch job or start a subsystem.^[1]

More specifically, the purpose of JCL is to say which programs to run, using which files or devices ^[2] for input or output, and at times to also indicate under what conditions to skip a step.

Parameters in the JCL can also provide accounting information for tracking the resources used by a job as well as which machine the job should run on.

There are two distinct IBM Job Control languages:

• one for the operating system lineage that begins with DOS/360 and whose latest member is z/VSE; and
• the other for the lineage from OS/360 to z/OS, the latter now including JES extensions, Job Entry Control Language (JECL).

They share some basic syntax rules and a few basic concepts, but are otherwise very different.^[3]

The VM operating system does not have JCL as such; the CP and CMS components each have command languages.

Terminology[edit]

Certain words or phrases used in conjunction to JCL are specific to IBM mainframe technology.

• Dataset: a «dataset» is a file; it can be temporary or permanent, and located on a disk drive, tape storage, or other device.^[4][5]
• Member: a «member» of a partitioned dataset (PDS) is an individual dataset within a PDS. A member can be accessed by specifying the name of the PDS with the member name in parentheses. For example, the system macro GETMAIN in SYS1.MACLIB can be referenced as SYS1.MACLIB(GETMAIN).^[6]
• Partitioned dataset: a «partitioned dataset» or PDS is collection of members, or archive, typically used to represent system libraries. As with most such structures, a member, once stored, cannot be updated; the member must be deleted and replaced, such as with the IEBUPDTE utility.^[6] Partitioned datasets are roughly analogous to ar-based static libraries in Unix-based systems.
• USS: Unix system services, a Unix subsystem running as part of MVS, and allowing Unix files, scripts, tasks, and programs to run on a mainframe in a UNIX environment.

Motivation[edit]

Originally, mainframe systems were oriented toward batch processing. Many batch jobs require setup, with specific requirements for main storage, and dedicated devices such as magnetic tapes, private disk volumes, and printers set up with special forms.^[7] JCL was developed as a means of ensuring that all required resources are available before a job is scheduled to run. For example, many systems, such as Linux allow identification of required datasets to be specified on the command line, and therefore subject to substitution by the shell, or generated by the program at run-time. On these systems the operating system job scheduler has little or no idea of the requirements of the job. In contrast, JCL explicitly specifies all required datasets and devices. The scheduler can pre-allocate the resources prior to releasing the job to run. This helps to avoid «deadlock», where job A holds resource R1 and requests resource R2, while concurrently running job B holds resource R2 and requests R1. In such cases the only solution is for the computer operator to terminate one of the jobs, which then needs to be restarted. With job control, if job A is scheduled to run, job B will not be started until job A completes or releases the required resources.

Features common to DOS and OS JCL[edit]

Jobs, steps and procedures[edit]

For both DOS and OS the unit of work is the job. A job consists of one or several steps, each of which is a request to run one specific program. For example, before the days of relational databases, a job to produce a printed report for management might consist of the following steps: a user-written program to select the appropriate records and copy them to a temporary file; sort the temporary file into the required order, usually using a general-purpose utility; a user-written program to present the information in a way that is easy for the end-users to read and includes other useful information such as sub-totals; and a user-written program to format selected pages of the end-user information for display on a monitor or terminal.

In both DOS and OS JCL the first «card» must be the JOB card, which:^[8]

• Identifies the job.
• Usually provides information to enable the computer services department to bill the appropriate user department.
• Defines how the job as a whole is to be run, e.g. its priority relative to other jobs in the queue.

Procedures (commonly called procs) are pre-written JCL for steps or groups of steps, inserted into a job. Both JCLs allow such procedures. Procs are used for repeating steps which are used several times in one job, or in several different jobs. They save programmer time and reduce the risk of errors. To run a procedure one simply includes in the JCL file a single «card» which copies the procedure from a specified file, and inserts it into the jobstream. Also, procs can include parameters to customize the procedure for each use.

Basic syntax[edit]

Both DOS and OS JCL have a maximum usable line length of 80 characters, because when DOS/360 and OS/360 were first used the main method of providing new input to a computer system was 80-column punched cards.^[9] It later became possible to submit jobs via disk or tape files with longer record lengths, but the operating system’s job submission components ignored everything after character 80.

Strictly speaking both operating system families use only 71 characters per line. Characters 73-80 are usually card sequence numbers which the system printed on the end-of-job report and are useful for identifying the locations of any errors reported by the operating system. Character 72 is usually left blank, but it can contain a nonblank character to indicate that the JCL statement is continued onto the next card.

All commands, parameter names and values have to be in capitals, except for USS filenames.

All lines except for in-stream input (see below) have to begin with a slash «/«, and all lines which the operating system processes have to begin with two slashes // — always starting in the first column. However, there are two exceptions: the delimiter statement and the comment statement. A delimiter statements begins with a slash and an asterisk (/*), and a comment statement in OS JCL begins with a pair of slashes and asterisk (//*) or an asterisk in DOS JCL.

Many JCL statements are too long to fit within 71 characters, but can be extended on to an indefinite number of continuation cards by:

The structure of the most common types of card is:^[10]

In-stream input[edit]

DOS and OS JCL both allow in-stream input, i.e. «cards» which are to be processed by the application program rather than the operating system. Data which is to be kept for a long time will normally be stored on disk, but before the use of interactive terminals became common the only way to create and edit such disk files was by supplying the new data on cards.

DOS and OS JCL have different ways of signaling the start of in-stream input, but both end in-stream input with /* at column 1 of the card following the last in-stream data card. This makes the operating system resume processing JCL in the card following the /* card.^[11]

• OS JCL: DD statements can be used to describe in-stream data, as well as data sets. A DD statement dealing with in-stream data has an asterisk (*) following the DD identifier, e.g. //SYSIN DD *. JCL statements can be included as part of in-stream data by using the DD DATA statements.

An operand named DLM allowed specifying a delimiter (default is «/*»). Specifying an alternate delimiter allows JCL to be read as data, for example to copy procedures to a library member or to submit a job to the internal reader.

• An example,^[12] which submits a job to the Internal Reader (INTRDR) and then deletes two files is:

//SUBM     EXEC PGM=IEBGENER
//SYSPRINT DD   SYSOUT=Z
//SYSUT2   DD   SYSOUT=(A,INTRDR)
//SYSIN    DD   DUMMY
//SYSUT1   DD   DATA,DLM=ZZ
//RUNLATR  JOB  ACCT,MANIX,CLASS=A.TYPRUN=HOLD
//* ^ a JOB to run later
//CPUHOG   EXEC PGM=PICALC1K
//OUTPUT   DD   DSN=PICALC.1000DGTS,SPACE=(TRK,1),DISP=(,KEEP)
ZZ
//* ^ as specified by DLM=ZZ
//DROPOLDR EXEC PGM=IEFBR14
//DELETE4  DD   DSN=PICALC.4DGTS,DISP=(OLD,DELETE)
//DELETE5  DD   DSN=PICALC.5DGTS,DISP=(OLD,DELETE)

1. The program called PICALC1K will await (TYPRUN=HOLD) being released manually
2. The program called IEFBR14 will run NOW and upon completion, the two existing files, PICALC.4DGTS and PICALC.5DGTS will be deleted.

• DOS JCL: Simply enter the in-stream data after the EXEC card for the program.

Complexity[edit]

Much of the complexity of OS JCL, in particular, derives from the large number of options for specifying dataset information. While files on Unix-like operating systems are abstracted into arbitrary collections of bytes, with the details handled in large part by the operating system, datasets on OS/360 and its successors expose their file types and sizes, record types and lengths, block sizes, device-specific information like magnetic tape density, and label information. Although there are system defaults for many options, there is still a lot to be specified by the programmer, through a combination of JCL and information coded in the program. The more information coded in the program, the less flexible it is, since information in the program overrides anything in the JCL; thus, most information is usually supplied through JCL.

For example, to copy a file on Unix operating system, the user would enter a command like:

cp oldFile newFile

The following example, using JCL, might be used to copy a file on OS/360:

//IS198CPY JOB (IS198T30500),'COPY JOB',CLASS=L,MSGCLASS=X
//COPY01   EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=OLDFILE,DISP=SHR
//SYSUT2   DD DSN=NEWFILE,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(40,5),RLSE),
//            DCB=(LRECL=115,BLKSIZE=1150)
//SYSIN  DD DUMMY

A second explanation for the complexity of JCL is the different expectations for running a job from those found in a PC or Unix-like environment.

• Low-end System/360 CPUs were less powerful and more expensive than the mid-1980s PCs for which MS-DOS was designed. OS/360 was intended for systems with a minimum memory size of 32 KB and DOS/360 for systems with a minimum of 16 KB. A 360/30 CPU—low-end when System/360 was announced in 1964—processed 1.8K to 34.5K instructions per second.^[13] The first IBM PC in 1981 had 16 KB or 64 KB of memory and would process about 330K instructions per second.^[14][15] As a result, JCL had to be easy for the computer to process, and ease of use by programmers was a much lower priority. In this era, programmers were much cheaper than computers.
• JCL was designed for batch processing. As such, it has to tell the operating system everything, including what to do depending on the result of a step. For example, DISP=(NEW,CATLG,DELETE) means «if the program runs successfully, create a new file and catalog it; otherwise delete the new file.» Programs run on a PC frequently depend on the user to clean up after processing problems.
• System/360 machines were designed to be shared by all the users in an organization. So the JOB card tells the operating system how to bill the user’s account (IS198T30500), what predefined amount of storage and other resources may be allocated (CLASS=L), and several other things. //SYSPRINT DD SYSOUT=* tells the computer to print the program’s report on the default printer which is loaded with ordinary paper, not on some other printer which might be loaded with blank checks. DISP=SHR tells the operating system that other programs can read OLDFILE at the same time.

Later versions of the DOS/360 and OS/360 operating systems retain most features of the original JCL—although some simplification has been made, to avoid forcing customers to rewrite all their JCL files.^{[citation needed]} Many users save as a procedure any set of JCL statements which is likely to be used more than once or twice.^[16]

The syntax of OS JCL is similar to the syntax of macros in System/360 assembly language, and would therefore have been familiar to programmers at a time when many programs were coded in assembly language.

DOS JCL[edit]

Positional parameters[edit]

//TLBL TAPEFIL,'COPYTAPE.JOB',,,,2
//ASSGN SYS005,200
//DLBL DISKFIL,'COPYTAPE.JOB',0,SD
//EXTENT SYS005,VOL01,1,0,800,1600

DOS JCL parameters are positional, which makes them harder to read and write, but easier for the system to parse.

• The programmer must remember which item goes in which position in every type of statement.
• If some optional parameters are omitted but later ones are included, the omitted parameters must be represented by commas with no spaces, as in the TLBL statement above.

DOS JCL to some extent mitigates the difficulties of positional parameters by using more statements with fewer parameters than OS JCL. In the example the ASSGN, DLBL and EXTENT statements do the same work (specifying where a new disk file should be stored) as a single DD statement in OS JCL.

Device dependence[edit]

In the original DOS/360 and in most versions of DOS/VS one had to specify the model number of the device which was to be used for each disk or tape file—even for existing files and for temporary files which would be deleted at the end of the job. This meant that, if a customer upgraded to more modern equipment, many JCL files had to be changed.

Later members of the DOS/360 family reduced the number of situations in which device model numbers were required.

Manual file allocation[edit]

DOS/360 originally required the programmer to specify the location and size of all files on DASD. The EXTENT card specifies the volume on which the extent resides, the starting absolute track, and the number of tracks. For z/VSE a file can have up to 256 extents on different volumes.

OS JCL[edit]

OS JCL consists of three basic statement types:^[17]

• JOB statement, which identifies the start of the job, and information about the whole job, such as billing, run priority, and time and space limits.
• EXEC statement, which identifies the program or procedure^[18] to be executed in this step of the job,
  and information about the step, including CONDitions for running or skipping a step.
• DD (Data Definition) statements, which identify a data file to be used in a step, and detailed info about that file. DD statements can be in any order within the step.

Right from the start, JCL for the OS family (up to and including z/OS) was more flexible and easier to use.

The following examples use the old style of syntax which was provided right from the launch of System/360 in 1964. The old syntax is still quite common in jobs that have been running for decades with only minor changes.

Rules for coding JCL statements[edit]

Each JCL statement is divided into five fields:^[19]

 Identifier-Field Name-Field Operation-Field Parameter-Field Comments-Field
                 ^          ^               ^               ^
              no space     space          space           space

Identifier-Field should be concatenated with Name-Field, i.e. there should be no spaces between them.

• Identifier-Field (//): The identifier field indicates to the system that a statement is a JCL statement rather than data. The identifier field consists of the following:
  • Columns 1 and 2 of all JCL statements, except the delimiter statement, contain //
  • Columns 1 and 2 of the delimiter statement contain /*
  • Columns 1, 2, and 3 of a JCL comment statement contain //*
• Name-Field: The name field identifies a particular statement so that other statements and the system can refer to it. For JCL statements, it should be coded as follows:
  • The name must begin in column 3.
  • The name is 1 through 8 alphanumeric or national ($, #, @) characters.
  • The first character must be an alphabetic.
  • The name must be followed by at least one blank.
• Operation-Field: The operation field specifies the type of statement, or, for the command statement, the command. Operation-Field should be coded as follows:
  • The operation field consists of the characters in the syntax box for the statement.
  • The operation follows the name field.
  • The operation must be preceded and followed by at least one blank.
  • The operation will be one of JOB, EXEC and DD.
• Parameter-Field: The parameter field, also sometimes referred to as the operand field, contains parameters separated by commas. Parameter field should be coded as follows:
  • The parameter field follows the operation field.
  • The parameter field must be preceded by at least one blank.
  • The parameter field contains parameters which are keywords that used in the statement to provide information such as the program or dataset name.
• Comments-Field: This contains comments. Comments-Field should be coded as Follows:
  • The comments field follows the parameter field.
  • The comments field must be preceded by at least one blank.

Keyword parameters[edit]

//NEWFILE DD DSN=MYFILE01,UNIT=DISK,SPACE=(TRK,80,10),
//           DCB=(LRECL=100,BLKSIZE=1000),
//           DISP=(NEW,CATLG,DELETE)

All of the major parameters of OS JCL statements are identified by keywords and can be presented in any order. A few of these contain two or more sub-parameters, such as SPACE (how much disk space to allocate to a new file) and DCB (detailed specification of a file’s layout) in the example above. Sub-parameters are sometimes positional, as in SPACE, but the most complex parameters, such as DCB, have keyword sub-parameters.

Positional parameter must precede keyword parameters. Keyword parameters always assign values to a keyword using the equals sign (=).^[20]

Data access (DD statement)[edit]

The DD statement is used to reference data. This statement links a program’s internal description of a dataset to the data on external devices: disks, tapes, cards, printers, etc. The DD may provide information such as a device type (e.g. ‘181’,’2400-5′,’TAPE’), a volume serial number for tapes or disks, and the description of the data file, called the DCB subparameter after the Data Control Block (DCB) in the program used to identify the file.

Information describing the file can come from three sources: The DD card information, the dataset label information for an existing file stored on tape or disk, and the DCB macro coded in the program. When the file is opened this data is merged, with the DD information taking precedence over the label information, and the DCB information taking precedence over both. The updated description is then written back to the dataset label. This can lead to unintended consequences if incorrect DCB information is provided.^[21]

Because of the parameters listed above and specific information for various access methods and devices the DD statement is the most complex JCL statement. In one IBM reference manual description of the DD statement occupies over 130 pages—more than twice as much as the JOB and EXEC statements combined.^[22]

The DD statement allows inline data to be injected into the job stream. This is useful for providing control information to utilities such as IDCAMS, SORT, etc. as well as providing input data to programs.

Device independence[edit]

From the very beginning, the JCL for the OS family of operating systems offered a high degree of device independence. Even for new files which were to be kept after the end of the job one could specify the device type in generic terms, e.g., UNIT=DISK, UNIT=TAPE, or UNIT=SYSSQ (tape or disk). Of course, if it mattered one could specify a model number or even a specific device address.^[23]

Procedures[edit]

Procedures permit grouping one or more «EXEC PGM=» and DD statements and then invoking them with «EXEC PROC=procname» -or- simply «EXEC procname» ^[24]

A facility called a Procedure Library allowed pre-storing procedures.

PROC & PEND[edit]

Procedures can also be included in the job stream by terminating the procedure with a // PEND statement, then invoking it by name the same was as if it were in a procedure library.

For example:

//SUMPRINT PROC 
//PRINT    EXEC PGM=IEBGENER
//SYSUT1   DD   DSN=CEO.FILES.DAYEND.RPT24A,DISP=SHR
//SYSUT2   DD   SYSOUT=A
//SYSIN    DD   DUMMY
//         PEND
// EXEC SUMPRINT

Parameterized procedures[edit]

OS JCL procedures were parameterized from the start, making them rather like macros or even simple subroutines and thus increasing their reusability in a wide range of situations.^[25]

//MYPROC PROC FNAME=MYFILE01,SPTYPE=TRK,SPINIT=50,SPEXT=10,LR=100,BLK=1000
.....
//NEWFILE DD DSN=&FNAME,UNIT=DISK,SPACE=(&SPTYPE,&SPINIT,&SPEXT),
//           DCB=(LRECL=&LR,BLKSIZE=&BLK),DISP=(NEW,CATLG,DELETE)
....

In this example, all the values beginning with ampersands «&» are parameters which will be specified when a job requests that the procedure be used. The PROC statement, in addition to giving the procedure a name, allows the programmer to specify default values for each parameter. So one could use the one procedure in this example to create new files of many different sizes and layouts. For example:

//JOB01  JOB ..........
//STEP01 EXEC MYPROC FNAME=JOESFILE,SPTYPE=CYL,SPINIT=10,SPEXT=2,LR=100,BLK=2000
or
//JOB02  JOB ..........
//STEP01 EXEC MYPROC FNAME=SUESFILE,SPTYPE=TRK,SPINIT=500,SPEXT=100,LR=100,BLK=5000

Referbacks[edit]

In multi-step jobs, a later step can use a referback instead of specifying in full a file which has already been specified in an earlier step. For example:

//MYPROC ................
//MYPR01 EXEC PGM=..........
//NEWFILE DD DSN=&MYFILE,UNIT=DISK,SPACE=(TRK,50,10),
//           DCB=(LRECL=100,BLKSIZE=1000),DISP=(NEW,CATLG,DELETE)
....
//MYPR02 EXEC PGM=..........
//INPUT01 DD DSN=*.MYPR01.NEWFILE

Here, MYPR02 uses the file identified as NEWFILE in step MYPR01 (DSN means «dataset name» and specifies the name of the file; a DSN could not exceed 44 characters^[26]).

In jobs which contain a mixture of job-specific JCL and procedure calls, a job-specific step can refer back to a file which was fully specified in a procedure, for example:

//MYJOB JOB ..........
//STEP01 EXEC MYPROC             Using a procedure
//STEP02 EXEC PGM=.........      Step which is specific to this job
//INPUT01 DD DSN=*.STEP01.MYPR01.NEWFILE

where DSN=*.STEP01.MYPR01.NEWFILE means «use the file identified as NEWFILE in step MYPR01 of the procedure used by step STEP01 of this job». Using the name of the step which called the procedure rather than the name of the procedure allows a programmer to use the same procedure several times in the same job without confusion about which instance of the procedure is used in the referback.

[edit]

JCL files can be long and complex, and the language is not easy to read. OS JCL allows programmers to include two types of explanatory comment:

• On the same line as a JCL statement. They can be extended by placing a continuation character (conventionally «X«) in column 72, followed by «// » in columns 1–3 of the next line.
• Lines which contain only comment, often used to explain major points about the overall structure of the JCL rather than local details. Comment-only lines are also used to divide long, complex JCL files into sections.

//MYJOB JOB ..........
//*  Lines containing only comments.
//******** Often used to divide JCL listing into sections ********
//STEP01 EXEC MYPROC             Comment 2 on same line as statement
//STEP02 EXEC PGM=.........      Comment 3 has been extended and       X
//         overflows into another line.
//INPUT01 DD DSN=STEP01.MYPR01.NEWFILE

Concatenating input files[edit]

OS JCL allows programmers to concatenate («chain») input files so that they appear to the program as one file, for example

//INPUT01 DD DSN=MYFILE01,DISP=SHR
//        DD DSN=JOESFILE,DISP=SHR
//        DD DSN=SUESFILE,DISP=SHR

The 2nd and third statements have no value in the name field, so OS treats them as concatenations. The files must be of the same basic type (almost always sequential), and must have the same record length, however the block length need not be the same.

In early versions of the OS (certainly before OS/360 R21.8) the block length must be in decreasing order, or the user must inspect each instance and append to the named DD statement the maximum block length found, as in, for example,

//INPUT01 DD DSN=MYFILE01,DISP=SHR,BLKSIZE=800
//        DD DSN=JOESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 800)
//        DD DSN=SUESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 800)

In later versions of the OS (certainly after OS/MVS R3.7 with the appropriate «selectable units») the OS itself, during allocation, would inspect each instance in a concatenation and would substitute the maximum block length which was found.

A usual fallback was to simply determine the maximum possible block length on the device, and specify that on the named DD statement, as in, for example,

//INPUT01 DD DSN=MYFILE01,DISP=SHR,BLKSIZE=8000
//        DD DSN=JOESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 8000)
//        DD DSN=SUESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 8000)

The purpose of this fallback was to ensure that the access method would allocate an input buffer set which was large enough to accommodate any and all of the specified datasets.

Conditional processing[edit]

OS expects programs to set a return code which specifies how successful the program thought it was. The most common conventional values are:^[27]: p.87

• 0 = Normal — all OK
• 4 = Warning — minor errors or problems
• 8 = Error — significant errors or problems
• 12 = Severe error — major errors or problems, the results (e.g. files or reports produced) should not be trusted.
• 16 = Terminal error — very serious problems, do not use the results!

OS JCL refers to the return code as COND («condition code»), and can use it to decide whether to run subsequent steps. However, unlike most modern programming languages, conditional steps in OS JCL are not executed if the specified condition is true—thus giving rise to the mnemonic, «If it’s true, pass on through [without running the code].» To complicate matters further, the condition can only be specified after the step to which it refers. For example:

//MYJOB JOB ...........
//STEP01 EXEC PGM=PROG01
....
//STEP02 EXEC PGM=PROG02,COND=(4,GT,STEP01)
....
//STEP03 EXEC PGM=PROG03,COND=(8,LE)
....
//STEP04 EXEC PGM=PROG04,COND=(ONLY,STEP01)
....
//STEP05 EXEC PGM=PROG05,COND=(EVEN,STEP03)
....

means:

1. Run STEP01, and collect its return code.
2. Don’t run STEP02 if the number 4 is greater than STEP01‘s return code.
3. Don’t run STEP03 if the number 8 is less than or equal to any previous return code.
4. Run STEP04 only if STEP01 abnormally ended.
5. Run STEP05, even if STEP03 abnormally ended.

This translates to the following pseudocode:

run STEP01
if STEP01's return code is greater than or equal to  4 then
    run STEP02
end if
if any previous return code is less than  8 then
    run STEP03
end if
if STEP01 abnormally ended then
    run STEP04
end if
if STEP03 abnormally ended then
    run STEP05
else
    run STEP05
end if

Note that by reading the steps containing COND statements backwards, one can understand them fairly easily. This is an example of logical transposition.
However, IBM later introduced IF condition in JCL thereby making coding somewhat easier for programmers while retaining the COND parameter (to avoid making changes to the existing JCLs where COND parm is used).

The COND parameter may also be specified on the JOB statement. If so the system «performs the same return code tests for every step in a job. If a JOB statement return code test is satisfied, the job terminates.»^[28]

Utilities[edit]

Jobs use a number of IBM utility programs to assist in the processing of data. Utilities are most useful in batch processing. The utilities can be grouped into three sets:

• Data Set Utilities — Create, print, copy, move and delete data sets.
• System Utilities — Maintain and manage catalogs and other system information.
• Access Method Services — Process Virtual Storage Access Method (VSAM) and non-VSAM data sets.

Difficulty of use[edit]

OS JCL is undeniably complex^[29] and has been described as «user hostile».^[30][31] As one instructional book on JCL asked, «Why do even sophisticated programmers hesitate when it comes to Job Control Language?»^[32] The book stated that many programmers either copied control cards without really understanding what they did, or «believed the prevalent rumors that JCL was horrible, and only ‘die-hard’ computer-types ever understood it» and handed the task of figuring out the JCL statements to someone else.^[32] Such an attitude could be found in programming language textbooks, which preferred to focus on the language itself and not how programs in it were run. As one Fortran IV textbook said when listing possible error messages from the WATFOR compiler: «Have you been so foolish as to try to write your own ‘DD’ system control cards? Cease and desist forthwith; run, do not walk, for help.»^[33]

Nevertheless, some books that went into JCL in detail emphasized that once it was learned to an at least somewhat proficient degree, one gained freedom from installation-wide defaults and much better control over how an IBM system processed your workload.^[32][29] Another book commented on the complexity but said, «take heart. The JCL capability you will gain from [the preceding chapter] is all that most programmers will ever need.»^[29]

Job Entry Control Language[edit]

On IBM mainframe systems Job Entry Control Language or JECL is the set of command language control statements that provide information for the spooling subsystem – JES2 or JES3 on z/OS or VSE/POWER for z/VSE. JECL statements may «specify on which network computer to run the job, when to run the job, and where to send the resulting output.»^[27]

JECL is distinct from job control language (JCL), which instructs the operating system how to run the job.

There are different versions of JECL for the three environments.

OS/360[edit]

An early version of Job Entry Control Language for OS/360 Remote Job Entry (Program Number 360S-RC-536) used the identifier  ..  in columns 1–2 of the input record and consisted of a single control statement: JED (Job Entry Definition). «Workstation Commands» such as LOGON, LOGOFF, and STATUS also began with  .. .^[34]

pre-JES JECL[edit]

Although the term had not yet been developed, HASP did have similar functionality to what would become the JECL of JES, including /* syntax.

z/OS[edit]

For JES2 JECL statements start with /*, for JES3 they start with //*, except for remote  /*SIGNON  and  /*SIGNOFF  commands. The commands for the two systems are completely different.

JES2 JECL[edit]

The following JES2 JECL statements are used in z/OS 1.2.0.^[35]

JES3 JECL[edit]

The following JES3 JECL statements are used in z/OS 1.2.0^[37]

z/VSE[edit]

For VSE JECL statements start with ‘* $$‘ (note the single space). The Job Entry Control Language defines the start and end lines of JCL jobs. It advises VSE/POWER how this job is handled. JECL statements define the job name (used by VSE/POWER), the class in which the job is processed, and the disposition of the job (i.e. D, L, K, H).

Example:

* $$ JOB JNM=NAME,DISP=K,CLASS=2

[some JCL statements here]

* $$ EOJ

Other systems[edit]

Other mainframe batch systems had some form of job control language, whether called that or not; their syntax was completely different from IBM versions, but they usually provided similar capabilities. Interactive systems
include «command languages»—command files (such as PCDOS «.bat» files) can be run non-interactively, but these usually do not provide as robust an environment for running unattended jobs as JCL. On some computer systems the job control language and the interactive command language may be different. For example, TSO on z/OS systems uses CLIST or Rexx as command languages along with JCL for batch work. On other systems these may be the same.

See also[edit]

• dd (Unix), Unix program inspired by DD
• IBM mainframe utility programs
• Batch processing
• Data set (IBM mainframe)#Generation Data Group

References[edit]

Sources[edit]

• «z/OS V1R6.0 MVS JCL User’s Guide» (PDF) (5th ed.). IBM. September 2004.
• «z/OS V1R7.0 MVS JCL Reference» (PDF) (11th ed.). IBM. April 2006.
• Johnston, Jerry (1 April 2005). «VSE: A Look at the Past 40 Years». z/Journal. Thomas Communications. Archived from the original on 4 March 2009.
• «Computer Chronicles: 1972 — 1981». ThinkQuest. Oracle Corporation. 1998. Archived from the original on 21 June 2009.
• DeWard Brown, Gary (7 June 2002). zOS JCL (5th ed.). Wiley. ISBN 978-0-471-23635-1.
• «JCL Statement Fields». z/OS V1R11.0 MVS JCL Reference z/OS V1R10.0-V1R11.0. IBM. 2010.
• IBM Corporation (March 2007). Introduction to the New Mainframe: z/VSE Basics (PDF). ISBN 978-0-73-848624-6. Retrieved 2017-12-06.
• Ashley, Ruth; Fernandez, Judi N. (1978). Job Control Language: A Self-Teaching Guide. New York: John Wiley & Sons. ISBN 0-471-03205-0.
• McQuillen, Kevin (1975). System/360–370 Assembler Language (OS). Fresno, California: Mike Murach & Associates. LCCN 74-29645.
• Stern, Nancy; Stern, Robert A. (1980). Structured COBOL Programming (3rd ed.). New York: John Wiley & Sons. ISBN 0-471-04913-1.

This article is about IBM mainframe job control language. For open systems, see job control (Unix). For general term, see job control.

Job Control Language (JCL) is a name for scripting languages used on IBM mainframe operating systems to instruct the system on how to run a batch job or start a subsystem.^[1]

More specifically, the purpose of JCL is to say which programs to run, using which files or devices ^[2] for input or output, and at times to also indicate under what conditions to skip a step.

Parameters in the JCL can also provide accounting information for tracking the resources used by a job as well as which machine the job should run on.

There are two distinct IBM Job Control languages:

• one for the operating system lineage that begins with DOS/360 and whose latest member is z/VSE; and
• the other for the lineage from OS/360 to z/OS, the latter now including JES extensions, Job Entry Control Language (JECL).

They share some basic syntax rules and a few basic concepts, but are otherwise very different.^[3]

The VM operating system does not have JCL as such; the CP and CMS components each have command languages.

Terminology[edit]

Certain words or phrases used in conjunction to JCL are specific to IBM mainframe technology.

• Dataset: a «dataset» is a file; it can be temporary or permanent, and located on a disk drive, tape storage, or other device.^[4][5]
• Member: a «member» of a partitioned dataset (PDS) is an individual dataset within a PDS. A member can be accessed by specifying the name of the PDS with the member name in parentheses. For example, the system macro GETMAIN in SYS1.MACLIB can be referenced as SYS1.MACLIB(GETMAIN).^[6]
• Partitioned dataset: a «partitioned dataset» or PDS is collection of members, or archive, typically used to represent system libraries. As with most such structures, a member, once stored, cannot be updated; the member must be deleted and replaced, such as with the IEBUPDTE utility.^[6] Partitioned datasets are roughly analogous to ar-based static libraries in Unix-based systems.
• USS: Unix system services, a Unix subsystem running as part of MVS, and allowing Unix files, scripts, tasks, and programs to run on a mainframe in a UNIX environment.

Motivation[edit]

Originally, mainframe systems were oriented toward batch processing. Many batch jobs require setup, with specific requirements for main storage, and dedicated devices such as magnetic tapes, private disk volumes, and printers set up with special forms.^[7] JCL was developed as a means of ensuring that all required resources are available before a job is scheduled to run. For example, many systems, such as Linux allow identification of required datasets to be specified on the command line, and therefore subject to substitution by the shell, or generated by the program at run-time. On these systems the operating system job scheduler has little or no idea of the requirements of the job. In contrast, JCL explicitly specifies all required datasets and devices. The scheduler can pre-allocate the resources prior to releasing the job to run. This helps to avoid «deadlock», where job A holds resource R1 and requests resource R2, while concurrently running job B holds resource R2 and requests R1. In such cases the only solution is for the computer operator to terminate one of the jobs, which then needs to be restarted. With job control, if job A is scheduled to run, job B will not be started until job A completes or releases the required resources.

Features common to DOS and OS JCL[edit]

Jobs, steps and procedures[edit]

For both DOS and OS the unit of work is the job. A job consists of one or several steps, each of which is a request to run one specific program. For example, before the days of relational databases, a job to produce a printed report for management might consist of the following steps: a user-written program to select the appropriate records and copy them to a temporary file; sort the temporary file into the required order, usually using a general-purpose utility; a user-written program to present the information in a way that is easy for the end-users to read and includes other useful information such as sub-totals; and a user-written program to format selected pages of the end-user information for display on a monitor or terminal.

In both DOS and OS JCL the first «card» must be the JOB card, which:^[8]

• Identifies the job.
• Usually provides information to enable the computer services department to bill the appropriate user department.
• Defines how the job as a whole is to be run, e.g. its priority relative to other jobs in the queue.

Procedures (commonly called procs) are pre-written JCL for steps or groups of steps, inserted into a job. Both JCLs allow such procedures. Procs are used for repeating steps which are used several times in one job, or in several different jobs. They save programmer time and reduce the risk of errors. To run a procedure one simply includes in the JCL file a single «card» which copies the procedure from a specified file, and inserts it into the jobstream. Also, procs can include parameters to customize the procedure for each use.

Basic syntax[edit]

Both DOS and OS JCL have a maximum usable line length of 80 characters, because when DOS/360 and OS/360 were first used the main method of providing new input to a computer system was 80-column punched cards.^[9] It later became possible to submit jobs via disk or tape files with longer record lengths, but the operating system’s job submission components ignored everything after character 80.

Strictly speaking both operating system families use only 71 characters per line. Characters 73-80 are usually card sequence numbers which the system printed on the end-of-job report and are useful for identifying the locations of any errors reported by the operating system. Character 72 is usually left blank, but it can contain a nonblank character to indicate that the JCL statement is continued onto the next card.

All commands, parameter names and values have to be in capitals, except for USS filenames.

All lines except for in-stream input (see below) have to begin with a slash «/«, and all lines which the operating system processes have to begin with two slashes // — always starting in the first column. However, there are two exceptions: the delimiter statement and the comment statement. A delimiter statements begins with a slash and an asterisk (/*), and a comment statement in OS JCL begins with a pair of slashes and asterisk (//*) or an asterisk in DOS JCL.

Many JCL statements are too long to fit within 71 characters, but can be extended on to an indefinite number of continuation cards by:

The structure of the most common types of card is:^[10]

In-stream input[edit]

DOS and OS JCL both allow in-stream input, i.e. «cards» which are to be processed by the application program rather than the operating system. Data which is to be kept for a long time will normally be stored on disk, but before the use of interactive terminals became common the only way to create and edit such disk files was by supplying the new data on cards.

DOS and OS JCL have different ways of signaling the start of in-stream input, but both end in-stream input with /* at column 1 of the card following the last in-stream data card. This makes the operating system resume processing JCL in the card following the /* card.^[11]

• OS JCL: DD statements can be used to describe in-stream data, as well as data sets. A DD statement dealing with in-stream data has an asterisk (*) following the DD identifier, e.g. //SYSIN DD *. JCL statements can be included as part of in-stream data by using the DD DATA statements.

An operand named DLM allowed specifying a delimiter (default is «/*»). Specifying an alternate delimiter allows JCL to be read as data, for example to copy procedures to a library member or to submit a job to the internal reader.

• An example,^[12] which submits a job to the Internal Reader (INTRDR) and then deletes two files is:

//SUBM     EXEC PGM=IEBGENER
//SYSPRINT DD   SYSOUT=Z
//SYSUT2   DD   SYSOUT=(A,INTRDR)
//SYSIN    DD   DUMMY
//SYSUT1   DD   DATA,DLM=ZZ
//RUNLATR  JOB  ACCT,MANIX,CLASS=A.TYPRUN=HOLD
//* ^ a JOB to run later
//CPUHOG   EXEC PGM=PICALC1K
//OUTPUT   DD   DSN=PICALC.1000DGTS,SPACE=(TRK,1),DISP=(,KEEP)
ZZ
//* ^ as specified by DLM=ZZ
//DROPOLDR EXEC PGM=IEFBR14
//DELETE4  DD   DSN=PICALC.4DGTS,DISP=(OLD,DELETE)
//DELETE5  DD   DSN=PICALC.5DGTS,DISP=(OLD,DELETE)

1. The program called PICALC1K will await (TYPRUN=HOLD) being released manually
2. The program called IEFBR14 will run NOW and upon completion, the two existing files, PICALC.4DGTS and PICALC.5DGTS will be deleted.

• DOS JCL: Simply enter the in-stream data after the EXEC card for the program.

Complexity[edit]

Much of the complexity of OS JCL, in particular, derives from the large number of options for specifying dataset information. While files on Unix-like operating systems are abstracted into arbitrary collections of bytes, with the details handled in large part by the operating system, datasets on OS/360 and its successors expose their file types and sizes, record types and lengths, block sizes, device-specific information like magnetic tape density, and label information. Although there are system defaults for many options, there is still a lot to be specified by the programmer, through a combination of JCL and information coded in the program. The more information coded in the program, the less flexible it is, since information in the program overrides anything in the JCL; thus, most information is usually supplied through JCL.

For example, to copy a file on Unix operating system, the user would enter a command like:

cp oldFile newFile

The following example, using JCL, might be used to copy a file on OS/360:

//IS198CPY JOB (IS198T30500),'COPY JOB',CLASS=L,MSGCLASS=X
//COPY01   EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=OLDFILE,DISP=SHR
//SYSUT2   DD DSN=NEWFILE,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(40,5),RLSE),
//            DCB=(LRECL=115,BLKSIZE=1150)
//SYSIN  DD DUMMY

A second explanation for the complexity of JCL is the different expectations for running a job from those found in a PC or Unix-like environment.

• Low-end System/360 CPUs were less powerful and more expensive than the mid-1980s PCs for which MS-DOS was designed. OS/360 was intended for systems with a minimum memory size of 32 KB and DOS/360 for systems with a minimum of 16 KB. A 360/30 CPU—low-end when System/360 was announced in 1964—processed 1.8K to 34.5K instructions per second.^[13] The first IBM PC in 1981 had 16 KB or 64 KB of memory and would process about 330K instructions per second.^[14][15] As a result, JCL had to be easy for the computer to process, and ease of use by programmers was a much lower priority. In this era, programmers were much cheaper than computers.
• JCL was designed for batch processing. As such, it has to tell the operating system everything, including what to do depending on the result of a step. For example, DISP=(NEW,CATLG,DELETE) means «if the program runs successfully, create a new file and catalog it; otherwise delete the new file.» Programs run on a PC frequently depend on the user to clean up after processing problems.
• System/360 machines were designed to be shared by all the users in an organization. So the JOB card tells the operating system how to bill the user’s account (IS198T30500), what predefined amount of storage and other resources may be allocated (CLASS=L), and several other things. //SYSPRINT DD SYSOUT=* tells the computer to print the program’s report on the default printer which is loaded with ordinary paper, not on some other printer which might be loaded with blank checks. DISP=SHR tells the operating system that other programs can read OLDFILE at the same time.

Later versions of the DOS/360 and OS/360 operating systems retain most features of the original JCL—although some simplification has been made, to avoid forcing customers to rewrite all their JCL files.^{[citation needed]} Many users save as a procedure any set of JCL statements which is likely to be used more than once or twice.^[16]

The syntax of OS JCL is similar to the syntax of macros in System/360 assembly language, and would therefore have been familiar to programmers at a time when many programs were coded in assembly language.

DOS JCL[edit]

Positional parameters[edit]

//TLBL TAPEFIL,'COPYTAPE.JOB',,,,2
//ASSGN SYS005,200
//DLBL DISKFIL,'COPYTAPE.JOB',0,SD
//EXTENT SYS005,VOL01,1,0,800,1600

DOS JCL parameters are positional, which makes them harder to read and write, but easier for the system to parse.

• The programmer must remember which item goes in which position in every type of statement.
• If some optional parameters are omitted but later ones are included, the omitted parameters must be represented by commas with no spaces, as in the TLBL statement above.

DOS JCL to some extent mitigates the difficulties of positional parameters by using more statements with fewer parameters than OS JCL. In the example the ASSGN, DLBL and EXTENT statements do the same work (specifying where a new disk file should be stored) as a single DD statement in OS JCL.

Device dependence[edit]

In the original DOS/360 and in most versions of DOS/VS one had to specify the model number of the device which was to be used for each disk or tape file—even for existing files and for temporary files which would be deleted at the end of the job. This meant that, if a customer upgraded to more modern equipment, many JCL files had to be changed.

Later members of the DOS/360 family reduced the number of situations in which device model numbers were required.

Manual file allocation[edit]

DOS/360 originally required the programmer to specify the location and size of all files on DASD. The EXTENT card specifies the volume on which the extent resides, the starting absolute track, and the number of tracks. For z/VSE a file can have up to 256 extents on different volumes.

OS JCL[edit]

OS JCL consists of three basic statement types:^[17]

• JOB statement, which identifies the start of the job, and information about the whole job, such as billing, run priority, and time and space limits.
• EXEC statement, which identifies the program or procedure^[18] to be executed in this step of the job,
  and information about the step, including CONDitions for running or skipping a step.
• DD (Data Definition) statements, which identify a data file to be used in a step, and detailed info about that file. DD statements can be in any order within the step.

Right from the start, JCL for the OS family (up to and including z/OS) was more flexible and easier to use.

The following examples use the old style of syntax which was provided right from the launch of System/360 in 1964. The old syntax is still quite common in jobs that have been running for decades with only minor changes.

Rules for coding JCL statements[edit]

Each JCL statement is divided into five fields:^[19]

 Identifier-Field Name-Field Operation-Field Parameter-Field Comments-Field
                 ^          ^               ^               ^
              no space     space          space           space

Identifier-Field should be concatenated with Name-Field, i.e. there should be no spaces between them.

• Identifier-Field (//): The identifier field indicates to the system that a statement is a JCL statement rather than data. The identifier field consists of the following:
  • Columns 1 and 2 of all JCL statements, except the delimiter statement, contain //
  • Columns 1 and 2 of the delimiter statement contain /*
  • Columns 1, 2, and 3 of a JCL comment statement contain //*
• Name-Field: The name field identifies a particular statement so that other statements and the system can refer to it. For JCL statements, it should be coded as follows:
  • The name must begin in column 3.
  • The name is 1 through 8 alphanumeric or national ($, #, @) characters.
  • The first character must be an alphabetic.
  • The name must be followed by at least one blank.
• Operation-Field: The operation field specifies the type of statement, or, for the command statement, the command. Operation-Field should be coded as follows:
  • The operation field consists of the characters in the syntax box for the statement.
  • The operation follows the name field.
  • The operation must be preceded and followed by at least one blank.
  • The operation will be one of JOB, EXEC and DD.
• Parameter-Field: The parameter field, also sometimes referred to as the operand field, contains parameters separated by commas. Parameter field should be coded as follows:
  • The parameter field follows the operation field.
  • The parameter field must be preceded by at least one blank.
  • The parameter field contains parameters which are keywords that used in the statement to provide information such as the program or dataset name.
• Comments-Field: This contains comments. Comments-Field should be coded as Follows:
  • The comments field follows the parameter field.
  • The comments field must be preceded by at least one blank.

Keyword parameters[edit]

//NEWFILE DD DSN=MYFILE01,UNIT=DISK,SPACE=(TRK,80,10),
//           DCB=(LRECL=100,BLKSIZE=1000),
//           DISP=(NEW,CATLG,DELETE)

All of the major parameters of OS JCL statements are identified by keywords and can be presented in any order. A few of these contain two or more sub-parameters, such as SPACE (how much disk space to allocate to a new file) and DCB (detailed specification of a file’s layout) in the example above. Sub-parameters are sometimes positional, as in SPACE, but the most complex parameters, such as DCB, have keyword sub-parameters.

Positional parameter must precede keyword parameters. Keyword parameters always assign values to a keyword using the equals sign (=).^[20]

Data access (DD statement)[edit]

The DD statement is used to reference data. This statement links a program’s internal description of a dataset to the data on external devices: disks, tapes, cards, printers, etc. The DD may provide information such as a device type (e.g. ‘181’,’2400-5′,’TAPE’), a volume serial number for tapes or disks, and the description of the data file, called the DCB subparameter after the Data Control Block (DCB) in the program used to identify the file.

Information describing the file can come from three sources: The DD card information, the dataset label information for an existing file stored on tape or disk, and the DCB macro coded in the program. When the file is opened this data is merged, with the DD information taking precedence over the label information, and the DCB information taking precedence over both. The updated description is then written back to the dataset label. This can lead to unintended consequences if incorrect DCB information is provided.^[21]

Because of the parameters listed above and specific information for various access methods and devices the DD statement is the most complex JCL statement. In one IBM reference manual description of the DD statement occupies over 130 pages—more than twice as much as the JOB and EXEC statements combined.^[22]

The DD statement allows inline data to be injected into the job stream. This is useful for providing control information to utilities such as IDCAMS, SORT, etc. as well as providing input data to programs.

Device independence[edit]

From the very beginning, the JCL for the OS family of operating systems offered a high degree of device independence. Even for new files which were to be kept after the end of the job one could specify the device type in generic terms, e.g., UNIT=DISK, UNIT=TAPE, or UNIT=SYSSQ (tape or disk). Of course, if it mattered one could specify a model number or even a specific device address.^[23]

Procedures[edit]

Procedures permit grouping one or more «EXEC PGM=» and DD statements and then invoking them with «EXEC PROC=procname» -or- simply «EXEC procname» ^[24]

A facility called a Procedure Library allowed pre-storing procedures.

PROC & PEND[edit]

Procedures can also be included in the job stream by terminating the procedure with a // PEND statement, then invoking it by name the same was as if it were in a procedure library.

For example:

//SUMPRINT PROC 
//PRINT    EXEC PGM=IEBGENER
//SYSUT1   DD   DSN=CEO.FILES.DAYEND.RPT24A,DISP=SHR
//SYSUT2   DD   SYSOUT=A
//SYSIN    DD   DUMMY
//         PEND
// EXEC SUMPRINT

Parameterized procedures[edit]

OS JCL procedures were parameterized from the start, making them rather like macros or even simple subroutines and thus increasing their reusability in a wide range of situations.^[25]

//MYPROC PROC FNAME=MYFILE01,SPTYPE=TRK,SPINIT=50,SPEXT=10,LR=100,BLK=1000
.....
//NEWFILE DD DSN=&FNAME,UNIT=DISK,SPACE=(&SPTYPE,&SPINIT,&SPEXT),
//           DCB=(LRECL=&LR,BLKSIZE=&BLK),DISP=(NEW,CATLG,DELETE)
....

In this example, all the values beginning with ampersands «&» are parameters which will be specified when a job requests that the procedure be used. The PROC statement, in addition to giving the procedure a name, allows the programmer to specify default values for each parameter. So one could use the one procedure in this example to create new files of many different sizes and layouts. For example:

//JOB01  JOB ..........
//STEP01 EXEC MYPROC FNAME=JOESFILE,SPTYPE=CYL,SPINIT=10,SPEXT=2,LR=100,BLK=2000
or
//JOB02  JOB ..........
//STEP01 EXEC MYPROC FNAME=SUESFILE,SPTYPE=TRK,SPINIT=500,SPEXT=100,LR=100,BLK=5000

Referbacks[edit]

In multi-step jobs, a later step can use a referback instead of specifying in full a file which has already been specified in an earlier step. For example:

//MYPROC ................
//MYPR01 EXEC PGM=..........
//NEWFILE DD DSN=&MYFILE,UNIT=DISK,SPACE=(TRK,50,10),
//           DCB=(LRECL=100,BLKSIZE=1000),DISP=(NEW,CATLG,DELETE)
....
//MYPR02 EXEC PGM=..........
//INPUT01 DD DSN=*.MYPR01.NEWFILE

Here, MYPR02 uses the file identified as NEWFILE in step MYPR01 (DSN means «dataset name» and specifies the name of the file; a DSN could not exceed 44 characters^[26]).

In jobs which contain a mixture of job-specific JCL and procedure calls, a job-specific step can refer back to a file which was fully specified in a procedure, for example:

//MYJOB JOB ..........
//STEP01 EXEC MYPROC             Using a procedure
//STEP02 EXEC PGM=.........      Step which is specific to this job
//INPUT01 DD DSN=*.STEP01.MYPR01.NEWFILE

where DSN=*.STEP01.MYPR01.NEWFILE means «use the file identified as NEWFILE in step MYPR01 of the procedure used by step STEP01 of this job». Using the name of the step which called the procedure rather than the name of the procedure allows a programmer to use the same procedure several times in the same job without confusion about which instance of the procedure is used in the referback.

[edit]

JCL files can be long and complex, and the language is not easy to read. OS JCL allows programmers to include two types of explanatory comment:

• On the same line as a JCL statement. They can be extended by placing a continuation character (conventionally «X«) in column 72, followed by «// » in columns 1–3 of the next line.
• Lines which contain only comment, often used to explain major points about the overall structure of the JCL rather than local details. Comment-only lines are also used to divide long, complex JCL files into sections.

//MYJOB JOB ..........
//*  Lines containing only comments.
//******** Often used to divide JCL listing into sections ********
//STEP01 EXEC MYPROC             Comment 2 on same line as statement
//STEP02 EXEC PGM=.........      Comment 3 has been extended and       X
//         overflows into another line.
//INPUT01 DD DSN=STEP01.MYPR01.NEWFILE

Concatenating input files[edit]

OS JCL allows programmers to concatenate («chain») input files so that they appear to the program as one file, for example

//INPUT01 DD DSN=MYFILE01,DISP=SHR
//        DD DSN=JOESFILE,DISP=SHR
//        DD DSN=SUESFILE,DISP=SHR

The 2nd and third statements have no value in the name field, so OS treats them as concatenations. The files must be of the same basic type (almost always sequential), and must have the same record length, however the block length need not be the same.

In early versions of the OS (certainly before OS/360 R21.8) the block length must be in decreasing order, or the user must inspect each instance and append to the named DD statement the maximum block length found, as in, for example,

//INPUT01 DD DSN=MYFILE01,DISP=SHR,BLKSIZE=800
//        DD DSN=JOESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 800)
//        DD DSN=SUESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 800)

In later versions of the OS (certainly after OS/MVS R3.7 with the appropriate «selectable units») the OS itself, during allocation, would inspect each instance in a concatenation and would substitute the maximum block length which was found.

A usual fallback was to simply determine the maximum possible block length on the device, and specify that on the named DD statement, as in, for example,

//INPUT01 DD DSN=MYFILE01,DISP=SHR,BLKSIZE=8000
//        DD DSN=JOESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 8000)
//        DD DSN=SUESFILE,DISP=SHR (BLKSIZE assumed to be equal to or less than 8000)

The purpose of this fallback was to ensure that the access method would allocate an input buffer set which was large enough to accommodate any and all of the specified datasets.

Conditional processing[edit]

OS expects programs to set a return code which specifies how successful the program thought it was. The most common conventional values are:^[27]: p.87

• 0 = Normal — all OK
• 4 = Warning — minor errors or problems
• 8 = Error — significant errors or problems
• 12 = Severe error — major errors or problems, the results (e.g. files or reports produced) should not be trusted.
• 16 = Terminal error — very serious problems, do not use the results!

OS JCL refers to the return code as COND («condition code»), and can use it to decide whether to run subsequent steps. However, unlike most modern programming languages, conditional steps in OS JCL are not executed if the specified condition is true—thus giving rise to the mnemonic, «If it’s true, pass on through [without running the code].» To complicate matters further, the condition can only be specified after the step to which it refers. For example:

//MYJOB JOB ...........
//STEP01 EXEC PGM=PROG01
....
//STEP02 EXEC PGM=PROG02,COND=(4,GT,STEP01)
....
//STEP03 EXEC PGM=PROG03,COND=(8,LE)
....
//STEP04 EXEC PGM=PROG04,COND=(ONLY,STEP01)
....
//STEP05 EXEC PGM=PROG05,COND=(EVEN,STEP03)
....

means:

1. Run STEP01, and collect its return code.
2. Don’t run STEP02 if the number 4 is greater than STEP01‘s return code.
3. Don’t run STEP03 if the number 8 is less than or equal to any previous return code.
4. Run STEP04 only if STEP01 abnormally ended.
5. Run STEP05, even if STEP03 abnormally ended.

This translates to the following pseudocode:

run STEP01
if STEP01's return code is greater than or equal to  4 then
    run STEP02
end if
if any previous return code is less than  8 then
    run STEP03
end if
if STEP01 abnormally ended then
    run STEP04
end if
if STEP03 abnormally ended then
    run STEP05
else
    run STEP05
end if

Note that by reading the steps containing COND statements backwards, one can understand them fairly easily. This is an example of logical transposition.
However, IBM later introduced IF condition in JCL thereby making coding somewhat easier for programmers while retaining the COND parameter (to avoid making changes to the existing JCLs where COND parm is used).

The COND parameter may also be specified on the JOB statement. If so the system «performs the same return code tests for every step in a job. If a JOB statement return code test is satisfied, the job terminates.»^[28]

Utilities[edit]

Jobs use a number of IBM utility programs to assist in the processing of data. Utilities are most useful in batch processing. The utilities can be grouped into three sets:

• Data Set Utilities — Create, print, copy, move and delete data sets.
• System Utilities — Maintain and manage catalogs and other system information.
• Access Method Services — Process Virtual Storage Access Method (VSAM) and non-VSAM data sets.

Difficulty of use[edit]

OS JCL is undeniably complex^[29] and has been described as «user hostile».^[30][31] As one instructional book on JCL asked, «Why do even sophisticated programmers hesitate when it comes to Job Control Language?»^[32] The book stated that many programmers either copied control cards without really understanding what they did, or «believed the prevalent rumors that JCL was horrible, and only ‘die-hard’ computer-types ever understood it» and handed the task of figuring out the JCL statements to someone else.^[32] Such an attitude could be found in programming language textbooks, which preferred to focus on the language itself and not how programs in it were run. As one Fortran IV textbook said when listing possible error messages from the WATFOR compiler: «Have you been so foolish as to try to write your own ‘DD’ system control cards? Cease and desist forthwith; run, do not walk, for help.»^[33]

Nevertheless, some books that went into JCL in detail emphasized that once it was learned to an at least somewhat proficient degree, one gained freedom from installation-wide defaults and much better control over how an IBM system processed your workload.^[32][29] Another book commented on the complexity but said, «take heart. The JCL capability you will gain from [the preceding chapter] is all that most programmers will ever need.»^[29]

Job Entry Control Language[edit]

On IBM mainframe systems Job Entry Control Language or JECL is the set of command language control statements that provide information for the spooling subsystem – JES2 or JES3 on z/OS or VSE/POWER for z/VSE. JECL statements may «specify on which network computer to run the job, when to run the job, and where to send the resulting output.»^[27]

JECL is distinct from job control language (JCL), which instructs the operating system how to run the job.

There are different versions of JECL for the three environments.

OS/360[edit]

An early version of Job Entry Control Language for OS/360 Remote Job Entry (Program Number 360S-RC-536) used the identifier  ..  in columns 1–2 of the input record and consisted of a single control statement: JED (Job Entry Definition). «Workstation Commands» such as LOGON, LOGOFF, and STATUS also began with  .. .^[34]

pre-JES JECL[edit]

Although the term had not yet been developed, HASP did have similar functionality to what would become the JECL of JES, including /* syntax.

z/OS[edit]

For JES2 JECL statements start with /*, for JES3 they start with //*, except for remote  /*SIGNON  and  /*SIGNOFF  commands. The commands for the two systems are completely different.

JES2 JECL[edit]

The following JES2 JECL statements are used in z/OS 1.2.0.^[35]

JES3 JECL[edit]

The following JES3 JECL statements are used in z/OS 1.2.0^[37]

z/VSE[edit]

For VSE JECL statements start with ‘* $$‘ (note the single space). The Job Entry Control Language defines the start and end lines of JCL jobs. It advises VSE/POWER how this job is handled. JECL statements define the job name (used by VSE/POWER), the class in which the job is processed, and the disposition of the job (i.e. D, L, K, H).

Example:

* $$ JOB JNM=NAME,DISP=K,CLASS=2

[some JCL statements here]

* $$ EOJ

Other systems[edit]

Other mainframe batch systems had some form of job control language, whether called that or not; their syntax was completely different from IBM versions, but they usually provided similar capabilities. Interactive systems
include «command languages»—command files (such as PCDOS «.bat» files) can be run non-interactively, but these usually do not provide as robust an environment for running unattended jobs as JCL. On some computer systems the job control language and the interactive command language may be different. For example, TSO on z/OS systems uses CLIST or Rexx as command languages along with JCL for batch work. On other systems these may be the same.

See also[edit]

• dd (Unix), Unix program inspired by DD
• IBM mainframe utility programs
• Batch processing
• Data set (IBM mainframe)#Generation Data Group

References[edit]

Sources[edit]

• «z/OS V1R6.0 MVS JCL User’s Guide» (PDF) (5th ed.). IBM. September 2004.
• «z/OS V1R7.0 MVS JCL Reference» (PDF) (11th ed.). IBM. April 2006.
• Johnston, Jerry (1 April 2005). «VSE: A Look at the Past 40 Years». z/Journal. Thomas Communications. Archived from the original on 4 March 2009.
• «Computer Chronicles: 1972 — 1981». ThinkQuest. Oracle Corporation. 1998. Archived from the original on 21 June 2009.
• DeWard Brown, Gary (7 June 2002). zOS JCL (5th ed.). Wiley. ISBN 978-0-471-23635-1.
• «JCL Statement Fields». z/OS V1R11.0 MVS JCL Reference z/OS V1R10.0-V1R11.0. IBM. 2010.
• IBM Corporation (March 2007). Introduction to the New Mainframe: z/VSE Basics (PDF). ISBN 978-0-73-848624-6. Retrieved 2017-12-06.
• Ashley, Ruth; Fernandez, Judi N. (1978). Job Control Language: A Self-Teaching Guide. New York: John Wiley & Sons. ISBN 0-471-03205-0.
• McQuillen, Kevin (1975). System/360–370 Assembler Language (OS). Fresno, California: Mike Murach & Associates. LCCN 74-29645.
• Stern, Nancy; Stern, Robert A. (1980). Structured COBOL Programming (3rd ed.). New York: John Wiley & Sons. ISBN 0-471-04913-1.

Другим средством общения в ОС ЕС являются команды оператора [21], предназначенные для обращения с пультового устройства или с дисплея-консоли к управляющей программе. Различают команды оператора информационные, управления устройствами ввода-выво-да, управления работой системных программ, управления прохождением заданий в системе и др. Некоторые команды оператора можно направлять через входной поток вместе с операторами языка управления заданиями, что дает возможность пользователю наравне с оператором ЭВМ влиять на организацию вычислительного процесса в системе.
 [c.126]

Необходимо знание командного языка или языка управления заданиями Да Да Нет Да Да Да
 [c.114]

Программу на входном языке системы называют исходным модулем, а программу после трансляции — объектным модулем. Объектные модули могут объединяться в новый модуль с помощью редактора связи и называются в том случае загрузочным модулем, который может быть загружен в оперативную память и выполнен или записан в библиотеку. Поиск модулей в библиотеках, их запись, трансляция и другие системные действия обычно выполняются под управлением супервизора согласно заданию, записанному на языке управления заданиями.
 [c.57]

При этом возможны различные варианты реализации системы в целом. Это может быть реализация системы в виде набора готовых к выполнению (формат загрузки) программ, реализующих те или иные функции как обработки, так и базы данных, и отображения результатов. Последовательность выполнения обработки определяется ири этом оператором и набором заданий на языке управления задания конкретной системы базового математического обеспечения ЭВМ. Такая организация программой системы позволяет осуществлять обработку по различным алгоритмам в пакетном режиме [5].
 [c.43]

Язык управления заданиями ОС ЕС ЭВМ. Язык управления заданиями ОС ЕС ЭВМ [63, 95] отвечает общим положениям, рассмотренным выше. Многие параметры и подпараметры ЯУЗ имеют стандартные значения и в типовых случаях могут явно не указываться. Для упрощения оформления заданий имеются каталогизированные процедуры, обеспечивающие выполнение заданий. Например, для реализации исходных модулей, написанных на Фортране, или соответствующих объектных модулей используются каталогизированные процедуры с именами
 [c.175]

Специальное, прикладное проблемно-ориентированное программное обеспечение формируется в виде ППП простой и сложной структуры. В ППП простой структуры все управляющие функции выполняются ОС, маршрут работ определяется посредством языка управления заданиями ОС. В ППП сложной структуры кроме прикладных программ подсистемы проектирования имеется управляющая программа, которую можно рассматривать в качестве проблемно-ориентированной подсистемы ОС, подчиненной ОС ЭВМ в общей иерархической структуре ПО САПР.
 [c.191]

Проблема новых языков. Для использования ППП необходимо изучать два языка первый — для собственного описания параметров проектных задач, второй — командный (язык управления заданиями).
 [c.60]

Различают несколько типов ППП в зависимости от состава пакета. Пакеты прикладных программ простой структуры характеризуются наличием только обрабатывающей части — набора функциональных программ, каждая из которых предназначена для выполнения некоторой проектной операции или процедуры. Объединение нужных программ для реализации маршрутов проектирования происходит средствами операционной системы ЭВМ или мониторной системы САПР на основе соответствующего языка управления заданиями. Совместное исполнение этих программ определяется возможностями организации их информационного интерфейса. В ППП простой структуры организация информационного интерфейса в значительной мере возлагается на пользователя. Такие пакеты просты в разработке, но неразвитость средств управления, информационного интерфейса и отсутствие удобного лингвистического обеспечения ограничивают их возможности. Они применяются лишь на маршрутах проектирования, на которых последовательно выполняемые операции достаточно автономны, информационные связи программ между собой и с пользователем достаточно слабые.
 [c.283]

Команды оператора Язык управления заданием
 [c.128]

Язык управления исполнением в основном выполняет те же функции, что и язык управления заданиями в системе ОС. Связь пользователя с МС осуществляется с помощью операторов языка управления исполнением, которые в совокупности организуют пакет управления исполнением.
 [c.228]

Программы управления заданиями (планировщики) организуют вычислительный процесс для решения задачи в соответствии с заданными директивами. Программы управления данными организуют обмен данными между устройствами ввода —вывода и подсистемами САПР. Сервисные программы (трансляторы, редакторы связей и загрузчики) предназначены для перевода с алгоритмических и входных языков, объединения программных модулей в рабочую программу и загрузки рабочей программы в оперативную память ЭВМ.
 [c.25]

Язык управления пакетом обеспечивает возможность создания пакетных заданий, размещаемых в виде файлов на магнитных дисках и лентах или на перфокартах и перфоленте. Пакетные задания управляют режимом пакетной обработки. Система пакетной обработки содержит средства, позволяющие передавать управление из одного пакета другому, вызывать во время выполнения пакетного задания другое задание и др.
 [c.200]

Язык управления служит основным средством для программирования задач робота и управления всем робототехническим комплексом в целом. Соответственно своему назначению язык управления содержит два компонента — язык программирования задач робота и командный язык, или язык директив. Язык программирования роботов характеризуется определенным уровнем (низким или высоким) и по своим функциям подобен обычному языку программирования ЭВМ соответствуюп его уровня, дополненному операторами, специфичными для промышленных роботов. К таким операторам относятся, например, операторы перемещения руки робота, открытия и закрытия захвата, опроса состояния сенсорных устройств, выдержки заданного интервала времени и т. п. Нередко в язык программирования включают операторы для организации параллельного выполнения и синхронизации задач, что особенно важно при программировании роботов с двумя и более руками.
 [c.145]

Параллельно с исполнением роботом задания человек-оператор может формировать новые рабочие программы в виде текстов на входном проблемно-ориентированном языке управления.
 [c.21]

Язык, на котором формируется задание роботу, а также транслятор с него являются важнейшей частью программного обеспечения адаптивного робота. По мнению ряда авторов, основная задача разработки программного обеспечения — это создание высокоуровневых проблемно-ориентированных языков управления роботом.
 [c.21]

Проблемно-ориентированный язык управления —это в большей степени компонента программного обеспечения адаптивного робота, поскольку роботу 1-го поколения свойственна жесткая программа, сформулированная в виде последовательности точек позиционирования, которые робот должен обойти, чтобы выполнить задание. Для адаптивных роботов программа как фиксированный набор данных неприемлема, поскольку заранее (в тот момент, когда составляется программа) неизвестны многие данные, входящие в программу они
 [c.21]

В состав МС САПР входят процедурно-ориентированные языки (метаязыки) проектирования и управления процессом проектирования, языки описаний функций МС, т. е. распределения ресурсов САПР, формирования плановых заданий и другое, языки описания структуры данных и преобразования базы данных, программы, обеспечивающие реализацию функций МС, базы данных МС.
 [c.57]

Система диалогового ввода заданий JE предназначена для диалоговой подготовки пакетных заданий. Отличительной чертой данной системы является управление диалогом преимущественно с помощью меню и подсказок. Все обозначения запросов и их параметров задаются на русском языке. Такая форма общения обеспечивает быстрое обучение пользователей и простоту эксплуатации ДС. Однако система не имеет воз-
 [c.112]

Процедура — последовательность операторов языка управления заданиями, хранящаяся в специальной системной библиотеке (SYS1. PRO LIB), которую можно вызвать по имени и использовать в пункте задания, т. е. процедуры — зара ее сформированные из операторов ЯУЗ задания для наиболее часто встречающихся последовательностей вычислительных операций. Каждая такая процедура в зависимости от сложности задания включает и себя 5…20 операторов ЯУЗ, а вызвана может быть с помощью единственного оператора ЕХЕС. В результате сокращаются тексты пользовательских заданий и число совершенных ошибок.
 [c.126]

Язык управления заданиями содержит девять типов операторов задания (JOB), исполнительный (ЕХЕС), описания данных (DD), командный, разделительный, пустой, процедуры (PRO ), конца процедуры (PEND), комментариев. Эти операторы имеют соответствующие параметры, которые позволяют планировщику заданий регулировать выполнение заданий и пунктов заданий, отыскивать и размещать данные, распределять ресурсы ввода/вывода, а главному планировщику — осуществлять связь с оператором вычислительной системы.
 [c.367]

В системном программном обеспечении эбычно различают системы исполнения и системы подготовки программ. Пользователь ЭВМ имеет возможность с помо1дью этого математического обеспечения затребовать те или иные ресурсы ЭВМ необходимое адрес<ое поле, машинное время, периферийные устройства, режимы обслуживс ния своей задачи в рамках общей дасциплины обслуживания. Свои поло ения пользователь излагает на специальном входном языке — языке управления заданиями.
 [c.131]

Лингвистическое обеспечение САПР ОЭП призвано освободить проектанта от необходимости описывать модели объекта проектирования на алгоритмических языках и компоновать отдельные проблемные модули в единый программный продукт. >отя эту компоновку и осуществляет ЭВМ под управлением программы РЕДАКТОР, задание на эту работу с указанием характера компоновка проектант, как любой пользователь ЭВМ, должен записать на спепиагьном языке управления заданиями в операщюнной системе ЭВМ, который обладает слабой мнемоничностью и требует от пользователя хорошего знания всех особенностей состава ЭВМ. Составление программ на алгоритмическом языке и на языке управления заданиями, а главное — их отладка потребует от проектанта значительных временных затрат, которые приведут к появлению неоптимальной программы. Однако главное при этол( — проектант отвлекается от решения своей непосредственной задачи.
 [c.134]

Языки управления заданиями (ЯУЗ ОСЕС, Я УЗ ОС АРМ, Я УЗ ОС РВ и т.п.>
 [c.192]

Существенным элементом автоматизированного фонда является постоянно пополняющаяся библиотека каталогизированных процедур, написанных на языке управления заданиями ОС ЕС, которые обеспечат выполнение как простых заявок, требующих только поиска нужной информации и ее тиражирования, так и более сложных, связанных с получением новой информации путем обработки уже содержащейся в фоэде.
 [c.83]

Для управления пакетом обычно испо. 1ьзуются возможности языка управления заданиями операционной системы (ОС) ЭВМ.
 [c.11]

Целочисленная константа или переменная U определяет имя оператора DD языка управления заданиями, который определяет устройство вывода графических данных. Этот параметр может принимать значения от 01 до 99. Например, если задано U=15, то программа PLOTS находит оператор DD с именем FT15F001, определяет тип устройства, указанный в этом операторе, и настраивается на работу с этим устройством вывода. Если параметр U не задан или задан неверно, то его значение устанавливается равным 10. Имя оператора DD, определяющего тип устройства, всегда имеет вид
 [c.101]

СССД могут активно выполнять функции контроля при использовании метаданных (рис. 1.10) и при обработке данных (базы данных). Для работы всех программных комплексов, как прикладных, так и системных, необходимы метаданные, например, для работы СУБД. Метаданные СУБД могут принимать форму схемы или описания базы данных. В прикладные программы, написанные на Коболе, метаданные включаются в форме секций описаний файлов и (или) подсхемы. Средства системного программного обеспечения, например операционная система, воспринимают метаданные в виде конструкций языка управления заданиями. На практике, контролируя метаданные, можно управлять самими обрабатывающими программами.
 [c.31]

Применение активной СССД имеет определенные преимущества и с точки зрения управления заданиями в операционной системе. Такая СССД может генерировать метаданные для средств управления в форме операторов языка управления заданиями.
 [c.154]

Вызов каталогизированных процедур для запуска программ обеспечивается средствами языка управления заданиями ОС — чэператором ЕХЕС. Указывается имя каталогизированной процедуры запуска программы. Вызов процедур возможен с перфокарт или с пульта оператора.
 [c.45]

Комплексная САПР МЭА как сложная система имеет, таким образом, семиотическую (языковую) природу информационных связей между отдельными подсистемами, включая коллективы разработчиков и пользователей САПР. Качественное отличие комплексной САПР от программных систем и ППП заключается в том, что обмен информацией в ней происходит на семантическом уровне. В обычных программных системах и пакетах информационные связи осуществляются на синтаксическом уровне, например на уровне синтаксиса языка управления заданиями ОС ЕС.
 [c.53]

Язык управления монитором САПР достаточно прост, в его основе лежат команды вызова необходимых проектирующих подсистем ПО и задания им управляющих параметров, а также команды, описывающие способ информационного обмена между подсистемами — через оперативную или внешнюю память, посредством подсистемы управления базой данных. Средства этого языка должны позволять создавать макрокоманды, определяющие марщруты выполнения проектирующих подсистем ПО. Языки управления проектирующих пакетов значительно сложнее, поскольку должны отражать все возможн1>1е постановки задач проектирования в конкретных предметных областях, решение которых допускают пакеты. Обычно эти языки имеют процедурный характер (см. 5.3).
 [c.28]

Рабочая программа (обрабатывающая подсистема) комплекса ПА-6. Выполнение рабочей программы происходит под управлением монитора, в функции которого входят интерпретация псевдокоманд, отражающих операторы промежуточного языка описания задания, передача управления на диспетчеры, контролирующие вычисления по той или иной псевдокоманде, анализ кодов возврата, организация циклов псевдокоманд, ведение службы времени, установка контрольных точек и т. п.
 [c.144]

Модульная структура рабочей программы комплекса ПЛ-6 совпадает со структурой базового математического обеспечения, представленной на рис. 5.2. Однако в комплексе ПА-б группы модулей параметрическая оптимизация ОПТ, многовариантный анализ MBA, одновариантный анализ ОБА являются равноуровневыми и располагаются в отдельных перекрываемых сегментах оверлейной структуры рабочей программы. Связь между ними по управлению и информации осуществляется через монитор рабочей программы, как это показано на рис, 5.7, Поэтому подпрограммы, составляющие эти группы, должны быть повторновходимыми, это несколько усложняет их программирование, по зато, кроме значительной экономии ОП, дает возможность организации вложенных циклов операторов языка описания задания промежуточного языка комплекса ПА-б.
 [c.144]

Вторая группа языков — входные языки ППП. Это языки кодирования (описания) проектной документации при вводе в ЭВМ, языки директив управления процессом проектирования, языки взаимодействия с банком данных и т. д. Как правило, выделяется соответственно два подмножества языков языки описания объекта (ЯОО) и языки описания заданий (ЯОЗ). ЯОО обычно подразделяются на процедурные (алгоритмические) и непроцедурные, в том числе автоматные (схемные). Процедурные языки широко применяются в ЛО САПР, так как исходная информация обычно содержит алгоритм функционирования объекта. Процедурные языки близки к алгоритмическим языкам высокого уровня. Иепро-цедурные (автоматные) языки обычно описывают объект в виде отношений, например структуру объекта в схемотехническом проектировании, в конструкторском проектировании. ЯОЗ обычно также процедурные языки.
 [c.192]

Таким образом яолучено новое, ранее не заданное отношение, в котором можно по любому признаку найти необходимые элементы, т. е. можно проводить произвольный ассоциативный поиск. Например, ЗИП, используемые слесарями, типы аварии, рассмотренные в инструкции 3, и т. д. В реляционных моделях возможно получение отдельных фрагментов отношений, сравнение их, создание новых отношений и т. д. Определение операций над отношениями позволяет использовать в качестве языка управления данными язык, основанный на алгебре отношений, или язык, основанный на исчислении отношений. Использование этих языков позволяет сводить вопросы пользователей к операциям над отношениями и получать в результате выполненных действий новые отношения, удовлетворяющие требованиям пользователей. Эти языки обладают большой селективной силой и являются хорошим средством манипулирования данньгми.
 [c.156]

Так как язык описания заданий весьма сложен, чаще используют интерактивное диалоговое управление системой SPE TRA.
 [c.594]

Применение ЭВМ для расчета посадок рассмотрим на примере расчета посадок с натягом. Алгоритм расчета посадок с натягом (вычисления функциональных натягов Л шахр и Л тш f по методике, изложенной в подразд. 9.3) приведен на рис. 9.12. Программа расчета, реализующая этот алгоритм, составлена на алгоритмическом языке ФОРТРАН-IV. Для облегчения чтения программы в нее введены комментарии, помеченные в первой позиции буквой С. Строка с меткой С транслятором не обрабатывается, но ее содержимое выдается на печать при распечатке программы. Реализация расчета осуществляется иод управлением ОС ЭВМ ЕС. Чтобы операционная система могла выполнить заданную программу, ей необходимо сообщить задание , т. е. имя программы, имя библиотеки, содержащей эту программу, шифры устройств, на которых размещаются используемые в программе наборы данных и т. д. Полный
 [c.229]

Windows
—
интегрированная
программа.
Под управлением оболочки Windows
могут работать не только специальные
программы, разрабо­танные для
эксплуатации
в
среде
Windows
(Windows-приложения), но
и «обычные» программы, работающие
в среде
DOS, т.н.
DOS-приложения (DOS-прикладные
программы). Оболочка
Window
обеспечивает эффективный и комфортабельный
обмен информацией между отдельными
программами, выполняемыми под ее
управлением. Здесь речь в первую очередь
идет о
Windows-пpилoжeнияx.
С понятием
интегрированности связывают обычно
также возможность совместного
использования ресурсов компьютера
различными прог­раммами. Так, к примеру,
принтер, подключенный к компьютеру,
может с одинаковым успехом использоваться
всеми программами на конкурентной
основе. Причем все операции, связанные
с необходимостью перекодировок, смен
драйверов (например, при переходе от
печати текстов к выводу иллюстраций)
берет на себя оболочка.

Большинство
пользователей привлекает в среде
Windows не
только и не столько комфортабельность
самой оболочки, сколько специфика
ре­ализованных в этой среде приложений.
Особенности реализации в среде Windows
даже знакомых пользователям по работе
в
DOS прикладных
программ (приложений)
практически позволяют рассматривать
Windows-версии
этих программ как совершенно новые
продукты.

Работа в
o6oлочке
Windows
и в
Windows-приложениях
предполагает своеобразную перестройку
«образа жизни». «Жизнь»
пользователя в среде ‘Windows
сопряжена с «мышиным» управлением,
обменами данными между отдельными
программами и параллельным выполнением.
Стандартизация интерфейсов отдельных
Windows-приложений
позволяет легко переходить от одного
приложения к другому, не начиная каждый
раз с нуля (хотя бы в плане способов и
средств управления).

зафиксировать
курсор
кнопкой мыши
— и операция
выполняется. С помощью того же манипулятора
можно перемещать пиктограммы и окна
по экрану, менять их размер, открывать
и закрывать их
— и все
это при минимальном использовании
клавиатуры для ввода каких бы то ни
было директив. Кроме того, для любителей
традиционного интерфейса
DOS реализована
возможность выхода на этот уровень.
При разработке графического интерфейса
Windows не
последнюю роль играли и эргономические
соображения: учтены требования к
цветовой гамме, сочетаниям цветов,
шрифтам, формам и размерам пиктограмм
и окон. По сравнению с некоторыми другими
пакетами внешнее оформление оболочки
Windows может
быть признано «спар­танским»
вследствие отсутствия излишеств и за
деловой стиль. Понятие
«графически-ориентированный»
включает в себя для
Win­dows
также и соответствие изображения на
экране последующему изображению на
твердой копии (распечатке). В этом плане
можно считать, что в оболочке
Windows
реализован принцип
WYSIWYG (
What
Yon See Is What You Get
=
To, что Вы
видите, то и получаете), до сих нор бывший
привилегией относительно небольшого
числа программ- С помощью
TrueType-шрифтов
этот принцип нашел в рамках
Windows
3.1 свое
дальнейшее развитие.

Windows
обеспечивает независимый
запуск и
параллельное
выпол­нение нескольких программ.
Большинство других оболочек и операционных

В фирменной поставке
пакета Windows
находится несколько при­ложений. Все
они объединены в группу
Accessories
(аксессуары, инстру­менты). Это небольшие
по размеру и возможностям прикладные
програм­мы, составляющие «джентльменский
набор» пользователя. Им далеко до
профессиональных специализированных
пакетов. Но они прекрасно ил­люстрируют
возможности оболочки и обеспечивают
некоторый мини­мальный сервис. Более
того, весьма полезно начинать знакомство
с серь­езными пакетами именно с
соответствующих средств этой группы.
Так, например, поработав некоторое время
с текстовым редактором
Write,
в дальнейшем можно легко перейти к
использованию таких профессиональ-ных
пакетов обработки текстов, как
Word
для Windows, Lotus
Ami Professional, WordPerfect для
Windows’ т.п.
Кроме того, в приложениях из группы
Accessories
реализованы многие новинки, характерные
именно для последней версии
3.1 оболочки
Windows (работа с объектами,
новые шрифты…).

Windows
95

Объектно-ориентированный
подход

При создании
Windows
95 фирма
Microsoft в
полной мере реализо­вала
объектно-ориентированный подход.
Поскольку именно он лег в основу новой
операционной системы, вначале скажем
несколько слов о том, что такое ориентация
на объекты.

Понятие
«объектно-ориентированный» возникло
в программиро­вании сравнительно
недавно. Когда вычислительная мощность
ма­шин была невысока, о создании
объектно-ориентированных сис­тем не
могло быть и речи. Основой всего был
программный код. Программисты записывали
последовательности команд для выпол­нения
тех или иных действий над данными,
которые оформлялись в модули и процедуры.
Для работы с каждым объектом создавалась
своя процедура.

Объекты,
их свойства и
методы

Постепенно с
увеличением производительности
вычислительных систем процедурный
подход начал заменяться объектным. На
пер­вое место выдвинулся объект, а не
код, который его обрабатывает. На уровне
пользователя объектный подход выражается
в том, что интерфейс представляет собой
подобие реального мира, а работа с
машиной сводится к действиям с привычными
объектами. Так, пап­ки можно открыть,
убрать в портфель, документы
— просмотреть,
исправить, переложить с одного места
на другое, выбросить в корзину, факс или
письмо
— отправить
адресату и т. д. Понятие объекта оказалось
настолько широким, что до сих пор не
получило строгого определения.

Объект, как и в
реальном мире, обладает различными
свойствами. Программист или пользователь
может изменять не все свойства объектов,
а только некоторые из них. Можно изменить
имя объек­та, но нельзя изменить объем
свободного места на диске, который также
является его свойством. Свойства первого
типа в языках про­граммирования носят
название
read/write (для
чтения и записи), а свойства второго
—
read only
(только для чтения).

Метод
— это
способ воздействия на объект. Методы
позволяют со­здавать и удалять объекты,
а также изменять их свойства. Напри­мер,
для того чтобы нарисовать на экране
точку, линию или плоскую фигуру,
составляются разные последовательности
кодов или програм­мы. Пользователь,
однако, применяет для отображения этих
объек­тов один метод
Draw(
), который
содержит коды для отображения всех
объектов, с которыми он работает. За
такое удобство приходится пла­тить
тем, что объектно-ориентированные
системы могут работать только на
достаточно мощных вычислительных
установках.

Процедурный подход
в ранних ОС

До настоящего
времени во всех операционных системах
преобла­дал процедурный подход. Для
того чтобы произвести в системе
ка­кое-либо действие, пользователь
должен был вызвать соответству­ющую
программу (процедуру) и передать ей
определенные пара­метры, например,
имя обрабатываемого файла. Программа
выпол­няла над файлом указанные
действия и заканчивала работу. При этом
пользователь в первую очередь имел дело
с задачей обработки документа, а затем
уже с самим документом. В давние времена,
когда ЭВМ не были персональными,
пользователь описывал дейст­вия,
которые должна была выполнить задача,
на некоем странном языке, называемом
языком управления заданиями
(JCL—Job
Con­trol Language).

С появлением
терминала язык управления заданиями
упростился и постепенно превратился в
командную строку, однако на первом месте
все равно находилась процедура обработки
документа, а сам документ играл
вспомогательную роль.

Следующим этапом
упрощения работы с машиной стал создание
различного рода операционных оболочек
(сначала текстовых),которые «спрятали»
от пользователя командную строку
DOS. Ввод
последовательности символов, из которой
состоит команда опера­ционной системы,
свелся к нажатию одной функциональной
кла­виши или щелчку мыши. Самой
распространенной из таких «надстро­ек»
над операционной системой стала оболочка
Norton Commander,

Однако основным
«инструментом» пользователя все еще
оставалась клавиатура. Качественный
переход произошел после того, как
поя­вились графические оболочки.
Теперь пользователь в основном ра­ботает
с устройством указания, таким как мышь,
трекбол или план­шет, а не с клавиатурой
(разумеется, это не относится к работе
внут­ри самих приложений, например,
в текстовых редакторах). Ему не нужно
помнить почти никаких команд операционной
системы. Для того чтобы запустить
приложение, достаточно щелкнуть мышью
на его изображении или на «значке»
(автор предпочитает называть его
пиктограммой).

От
процедурного подхода к объектно-ориентированному

В начале 90-х гг.
процедурный подход все еще преобладает,
однако намечаются и некоторые признаки
объектно-ориентированного. Например,
уже в
Windows 3+ можно
поставить в соответствие кон­кретному
документу приложение для его обработки.
Тогда же поя­вился метод объектного
связывания и встраивания
(OLE),
позволя­ющий щелчком на изображении
объекта неявно запустить прило­жение,
которое его обрабатывает, а после
окончания обработки вернуться в
предыдущее приложение.

С
OLE тесно
связан так называемый метод редактирования
доку­ментов «на месте»
(in-place). Если
в документ встроен объект, ко­торый
должен обрабатываться конкретным
приложением, то при щелчке на этом
объекте нужное приложение неявным
образом за­пускается, причем в рабочем
поле не изменяется ничего, кроме па­нелей
инструментов. Например, если в тексте,
который обрабаты­вается в редакторе
Microsoft Word,
есть таблица, созданная в редакторе
Microsoft Excel,
то при щелчке на ней произойдет замена
nанелей
инструментов
Excel.
Пользователь может обрабатывать документ
совсем другим приложе­нием, даже не
подозревая об этом,

Еще один механизм,
который упростил работу и приблизил
эру объ­ектно-ориентированного
подхода, называется
«Drag
&
Drop», что в
буквальном переводе означает
«перетащить-и-оставить». Работая этим
методом, вы щелкаете кнопкой мыши (как
правило, левой) на изображении объекта,
перемещаете его по экрану при нажатой
кнопке и отпускаете кнопку, когда
указатель окажется в нужном месте
экрана. Таким образом, процедуры
копирования, перемеще­ния и удаления
стали объектно-ориентированными.

Что делал
пользователь, когда ему нужно было
удалить файлы
в
опе­рационной
системе
MS-DOS? Он
запускал процедуру удаления фай­лов,
передавая их имена в качестве параметров:

del
FILEI.TXT FILE2TXT

Это действие ничем
не напоминает реальный мир, в котором
вы просто выбрасываете ненужные

Бумаги в мусорную
корзину. На первом месте для пас стоит
объект (бумага), над которым выполня­ется
процедуры (переноса в мусорную корзину),
R операционных
оболочках, которые работают под
управлением
Windows
3.1,
такое действие уже реализовано как
объектное-ориентированное
— с по­мощью
механизма
«Draw
&
Drop».
Например, в оболочке
Norton Desktop
можно схватить мышью файл и перенести
его на изобра­жение мусорной корзины.
Этого достаточно для удаления файла.
Так работа на персональном компьютере
все больше напоминает манипуляции с
объектами в реальном мире.

Выбор
показателей и параметров для оценке ОС

Windows
95 —
объектно-ориентированная ОС

Windows
95—полноценная
операционная система

Использование
стандарта
Plug
&
Play

Язык управления заданиями ( JCL ) — это название языков сценариев, используемых в операционных системах мэйнфреймов IBM для указания системе, как запустить пакетное задание или запустить подсистему. ^[1]

Более конкретно, цель JCL — указать, какие программы запускать, какие файлы или устройства ^{[2] использовать} для ввода или вывода, а иногда также указывать, при каких условиях нужно пропустить шаг.

Существует два разных языка IBM Job Control:

• один для линейки операционных систем, которая начинается с DOS / 360 и последним членом которой является z / VSE ; а также
• другие для линии от OS / 360 к г / OS , последние в настоящее время в том числе JES расширений, работа вход управление Language (JECL) .

У них есть общие правила синтаксиса и несколько основных концепций, но в остальном они очень разные. ^[3] операционная система ВМ не JCL как таковой; в CP и CMS компоненты каждого есть языки команд .

Терминология

Некоторые слова или фразы, используемые в связи с JCL, относятся к технологии мэйнфреймов IBM.

• Набор данных: «набор данных» — это файл; он может быть временным или постоянным и находиться на жестком диске, ленточном накопителе или другом устройстве. ^{[4] [5]}
• Член: «член» секционированного набора данных (PDS) — это отдельный набор данных в PDS. Доступ к члену можно получить, указав имя PDS с именем члена в круглых скобках. Например, системный макрос GETMAIN в SYS1.MACLIB может упоминаться как SYS1.MACLIB (GETMAIN). ^[6]
• Многораздельный набор данных: «многораздельный набор данных» или PDS — это набор элементов или архив, обычно используемый для представления системных библиотек. Как и в случае с большинством таких структур, член, однажды сохраненный, не может быть обновлен; член необходимо удалить и заменить, например, с помощью служебной программы IEBUPDTE . ^[6] Разделенные наборы данных примерно аналогичны статическим библиотекам на основе ar в системах на основе Unix.
• USS: системные службы Unix, подсистема Unix, работающая как часть MVS и позволяющая запускать файлы, сценарии, задачи и программы Unix на мэйнфрейме в среде UNIX.

Мотивация

Первоначально системы мэйнфреймов были ориентированы на пакетную обработку . Многие пакетные задания требуют настройки с особыми требованиями к основному хранилищу и выделенным устройствам, таким как магнитные ленты , частные тома дисков и принтеры, настроенным с использованием специальных форм. ^[7] JCL был разработан как средство обеспечения доступности всех необходимых ресурсов до того, как задание будет запланировано для выполнения. Например, многие системы, такие как Linux, позволяют указывать необходимые наборы данных в командной строке и, следовательно, заменять их оболочкой или генерировать программой во время выполнения. В этих системах планировщик заданий операционной системы мало или совсем не понимает требований работы. Напротив, JCL явно определяет все необходимые наборы данных и устройства. Планировщик может предварительно выделить ресурсы перед запуском задания. Это помогает избежать « взаимоблокировки », когда задание A удерживает ресурс R1 и запрашивает ресурс R2, в то время как одновременно выполняющееся задание B удерживает ресурс R2 и запрашивает R1. В таких случаях единственное решение для оператора компьютера — прекратить одно из заданий, которое затем необходимо перезапустить. При управлении заданием, если задание A запланировано для запуска, задание B не будет запущено, пока задание A не завершит или не освободит необходимые ресурсы.

Функции, общие для DOS и OS JCL

Работа, шаги и процедуры

И для DOS, и для ОС единица работы — это работа . Задание состоит из одного или нескольких шагов, каждый из которых является запросом на запуск одной конкретной программы. Например, до появления реляционных баз данных задание по созданию печатного отчета для управления могло состоять из следующих шагов: написанная пользователем программа для выбора соответствующих записей и их копирования во временный файл; отсортируйте временный файл в нужном порядке, обычно используя универсальную утилиту; написанная пользователем программа для представления информации в виде, удобном для чтения конечными пользователями, и включает другую полезную информацию, такую ​​как промежуточные итоги; и написанная пользователем программа для форматирования выбранных страниц информации о конечном пользователе для отображения на мониторе или терминале.

И в DOS, и в OS JCL первой «картой» должна быть карта JOB, которая: ^[8]

• Определяет работу.
• Обычно предоставляет информацию, позволяющую отделу компьютерных услуг выставить счет соответствующему отделу пользователей.
• Определяет, как должно выполняться задание в целом, например, его приоритет относительно других заданий в очереди.

Процедуры (обычно называемые проки ) предварительно написаны JCL для шагов или групп шагов, вставляются в работу. Оба JCL допускают такие процедуры. Процедуры используются для повторения шагов, которые используются несколько раз в одном задании или в нескольких разных заданиях. Они экономят время программиста и снижают риск ошибок. Чтобы запустить процедуру, нужно просто включить в файл JCL одну «карточку», которая копирует процедуру из указанного файла и вставляет ее в поток заданий. Кроме того, procs может включать параметры для настройки процедуры для каждого использования.

Базовый синтаксис

И DOS, и OS JCL имеют максимальную полезную длину строки 80 символов, потому что, когда DOS / 360 и OS / 360 были впервые использованы, основным методом предоставления нового ввода в компьютерную систему были перфокарты с 80 столбцами . ^[9] Позже стало возможно отправлять задания через файлы на диске или на магнитной ленте с большей длиной записи, но компоненты отправки заданий операционной системы игнорировали все, что находится после символа 80.

Строго говоря, оба семейства операционных систем используют только 71 символ в строке. Символы 73-80 обычно представляют собой порядковые номера карт, которые система печатает в отчете об окончании работы и полезны для определения местоположения любых ошибок, о которых сообщает операционная система. Символ 72 обычно остается пустым, но он может содержать непустой символ, чтобы указать, что оператор JCL продолжается на следующей карточке.

Все команды, имена параметров и значения должны быть заглавными, за исключением имен файлов USS .

Все строки, кроме входящего потока (см. Ниже), должны начинаться с косой черты » /«, а все строки, которые обрабатываются операционной системой, должны начинаться с двух косых черт //— всегда начиная с первого столбца . Однако есть два исключения: оператор-разделитель и оператор комментария. Операторы-разделители начинаются с косой черты и звездочки ( /*), а оператор комментария в OS JCL начинается с пары косых черт и звездочки ( //*) или звездочки в DOS JCL.

Многие операторы JCL слишком длинные, чтобы уместиться в 71 символ, но их можно расширить до неопределенного числа карточек продолжения:

Структура наиболее распространенных типов карт следующая: ^[10]

Ввод In-Stream

И DOS, и OS JCL позволяют ввод в потоке, то есть «карты», которые должны обрабатываться прикладной программой, а не операционной системой. Данные, которые должны храниться в течение длительного времени, обычно хранятся на диске, но до того, как использование интерактивных терминалов стало обычным явлением, единственным способом создания и редактирования таких файлов на диске было размещение новых данных на карточках.

DOS и OS JCL имеют разные способы сигнализации о начале ввода в потоке, но оба заканчивают ввод в потоке с помощью /*столбца 1 карты, следующего за последней картой данных в потоке. Это заставляет операционную систему возобновлять обработку JCL на карте, следующей за /*картой. ^[11]

• OS JCL: операторы DD могут использоваться для описания данных в потоке, а также наборов данных. Оператор DD, имеющий дело с данными в потоке, имеет звездочку (*) после идентификатора DD, например //SYSIN DD *. Операторы JCL могут быть включены как часть данных в потоке с помощью операторов DD DATA.

Операнд с именем DLM позволяет указывать разделитель (по умолчанию «/ *»). Указание альтернативного разделителя позволяет читать JCL как данные, например, для копирования процедур в член библиотеки или для отправки задания внутреннему считывателю .

• Пример ^[12], который отправляет задание внутреннему устройству чтения ( INTRDR ):

// SUBM EXEC PGM = IEBGENER // SYSPRINT ДД    SYSOUT = Z // SYSUT2    ДД    SYSOUT = ( , INTRDR ) // SYSIN     ДД    МАНЕКЕН // SYSUT1    ДД    ДАННЫЕ , ДАЯ = ZZ // RUNLATR РАБОТА АССТ , Manix , КЛАСС = . TYPRUN = HOLD // * ^ ЗАДАНИЕ, которое нужно запустить позже      




    

// CPUHOG EXEC PGM = PICALC1K    
// ВЫВОД    DD    DSN = PICALC .1000 DGTS , SPACE = ( TRK , 1 ), DISP = (, KEEP ) 
ZZ 
// * ^ как указано в DLM = ZZ
// DROPOLDR EXEC PGM = IEFBR14  
// УДАЛИТЬ4   DD    DSN = PICALC .4 DGTS , DISP = ( СТАРЫЙ , УДАЛИТЬ )
// УДАЛИТЬ5   DD    DSN = PICALC .5 DGTS , DISP = ( СТАРЫЙ , УДАЛИТЬ )

1. Программа под названием PICALC1K будет ждать (TYPRUN = HOLD) ручного освобождения.
2. Два файла, PICALC.4DGTS и PICALC.5DGTS, будут удалены СЕЙЧАС.

• DOS JCL: просто введите данные в потоке после карты EXEC для программы.

Сложность

Большая часть сложности OS JCL, в частности, проистекает из большого количества опций для указания информации набора данных. В то время как файлы в Unix- подобных операционных системах абстрагируются в произвольные наборы байтов, при этом детали обрабатываются в значительной степени операционной системой, наборы данных в OS / 360 и ее преемниках раскрывают свои типы и размеры файлов, типы и длину записей, размеры блоков. , информация об устройстве, например, на магнитной ленте.плотность и информация на этикетке. Хотя для многих параметров существуют системные значения по умолчанию, программисту еще многое предстоит указать с помощью комбинации JCL и информации, закодированной в программе. Чем больше информации закодировано в программе, тем она менее гибкая, поскольку информация в программе перекрывает все, что есть в JCL; таким образом, большая часть информации обычно предоставляется через JCL.

Например, чтобы скопировать файл в операционной системе Unix , пользователь должен ввести такую ​​команду:

cp oldFile newFile

Следующий пример с использованием JCL можно использовать для копирования файла в OS / 360:

// IS198CPY JOB ( IS198T30500 ), 'COPY JOB' , CLASS = L , MSGCLASS = X // COPY01 EXEC PGM = IEBGENER  
    
// SYSPRINT DD SYSOUT = *
// SYSUT1    DD DSN = OLDFILE , DISP = SHR 
// SYSUT2    DD DSN = NEWFILE , 
// DISP = ( NEW , CATLG , DELETE ), // SPACE = ( CYL , ( 40 , 5 ), RLSE ), // DCB = ( LRECL = 115 , BLKSIZE = 1150 ) // SYSIN   DD            
            
            
ДУРАЧОК

Второе объяснение сложности JCL заключается в том, что ожидания выполнения задания отличаются от ожиданий на ПК или в Unix-подобной среде.

• Младшие процессоры System / 360 были менее мощными и более дорогими, чем ПК середины 1980-х годов, для которых была разработана MS-DOS. OS / 360 была предназначена для систем с минимальным объемом памяти 32 КБ, а DOS / 360 — для систем с минимальным объемом памяти 16 КБ. 360/30 ЦП низкого уровня , когда система / 360 было объявлено в 1964-обработке 1.8K к 34.5K команд в секунду. ^[13] Первый IBM PC в 1981 году имел 16 КБ или 64 КБ памяти и мог обрабатывать около 330К инструкций в секунду. ^{[14] [15]} В результате, JCL должен быть легким для компьютера в процессе, и простота использования программистами был гораздо более низким приоритетом. В то время программисты были намного дешевле компьютеров.
• JCL был разработан для пакетной обработки . Таким образом, он должен сообщать операционной системе все, в том числе, что делать в зависимости от результата шага. Например, DISP=(NEW,CATLG,DELETE)означает «если программа работает успешно, создайте новый файл и внесите его в каталог; в противном случае удалите новый файл». Программы, запускаемые на ПК, часто зависят от того, что пользователь решит после проблем с обработкой.
• Машины System / 360 были разработаны для совместного использования всеми пользователями в организации. Таким образом, JOBкарта сообщает операционной системе, как выставлять счет для учетной записи пользователя ( IS198T30500), какой предопределенный объем хранилища и других ресурсов может быть выделен ( CLASS=L) и некоторые другие вещи. //SYSPRINT DD SYSOUT=*указывает компьютеру распечатать отчет программы на принтере по умолчанию, в который загружена обычная бумага, а не на каком-либо другом принтере, который может быть загружен с пустыми чеками. DISP=SHRсообщает операционной системе, что другие программы могут читать OLDFILE одновременно .

Более поздние версии операционных систем DOS / 360 и OS / 360 сохраняют большинство функций исходного JCL, хотя были сделаны некоторые упрощения, чтобы не заставлять клиентов переписывать все свои файлы JCL. ^{[ необходима цитата ]} Многие пользователи сохраняют в качестве процедуры любой набор операторов JCL, который, вероятно, будет использоваться более одного или двух раз. ^[16]

Синтаксис OS JCL аналогичен синтаксису макросов на языке ассемблера System / 360 и поэтому был бы знаком программистам в то время, когда многие программы были написаны на языке ассемблера.

DOS JCL

Позиционные параметры

// TLBL TAPEFIL, 'COPYTAPE.JOB' ,,,, 2 // ASSGN SYS005,200 // ДБККЛ DISKFIL, 'COPYTAPE.JOB', 0, SD // ОБЪЕМ SYS005, VOL01,1,0,800,1600 
 
 
 

Параметры DOS JCL являются позиционными, что затрудняет их чтение и запись, но упрощает анализ системы.

• Программист должен помнить, какой элемент в какой позиции находится в каждом типе оператора.
• Если некоторые необязательные параметры опущены, но включены более поздние, пропущенные параметры должны быть представлены запятыми без пробелов, как в заявлении TLBL выше.

DOS JCL в некоторой степени смягчает трудности позиционных параметров за счет использования большего количества операторов с меньшим количеством параметров, чем OS JCL. В этом примере операторы ASSGN, DLBL и EXTENT выполняют ту же работу (указывая, где должен быть сохранен новый файл на диске), что и один DDоператор в OS JCL.

Зависимость от устройства

В исходной DOS / 360 и в большинстве версий DOS / VS нужно было указать номер модели устройства, которое должно было использоваться для каждого диска или файла на магнитной ленте, даже для существующих файлов и для временных файлов, которые будут удалены при конец работы. Это означало, что, если заказчик переходил на более современное оборудование, многие файлы JCL приходилось изменять.

Позднее члены семейства DOS / 360 сократили количество ситуаций, в которых требовались номера моделей устройств.

Размещение файлов вручную

DOS / 360 изначально требовал, чтобы программист указывал расположение и размер всех файлов на DASD . В EXTENTкарты указывает на объем которой степень проживает, исходный абсолютный дорожки, и количество дорожек. Для z / VSE файл может иметь до 256 экстентов на разных томах.

OS JCL

OS JCL состоит из трех основных типов операторов: ^[17]

• JOB оператор, который определяет начало задания, а также информацию обо всем задании, такую ​​как выставление счетов, приоритет выполнения, а также ограничения по времени и пространству.
• EXECутверждение, которое идентифицирует программу или процедуру ^[18] , которые будут выполняться на этом этапе работы,
  а также информации о шаге, в том числе COND itions для бега или пропуская шаг.
• DDОператоры (Определение данных), которые идентифицируют файл данных, который будет использоваться на шаге, и подробную информацию об этом файле. DDинструкции могут быть в любом порядке в пределах шага.

С самого начала JCL для семейства ОС (включая z / OS ) был более гибким и простым в использовании.

В следующих примерах используется старый стиль синтаксиса, который был предоставлен с момента запуска System / 360 в 1964 году. Старый синтаксис все еще довольно распространен в заданиях, которые выполнялись десятилетиями, с незначительными изменениями.

Правила кодирования заявлений JCL

Каждое заявление JCL разделено на пять полей: ^[19]

 Идентификатор-Имя поля-Операция-Поле Параметр-Поле Комментарии-Поле
                 ^ ^ ^ ^
              нет космоса космоса космоса

Поле идентификатора должно быть объединено с полем имени , т.е. между ними не должно быть пробелов.

• Поле идентификатора ( //): поле идентификатора указывает системе, что оператор является оператором JCL, а не данными. Поле идентификатора состоит из следующего:
  
  • Столбцы 1 и 2 всех операторов JCL, кроме оператора-разделителя, содержат //
  • Столбцы 1 и 2 оператора-разделителя содержат /*
  • Столбцы 1, 2 и 3 комментария JCL содержат //*
• Поле имени : поле имени идентифицирует конкретный оператор, чтобы другие операторы и система могли ссылаться на него. Для операторов JCL он должен быть закодирован следующим образом:
  
  • Имя должно начинаться в столбце 3.
  • Имя 1 до 8 буквенно — цифровых или национальных ( $, #, @) символов.
  • Первый символ должен быть буквенным.
  • После имени должен быть хотя бы один пробел.
• Поле операции: поле операции определяет тип оператора или, для оператора команды, команду. Поле операции должно быть закодировано следующим образом:
  
  • Поле операции состоит из символов в поле синтаксиса оператора.
  • Операция следует за полем имени.
  • Перед операцией должен быть хотя бы один пробел.
  • Операция будет одной из JOB, EXECи DD.
• Поле параметра: поле параметра, также иногда называемое полем операнда, содержит параметры, разделенные запятыми. Поле параметра должно быть закодировано следующим образом:
  
  • Поле параметра следует за полем операции.
  • Перед полем параметра должен быть хотя бы один пробел.
  • Поле параметра содержит параметры, которые являются ключевыми словами, которые используются в операторе для предоставления такой информации, как имя программы или набора данных.
• Поле комментариев : содержит комментарии . Поле комментариев должно быть закодировано следующим образом:
  
  • Поле комментариев следует за полем параметра.
  • Перед полем комментариев должен быть хотя бы один пробел.

Параметры ключевого слова

// NEWFILE DD DSN = MYFILE01 , UNIT = DISK , SPACE = ( TRK , 80 , 10 ), 
// DCB = ( LRECL = 100 , BLKSIZE = 1000 ), // DISP = ( NEW , CATLG , DELETE )           
           

Все основные параметры операторов JCL ОС идентифицируются ключевыми словами и могут быть представлены в любом порядке. Некоторые из них содержат два или более субпараметра, например SPACE(сколько дискового пространства выделить для нового файла) и DCB(подробная спецификация структуры файла) в приведенном выше примере. Подпараметры иногда позиционны, как в SPACE, но самые сложные параметры, такие как DCB, имеют подпараметры ключевых слов.

Позиционный параметр должен предшествовать параметрам ключевого слова. Параметры ключевого слова всегда присваивают значения ключевому слову с помощью знака равенства ( =). ^[20]

Доступ к данным (инструкция DD)

DDОператор используется для справочных данных. Этот оператор связывает внутреннее описание набора данных в программе с данными на внешних устройствах: дисках, магнитных лентах, картах, принтерах и т. Д. DD может предоставлять такую ​​информацию, как тип устройства (например, «181», «2400-5», » TAPE ‘), серийный номер тома для лент или дисков и описание файла данных, называемого DCBсубпараметром после блока управления данными (DCB) в программе, используемой для идентификации файла.

Информация, описывающая файл, может поступать из трех источников: информация о карте DD, информация о метке набора данных для существующего файла, хранящегося на ленте или диске, и макрос DCB, закодированный в программе. Когда файл открывается, эти данные объединяются, причем информация DD имеет приоритет над информацией о метке, а информация DCB имеет приоритет над обоими. Затем обновленное описание записывается обратно в метку набора данных. Это может привести к непредвиденным последствиям, если будет предоставлена ​​неверная информация DCB. ^[21]

Из-за перечисленных выше параметров и конкретной информации для различных методов доступа и устройств оператор DD является наиболее сложным оператором JCL. В одном справочном руководстве IBM описание оператора DD занимает более 130 страниц — более чем в два раза больше, чем операторы JOB и EXEC вместе взятые. ^[22]

Независимость от устройства

С самого начала JCL для семейства операционных систем OS предлагал высокую степень независимости устройства. Даже для новых файлов , которые должны были быть сохранены после завершения задания можно указать тип устройства в общих терминах, например, UNIT=DISK, UNIT=TAPEили UNIT=SYSSQ(лента или диск). Конечно, если это имело значение, можно было указать номер модели или даже адрес конкретного устройства. ^[23]

Процедуры

Процедуры позволяют сгруппировать один или несколько операторов « EXEC PGM = » и DD, а затем вызвать их с помощью « EXEC PROC = procname» или просто «EXEC procname» ^[24]

Средство, называемое библиотекой процедур, позволяет предварительно сохранять процедуры.

PROC & PEND

Процедуры также могут быть включены в поток заданий, завершив процедуру с помощью // PENDоператора, а затем вызвав его по имени, как если бы он находился в библиотеке процедур.

Например:

// SUMPRINT PROC
// ПЕЧАТЬ EXEC PGM = IEBGENER // SYSUT1    DD    DSN = CEO . ФАЙЛЫ . ДЕНЬ . RPT24A , DISP = SHR // SYSUT2    DD    SYSOUT = // SYSIN     DD    DUMMY    



// PEND         
// EXEC SUMPRINT  

Параметризованные процедуры

Процедуры OS JCL были параметризованы с самого начала, что делало их скорее похожими на макросы или даже простые подпрограммы и, таким образом, увеличивало возможность их повторного использования в широком диапазоне ситуаций. ^[25]

// MYPROC PROC FNAME = MYFILE01 , SPTYPE = TRK , SPINIT = 50 , SPEXT = 10 , LR = 100 , BLK = 1000 
..... 
// NEWFILE DD DSN = & FNAME , UNIT = DISK , SPACE = ( & SPTYPE , & SPINIT , & SPEXT ), 
// DCB = (           LRECL = & LR , BLKSIZE = & BLK ), DISP = ( NEW , CATLG , DELETE ) 
....

В этом примере все значения, начинающиеся с амперсандов » &«, являются параметрами, которые будут указаны, когда задание запрашивает использование процедуры. Оператор PROC, помимо присвоения имени процедуре, позволяет программисту указать значения по умолчанию для каждого параметра. Таким образом, можно использовать одну процедуру в этом примере для создания новых файлов разных размеров и макетов. Например:

// JOB01 JOB .......... // STEP01 EXEC MYPROC FNAME = JOESFILE, SPTYPE = CYL, SPINIT = 10, SPEXT = 2, LR = 100, BLK = 2000 или // JOB02 JOB ... ....... // STEP01 EXEC MYPROC FNAME = SUESFILE, SPTYPE = TRK, SPINIT = 500, SPEXT = 100, LR = 100, BLK = 5000   
   

   
   

Ссылки

В многоэтапных заданиях на более позднем этапе может использоваться обратная ссылка вместо полного указания файла, который уже был указан на более раннем этапе. Например:

// MYPROC ................ // MYPR01 EXEC PGM = .......... // NEWFILE DD DSN = & MYFILE , UNIT = DISK , SPACE = ( TRK , 50 , 10 ), // DCB = ( LRECL = 100 , BLKSIZE = 1000 ), DISP = ( NEW , CATLG , DELETE ) .... // MYPR02 
  

           

 EXEC PGM = .......... // INPUT01 DD DSN = * . MYPR01 . НОВЫЙ ФАЙЛ 

Здесь MYPR02используется файл, указанный NEWFILEв шаге MYPR01( DSNозначает «имя набора данных» и указывает имя файла; DSN не может превышать 44 символа ^[26] ).

В заданиях, которые содержат смесь JCL для конкретного задания и вызовов процедур, шаг для конкретного задания может ссылаться на файл, который был полностью указан в процедуре, например:

// MYJOB JOB .......... // STEP01 EXEC MYPROC Использование процедуры // STEP02 EXEC PGM = ......... Шаг, специфичный для этого задания // INPUT01 DD DSN = * . ШАГ01 . MYPR01 . НОВЫЙ ФАЙЛ  
               
        

где DSN=*.STEP01.MYPR01.NEWFILEозначает «использовать файл, указанный NEWFILEна шаге MYPR01процедуры, использованной на шаге STEP01этого задания». Использование имени шага, который вызвал процедуру, а не имени процедуры, позволяет программисту использовать одну и ту же процедуру несколько раз в одном и том же задании, не беспокоясь о том, какой экземпляр процедуры используется в ссылке.

Файлы JCL могут быть длинными и сложными, а язык непросто читать. OS JCL позволяет программистам включать два типа пояснительных комментариев:

• В той же строке, что и оператор JCL. Их можно расширить, поместив символ продолжения (обычно « X») в столбец 72, за которым следует « // » в столбцах 1–3 следующей строки.
• Строки, содержащие только комментарии, часто используются для объяснения основных моментов общей структуры JCL, а не местных деталей. Строки, содержащие только комментарии, также используются для разделения длинных сложных файлов JCL на разделы.

// MYJOB JOB .......... // * Строки, содержащие только комментарии. // ******** Часто используется для разделения листинга JCL на разделы ******** // STEP01 EXEC MYPROC Комментарий 2 в той же строке, что и оператор // STEP02 EXEC PGM = ...... ... Комментарий 3 был расширен и X // перетекает в другую строку. // INPUT01 DD DSN = STEP01 . MYPR01 . НОВЫЙ ФАЙЛ  


               
        
          

Объединение входных файлов

OS JCL позволяет программистам объединять («цеплять») входные файлы, чтобы они отображались в программе как один файл, например

// INPUT01 DD DSN = MYFILE01 , DISP = SHR 
// DD DSN = JOESFILE, DISP = SHR // DD DSN = SUESFILE, DISP = SHR         
         

Второй и третий операторы не имеют значения в поле имени, поэтому ОС обрабатывает их как конкатенации. Файлы должны быть одного базового типа (почти всегда последовательные) и иметь одинаковую длину записи, однако длина блока не обязательно должна быть одинаковой.

В ранних версиях ОС (конечно, до OS / 360 R21.8) длина блока должна быть в порядке убывания, или пользователь должен проверить каждый экземпляр и добавить к названному оператору DD найденную максимальную длину блока, как, например, ,

// INPUT01 DD DSN = MYFILE01 , DISP = SHR , BLKSIZE = 800 
// DD DSN = JOESFILE, DISP = SHR (предполагается, что BLKSIZE равно или меньше 800) // DD DSN = SUESFILE, DISP = SHR (предполагается BLKSIZE быть равным или менее 800)         
         

В более поздних версиях ОС (обязательно после OS / MVS R3.7 с соответствующими «выбираемыми единицами») сама ОС во время выделения будет проверять каждый экземпляр в конкатенации и подставлять максимальную длину найденного блока.

Обычным откатом было просто определить максимально возможную длину блока на устройстве и указать это в названном операторе DD, как, например, в

// INPUT01 DD DSN = MYFILE01 , DISP = SHR , BLKSIZE = 8000 
// DD DSN = JOESFILE, DISP = SHR (BLKSIZE предполагается равным или меньшим 8000) // DD DSN = SUESFILE, DISP = SHR (предполагается BLKSIZE быть равным или меньше 8000)         
         

Цель этого запасного варианта состояла в том, чтобы гарантировать, что метод доступа выделит набор входных буферов, который был достаточно большим для размещения любого и всех указанных наборов данных.

Условная обработка

ОС ожидает, что программы установят код возврата, который указывает, насколько успешной была программа . Наиболее распространенные условные значения: ^{[27] : стр.87}

• 0 = Нормально — все ОК
• 4 = Предупреждение — незначительные ошибки или проблемы
• 8 = Ошибка — существенные ошибки или проблемы
• 12 = Серьезная ошибка — серьезные ошибки или проблемы, результатам (например, созданным файлам или отчетам) нельзя доверять.
• 16 = Терминальная ошибка — очень серьезные проблемы, не используйте результаты!

OS JCL ссылается на код возврата как COND(«код условия») и может использовать его, чтобы решить, выполнять ли последующие шаги. Однако, в отличие от большинства современных языков программирования, условные шаги в OS JCL не выполняются, если указанное условие истинно — таким образом, возникает мнемоника : «Если это правда, переходите [без выполнения кода]». Еще больше усложняет ситуацию то, что условие может быть указано только после шага, к которому оно относится. Например:

// MYJOB JOB ........... // STEP01 EXEC PGM = PROG01 .... // STEP02 EXEC PGM = PROG02 , COND = ( 4 , GT , STEP01 ) .... // STEP03 EXEC PGM = PROG03 , COND = ( 8 , LE ) .... // STEP04 EXEC PGM = PROG04 , COND = (  
  

  

  

  ТОЛЬКО , STEP01 ) 
.... 
// STEP05 EXEC PGM = PROG05 , COND = ( EVEN , STEP03 ) ....