0% found this document useful (0 votes)
46 views13 pages

JCL Job Change and Debugging Guide

The document outlines the procedures for making changes to JCL jobs in COBOL, including version control, testing, and scheduling using tools like Changeman and Panvalet. It details the roles of developers and support teams in monitoring job cycles, handling job abends, and managing service level agreements (SLAs) for incident resolution. Additionally, it emphasizes the importance of documentation and the change ticket process for implementing modifications in production environments.

Uploaded by

tejareddi07
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
46 views13 pages

JCL Job Change and Debugging Guide

The document outlines the procedures for making changes to JCL jobs in COBOL, including version control, testing, and scheduling using tools like Changeman and Panvalet. It details the roles of developers and support teams in monitoring job cycles, handling job abends, and managing service level agreements (SLAs) for incident resolution. Additionally, it emphasizes the importance of documentation and the change ticket process for implementing modifications in production environments.

Uploaded by

tejareddi07
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

TOOL SESSION 04:-

-----------------------------------------------------------------------------------
---
COBOL - COPYBOOK -CHANGE & DEBUG -> VERSION CONTROL -> CHANGEMAN , END , PANVALET
---
HOW TO WE MAKE A CHANGE IN JCL JOB

-> TSO PROD -> CHANGE IN THE JOB.? NO

->PROJECT-A - APPLICATION-A -> CHANGE IN JCL JOB/PROC

1. TSO -TEST/DEVL
2. CASE-1 :EXISTING JOB -COPY OF THE PROD JOB -> INTO PEROSNAL JOB
CASE-2 :NEW JOB NEED TO CODED IN OUR PERSONL JOB
3. TEST AND REVIEW
4. OUR OWN APPLICATION SCREEN -> WE CAN MOVE THE JOB FROM TEST - PROD

-> PROJECT-B -> APPLICATION-A -> CHANGE IN JCL JOB (CURRENT PROJECT)

1. TSO TEST/DEVL
2. CASE-1 :EXISTING JOB -COPY OF THE PROD JOB -> INTO PEROSNAL JOB
CASE-2 :NEW JOB NEED TO CODED IN OUR PERSONL JOB
3. TEST & REVIEW
4. SCHDULER TOOL -> WE MOVE THE JOB FROM PERDSONAL PDS -> TO TSO PROD
PDS

--> SCHDULER TOOL:- 1. USE IT TO SET THE SCHDULER FOR THE JOB
2. WE CAN MOVE THE JCL CHANGE TO PROD

3. WE CAN MONIOR THE JOB CYCLE


4. WE CAN RERUN THE JOB IN CASE OF ABEND

-> AS A DEVELOPER -> HOW TO CREATE A NEW SCHDULE:-

INTERVIEW: -> I WOULD SUGGEST -> WE REQUEST -> S-TEAM TO SETUP ANY NEW SHC OR
CHANGE ANYTHING IN THE SCHDULER

-> DETAILS: 1. PROCESS NAME/APPLICATION /EVENT


2. SCHEDULER -> 1. FREQUENY --> HOURS, DAILY,
MONTHLY , ONLY MON , MON + TUE
--> CALENDAR** -WORKING ,
HOLIDAY , VACH , CH, NEW YEAR , OTHER HOLIDER
-> MONTH-END DATE,
ACCOUNTING DATES, YEAR END DATE
2. TIME -> 8AM
3. JOB LIST:- SINGLE JOB -> J1
MULTIPE JOBS -> SET A DEPENDECY ---> JOB J1
---> J2 --> J3
|
|
PRE-DE YOUR JOB
SUCCESSOR

-> DETAILS -> REVIEW -> OPTION -> WE MOVE THE SCHDULER -PROCESS* TO
PROD
-> AS A SUPT:- 1. DAY-DAY -> MONITOR THE JOB CYCLE
-> 1. LEVEL L1 - L2 - L3
|
L1 -> OPERATION TEAM ->MONTIOR - MANY
APPLICATION JOB
-> IN CASE ABEND -> 1. FOLLOW
RESTART INTRUCATIONS -> RERUN THE JOB
2. IF IT
FAIL'S -> CREATE A TICKET FOR APPLICATION-SUPT
> IN CASE ABEND -> 1.
DIRECTLY THE CREATE A TICKET FOR APPLICATION-SUPT

