Often, in a working environment, the same JCL can be utilized by several users. For example, if a common data set is to be accessed by several users, then the JCL that they will code to open and read the data set will be similar. Group of commonly used JCL statements can be categorized into procedures that are given names. The system has to be notified when these kinds of procedures are created and/or accessed. The names of the procedures comprised of groups of JCL statements can be recorded by the system and stored just like any other members of a PDS. The system has to be notified each time these procedures are to be recorded and. or accessed. Before a group of JCL statement can be recorded under a procedure name by the system, they should be tested. Thus, the groups of JCL statements that make the procedure become a part of the input stream of the job itself. The system has to be notified if a group of JCL statements are to be grouped together in this way. Sometimes, the same JCL can be utilized by different users, but with different parameters. In these cases, JCL provides us with a useful feature that allows us override one parameter with another. If a parameter has the capability of being overridden in this way, then the system has to be notified.
Procedure or PROC
The use of procedure helps in minimizing duplication of code and probability of error. This is because a procedure should consist of pre-tested statements. Each time a procedure is invoked; there is no need to re-test its functionality, since it is pre-tested. A procedure is initiated with the keyword PROC. The system is notified about the end of the procedure with the keyword PEND. The syntax is as follows:
The segment of JCL, which executes this procedure, will be something like
A procedure name can be 1 to 8 alphanumeric and national characters. The first character should be alphabetic or national. No more than 255 job steps can be coded in one procedure. The following JCL statements cannot be included within the procedure:
A cataloged procedure, like an in-stream procedure, is a named set of job control statements. However, these control statements are placed, or cataloged, in a partitioned data set (PDS) or partitioned data set extended (PDSE) known as a procedure library. This enables a cataloged procedure to be invoked by any job.
Cataloged procedures can be placed in the system procedure library SYS1.PROCLIB or in any user-specified procedure library (for example JCLLIB).
Once the procedure has been created and tested, it can be cataloged and placed inside a system or user-defined library. A system of user-defined library is simply an area in the system, which is used to store cataloged procedures. These libraries reside as PDSs within the system. IBM supplies a system library called SYSl.PROCLIB. The above procedure can be place in this library, or it can be placed inside a user-defined library. The segment of JCL, which executes this cataloged procedure, will be something like the following:
The DD statement defines the location of the cataloged procedure and the EXEC statement executes it.
An in-stream procedure is a named set of job control statements in a job that can be re-executed within that job, simply by invoking the name of the procedure. This enables you to execute the set of control statements more than one time in the same job without having to repeat the statements.
When a job is executed, and the system detects a PROC immediately following the JOB statement, the system goes through a special routine that reads and saves all statements that follow, until the PEND statement. This saved JCL is assigned a name, just like cataloged procedures. Then, each time an EXEC statement followed by this pre-defined name is detected, the group of saved JCL statements are executed.
In-stream procedures must begin with a PROC statement and end with a PEND statement. If in-stream procedures are defined within a job, then they must be coded immediately after the JOB statement, before the first EXEC statement. No more than 15 in-stream procedures can be coded in a job.
Overriding Parameters in Procedures
Sometimes there may be a need to override one or more parameters in procedures. For example, you might want to change the data set in a DD statement. Keep in mind that the modified contents of a procedure which has 'overrides' in it are active only for the duration of the job in which they exist; the original contents remain intact. The syntax for overriding existing parameters in a procedure is as follows:
Where name is the stepname/ln the job that the procedure will be executed form; procedure_name is the name of the procedure whose parameters will be overridden; procstep is the stepname in the procedure whose parameters will be overridden; and ddname is the ddname of the DD statements containing those parameters. One or more modified parameters can follow the DD.
Suppose we want to modify the disposition of FILE1 from SHR to OLD. Here is the JCL that will modify the contents during execution:
Symbolic parameters are used to override parameters on the DD statement. They can be used in both cataloged and in-stream procedures. Frequently, the same JCL can be used by different programmers to implement common tasks, such as the opening, reading, and writing of data sets. The only difference is in the parameters required to access different data sets.
Symbolic parameters provide a convenient means of assigning different parameters to commonly used JCL procedures. A symbolic parameter on a DD statement is coded by preceding the parameter that will be assigned a value with '&'. The value that will be assigned to a symbolic parameter is coded in the PROC statement of the cataloged or in-stream procedure. Symbolic parameters can be used with parameters, sub-parameters, and even hard-coded values.
A symbolic parameter can consist of 1 to 8 alphanumeric and national characters (including the '&'). The first character must be '&.'. The next character must be alphabetic or national. Symbolic parameters cannot be code for the keywords on the EXEC statement. However, they may be coded for the values associated with a keyword. A value assigned to a symbolic parameter may be overridden by yet another value as long as the redefinition is within the same job. If it is not overridden then the same value will be assigned to it each time it is called. There is no restriction on the length of the value assigned to a symbolic parameter. However, the assignment must fit on the same line; it cannot continue to the next line.
If positional parameters are coded as symbolic, then a period should be inserted between them. This period is in addition to any periods that would be required for the correct syntax of the statement that is being coded. Symbolic parameters cannot be concatenated with other symbolic parameters, to produce yet another symbolic parameter. However, they can be concatenated with each other, each retaining the value originally assigned to it. Symbolic parameters cannot be concatenated with regular parameters, or portions of regular parameters, in order to produce yet another symbolic parameter. They can be concatenated with other parameters, or portions of them, as long as they retain the value originally assigned to them. Concatenated symbolic and/or regular parameters must not exceed 120 characters.
If a symbolic parameter is defined then it must be assigned a value and used within the procedure that defines that parameter. The following special characters (blank, comma, period, slash (/), single quotes ('), parentheses, &, +, -, =) can be coded as is, if they are assigned to symbolic parameter. Any other special characters must be enclosed within single quotes. Value can be assigned to the symbolic parameters in either or both of the following statements:
Here &F1LE1 is substituted with DATAFILE
Here &PXRMX is substituted with 01-01-97.
IBM Mainframe Related Interview Questions
|IBM Lotus Notes Interview Questions||IBM-CICS Interview Questions|
|COBOL Interview Questions||Linux Interview Questions|
|IBM-JCL Interview Questions||IBM Mainframe Interview Questions|
|IBM AIX Interview Questions||IBM WAS Administration Interview Questions|
|IBM Lotus Domino Interview Questions||IBM Integration Bus Interview Questions|
|Mainframe DB2 Interview Questions||Unix Production Support Interview Questions|
Ibm Mainframe Tutorial
Introduction To Software Development
Introduction To Ibm Mainframes
Tso And Ispf
Jes2, ]es3 And Sms
Introduction To Job Control Language (jcl)
The Job Statement
The Exec Statement
The Job And Exec Statements
The Dd Statement
Procedures And Symbolic Parameters
Generation Data Groups (gdg), Compile/link-edit And Run Jcls
Access Method Services (ams)
Additional Vsam Commands
Introduction To Rexx
Overview Of Rexx
Introduction To Cics
Exception Handling In Cics
Developing A Cics Application
Cics Programming Techniques
Basic Mapping Support (bms)
Transient Data Control
Temporary Storage Control
Interval And Task Control
Cics Application Design
Recovery And Restart
System Security And Intersystem Communication
Cics Debugging Facilities And Techniques
Bms Map Definition Macros And Copylib Members
Cics Response And Abend Codes
Data, Information And Information Processing
Introduction To Database Management Systems
Introduction To Relational Database Management Systems
Database Architecture And Data Modeling
Overview Of Db2
Structured Query Language (sql)
Data Security And Access
Db2 Application Development
Qmf And Db2i
Db2 Performance Monitoring, Utilities And Recovery/restart
Overview Of Information Management System (ims)
Introduction To Vs Cobol Ii
Overview Of Application Development In Vs Cobol Ii
Overview Of The Cobol Program
Sorting And Merging Files
Coding Cobol Programs That Run Under Cics. Ims, Db2 And Ispf
Compiling The Program
Link-editing The Program
Executing The Program
Improving Program Performance
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.