1.

Welcome to the “Close Of Business - Important Concepts and COB Crashes”

learning unit. This learning unit will help you understand some additional
information which will help you manage COB better

COB3.Close Of Business - Important Concepts and COB Crashes -R14 1

 After completing this learning unit/course, you will be able to:

• Use additional fields in PGM.FILE for a job

• Use additional fields in BATCH application
• Learn the selection logic
• Understand the concept of Caching during COB
• Understand the information shown in JOB.TIMES application
• Understand certain COB crashes and their analysis

COB3.Close Of Business - Important Concepts and COB Crashes -R14 2

 1. It is possible for you to have ID filtering Logic in the record routine of the Multi threaded job.
This eradicates the need to have a “.FILTER” routine. You are already aware that the record
routine takes in the Contract ID to be processed as a parameter. If the Contract ID needs to be
processed then the record routine can go ahead and process it otherwise it can reject it

2. The routine can return -1 or -2, depending upon if the Contract ID should be accepted or
rejected.

3. Based on the return value, BATCH.JOB.CONTROL, will update the field REC.VERIFY in
the PGM.FILE entry for that job, to “Y” or “N”, indicating Yes(if return value is -1 or -2) or No,
otherwise.

4. What are we trying to achieve by doing this?

If a value of Yes is returned, what BATCH.JOB.CONTROL is trying to say is that, this job has
the internal logic to Check if the Contract ID needs to be processed or not in the Record
Routine of the Job. In other words the record routine has the logic to accept or reject a
Contract ID.

4. For E.g.: The name of the job is ROUTINE1 and takes in ID.REC as a parameter. Now,
within the logic of the record routine we can write a simple IF condition to decide whether the
Contract ID should be processed or rejected.
- If the Contract ID is accepted then the Record Routine (ROUTINE1) will return a value of
“–1” in the variable ID.REC. Subsequently BATCH.JOB.CONTROL, will update the PGM.FILE
with the field REC.VERIFY with the value “Y”, indicating that this job has record verification
capabilities
- If the Contract ID is rejected then the Record Routine (ROUTINE1) will return a value of

COB3.Close Of Business - Important Concepts and COB Crashes -R14 3

 “–2” in the variable ID.REC. Subsequently BATCH.JOB.CONTROL, will still update the
PGM.FILE with the field REC.VERIFY with the value “Y”, indicating that this has record
verification capabilities

COB3.Close Of Business - Important Concepts and COB Crashes -R14 3

 1. In PGM.FILE, REC.VERIFY is a NO.INPUT field and will be updated only by
BATCH.JOB.CONTROL. This field will be updated during COB.

2. After the RECORD.VERFIY has been updated with a value by the system, the field
BYPASS.SEL opens up for input by the user. The allowed values and Y and N.
-This field can be updated with a “Y” if the system has to bypass the selection criteria
made on the .SELECT routine of the batch job. In this case, the system will select all
the records from the file and send it to the record routine. This is because the record
routine now has the capability to accept or reject an ID.
-This file can be updated with “Y” only if RECORD.VERIFIY is set to Y. If this field is
set to N then the system will follow the normal procedure of using the criteria in the
.SELECT routine

Q. What is the advantage of these two fields?

A.Simple, To Improve Performance! If the Record routine of the job has ID filtering
logic, then you can set BYPASS.SEL field to “Y”. Instead of doing a complex select,
the system will do a simple Internal select on the file which is much faster than a
SELECT with any condition

For e.g.: SELECT FBNK.CUSTOMER instead of SELECT FBNK.CUSTOMER WITH

SECTOR GT 1200. BATCH.JOB.CONTROL will pass the CUSTOMER ID’s one by
one to the record routine. You can write the logic in the record routine to decide if the
CUSTOMER ID needs to be processed or not based on the SECTOR with a simple IF
condition.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 4

 1. The client might want to Bulk records in a particular job to improve performance. In
that case, he can open the PGM.FILE entry for that job and enter the number of
contracts to bulk in the field BULK.NO. It also possible to specify the bulk no in the
sixth position of the first parameter to BATCH.BUILD.LIST. However, the value
configured in PGM.FILE takes precedence. The value in this field should be
numeric and between 1 and 200 as the maximum bulk limit is 200.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 5

 1. It is possible for jobs to do selection earlier than it’s configured stage. This feature