L2 -> APPLICATION SUPT (WE ARE HERE) 1. TICKET


+ SLA
2. ANALYSIS ON
ISSUE
3. FIX THE ISSUE
4. RERUN THE
ABEND JOB
-> I CANNOT FIX IT --> CONTACT ->
L3 (ONSIE SME)

L3 -> SME (CLIENT TEAM)

ON A DAY -> ANIL : 10AM -> CHECK THE EMAIL -> 1. ANY NEW WORK GIVEN TO
ME
-> 2. REPLY FOR THE EMAIL I SENT BEFORE
-> 3. BATCH JOB -MESSAGE
-> 4. TEAM -EMAIL
-> 5. CAL ->MEETING --> 30MIN
/40MIN
O/P: PLAN MY DAY

11AM -> ANALYSIS + CHANGES + TESTING + DOCUMENTATION + PREPARE


FOR THE MEETING

11AM -> ANYTIME OF UR WORK -> JOB ABEND -> PRTY (SLA)

2. RERUN THE JOB 0> [Link] PROJECT -> DO WE 'SUBMIT' ANY PROD JOB IF
ABEND --> NO
-> JOB -> SUBMIT -> SYSEM -> SET UR
'USERID' FOR ACCESS LEVEL

-> JOB ABEND -> RERUN 1. RERUN THRU SCHDULER TOOL ONLY (DO
NOT SUB ANY JOB FROM 3.4)

--> JOB STATUS -> WAIT - PEND - FAIL - EXEC - COMPL


| |
TIME-8.30AM JOB J1 -> [Link] -> TRIGGER -> RUNNING 11.15
JOB J2 -> 11.10 -> TRIGGER -11.10 --TO--11.15 - PEND

==> BIGGEST ISSUE IN THE JOB CYCLE:

OVER-LAPPING WITH BATCH CYCLE:- 1. BATCH CYCLE -> 8HR (MAX) > 5PM
(USA TIME) ---> 3AM --> BUFFER -> 5-6AM
5PM -> 5AM
-> DAY CYCLE -> JOB J1 -> EVERY 30MIN (15MIN)
=> MONTHLY CYCLY -> 40-50 JOB -> RUN A 1-2
DAYS

-> OVER-LAPPING:-> DAY CYCL -> JOB J1 -> 15MIN -> 10.00 -> JOB
J1 ABEND --> SOMETIME WE FIX , SOMETIMES WE CANNOT
10.15 -> JOB J1 TRIGGER
10.30
10.45
11.00 -> JOB J1 TRIGGER
(RERUN THE 10.00 JOB J1 AT 11 AM)

SB37, S322

-> OVER-LAPPING-> AUG 31 -> DAILY CYCLE > ALREADY EXECUTING


MONTH-END CYCLE -> OVER-LAP ->
AUG-1 - AUG30 + AUG31

-> OVER-LAPPING ->


AUG 23 -> 5PM -> DAILY CYCLE TO RUN
-> JOB J100 -> ABEND -> NO FIX ->
REASON WE CANNOT RERUN THIS FELLOW
-> WAIT FOR THE FIX -> 18HR
-> CURRENT DATE - 1 DAY ==> CURRENT
DATE - 3 DAY

-> AUG 24 -> 5PM -> NEXT DAILY CYCLE TO TRIGGER

--> LAST YEAR -> 1. MONTH-END


2. WEEK-END
3. APPL-B (AM HERE) -> APPL-A ->JOB ABEND --> LOGIN TO
MAINFRMAE -> HE WAS NOT ABLE TO CONNECT MAINFRAME
-> ANIL - CAN U CHECK /CONNECT -> I TRIED ->
NOT ABLE CONNECT
-> 30MIN -> WE TRIED
=? OFFSHORE -> TO CHECK -> THEY ALSO NOT ABLE
TO CONNECT
=> OPERATION TEAM -> THEY SAID -> MAINFRAME IS
DOWN
=> SME -> MANAGER -> P1 TICKET -> IBM TEAM

> 3/4 HOURS -> FIBER CABLE ISSUE -CAUSING THIS


