********************************************************************************************PROC:

********************************************************************************************1. Naming : The Proc name should start by GGP, which is the qualifier for CARBS. And

then one of the following alphabet should come according to the time of submission of the job:

D => Daily M => Monthly W => Weekly A => Annually K => On-request Q => Quarterly

2. Following the frequency digit, are two characters identifying the particular job and where it runs in the cycle. According to the corporate standard this should be a numeric user–defined value.

3. The 7th and 8th letter varies according to the region it is meant to be run, which is as following:

DB2A : BP DB2C : PI DB2F : AP DB2O : PA

e.g. GGPM01PA:

GGP : For CARBSM : Monthly job01 : Name of procPA : DB2O (Production) region proc

4. Symbolic Parameters : The symbolic parameters are those which indicate the version of the GDGs in a particular step. The name of the symbolic parameter should be starting from G, followed by the step number’s last 4 digits, in which the GDG is created. And form thereon, wherever we want to reference to that GDG’s particular version, we should use that symbolic parameter.

e.g. If a GDG named GIT.GP0.GGPM0520.S1 is created in Step number GGPM0520 and if we want to declare a symbolic parameter for that GDG, then the name for the symbolic parameter should be “G0520”, the declaration can look like //GGPM05PI PROC G0520='(+1)'

And from thereon, the GDG’s (+1) version can be accessed by giving://<LABEL> DD DSN=GIT.GP0.GPM0520.S1&G0520, // DISP=SHR

5. Documentation: After the Proc name and symbolic parameter declarations, there should be a flower box which contains the information regarding to the working of each step in the proc along with the module for which the Proc is made for. Firstly, the name of the module, the Proc is made for, comes in the box and after that one line describing the main purpose of the Proc should be written.

After that, a list of the steps along with their functioning should be mentioned. Following the list, there should be a maintenance log, which contains the history of the changes being made each time. This should be shown by the name of the individual, making the changes, the release month and year for which the changes are being made and the changes made in three columns and a search key should also be specified if there is anyone. Each time there is any change being made to the Proc, the maintenance log should be updated.

Above each step, there should be a flower box, indicating the step name and the working of the step, and that of the program executed in the step.

If any SYSIN is used in a step, then the contents of the SYSIN should be written as comments after the statement which declares the SYSIN. If the SYSIN is large in size then the significant statements showing the functionality of the SYSIN should be written in comments.

6. OPDOC Information: This is the information given to the Production Support people to help them in case of an Abend. The structure of the OPDOC information is like below:

//<Step Name> EXEC PGM=<As per Req.>,COND=<If necessary>//* //*OPDOC RESTART CALL=N(<Return code/s>),CALL=Y(<Return code/s> or OTHER)://*OPDOC STEP =<Step Name>: //*OPDOC SPREP = None or SET <Symbolic Parameter> = ‘<value>’//*OPDOC RSTIMG=// RESTART=<Proc name>.<Step name>//*

This information is a must and it should be present after each step declaration as shown above. The values shown between ‘<’ and ’>’ signs should be replaced by a particular value.

//*OPDOC RESTART CALL=N(<Return code/s>),CALL=Y(<Return code/s> or OTHER):

In this step, we are providing whether to call the concerned people or not for particular return codes in case of an abend. We specify the return codes for which we don’t want to make the calls in “CALL=N(<Return code/s>)”. We specify “OTHER” or the return codes for which we want to call in “CALL=Y(<Return code/s> or OTHER)”.

//*OPDOC STEP =<Step Name>:

This step simply tells the step name where this information is written.

//*OPDOC SPREP = None or SET <Symbolic Parameter> = ‘<value>’

If we are using any symbolic parameters in this step and if we want to initialize it to a particular value before they restart the job after abend, the new value is specified in this statement. E.g., SPREP=SET G0510='(+0)'

//*OPDOC RSTIMG=// RESTART=<Proc name>.<Step name>

This is the restarting information. It shows the Proc name and the step name from which the Proc should be restarted in case of an abend.

A whole OPDOC statement along with the step name is shown below for example:

//GGPM0122 EXEC PGM=USER200,COND=(0,EQ,GGPM0120) //* //*OPDOC RESTART CALL=N(B37),CALL=Y(OTHER): //*OPDOC STEP=GGPM0122:

//*OPDOC SPREP=SET G0110='(+0)' //*OPDOC RSTIMG=// RESTART=GGPM01PA.GGPM0120; //* 7. Various Utilities used in the Proc: We use the following Utilities frequently in Procs:

IEFBR14: This Utility is used to allocate or delete Datasets or to generate the next generation for the GDGs used in the Proc.

EZTPA00X: If we are using any Easytrieves in the Proc, then this Utility is used to run these Easytrieves. The name of the Easytrieve is passed in the sysin, which should be present at the location specified in the DD DSN statement.

DB2UTIL: This Utility is used if we want to perform any loading using a load card for a particular table. The load card is specified in the SYSIN. The data to be loaded is specified in SYSREC label as a PS or GDG. The SYSDISC label shows the GDG or PS where the discarded records should be written.