can be configured at individual job level using SELECT.AHEAD field in BATCH
application. It breaks away from the traditional COB framework i.e., idle sessions
during an earlier stage can be tuned to do the selection of such jobs. Whenever
there is an idle time encountered by the agents, the agents irrespective of the
batch stage will jump ahead to do just the SELECT part for a job in a different
batch stage. Only list file allocation and initial selection is done in the stage
mentioned in SELECT.AHEAD, not the processing. But this should not be used for
business dependent jobs(like PD select before a LD job etc.,)
This fastens COB times and prevents having any idle agents running.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 6

 1. From R10, by default the static cache (cache used by CACHE.READ), will be
cleared only when the batch stage changes(i.e., A to S, S to R etc.,) unlike before
when the static cache was cleared after every job. If you still want to clear the
cache like before and not during batch stage change, then set the field
CLEAR.STATIC.CACHE to ‘YES’.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 7

 1. Once the LOAD has been completed, the select routine needs to be executed. The
result of the select is a list of contracts populated in a LIST file
2. Has the select routine told how many contracts to write in 1 record of the LIST file
(Bulking)?
3. If not, then T24 will assign the logic

LOGIC 1: For the first 100 contract id’s selected (as a result of the select statement),
there will be one contract id per record in the LIST FILE

LOGIC 2: If the number of contract ids selected are more than 100 but less than or
equal to thousand, then for the first hundred contracts logic 1 will apply. For the
remaining contract ID’s, there will be 10 contract ID’s per record in the LIST FILE

LOGIC 3: If the number of contract id’s selected are more than 1000 but less than or
equal to 10000, then for the first hundred contracts logic 1 will apply, for 101 to 1000
contracts logic 2 will apply. For the remaining contract ID’s, there will be 100 contract
ID’s per record in the LIST FILE

LOGIC 4: If the number of contract id’s selected are more than 10,000, then for the
first hundred contracts logic 1 will apply, for 101 to 1000 contracts logic 2 will apply, for
1001 – 10,000 contracts logic 3 will apply. For the remaining contract ID’s, there will be
200 contracts per ID in the LIST file

COB3.Close Of Business - Important Concepts and COB Crashes -R14 8

 1. Let’s assume the select routine retrieved 5 contract id’s.
2. How many records will be created in the LIST FILE?
2.1 The LIST file will have 5 records. Each record will hold 1 contract ID.

In the snapshot, List file records 1 and 5 contain 1 FT contract Id each.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 9

 1. For conceptual view, the LIST FILE as a result of the previous select will look like
this.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 10

 1. Let’s assume the select routine retrieved 130 contract id’s
2. How many records will be created in the LIST FILE?
2.1 The first hundred contracts are written into hundred LIST file records (Record ID
1-100). Each LIST file record contains one contract ID as shown in the snapshot
2.2 The 30 remaining contracts, are written into 3 LIST records - (30/10) with record
ID’s 101,102 and 103. Each record contains 10 contract ID’s.
2.4 Therefore, total number of LIST Record ID’s created will be 100 + 3 =103 and the
total number of contracts selected = 130.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 11

 1. For conceptual view, the LIST FILE as a result of the previous select will look like
this -

COB3.Close Of Business - Important Concepts and COB Crashes -R14 12

 1. By default before getting into the record routine, the cache is turned on thus making
sure that all the reads and writes that happen within the routine will be cached. This is
done to improve performance of COB

2. This is controlled by common variables CACHE.OFF and WRITE.CACHE. Values in

CACHE.OFF controls if the entire caching should be turned on or turned off. Values in
WRITE.CACHE controls, if F.WRITE should write to disk or write to cache during
COB

3. Both the common variables are defined in I_COMMON insert file

4. When CACHE.OFF is equal to zero or NULL, then this is to tell the system to use
cache,
5. When CACHE.OFF is equal to one, then it is to switch off caching. Which means
telling the system NOT TO use cache

6. When WRITE.CACHE is set to zero or NULL then all the F.WRITES will not write to
cache, it will directly write to disk
7. When WRITE.CACHE is set to one, then all the F.WRITES will write to cache. Later
when there is a TRANS END, all the data will be dumped from cache to disk.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 13

 1. In BATCH.JOB.CONTROL, before calling the RECORD.ROUTINE, the Caching is