PROBLEM 0-> A DAY TO FIX IT

-> 1 DAY -> SME -> ANALYSIS TO SEE - ONCE THE SYSTEM
IS UP - WHAT WE NEED TO
-> VDI -CONNECT GOT DROPPED.
-> TEAM - GROUP
- MON -- ONLINE
TOOL SESSION 03:-
-----------------------------------------------------------------------------------
---
CLIENT (CITY BANK) ---> 10000 APPLICATION -> 6000 -APPLICATION THEY DO THEMSELF
-> 4000 -> OUT SOURCE -> 100, 500,200,300 ->
PACKAGE APPLICATION
--------------------
|
BIDDING (TCS(20),IBM(30)...)
|
100 APPLICATION ->
DEVELOPEMENT,MAINTRANECE,SUPPORT

SLA -> SERCIVE LEVEL AGREE


--> SLA -> TIME LINES -> TICKET -PTRY

-> TICKET PRTY* TYPE RESPONSE/ACK


RESOLUTION/SOLVE-CLOSE
P1 URGENT 2MIN - 15MIN 20MIN
- 2-4HR
P2 HIGH 2MIN - 15MIN 30MIN - 4-
8HR
P3 MEDIUM 15MIN - 30MIN SAME
DAY -- 1 WEEK
P4 LOW 15MIN - 30MIN SAME DAY --
2 WEEK

TICKET -> STATUS 1. NEW


2. IN-PROGESS + SET THE TICKET ON UR NAME
3. PENDING/ON HOLD EX: REGION - S822
-> REGION=0M, STORAGE TEAM - CLEAN THE SPACE
4. RESOLVE
5. CLOSE

REASON -> 12 YEAR -> A -> ONLY DEVELOPMENT SKILL


-> CODE A COBOL PGM -> FILTER THAT RECORD OUT? -> RIGHT/WRONG!!

--> DEVE THINK -> TO CODE SOMETHING

Q? -> I HAVE BAD RECORD IN PROD -> I NEED TO REMOVE/CORRECT IT


-> HOW U WILL DO IT?

-> FILE -> - SUPERID -> I CAN REMOVE IT


-> TABLE -> - SUPERID -> I CAN REMOVE IT
----------------------------------------------------------------------
TOOL SESSION 02:-
--------------------------------------------
1. VERSION CONTROL TOOL -> ENDEVOR -> ANY CODING - COBOL , COPYBOOK << TSO
TEST/DEVL - NOT IN PROD

ENV: WE HAVE ENV -> PROD -CURRENT


-> DEVL -- COPY OF CURRENT CODE --> CHANGE -> NEW VERSION
-> TEST --> NEW VERSION -

END TOOL: 1. CHECKOUT THE COMPEOENT: 1. OPTION "G" GENERATE --> COPY OF
THE PGM FROM PROD - DEVL ENVIRONMET
2. STAGE 1. E -EDIT -- NEED TO COMPILE
2. COMPILATION -> WITH CHANGE -> E-
EDIT -> CHANGE -> F3 + ENTER --> CHECK UR MAXCC=00
-> NO CHANGE -> G - GENERATE
-> SUBMIT THE JOB -> CHECK UR MAXCC=00
3. PROMOTE -> DEPLOY TO TEST 1. OPTION "DT" --> CHOOSE THE TEST
ENV (UNIT,SYSTEM,QA)
2. WE WANT TO DO DEBUG > WE NEED CODE IN
TEST ENV.
4. IMPELEMTNATION -> TO PROD 1. CREATE A PACKAGE - 'TSO
PACKAGE'
2. SME - APPROVAL
3. BATCH JOB -> MOVE THE CHANGES.

5. POST PROD CHECK -> 1. BATCH JOB -> WAIT TILL 1ST
BATCH JOB TO COMPLETE
-> 2. ONLINE SCREEN -> IF U HAVE ACCESS -
> U RUN A TEST IN PROD
-> I DONT ACCESS -> ASK
BUINESS TEAM TO CHECK - CONFIMR EMAIL

IN ENV TOOL: PGM P1 -> PROD


