top of page

Optimizing JOB.LIST Files in T24 Core Banking Operations

Writer: Josef MayrhoferJosef Mayrhofer

When a job is executed during COB, the corresponding files are selected based on the underlying query, and the record IDs to be processed by the job are written inside the file F_JOB_LIST_xx. Then, the tSA (agents) would pick and process each ID from the job list.

 

Recommended behavior of the BATCH JOBs executed during the COB

When a job is started processing, the job list file for this job is initialized according to the internal code. Then, the job's select command is executed, and the record IDs are written inside the initialized job list. Then, all the agents will access the job list file. All the running agents pick IDs one by one and process them.

 

The size (jrf) recommendation for these files

The job list files are used only when we run services like COB, SWIFT services… (Services defined in TSA.SERVICE). Once the service is complete, the job list files will become empty. Also, the job list files are accessed every day. So, the file doesn't require file maintenance.


Get jobs and report lists

Which Batch is running what JOB, and which JOB is generating what reports

By using the below commands, you can know  which Batch is running what JOB and which JOB is generating what reports

>LIST F.JOB.TIMES

>LIST F.REPORT.TIMES

 

Tuning considerations:

 

  1. JOB.LIST files increase in size daily

    JOB.LIST tables are temporary files that are used by the COB/service framework to populate record keys that will be processed by the tSA agents. The data written to these tables depends on the nature of the job that utilizes it. Hence, there is a chance that these could have larger data/record keys written to them. All these data/record keys will be processed and deleted by the TSA agents after the job is successfully completed. 

    However, this will not reduce the physical size of this JOB.LIST tables consumed in the Table space. File maintenance activity must be run on these tables periodically. We recommend generating a script that would select all the T24 JOBs.LIST tables and run the shrink commands in a timely fashion to reduce the unclaimed LOB size, which is obviously expected in the OLTP environments like T24.


  1. The system crashes while trying to access/create a JOB.LIST when running COB/ Online Services

    We request you check the ORA/SQL/XMLdriver.log for the timestamp when the problem occurred.

 

  1. Residual entries in JOB.LIST

    Residual entries are still present in the JOB.It is a list file, though the job says it is completed.

    Additionally,' Job finished by another thread' can be seen in the COMO records.

    You need to check whether the 'ROLLBACK' flag is correct.

     

  2. Some F_JOB_LIST_xx files contain some records before the COB.

    Please note that if any job list files contain data before COB is started, it is not a problem. The contents of the job list will be because of some other service (SWIFT service, STATEMENT.PRINT) running in the system. This will not lead to any miscalculation with the processing of COB. Each job list will be handled properly against the corresponding service.

     

  3. DW export performance linked to JOB.LIST

    The fields BULK.NO and BBL.CALL in the DW.EXPORT.PARAM records are to be set  for all lead companies

    When a large amount of data is being extracted from an application, these fields will ensure a smooth extraction and avoid hanging. These fields are globally used for all DW.EXPORT records extraction.


  4. BYTELEN function in BATCH.BUILD.LIST

    The BYTELEN function is used in BATCH.BUILD.LIST takes more time when the large array of keys is passed. It tries to execute the  BYTELEN for the whole array by 4KB, which causes the performance overhead to take time to write the JOB.LIST.

Keep up the great work! Happy Performance Engineering!



Comments


bottom of page