switched ON, by setting the variables CACHE.OFF = 0 and WRITE.CACHE = 1, to
use the Cache and Write to Cache.

2. Then the Record Routine is called. Within the record routine, imagine 10 reads and
writes happen, all the reads and writes are done from cache.

3. Now the record routine has completed its task and the control is back in
BATCH.JOB.CONTROL, in that a check is done to see if WRITE.CACHE is still on.
Sometimes it can be turned off in the record routine, so just to be sure a check is
done.

4. When there is a TRANSEND, the data is flushed from cache to disk.

Without caching, all the 10 reads and writes would have taken place directly to disk thus
increasing the I/O.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 14

 1. It is possible to turn off Caching through the PGM.FILE. This is done so that it is
configurable at user level rather than the routine level.

2. Open the PGM.FILE entry for the job

3. In the ADDITIONAL.INFO field set the value to “.NUC” which stands for NOT USE
CACHE. This means that when this job is running the caching will be turned off.
Any writes will directly take place to disk and not to cache.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 15

 1. BATCH.THREAD.KEY is a common variable defined in I_BATCH.FILES. It
contains the LIST.KEY ID followed by a space and the Current CONTRACT ID
being executed. For e.g.: 1 space FT2345600001, means the current LIST KEY
being read is 1 and the contract being processed is FT2345600001

2. C$BATCH.START.DATE is a common variable defined in I_BATCH.FILES that

contains the date on which COB is started. For e.g.: If cob was started on 3rd Feb
2009, during start of day, the date would be rolled forward to 4th Feb 2009. This
variable will however contain the value 3rd Feb 2009.

3. BATCH.INFO is a common variable in I_BATCH.FILES which contains the

information of the current job process and routine being executed. Example
BNK/AA.ARR.PRODUCT.TRACKERFMBATCH.JOB.CONTROLFMAA.ARR.PRO
DUCT.TRACKER

COB3.Close Of Business - Important Concepts and COB Crashes -R14 16

 1. This application is a Live file and is updated by T24

2. It holds the day wise job statistics for every job that ran during COB

3. The ID of a record in this application is <Process-Name>-<Job-Name>

4.1 E.g.: BNK/AA.SOD.PROCESS-AA.SERVICE.PROCESS

4. JOB.TIMES file will maintain details of each job's information for 10 days

5. This will facilitate Batch performance tuning and better analysis of each job

6. JOB.TIMES.HISTORY is a file which is an exact replica of JOB.TIMES in terms of

the structure. This file will be updated whenever JOB.TIMES is modified and each
record in this file will contain the same record of JOB.TIMES just before it was
updated

COB3.Close Of Business - Important Concepts and COB Crashes -R14 17

 1. START.TIME specifies the start time of the job
2. END.TIME specifies the end time of the job
3. TOTAL specifies the number of records selected for processing
4. THROUGHPUT specifies the records processed per minute. THROUGHPUT
indicates the overall performance of the job (Avg time taken to process each
transaction) calculated as: keys processed / elapsed time * 60
5. COMPLETED specifies the total number of records processed by the job
6. LAST TIME specifies the Total time taken for processing of all records in seconds
7. TXN.MANAGEMENT – This field will be updated with N if the field
ADDITIONAL.INFO in the PGM.FILE record of the batch job is set to “.NTX”. This
means “No Transaction Boundary”. That is the JOB doesn’t follow the default
transaction boundary. Otherwise, this field will be set to “Y”
8. BULK.NUMBER – This field shows the number of records that have been bulked
in the particular job
9. READ.WRITE.CACHE – If CACHE.OFF = 0 or NULL, then this field will contain
“Y” to indicated cache is used. If CACHE.OFF = 1, then this field will contain “N” to
indicate cache is not used
10. LOCK.COLLISSION – If the job routine encounters a lock collision, then this field
will be updated with the number of collisions that the job has experienced during
that particular day’s COB. You need to know the cumulative number of lock
collisions in the job. This is to find out whether the job needs a design change or
there is a setup issue. This can also given a clear picture on the duration of the
job.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 18

 1. There is an Enquiry called JOB.PROGESS in T24 that will help you to view the