PGM P1 -> DEVL < WE ARE MAKING CHANGES -->E-
EDIT- MAKE SECOND CHANGE -- COMPILE -> DEPLOY
PGM P1 -> TEST < TESTING -. WE FOUND MISTKAE -> # =DELETE
-> NEW CHNAGE -> TEST IT

CHNAGE TICKET PROCESS: 2 WAY TO DO THE CHANGE IN THE COBOL PGM:

1. JIRA -> USER STORY -> WORK STATUS/UPDATE/HOURS ALL WILL BE UPDATED IN THIS
TOOL

2. SERVICE NOW- > TICKET -> 3 TYPE 1. INCEIDENT <<JOB ABEND -> SLA
2. SERVICE REQUEST -> ANALYSIS -> USER ADHOC
REPORT -> NO SLA -> TIME LINE
3. CHANGE REQUEST (CR)
--> UNDER CHANGE REQUEST:
1. NEW -> ANALYSIS + CODING + TESTING
2. AUTHORIZATION -> APPROVAL (SME , BUNIESS APP OWNER)
3. SCHDULE -> DATE + TIME *DEPEND'S 1. ONLY
WEEKEND
2. ANY TIME IF
READY
3. ONLY WEEK DAY
-> 15 DAYS
4. ON THAT DAY -> IMPLEMENTATION --> MOVE UR CODE
5. 'POST CHECK/REVIEW' -> CHECK THE PROD RUN
6. CLOSE

--> DOCUMENTATION: 1. ANALYSIS DOCUMENTATION -> FOUND


ISSUE -> & WE NEED CHANGE
2. DESIGN -> FUNCTUIONAL -> OUTLINE OF THE CHANGE
> HLD
TECHNICAL -> PGM , FILED -> CONDITION -
> CAL > LLD / SPECICATION
-> KEEP - POSSIBALE TEST CASE
-PREPARE ESITMATES -> GO FOR THE APPROVAL
(ANALYSIS + CODING + TESTING + DOCUMENTATION + EXTRA)
3. CODE + TESTING - -> TEST
RESULT DPCUMENT
4. CHECKLIST -> REIVEW
5. SOX -> THIS IS FOR FSA *FINAICAL APPLICATION
6. POST PRODUCTION -REVIEW/VERIFY DOC

INTERVIEW: 1. INTRUDCTION 2. PROJECT RELATED -> WORK -> ROLE - RESP -


CHNAGLLEGE << THIS IS THE PLACE WHERE - PROJECT QUESTION
3. TECHNICAL ROUND => COBOL , JCL , DB2 , CICS, IMS..

--> NOW FOR THE DEBUG:-:- REASON 1. TEST MY CHNAGES


2. ANALYSIS THE EXITING PROGM

3 THINGS: 1. PREPARE THE PROGRAM FOR DEBUG


2. PREPARE THE TEST JOB + TEST DATA
3. WE CAN DEBUG

1. PREPARE THE PROGRAM FOR DEBUG

1. WE NEED VERSION CONTROL TOOL


2. CHECK OUT - STAGE -> WITH CHANGE/WITHOUT CHANGE -> COMPILE ***WE
NEED CHOOSE OPTION XPED -'Y'
** TO DEBUG ANY PGM -> WE NEED A FILE 'DDIO' -> WHICH WIL
ALLOW DEBUG TOOL -EXECUTE PGM LINE BY LINE
3. MOVE THE CODE TO TEST (DT - DEPLOY TO TEST)

MAINPGM OR SUBPGM -> ALL PGM MUST BE IN TEST ENV

2. PREPARE THE TEST JOB AND TEST DATA

BATCH APPLICATION 1. -> NEW COBOL PGM -> IN UR PERSONAL PDS ->
CODE A NEW JCL JOB
-> EXISTING PGM -> IN UR PERSONAL PDS -
> COPY-PASTE THE PROD JOB -> INTO UR PDS

2. CHANGE TO DATASET NAME (PROD INPUT FILE - WE


CAN USE IT)
PROD OUTPUT FILE > ALWAYS
NEED TO CHANGE UR FILES)

3. PREPARE THE TEST DATA


FILE AS INPUT -> 1. TSO PROD
2. FIND THE PROD INPUT FILE
3. SEND IT TO TSO TEST *FTP
(TRANSFER FILE FROM TSO PROD -TO- TSO TEST)

