|
We found a problem with program OSLPCP3/PC155 in a unique circumstance with Work Orders that had created detail records in MSTEXT (MSP02) but had somehow had their Status set back to a '1'... When users chose to create details again the segment of text shown below was executed and caused an infinite loop on our system that wrote 98 MILLION records on our disk before the problem was discovered...!!! I got woken up at 3:30 AM by a user who found this problem because the AMDAYEND routine locks the users out of the system... I was upset when they called, when I finally realized what was going on I was glad they called... It took us two days and a trigger program over MSP02 later to finally find the source (excuse the pun) of the problem... PS - The problem still exists in V3.5.2B SP3 too...!!! Here is the segment of code from PC155 that causes the infinite loop...: 0805.00 C K02 SETLLMSTEXT 891016 0806.00 C K02 READEMSTEXT 96 891016 0807.00B01C *IN96 DOWEQ'0' 891016 0808.00 C Z-ADDL#IDAT TXDT02 891016 0809.00 C WRITEMSR02 920702 (Time Bomb from July 2, 1992) 0810.00 C TXLN02 ADD 1 EXTLIN 40 891016 0811.00 C K02 READEMSTEXT 96 891016 0812.00E01C END 891016 (This code segment is like the train track scene from "The Wrong Trousers" with Wallace and Gromit when they are chasing the penguin around the house on the model train... Gromit is laying down new track sections as fast as he can just before the train runs over them...) Each record that is written is the next one read in the loop so this loop will run until either the file is full or the disk is full (if the file is set to MAXRCDS(*NOMAX) which in our case it was...Ooooo)...!!! The line numbers are different in 3.5.2B so I'll include that code segment here as well...: 0847.00 C K02 SETLLMSTEXT 891016 0848.00 C K02 READEMSTEXT 96 891016 0849.00B01C *IN96 DOWEQ'0' 891016 0850.00 C Z-ADDL#IDAT TXDT02 891016 0851.00 C WRITEMSR02 920702 0852.00 C TXLN02 ADD 1 EXTLIN 40 891016 0853.00 C K02 READEMSTEXT 96 891016 0854.00E01C END 891016 We have purged our system of duplicate records in file MSP02 but wanted to report this obvious logic flaw in the hopes that it could be removed from the system in order to prevent someone else's system from having their disk get filled up without them knowing about it...!!! I have another question related to this... There is a program that runs in the AMDAYEND routine - MS902 - Utilities - Clear redundant text records. Why does this program even exist...? Could it be because of the logic error in PC155 that I have reported above...? We would never have found the problem unless either the disk got full or the MS902 program held up our night job trying to delete 98 MILLION records...!!! MS902 was deleting records from MSP02 as fast as PC155 was writing them... A real comedy of errors...! This is a real flaw and if you have a programmer look closely at the logic you will easily see the logic flaw I'm referring to... If you cannot see it then call me and I'll be happy to explain it to you... Thank you. +--- | This is the JBA Software Users Mailing List! | To submit a new message send your mail to JBAUSERS-L@midrange.com. | To subscribe to this list send email to JBAUSERS-L-SUB@midrange.com. | To unsubscribe from this list send email to JBAUSERS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: doug333@aol.com. +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.