status of the BATCH jobs and how the jobs have progressed. This enquiry is
based on the application JOB.TIMES

COB3.Close Of Business - Important Concepts and COB Crashes -R14 20

 Many a times agents run into locking scenarios, the following methods can be used to
analyse the locks

1. mw42 – This is a jBASE utility to be executed at jBASE shell which will give the
details of every active port, their database usage and what is the current line of
code being executed. If the port is waiting on a lock the same will be shown as
BLOCK with information on the key and the file name

2. WHERE V <PORT NUMBER> - This gives more expanded information on the

particular port. The port number can be accessed from TSA.STATUS file for both
online and COB sessions.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 21

 1. SHOW-ITEM-LOCKS – This command displays the list of active locks and the
owner (port number). This command also contains information on the pending lock
request and who owns the same. If there is a value in the last column it means
that port is holding the lock which is requested by the port in the first column.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 22

 1. A critical job (PGM.FILE entry for job contains “.CRITICAL”)
COB.CHECK.EB.EOD.ERROR will crash if there are records in EB.EOD.ERROR
with errors that have not yet been rectified.

2. COB should not start the next day before correcting errors registered in
EB.EOD.ERROR

3. However, when a Critical JOB crashes, it will not create a EB.EOD.ERROR entry
as the error should be corrected before restarting COB

You will now see what happens when a critical job crashes

COB3.Close Of Business - Important Concepts and COB Crashes -R14 23

 1. When you are running COB in interactive mode, the error will be displayed on the
screen and the control will go back to jshell prompt

2. If you are running COB in phantom mode, the enquiry AGENT.STATUS will show
you that the agent has stopped. You will have the COMO ID of the agent, go to the
backend and list the &COMO& file with the day you ran COB

COB3.Close Of Business - Important Concepts and COB Crashes -R14 24

 1. In this screen shot you are able to see the output recorded in the COMO file

2. Open the BATCH record to notice the Process Status and Job Status field. The
value is updated to Error/Hold meaning that this job has encountered an error.
The field Job Message contains the error message due to which the JOB crashed

COB3.Close Of Business - Important Concepts and COB Crashes -R14 25

 1. Open the TSA.SERVICE record COB, notice that the SERVCIE has stopped.
Which means that the error has to be corrected and then the service needs to be
started again.

2. List records in EB.EOD.ERROR. You will see that only the previous Error is
logged and not the error caused due to the failure of the CRITICAL job during the
current COB.

3. Open the EB.EOD.ERROR record. You will see the details of the error.

Once the error has been rectified.

1. Set the Service Control field to “Start” in the TSA.SERVICE record COB

2. If running in phantom mode, the agents will automatically started as TSM is still
running
3. If running in interactive mode, the TSM will prompt you to launch the agents
manually, you will have to launch the agents (tSA) one by one.

COB3.Close Of Business - Important Concepts and COB Crashes -R14 26

 1. Some times COB crashes and returns to the Debugger Prompt (This will happen if
you are running COB in interactive mode).
In phantom mode, the agent will hang for a long time. Analysing the COMO file will
help you find out the reason for the error
2. You can type C (to continue). COB will crash and return to jshell prompt. You will
have to correct the error before starting COB again. In this case there is a missing
LOAD routine. Recompiling the routine solved the problem

- In this scenario the SERVICE.CONTROL field for the COB record in

TSA.SERVICE will not be set to STOP.
- The PROCESS.STATUS and the JOB.STATUS field will still be in status 1

COB3.Close Of Business - Important Concepts and COB Crashes -R14 27

 1. True
2. False – BYPASS.SEL in PGM.FILE has to be set to Yes
3. False – When the batch stage changes
4. True
5. False – Only for critical errors

COB3.Close Of Business - Important Concepts and COB Crashes -R14 28

 In this learning unit, you learnt about Important Concepts and COB Crashes

You will now be able to:

1. Use additional fields in PGM.FILE for a job

2. Use additional fields in BATCH application
3. Learn the selection logic
4. Understand the concept of Caching during COB
5. Understand the information shown in JOB.TIMES application
6. Understand certain COB crashes and their analysis

COB3.Close Of Business - Important Concepts and COB Crashes -R14

COB3.Close Of Business - Important Concepts and COB Crashes -R14 30