DB2 TABLE AS INPUT -> 1. TEST ENV -> HAVE


WEEKLY UPDATE FROM PROD - TEST
2. IN CASE - NO REGULAR
REFERSH
1. TSO PROD -> TABLE T1
->UNLOAD -> FILE
2. FTP -> FILE FROM PROD
-> TSO TEST
3. TSO TEST -> FILE F1
-> LOAD -> TABLE T1

3. DEBUG THE PGM**

TOOL: XPEDITOR 1. CREATE A "PROFILE" FOR THE PGM FOR DEBUG (1


TIME SETUP)
WITH THE HELP OF TEAM MEMBER**

1. SET A PROFFILE P1 -> ONLY COBOL PGM -->


1. LOAD LIB 2. COPYBOOK LIBS
2. SET A PROFILE P2 --> COBOL-DB2 PGM -> 1.
LOAD LIB 2. COPYBOOK 3. DBRM 4. SSID 5. AUTHOR
3. SET A PROFILE -> COBOL + DB2 + CICS ->

2. TO DEBUG -> BATCH PROGRAM - ONLINE PROGRAM ->


CHOOSE "OPTION 2 TSO"

=> WHEN U CHOOSE -> PROFILE -> BATCH PGM**


--> CHOOSE OTION -2: -> 1. PROGRAM NAME : ______
2. TEST JCL -> PDS(TESTJOB)
3. DB2 > SSID: _____ PLAN:
______

--> WHEN U CHOOSE -> PRFILE -> ONLINE PGM


--> CHOOSE OPTION 2: -> 1. TRANS-ID: _______
2. PROGRAM_NAME : ______
3. DB2 > SSID: _____ PLAN:
______

--> FOR EX: DEBUG A BATCH PROGRAM:


0OPTION -2 -> TSO SCREEN-1: 1. PGM NAME , TEST JCL JOBNAME , DB2
(Y/N) > ENTER
SCREEN-2: 1. SELECT -> DD STATMENT OF TEST JCL. (S
- SELECT DD LINE) --> "END" -> PROCESSING
SCREEN-3: 1. CREATE A COPY OF THE DD NAM SELECTION
(OPTIONAL)
SCREEN-4: 1. DEBUG SCREEN -> WE CAN DEBUG OUR PGM

DEBUG SCREEN: 2 PARTS:-

COMMAND: _____________________________________________________
*****************************************************
PART-A --> SHOW THE VARIABLE & VALUE
WS-IN-REC-COUNT : _____
WS-OT-REC-COUNT : _____
*****************************************************
PROCEDURE DIVISION.
0000-MAIN-PARA.
=======>B MOVE 0 TO VARA <1ST STATEMENT
MOVE 0 TO VARB
PART-B
A GOBACK. <LAST STATEMENT

*****************************************************

ONCE WE ARE IN DEBUG TOOL-> 1. CHECK THE PGM FLOW


2. CHECK THE VARIALE DATA

-> HOW TO EXEUTE THE LINES: 2 WAYS

1.**-> FUNCTION KEY F9 -> GO 1 -> DBBUG LINE BY LINE

X-PARA.
S1 ==> F9 -> SYSTEM EXECUTE S1 & MOVE THE
CONTROL TO S2
S2 ==> F9 -> SYSTEM EXECUTE S2 & MOVE THE
CONTROL TO S3
===> S3 -PREFOMR Y-PARA -> F9 -> SYSTEM EXECUTE
S3(PERFORM) & MOVE THE CONTROL TO S4 (Y-PARA)

Y-PARA.
==> S4

2. ** FUNCTION KEY -> BREAK-POINT + F12 --> GO

AS IN BELOW EX - I WANT TO DEBUG ONLY "PROCESS-PARA"

1. SET A BREAK-POINT (STOPPER) --> 2 TYPE B* -


BEFORE (TO STOP THE CONTROL BEFORE EXECUTING THE LINE)
A - AFTER (TO
STOP THE CONTROL AFTER EXECUTING THE LINE)
2. PRESS F12 -> SYSTEM WILL EXECUTE ALL LINES 1 BY 1 TILL
IT FIND A BREAK POINT
MAIN-PARA.
===> PERFORM INITIAL-PARA F12 -GO
PERFORM GET-INPUT-PARA
PERFORM 3000-PROCESS-PARA

