Difference between revisions of "Information Systems:Overnight Process Problems"
m (Norwinu moved page Information Systems:Overnight Problems to Information Systems:Overnight Process Problems) |
|||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | =Rebuild Time Axis Files Does not Complete= |
|
| + | |||
| − | * [[Rebuild Time Axis Files Does not Complete]] |
||
| + | EODUPD calls CL program DMC951 (Rebuild time axis file). |
||
| + | |||
| + | '''Clear SROTAF (Time axis file)''' |
||
| + | |||
| + | '''DMR951 (Reset time axis quantities in the warehouse file)''' |
||
| + | |||
| + | -In file SROSRO (Warehouse balance), clear fields SRCUSQ (Quantity on sales order), SRPURQ (Quantity on purchase order), SRPICQ (Quantity on pick list), and SRALCY (Order allocation qty) |
||
| + | |||
| + | '''DMR952(Update time axis and corresponding whs fields)''' |
||
| + | |||
| + | -Read SR10RL, which is a joined file of open sales order and purchase order lines. Accumulate, by item and warehouse, and update the fields cleared by DMR951. Then call DMR906 (Update time axis file) to update fields PLCUSO (Quantity on sales orders) and PLPURO (Quantity on purchase orders) on file SROTAF (Time axis file). |
||
| + | |||
| + | If this process is interrupted, SRPICQ (Quantity on pick list) on file SROSRO (Warehouse balance) may be zero instead of the actual quantity ready to be picked. However this shouldn't be much of an issue, as the warehouse picks most orders before the end of day. |
||
| + | |||
| + | But we may accept a few orders for items that have already been allocated to another order. I think that this is less of a risk than trying to correct SROTAF and SROSRO while orders are coming in the next morning. Or shutting down Web Orders to fix these files. |
||
| + | |||
| + | =Overnight Processing Does not Complete= |
||
| + | |||
| + | Six emails are issued as a part of the overnight processing so it can be monitored. There are two issues - has everything completed properly, and is there still enough time for one step to finish before the next step starts. See the [[Overnight Schedule]] for information on this last one. |
||
| + | |||
| + | [[Category: Overnight Processing]] |
||
| + | |||
| + | The subject lines of the emails are a bit terse so that the entire subject will fit onto the BlackBerry display. |
||
| + | |||
| + | ==EOD starting (2:15 3:00 5:00 6:30)== |
||
| + | |||
| + | This message is sent by program [[EODDAILY]] at 1:00AM; which is when the scheduler submits job ENDOFDAY. It includes the expected arrival times of the next four messages to make it easier for us to notice when something isn't right. Just be aware that a missing email doesn't necessarily mean it wasn't sent - sometimes the BlackBerry just doesn't receive them. |
||
| + | |||
| + | ==Daily overnite processing ended Normally== |
||
| + | |||
| + | The last thing program [[EODDAILY]] does, is to send this message. If it is not sent, it could mean program [[EOD]] did not complete, and some investigating has to be done. Look into the reports that are generated. Key in WRKSPLF EODJOB and press enter. Press page down until you get to the end of the reports that are status RDY (ready). Go back to find the latest DMR352P INVJOURNAL. Use option 5 on it, then F20 (upper shift - F8) to see the date and time in the upper right hand corner of the report. If it is not dated today, the overnight processing didn't even start. All the transactions from yesterday will be updated tonight. It means that, for example, yesterday will have no sales, and today will have double. We can live with that; but purchase suggestions will have to manually generated. |
||
| + | |||
| + | If the invoice journal is there, check to see if there were any purchase suggestions generated. From a command line in ASW, key in GO PURCHP and press enter. Select option 2 - Work with Purchase Suggestions. Clear your ID from the 'Handler' selection (bottom of the screen) and press enter. If there is nothing with today's date, DIS to FIN probably did not complete. I looked at a couple of these base ASW programs, and they are pretty well behaved - they either delete or flag the records after they are updated. DIS to FIN failed to complete several times when we were having the problem with the firmware, and it didn't seem to cause a problem. Again, anything that did not update, will do so next time. Also again, purchase suggestions will have to manually generated. |
||
| + | |||
| + | If there are some purchase suggestions, the next question is, did they complete? We can tell by looking at the file (SROPHH.B1) that is created in the next step. On a command line in ASW, key in WRKOBJ SROPUH.B1 and press enter. Use option 8 on the file to display the description. Page down to see 'Change date/time'. It should be this morning, just after 2AM. If it is yesterday, the purchase suggestions did not complete, and will have to be manually generated. |
||
| + | |||
| + | Everything that [[EOD]] runs after this can wait until tonight. |
||
| + | |||
| + | ==Full backup is starting== |
||
| + | |||
| + | This is sent by program [[EODBU]] at 3:00AM; which is when the scheduler submits job EODSAVE. |
||
| + | |||
| + | ==All systems are back up== |
||
| + | |||
| + | If the backup completes properly, this should be sent around 5:00AM. |
||
| + | |||
| + | It takes about 10 minutes to get into the system restricted state; that plus the batch limit timer of 150 minutes means that if the system is still down at around 5:40AM, it will be automatically started up. So if this message is sent after that, the daily backup did not complete. That is okay, as we have the full backup from the previous day, and the temporary backup run at 1AM. But you should look at the log and at QSYSOPR messages to find out what the problem was. |
||
| + | |||
| + | ==Statistics files rebuild is complete== |
||
| + | |||
| + | This program, [[EODREBLD]], was submitted by [[EOD]] to run after the system restricted state ends. Which is normally around 5:00AM. If it doesn't complete, most of the files will be correctly updated the next time it is run. Some will have to be done manually. |
||
| + | |||
| + | Note that in the following sections, the date formats are '''CCYYMMDD'''. |
||
| + | |||
| + | ===Sales order pattern, or sales by hour=== |
||
| + | |||
| + | Check to see it this updated by keying in the commands - |
||
| + | |||
| + | strsql |
||
| + | |||
| + | select * from ordpatp where opdate = '''yesterday''' |
||
| + | |||
| + | One record should be displayed. Press F3 twice, and enter to exit. |
||
| + | |||
| + | If nothing is displayed, add the record now by keying in CALL PGM(BLDORDLIN) PARM(' ') and pressing enter. (Note that this is eight blanks, which tells the program to use yesterday's date.) If there is already a record on the file, it will be deleted and re-added. |
||
| + | |||
| + | ===VEBA by province by day=== |
||
| + | |||
| + | Check to see it this updated by keying in the commands - |
||
| + | |||
| + | strsql |
||
| + | |||
| + | select count(*) from vebaprov where vpdate = '''today''' |
||
| + | |||
| + | The count should be around 100,000; or the number of items in the master file. Press F3 twice, and enter to exit. |
||
| + | |||
| + | If the count is either zero, or too low, add/replace the records now by keying in CALL PGM(BLDVEBA) PARM(' ') and pressing enter. (Note that this is eight blanks, which tells the program to use today's date.) If there are already some records on the file, they will be deleted and re-added. |
||
| + | |||
| + | ==Tape 0000xx used for Power8 backup== |
||
Latest revision as of 09:16, 7 July 2016
Rebuild Time Axis Files Does not Complete
EODUPD calls CL program DMC951 (Rebuild time axis file).
Clear SROTAF (Time axis file)
DMR951 (Reset time axis quantities in the warehouse file)
-In file SROSRO (Warehouse balance), clear fields SRCUSQ (Quantity on sales order), SRPURQ (Quantity on purchase order), SRPICQ (Quantity on pick list), and SRALCY (Order allocation qty)
DMR952(Update time axis and corresponding whs fields)
-Read SR10RL, which is a joined file of open sales order and purchase order lines. Accumulate, by item and warehouse, and update the fields cleared by DMR951. Then call DMR906 (Update time axis file) to update fields PLCUSO (Quantity on sales orders) and PLPURO (Quantity on purchase orders) on file SROTAF (Time axis file).
If this process is interrupted, SRPICQ (Quantity on pick list) on file SROSRO (Warehouse balance) may be zero instead of the actual quantity ready to be picked. However this shouldn't be much of an issue, as the warehouse picks most orders before the end of day.
But we may accept a few orders for items that have already been allocated to another order. I think that this is less of a risk than trying to correct SROTAF and SROSRO while orders are coming in the next morning. Or shutting down Web Orders to fix these files.
Overnight Processing Does not Complete
Six emails are issued as a part of the overnight processing so it can be monitored. There are two issues - has everything completed properly, and is there still enough time for one step to finish before the next step starts. See the Overnight Schedule for information on this last one.
The subject lines of the emails are a bit terse so that the entire subject will fit onto the BlackBerry display.
EOD starting (2:15 3:00 5:00 6:30)
This message is sent by program EODDAILY at 1:00AM; which is when the scheduler submits job ENDOFDAY. It includes the expected arrival times of the next four messages to make it easier for us to notice when something isn't right. Just be aware that a missing email doesn't necessarily mean it wasn't sent - sometimes the BlackBerry just doesn't receive them.
Daily overnite processing ended Normally
The last thing program EODDAILY does, is to send this message. If it is not sent, it could mean program EOD did not complete, and some investigating has to be done. Look into the reports that are generated. Key in WRKSPLF EODJOB and press enter. Press page down until you get to the end of the reports that are status RDY (ready). Go back to find the latest DMR352P INVJOURNAL. Use option 5 on it, then F20 (upper shift - F8) to see the date and time in the upper right hand corner of the report. If it is not dated today, the overnight processing didn't even start. All the transactions from yesterday will be updated tonight. It means that, for example, yesterday will have no sales, and today will have double. We can live with that; but purchase suggestions will have to manually generated.
If the invoice journal is there, check to see if there were any purchase suggestions generated. From a command line in ASW, key in GO PURCHP and press enter. Select option 2 - Work with Purchase Suggestions. Clear your ID from the 'Handler' selection (bottom of the screen) and press enter. If there is nothing with today's date, DIS to FIN probably did not complete. I looked at a couple of these base ASW programs, and they are pretty well behaved - they either delete or flag the records after they are updated. DIS to FIN failed to complete several times when we were having the problem with the firmware, and it didn't seem to cause a problem. Again, anything that did not update, will do so next time. Also again, purchase suggestions will have to manually generated.
If there are some purchase suggestions, the next question is, did they complete? We can tell by looking at the file (SROPHH.B1) that is created in the next step. On a command line in ASW, key in WRKOBJ SROPUH.B1 and press enter. Use option 8 on the file to display the description. Page down to see 'Change date/time'. It should be this morning, just after 2AM. If it is yesterday, the purchase suggestions did not complete, and will have to be manually generated.
Everything that EOD runs after this can wait until tonight.
Full backup is starting
This is sent by program EODBU at 3:00AM; which is when the scheduler submits job EODSAVE.
All systems are back up
If the backup completes properly, this should be sent around 5:00AM.
It takes about 10 minutes to get into the system restricted state; that plus the batch limit timer of 150 minutes means that if the system is still down at around 5:40AM, it will be automatically started up. So if this message is sent after that, the daily backup did not complete. That is okay, as we have the full backup from the previous day, and the temporary backup run at 1AM. But you should look at the log and at QSYSOPR messages to find out what the problem was.
Statistics files rebuild is complete
This program, EODREBLD, was submitted by EOD to run after the system restricted state ends. Which is normally around 5:00AM. If it doesn't complete, most of the files will be correctly updated the next time it is run. Some will have to be done manually.
Note that in the following sections, the date formats are CCYYMMDD.
Sales order pattern, or sales by hour
Check to see it this updated by keying in the commands -
strsql select * from ordpatp where opdate = yesterday
One record should be displayed. Press F3 twice, and enter to exit.
If nothing is displayed, add the record now by keying in CALL PGM(BLDORDLIN) PARM(' ') and pressing enter. (Note that this is eight blanks, which tells the program to use yesterday's date.) If there is already a record on the file, it will be deleted and re-added.
VEBA by province by day
Check to see it this updated by keying in the commands -
strsql select count(*) from vebaprov where vpdate = today
The count should be around 100,000; or the number of items in the master file. Press F3 twice, and enter to exit.
If the count is either zero, or too low, add/replace the records now by keying in CALL PGM(BLDVEBA) PARM(' ') and pressing enter. (Note that this is eight blanks, which tells the program to use today's date.) If there are already some records on the file, they will be deleted and re-added.