JCL (Job Control Language) is a programming language used to define jobs for IBM's S/390 mainframe computers' MVS, OS/390, and VSE operating systems. This blog will be extremely beneficial if you are preparing for an upcoming interview in this field. These JCL interview questions can assist both beginners and professionals ace the job interview.
JCL, or Job Control Language, is a programming language that was developed in 1964. JCL refers to scripting languages used on IBM mainframe operating systems to instruct the machine on how to run a batch job or launch a subsystem. The objective of JCL is to indicate which programmes to run, which files or devices to use for input or output, and, on occasion, when to skip a step.
In this blog, we've compiled a list of the most important JCL Interview Questions and Answers, along with detailed explanations. Let's take a look ahead.
We have classified JCL Interview Questions - 2023 (Updated) into two stages, they are:
Frequently Asked JCL interview questions
Job Control Language (JCL) is a programming language that allows you to control how your computer works. On the IBM mainframe operating system, JCL is a scripting language used to command the system for batch jobs. It's a sequence of statements you write to tell the operating system what you want to do. This set of statements can be fairly vast at times, but most jobs can be completed with only a small portion of it.
The following are the benefits of JCL:
You must specify where to get the input, how to process it, and what to do with the output for each job you submit. Job control statements in JCL are used to send data to MVS (Multiple Virtual Storage). JCL's comprehensive set of work control statements provides MVS with a wealth of information. Most activities, however, may be conducted using only a small number of these control statements. As you grow more comfortable with the jobs you normally run, you may find that you only need to understand the intricacies of a handful of the control statements.
The following three sorts of job control statements can be identified:
JOB Statement: It's the first of three JCL control statements that inform the mainframe OS (Operating System) about the job's identification. Other options in the JOB statement include class, msgclass, and msglevel, in addition to the Job name and accounting data. These options make it easier for the OS to choose the right scheduler. It can also be used to monitor CPU usage and provide messages to the user.
Syntax:
//Job-name JOB Positional-param, Keyword-param
Here,
Example:
//STEP01 EXEC PGM=INTERVIEWBIT
DD Statement: Data Definition (DD) aids in the specification of data sets used by a programme or procedure. A DD statement must be used to specify the required input and output resources for each job phase. Every data set utilised or generated in a job step must have DD statements. A step can include up to 3273 DD statements.
Syntax:
//DD-name DD Parameters
Here,
Example:
//STEP01 EXEC PGM=INTERVIEWBIT
DD Statement: Data Definition (DD) aids in the specification of data sets used by a programme or procedure. A DD statement must be used to specify the required input and output resources for each job phase. Every data set utilised or generated in a job step must have DD statements. A step can include up to 3273 DD statements.
Syntax:
//DD-name DD Parameters
Positional Parameters: In a JCL statement, positional parameters are those that appear in a specific order. They must be specified in that order since their order in the JCL statement is always fixed. An error will occur if the positional parameters in the JCL are moved.
Examples: ACCT (Accounting Information), PGM (Programmer Name), etc.
Keyword Parameters: For these characteristics, there is no need for a fixed position. There are no problems regardless of the sequence in which the keyword arguments are coded.
Examples: TIME, REGION, MSGLEVEL, CLASS, etc.
JCL is dealt with through a specific set of divisions.
It's an important indication in JCL statements. This indicator must appear at the beginning of every JCL statement. The JCL statements are executed in accordance with a set of rules; otherwise, the JCL statement will fail.
The JCL execution mechanism checks the symbol (//) at the beginning of JCL statements first. It prevents exceptions from happening in the middle of a program's execution.
The hierarchy levels are present in every JCL statement:
Condition checking is supported by JCL. At both the job and code levels, condition checking is possible. It's done with the COND keyword and a preset return code and operand in JCL. As a result, it is possible in JCL.
The Task statement tells the Operating System (OS) in the spool and the scheduler the job identity. In a JCL, it is the first control statement. The JOB statement's available parameters assist the OS in allocating the appropriate scheduler. It can also be used to analyse the amount of CPU time required and send notifications to the user.
Syntax:
A JCL JOB statement's fundamental syntax is shown below.
//Job-name JOB Positional-param, Keyword-param
JCL Procedures are a group of statements contained within a JCL file. The statements in this section are grouped together to fulfil a certain task. A procedure is used to code the fixed parts of the JCL, while the JCL is used to code the variable parts of the Job.
With the help of several input files, we can use a procedure to parallelize the execution of a programme. Each input file can have its own JCL, and by giving the name of the input file as a symbolic parameter, a single operation can be called simultaneously.
Syntax:
A JCL procedure definition's core syntax
//*
//Step-name EXEC procedure name
To check JCL syntax without running it, use TYPERUN=SCAN on a job card or use JSCAN. To request further job processing, such as examining or scanning a job for syntax errors, use the TYPRUN command. Without actually running the task, SCAN checks it for syntax errors. JSCAN can also inspect a JCL's syntax without running it.
A JCL can have multiple job stages, each of which can either execute a programme or invoke a procedure. As a result, JCL may run multiple programmes at the same time (job steps).
The EXEC statement is the statement that holds the job step programme data.
The EXEC statement's purpose is to give the necessary data. This data is passed along to the job step's programme.
Syntax:
The following is the fundamental syntax for a JCL EXEC statement.
//Step-name EXEC Positional-param, Keyword-param
JCL utilities are pre-written programmes that system programmers and application developers employ to satisfy day-to-day needs, organise data, and manage it. They are used to reorganise, change, or compare data at the record or data set level. Here is a couple of them, along with descriptions of their functions:
Related Article: VSAM Interview Questions |
The process does not allow the following JCL statements:
Related Articles: MainFrames Interview Questions |
The following are some of the DD statement's parameters. You can choose one or more parameters separated by commas based on your requirements.
DSN Parameter: It's used to give a dataset a name, whether it's new or old. The DSN value can have a total of 44 characters. The sub-names can be anywhere from one to eight characters long, separated by periods.
Syntax:
DSN=Physical Dataset Name
Here,
DISP Parameter: The keyword parameter "DISP" is used in JCL to represent the state of a data set to the operating system. It basically tells the operating system how to deal with the dataset after the JOB/STEP has finished. The status, normal, and abnormal JOB termination actions are the three sub-parameters.
Syntax:
DISP=({status},{normal Disposition},{abnormal Disposition})
Here,
DCB Parameter: The DCB (Data control block) parameter offers information about a dataset's physical properties. This parameter is necessary for freshly produced datasets.
Syntax:
DCB=<List of parameters>
Here,
SPACE Parameter: The SPACE option specifies how much space is needed on a Direct Access Storage Disk to store a dataset.
Syntax:
SPACE=(Unit of Space,(Primary,Secondary,Directory),RLSE,CONTIG,ROUND)
Here,
SYSOUT Parameter: So far, we've looked at the parameters of DD statements that match to dataset data. SYSOUT sends data to the output device based on the class supplied.
Syntax:
SYSOUT=class
EXEC is an acronym for EXECUTION. The EXEC statement describes the execution of a program/job phase, as well as utilities and procedures.
Syntax:
//Step-name EXEC Positional-param, Keyword-param
The following are some of the most regularly utilised positional and keyword parameters in EXEC statements:
The data processing centre (CPU). The OS must first look for and locate the application you specified before launching a JCL statement. A private library must be searched before seeking programmes in the system programme library. You must either specify the JOBLIB DD (Data Definition) statement or the STEPLIB DD (Data Definition) statement to allow OS to properly identify a programme in a private programme library.
JOBLIB and STEPLIB are two DD (Data Definition) statements. Despite the fact that both JOBLIB DD and STEPLIB DD specify a private library as the location of a certain programme, they behave differently in terms of OS search.
JOBLIB Statement: According to JOBLIB DD, every step of the JOB is searched in private libraries. It refers to the location of the JCL programme to be executed. After the JOB statement, but before the EXEC statement, comes this statement. It only applies to operations and programmes that run in the background.
Syntax:
//JOBLIB DD DSN=dsnname
Here,
STEPLIB statement: According to STEPLIB, the sole single stage of the JOB is a search of private libraries. It refers to the location of the application that will be run within a Job Step. This remark comes after the EXEC statement but before the job step's DD statement.
Syntax:
//STEPLIB DD DSN=dsnname
Here,
In JCL, the Generation Data Group (GDG) is a key notion. The GDG is made up of chronologically ordered groups of related data sets. Each of these interconnected groups has its own name. To make each data set inside a group distinct, a generation number and a version number are appended to the end of the name.
Syntax:
ABC.PQR.XYZ.GnnnnVmm
ABC.PRQ.XYZ is the GDG basis in this case.
The Generation number (Value range 0000–99999) is represented by G, and the Version number (Value range 00–99) is represented by V.
Example:
MYLIB.URMI.SAMPLE.G0001V00
MYLIB.URMI.SAMPLE.G0002V00, and so on.
Here, the GDG base is MYLIB.URMI.SAMPLE
Any parameter that changes with each programme execution should be considered a symbolic parameter. The process becomes more versatile when symbolic parameters are used. The technique will not need to be changed each time a tiny, recurring change is performed at a specific location.
The string of 1 to 7 alphameric letters in symbolic parameters is preceded by an ampersand (&). After the &, you must include an alphabetic character. Symbolic parameters may only occur in the operand field of JCL statements, not in the name or operation fields. If there are several symbolic parameters supplied to a PROC or EXEC statement, only the first one is used.
The ADDRSPC parameter is used to determine how much storage the system requires.
The following are some key points to remember regarding the ADDRSPC option.
The JCL TIME keyword parameter determines how long a job can use the CPU. TIME, in basic terms, provides the maximum amount of CPU time that can be used to complete the job. The TIME parameter can be coded at the Job and Step levels as well. When the set execution period has passed, the system will automatically terminate the JOB. As a result, the TIME parameter informs OS of the maximum CPU utilisation period, and once the job has spent the stated time, OS will automatically cancel the process.
You can regulate or adjust the listing of the Job output for each specific job using the Msglevel parameter. It determines how allocation and termination notifications appear in the job output (SYSOUT). Msglevel is used to tell JCL which messages we want to print.
Syntax:
MSGLEVEL=([statements][messages])
Here,
Temporary datasets (files containing one or more records) are only needed for the duration of the job and are removed after it is finished. They only require storage for the duration of the job, after which they are removed. DSN=&& name or simply without a DSN is how these datasets are commonly expressed. We can use them to pass the output of one step to another in the same job.
Datasets are mainframe documents that contain records that are formatted in a specified way. On the mainframe's Direct Access Storage Device (DASD) or Tapes, these files are the most basic data storage regions. If these data must always be examined in a packet programme, the physical dataset title and file type must be coded in a JCL.
The dataset definition for JCL may be found in the DD statement. Within a DD statement, the task step's required input and output resources must be specified. Dataset organisation, storage requirements, and record length must all be determined before using these resources.
Syntax
The following is the fundamental syntax for JCL DD.
//DD-name DD Parameters
You can convert an FB file to a VB file with SORT's FTOV option. This option converts fixed-length input records into variable-length output records. For RDW, VB files should include four extra bytes (Record Descriptor Word). As a result, the RDW (4 bytes) + the actual length of the record equals the length of the record in the VB file.
Example:
SORT parameters:
SORT FIELDS=COPY
OUTFIL FNAMES=SORTOUT1,FTOV
SORTOUT1 is the VB output file in this case.
If you give it an 80-byte FB file, it will return an 84-byte VB file (4 bytes for RDW).
To send data from JCL to COBOL, utilise the following methods:
DISP=OLD -> This is a reference to a previously produced dataset.
DISP=SHR -> It indicates that data can be shared by multiple users. It is, however, a read-only file.
Yes, both at the task and step levels, condition checking is possible with JCL. Obviously, this is accomplished by combining the COND keyword with a JCL-defined return code and operand. In many programming languages (such as C, C++, Java, and others), the concept of conditional checking is analogous to the concept of (if-else).
Syntax:
COND=(RC,OP)
COND=(RC,OP,STEPNAME)
COND=EVEN
COND=ONLY
The letters RC, OP, and STEPNAME stand for Return code, Operator, and Step name, respectively.
RC can be given any number between 0 and 4095, however in most circumstances, it will be given a number between 0 and 16 as follows:
The following are the main distinctions between Addressing mode and Run mode.
Addressing mode or Access Mode | Run Mode or Residency Mode |
AMODE(24) denotes 24-bit memory addressing below the line. | The RMODE(24) specifies that the programme must be loaded into memory below the line. |
AMODE(31) denotes 31-bit memory addressing above and below the line. | RMODE(31) indicates whether the programme should be loaded into memory above or below the line. |
It defines either 24-bit or 31-bit addressing techniques when AMODE=ANY is used. | RMODE=ANY indicates whether the programme should be loaded in 24-bit or 31-bit memory. |
The JCLLIB statement is used to define the job's private libraries. It works with both catalogued and in-process procedures.
Syntax
The following is the fundamental syntax for a JCL JCLLIB statement.
//name JCLLIB ORDER=(library1, library2....)
A COND parameter can be added to a JOB statement or an EXEC statement in JCL. This option can be used to skip stages based on previous steps' return codes. The return code from the previous task phases is being tested here. If the test is found to be true, the current job step execution will be skipped. It is not an atypical termination to skip a task stage but rather an omission.
COND is coded in JOB statement: When COND is coded into a JOB statement, every step of the job is tested. If the condition is true at any given task stage, it is skipped along with the future steps.
COND is coded in EXEC statement: If COND is found to be true in the EXEC statement of a job step, only that job step will be skipped, and execution will proceed to the next job step.
Example:
//MATEKSD JOB MSGLEVEL=(1,1),NOTIFY=&SYSUID, COND=(0,NE)
//STEP01 EXEC PGM=CONDPGM1
//STEP02 EXEC PGM=CONDPGM2,COND=(0,EQ)
//STEP03 EXEC PGM=CONDPGM3,COND=(4,EQ)
Explanation of COND=(0 NE)
The COND parameter is set to (0,NE) at the JOB level, as you can see. It will verify if the return code 0 is not the same as the return code of any of the JCL stages. If this is the case, the position should be eliminated. As a result, this condition will be true and the task will be cancelled if any of the stages (such as STEP01, STEP02, or STEP03) returns a non-zero return code.
CODE-EVEN: The current task step is executed regardless of whether the previous steps have ended unexpectedly when COND=EVEN is coded. If there are other RC conditions (return code conditions) coded alongside COND=EVEN, the job step will run even if none of them is true.
CODE-ONLY: The current task step will only be run if one of the preceding stages terminates abnormally, as indicated by the COND=ONLY code. If further RC conditions are coded alongside COND=ONLY, the job step will only run if none of the RC conditions is true and any preceding job steps have failed unexpectedly.
The IBM function DFSORT is quite useful. Datasets are copied, sorted, and merged using it. Input datasets are specified using the DD statements SORTIN and SORTINnn. Output data is determined using the SORTOUT and OUTFIL commands.
DFSORT is mainframe-only utility software for processing and manipulating sequential files using JCL.
The CLASS keyword option in JCL is used to categorise the jobs that run in a specific OS installation. The operating system is informed about the nature of the work that is being submitted by CLASS. It avoids conflicts between jobs that share a resource. This type of parameter helps to balance the load of all the jobs executing in a given environment. It can also be used to prioritise job completion.
Syntax:
CLASS= JOB-CLASS
The following are the possible JOB-CLASS values:
Example:
//JCL1234 JOB ‘max021’,’Ashish’CLASS=A
PROC stands for Procedure. A JCL Procedure is a set of statements in a JCL file that accomplish a specific task. JCL Procedures work across several JCLs in the same manner as language compilers and linkage editors do. Instead of using the PROC keyword, the EXEC statement can be used to code the procedure directly.
Syntax:
//Step-name EXEC PROC=Procedurename
Or
//Step-name EXEC Procedurename
Here,
Example 1:
//STEP05 EXEC PROC=MTHPROC
Or
//STEP05 EXEC MTHPROC
Use of PROC
Types of procedures
No, using instream data within a PROC is not possible. This is a set of guidelines. Before executing the PROC, it's usually best to add a few dummy statements and override the JCL's DD statements.
MVS sent a message. NOTCAT 2-GS denotes a duplicate catalogue entry. If we try to create a new dataset with dsn = 'xxxx.yyyy' using disp new, catlg, we will get this error.
The application will open and write, with the system attempting to place it in the system catalogue at the end of each phase. The catlg would fail and provide this warning since we already have an entry.
By removing the first data set and cataloguing the new dataset on the storage disc, we may solve the problem.
A group of JCL statements coded inside a PDS (partitioned data set) member can be identified and included in a JCL stream using INCLUDE statements. Many of the common documents used in JCLs, for example, can be coded as DD statements in an INCLUDE member and used within JCL
Syntax:
//name INCLUDE MEMBER=member-name
An INCLUDE statement does not contain a phoney DD statement, a data card specification, or JOB, PROC statements. With up to 15 layers of nesting, an INCLUDE statement can be coded within an INCLUDE member.
To construct temporary data sets, we utilize DISP=(NEW, PASS, DELETE). DISP NEW builds a new data set and allocates space. DISP PASS moves the data set to the next step after the current step is successfully finished. DISP DELETE removes the accessible data set once the step abends, leaving only non-abended data sets.
The programme must be written, as well as a load module containing all of the COBOL program's sub-programs for batch execution. When the JCL runs, it uses the load module instead of the actual programme. The load libraries are patched and sent to the JCL through JCLLIB or STEPLIB at the time of execution.
The below program will explain how to utilise JCL to run MYPROG using MYDATA.URMI.INPUT input file. This application creates two output files in the spool directory.
//COBBSTEP JOB CLASS=6,NOTIFY=&SYSUID
//
//STEP10 EXEC PGM=MYPROG,PARM=ACCT5000
//STEPLIB DD DSN=MYDATA.URMI.LOADLIB,DISP=SHR
//INPUT1 DD DSN=MYDATA.URMI.INPUT,DISP=SHR
//OUT1 DD SYSOUT=*
Through the use of a preset keyword parameter, it is possible to have an automatic restart in JCL. One of the restarting keywords is RDkeyword. In most cases, it succeeds in causing the programme to end abruptly. In light of the importance of checkpoints, which are used to specify task execution at various stages in the programme, we must evaluate the location of the automatic restart.
The operating system will be alerted about the work to be done in JCL using the SUBMIT command. When a programme ends abnormally during a step, it is called an abend. The following are some of the JCL Abend codes:
When working on a mainframe, we must compose a Job and send it to the computer for processing. This is referred to as "submitting a job."
You can submit a JOB from your CICS application software in a number of ways. We may achieve this by writing JCL straight to JES Spool using CICS Spool Interface instructions.
CICS is used to access MVS's JES (job entry subsystem). CICS programmes use the JES interface to produce spool files and retrieve them. In order to use the JES interface in CICS, the DHFSIT SPOOL option must be set to YES (DFHSIT SPOOL=YES).
The four SPOOL interface commands used in a job submission are provided by CICS. The following are the details.
Complete all-access to a JES spool file in a single task in a CICS programme. Any job that performs I/O on data sets with more than 1000 records is likely to have an impact on the rest of CICS' performance.
A preset keyword parameter, such as RD (Restart definition), can be used to restart JCL automatically. However, this frequently leads to sporadic programme termination. The restart definition (RD) immediately starts the job at the checkpoint. Checkpoints are used as markers for the job's execution at certain points. RD starts by looking for the last successful checkpoint and working his way backwards.
A job timeout occurs when a programme takes longer than the stated time limit for the selected class. It's commonly known as an "S322 abend." Due to circling errors, the programme does not finish in this case.
If the amount of data handled by the programme is really large and requires additional time to complete, the TIME parameter can be coded as TIME = 1440.
DISP Fresh allocates new memory and creates a new dataset. When the phase is completed, DISP CATLG can catalogue the data set. If the step abends/fails, DISP DELETE deletes the dataset.
DISP Fresh allocates new memory and creates a new dataset. When the phase is completed, DISP CATLG can catalogue the data set. A catalogued dataset can be referred to by name without requiring the user to indicate its location. The dataset is saved with DISP KEEP. The catalogue is not saved if the step fails. The three actions are dependable and ensure that the data set is always handled correctly.
Following a set of predetermined rules is all it takes to get a job among the available ones. Each work has a keyword defined by JCL's predefined job rules. A job can be held for later execution if TYPRUN is mentioned in the job declaration. The TYPRUN is currently holding a job with the variable name HOLD.
You can identify one empty file with JCL, but you must ensure that it is an IDCAMS input. VSAM (Virtual Storage Access Method) datasets are created, modified, and deleted using IDCAMS (Integrated Data Cluster Access Method Services). If the file is empty, an error is thrown (return code 4, i.e., RC=4) when it is entered into IDCAMS.
Name | Dates | |
---|---|---|
IBM Cognos Framework Manager Training | Oct 08 to Oct 23 | View Details |
IBM Cognos Framework Manager Training | Oct 12 to Oct 27 | View Details |
IBM Cognos Framework Manager Training | Oct 15 to Oct 30 | View Details |
IBM Cognos Framework Manager Training | Oct 19 to Nov 03 | View Details |
Madhuri is a Senior Content Creator at MindMajix. She has written about a range of different topics on various technologies, which include, Splunk, Tensorflow, Selenium, and CEH. She spends most of her time researching on technology, and startups. Connect with her via LinkedIn and Twitter .