B GOBACK

INTIAL-PARA. 100 LINES CODE

GET-INPUT-PARA. 50 LINES CODE

3000-PROCESS-PARA.
===> B -ENTER (B) S1. MOVE A TO B. CONTROL STOP HERE

3**: HOW TO DEBUG THE SUBPGM

-> NORMAL -> PARA-A.


MOVE -> F9 -> EXECUTE AND MOVE THE CONTROL
CALL -> F9 -> EXECUTE WHOLE SUBPGM -AND MOVE
THE CONTROL TO NEXT STATMENT
===> IF

-> WHAT U NEED TO DO:


1. UR ARE ALREADY IN MAINPGM DEBUG
2. WE NEED TO SET A BREAK POINT IN THE SUBPGM
1. SORUCE SUBPGM-NAME
2. ONCE WE ARE IN SUBPGM -> SET A BREAK POINT
*B/A ON -ANY STATEMENT
3. PRESS F9
3. KEEP ON PRESS F9 -> WHEN ITS 'CALL STATEMENT' ->
CONTROL WILL GO TO SUBPGM - STOP AT A BREACK

COMMAND: _______SORUCE SUBPGM-NAME_________________


--> COMMAND: ____SOURCE SUBPGM2___________
MAINPGM:
SUBPGM:
PARA-A:
MAIN-PARA.
====> MOVE A
===> B S1 *PRESS F9
====> MOVE B
S2
==> CALL 'SUBPGM' --> F9
------------------------------- ==> GOBACK
MOVE C

Tool Session -01: 7:15 AM 8/20/2024


----------------------------------------------------------------------
AS A MAINFRAME > RESOUCE -> JOB -> 2 PLACE -1. DEVELOPER/MAINTENACE
-2. SUPPORT

ALL THESE TOOL -> IS FOR INTERVIEW ONLY


-> REASON -> IN MAINFRAME WORLD -> WE HAVE A LOT OF TOOL

====================
DEVELOPER:- CODE DEVELOPMENT - CODE CHANGES - 1. COBOL 2. COPYBOOK
3. JCL JOB 4. CONTROL CARD 5. DB2 -PACKAGE/PLAN

-> COBOL-COPYBOOK --> 1. VERSION CONTROL TOOL -> CHANGEMAN - ENDEVOR


2. DEBUG TOOL -> IBM DEBUGGER , XPEDITOR ,
INTEREST
-> JCL JOB 3. SCHEDULER TOOL -> ESP , CA-11.. AJS , OPC

SUPPORT > 4. SCHEDULER TOOL


5. ABEND TOOL 1. ABEND-AID , SYSDUMP ,
FALUT ANAL.

SUPP/DEV 6. FILE MANAGEMENT TOOL


7. DB2 - SPUFI/ QMF -> BROWSE TOOL - MASTER-MIND , FILE-AID FOR
DB2 , RC QUERY

1. VERSION CONTROL -> ENDEEVOR


