Академический Документы
Профессиональный Документы
Культура Документы
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. 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
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
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
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.
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.
Without caching, all the 10 reads and writes would have taken place directly to disk thus
increasing the I/O.
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.
2. It holds the day wise job statistics for every job that ran during COB
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
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. 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
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
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
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.
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.