DSNTIAUL: This utility is used to Unload data from database SYNCSORT: This is utility used for sorting data IKJEFT01: If we want to execute a DB2-COBOL program, we use this Utility. The

System Name, Program Name and Plan are specified in the SYSIN. The STEPLIB indicates where the program is located.

IEBGENER: This Utility is used to produce a backup copy of a sequential data set, or a member of a PDS and to copy sequential datasets.

8) STEPLIB: This is library used to search the specified function in the step it varies by region For Ex: <STEPNAME> EXEC DB2UTIL STEPLIB: TTAT.TS2.DB2.APFLIB (DB2A/F/C) TTAP.TS2.DB2.APFLIB (DB2O)

9) USER 200: This is Abend utility which is executed if the named step execution fails this should be coded after each and every step that is to be executed in the J0B.It provides the user the information for the abend.

References:DB2A Proc: GTS.GP0.GACCP1.DB2A.PROC (GGPMISBP)DB2F Proc: GTS.GP0.GACCP1.DB2F.PROC (GGPMISAP)DB2C Proc: GIT.INTG.PROCLIB (GGPMISPI)DBDO Proc: GIO.END.GPROD.PROC (GGPMISPA)

***************************************************************************************************************JCL:

***************************************************************************************************************This is the JOB where the Proc gets executed

It has the following Syntax:[ ] – MANDATORY FIELDS { } - OPTIONAL FIELDSDB2A:1) Job Statement:Syntax:< [JOBNAME] [JOBCARD] [CLASS] [COMMENT] [MSGCLASS] [NOTIFY] >

JOBNAME: Will be the same as Proc name (8 characters)JOBCARD: JOB (G, GP0, GP05000, 4, B255)CLASS: A/B/C/J/K COMMENT: APPROPRIATE WITH MODULE

MSGCLASS: A/B/CMSGLEVEL: (1, 1)

NOTIFY: &SYSUID—Notify’s the User who’s executing the job2) Route Card –Region where the job is executedSyntax:ROUTE XEQ [REGION] REGION :DB2A

3) LOADMODULE:Syntax:JCLLIB ORDER=( [Path where the Proc is located ] )

4) EXEC STATEMENTSyntax: [PROCNAME] EXEC [PROCNAME]

Ex: GTS.GP0.GACCP1.DB2A.RUNJCL (GGPMZABP) DB2F:1) Job Statement:Syntax:< [JOBNAME] [JOBCARD] [CLASS] [COMMENT] [MSGCLASS] [MSGLEVEL] [NOTIFY] >

JOBNAME: Will be the same as Proc name (8 characters)JOBCARD: JOB (G, GP0, GP05000, 4, B255)CLASS: B/L COMMENT: APPROPRIATE WITH MODULEMSGCLASS: N MSGLEVEL: (1, 1)NOTIFY: &SYSUID—Notify’s the User who’s executing the job2) Route Card –Region where the job is executedSyntax:ROUTE XEQ [REGION] REGION :DB2F

3) LOADMODULE:Syntax:JCLLIB ORDER=( [Path where the Proc is located ] )

4) EXEC STATEMENTSyntax: [PROCNAME] EXEC [PROCNAME]

Ex: GTS.GP0.GACCP1.DB2F.RUNJCL (GGPMZAAP)

DB2C:1) Job Statement:Syntax:< [JOBNAME] [JOBCARD] [CLASS] [COMMENT] [MSGCLASS] [MSGLEVEL] [NOTIFY] >

JOBNAME: Will be the same as Proc name (8 characters)JOBCARD: JOB (G, GP0, GP05000, 4, B255)CLASS: 7

COMMENT: APPROPRIATE WITH MODULEMSGCLASS: N MSGLEVEL: (1, 1)NOTIFY: &SYSUID—Notify’s the User who’s executing the job2) Route Card –Region where the job is executedSyntax:ROUTE XEQ [REGION] REGION: DB2F

3) LOADMODULE:Syntax:JCLLIB ORDER= ([Path where the Proc is located])

4) EXEC STATEMENTSyntax: [PROCNAME] EXEC [PROCNAME]

Ex: GIT.INTG.JCLLIB (GGPMZAPI)

DB2O:1) Job Statement:Syntax:< [JOBNAME] [JOBCARD] [CLASS] [COMMENT] [MSGCLASS] {MSGLEVEL} {NOTIFY}

JOBNAME: Will be the same as Proc name (7 characters), should end with P JOBCARD: JOB (Q, GP0, GP06666, 1, B255, 9999)CLASS: R COMMENT: APPROPRIATE WITH MODULEMSGCLASS:N MSGLEVEL: (1, 1)NOTIFY: &SYSUID—Notify’s the User who’s executing the job2) Route Card –Region where the job is executedSyntax:ROUTE XEQ [REGION] REGION: DB2O

3) LOADMODULE:Syntax:JCLLIB ORDER= ([Path where the Proc is located])

4) EXEC STATEMENTSyntax: [PROCNAME] EXEC [PROCNAME] 5) STEPCOND and STEPCALL should be the last two steps of the Job

Ex: GIO.END.GPROD.RUNJCL (GGPMZAP)