2. DEBUG TOOL -> XPEDITOR
3. SCHEDULER -> AJS TOOL
4. ABEND TOOL -> ABEND-AID
5. FILE TOOL -> FILE-AID (FILE MANAGER)
6. SERVICENOW -> WORK MANAGAMENT
-----------------------------------------------------------------------------------
-----------
AS A DEVELOPER:- 1. CODE / MAKE A CHANGE IN COBOL PGM (INTERVIEW -
> 3 KIND OF RESUME 1. ONLY DEVELOPER

2. ONLY SUPPORT APPLICATION

3**. MAINTENACE -SUPPORT


> HOW DO U GET THE WORK?
-> BUEINSS USER -> IDEA / REASON FOR A DATA PROCESS
-> SME (SUBJECT MATTER EXPERT) -> DISCUSSION
-> ONSITE CO-ORDICAT -> ANALYSIS -> TECH -> DETAILS -> ESTIMATES
-> CAN WE DO THE WORK OR NOT
-> ESTIMATE -> BELOW < 80HR -> MAINTENACE WORK
> 80 -120 - 250- 1000 -> DEVELOP/ENCHANMENT

-> MAINT -> CHANGE -> CHANGE TICKET/CHANGE REQUEST (CR) <
SERVICE NOW TOOL
-> DEVELOPER -> JIRA -> QA TOOL --> WORKING MODEL ->
AGILE PROCESS (OLD -WATER FALL ->BIG PROJECT)

--> AS A DEVELOPER -> CHANGE -> 1. CHANGE REQUEST - PROCESS


2. AGLIE PROCESS

-> AGLIE PROCESS -> QUCIK & PERFECT METHOD

-> SPRINT -> DURATION OF THE WORK - 2 WEEK


->
1. SPRINT PLANNING MEETING -> 10 TASK - "USER STORY" -> HOW MANY ,
WHICH 1ST ,2DN - HOW MANY HOURS
-> ALLOCATION OF THE WORK IS TO DONE -> 80
HR
USER STORY -> POINT 1 , 2 ,3 ,4 , 5
| | |
20 HR 40HR 250 -> 1.
ANALYSIS - > 20
-> 2. DEVELOPR ->
20
-> 3. TESTING ->
40

2. STAND-UP MEETING -> EVERY DAY -> U NEED TO UPDATE TASK DETAILS

3. END OF THE SPRINT -> SOME USER STORY WILL BE COMPLETED , SOME THEY
WONT

4. BACKLOG MEETING -> RE=COLLECT -> USER STORY -> NEW & PENDING

5. ALL STEP -> WE DO LOT OF DOCUMENTATION

--> TO TRACK UR WORK STATUS & WORK HOURS --> TOOL -> JIRA TOOL < CHECK THIS
YOUTUBE

--> ONCE WE GET THE WORK -> WE NEED TO MAKE A CHANGE IN THE COBOL PGM , COPYBOOK

1. VERSION CONTROL TOOL: 0> CHANGEMANG , ENDEVOR**

IN MAINFRAME -> Z/OS --> TSO --> TSO-PROD


--> TSO-TEST/DEV --> ENVEDOR TOOL
CICS
IMS

--> TSO -> TEST/DEV -> ENDEVOR TOOL: -> 1. PROD ENV -> [Link]
PGM-P1 -V01 - V02

2. DEVL ENV -> [Link].DEV1 PGM-P1 -V01


-> CHANGE -> PGM-P1 -V02
[Link].DEV2 PGM P1 -V01
< HERE MY CHANGE
[Link].DEV3

3. TEST ENV -> [Link].TST1


-> [Link].TST2

-> TSO -> PROD - -> NO TOOL -> 1. PROD PDS -> [Link]
[Link]

WITHIN THE TOOL: (EXISTING PROG) > CHANGE REQUEST)

1. CHECKOUT -> OPTION 'G' - GENERATOR


-> COPY THE CODE FROM PROD --> TO DEV ENVIRONMNET
(DURING THE KT -> WE SHARE - ENV DETAILS)

2. STAGE -> OPTION E- EDITING -CHANGE


-> COMPILATION-> 2 CASE
1. CHANGE & COMPILE --> E-
EDIT -> CHANGE - F3 & ENTER -> COMPILE JOB SUB.
2. WITHOUT CHANGE -> COMPILE --> G
- GENERATE -TO COMPILE JOB SUBMIT.

3. PROMOTE(TEST) -> OPTION DT (DEPOLY TO TEST)


-> ENV -> 1. UNIT TEST
2. SYSTEM TEST
3. QULITY TEST (PRE-PROD ENV)
-> PERFORM THE TESTING
-> IF REQUIRED _ DEBUG HERE ONLY.

4. IMPLEMENTATION -> 1. CREATE THE PACKAGE < WE KEEP ALL THE


PGM,COPYBOOK
2. > 'TSO PACKAGE' -> CREATED -> STATUS
'CASTING'
3. > WE NEED REQUST -> SME -> APPROVAL OF THE
PACKAGE
4. SME -> APPROVES THE PACKAGE
5. BATCH JOB -> RUN - 15MIN CYCLE

1. FIND THE PACKAGE -> APPROVED STATUS


2. 1. MOVE THE CODE-LOAD TO PROD ENV
-> COBOL PGM -> COPY LOAD FROM
TEST/DEV -> PROD
-> COBOL-DB2 -> PRE-COMPILATION
TEST -> LOAD -> COPIED TO PROD
-> DBRM
-> COPIED TO PROD + BIND PROCESS EXEC
3. IF ABOVE STEP IS SUCCESSFUL
1. COPY THE DEV CODE (PGM -P1 -V2)
- COPIED TO - PROD -> PGM P1 V1

> PGM P1 V2** < CURRENT


2. DELETE ANY LEFTOVER ->
DEV/PACKAGE

Common questions

Powered by AI

The deployment process begins in the development environment, where code is edited and compiled, often using a version control tool like Endevor. After successful testing, the code is promoted through stages such as unit, system, and quality testing, using tools like Changeman or Endevor. Once testing is complete, a TSO package is created and requires SME approval before it can be implemented in the production environment. Post-implementation checks include running batch jobs to ensure code integrity and performance in production .

When a COBOL batch job Abends, the developer uses the scheduler tool to rerun the job, and they must never submit any production job directly through a method like '3.4'. The job is managed through the scheduler tool which allows the developer to monitor the job cycle and manage dependencies. If a rerun fails, a ticket is created for application support for further investigation .

Debugging a COBOL program with XPEDITOR involves creating a debug profile tailored to the program type, whether it's COBOL-only, COBOL-DB2, or COBOL with CICS. The developer prepares test jobs and data by replicating production conditions as closely as possible in a test environment. During debugging, variables and their values are checked, and control flows are examined by setting breakpoints and using step-through execution to identify errors in the program logic .

If an application support analyst at L2 cannot resolve a job failure, they perform an initial analysis and attempt to fix the issue. If the problem persists, they escalate it to L3, where an SME or client team might be involved for resolution. This escalation ensures that the issue receives the necessary expertise, and the analyst follows formal protocol by logging the details in a ticketing system .

To set up a scheduler for a new JCL job, the process involves identifying the process name, application, and event details. The schedule frequency—whether hourly, daily, or monthly—along with specific calendar considerations like holidays or month-end dates, must be determined. Job dependencies are also set to ensure correct execution order. Once details are confirmed, the process is moved to production, where the development team may request or coordinate with S-Team to make necessary changes .

Job scheduling overlaps in batch processing can lead to significant performance bottlenecks, as jobs may contend for system resources, causing delays or failures (Abends). To mitigate these issues, careful planning and scheduling are needed, accounting for dependencies and job priorities. Implementing buffer periods and leveraging the scheduler tool to rerun jobs in cases of failure can help manage overlaps. Furthermore, adjusting job frequencies and utilizing tools to monitor and analyze job performance can optimize the batch cycle efficiency .

Version control in mainframe environments, such as z/OS, supports development and maintenance by allowing developers to manage code changes systematically. Tools like Endevor allow for checkout, modification, and staging of programs in controlled environments. This ensures precise version management, facilitates collaboration among teams, and maintains a history of changes, all of which are crucial for complex and large-scale applications running on mainframes .

In Agile methodology, tasks are managed through sprints lasting typically two weeks. Each sprint involves planning meetings to allocate and prioritize tasks, daily stand-up meetings for updates, and a backlog meeting to reassess ongoing and new user stories. Documentation of work status and hours is crucial, facilitated by tools like JIRA, enabling the consistent tracking and adaptation of the workflow based on feedback and progress, ensuring agility and responsiveness in project management .

The Service Level Agreement (SLA) provides specific time frames for responding to and resolving incidents of varying priorities. For instance, a P1 urgent incident requires a response time of 2 to 15 minutes and resolution within 2 to 4 hours . This helps in prioritizing tasks and ensuring timely resolution based on the severity of incidents, thus maintaining service quality and client satisfaction.

Testing a new COBOL program involves preparing the development environment with proper dataset names to avoid writing to production files. Using XPEDITOR, the program undergoes debugging with a focus on correctly handling test data and monitoring variable values. Developers use a checklist for reviewing test results, performing unit tests first and progressing through system and quality assurance testing. After validation, any discovered issues are resolved, and the program is prepared for deployment through version control systems like Endevor, ensuring readiness for production .

You might also like