As a suggestion, John, maybe you could put a trigger on the SYS.MESSAGE file to capture what's being written. Be sure to put it on the BEFORE UPDATE and BEFORE WRITE steps. In the trigger, write the data, including record key, to a file in the accounts main data location or maybe even on another disk partition.
All depends on how much work you're wanting to put into tracking down the problem. Good luck, BobW -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Kent Sent: Wednesday, February 08, 2006 2:04 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] SYS.MESSAGE file being corrupted Charles, when SYS.MESSAGE was not read only it was being written to by Universe (say IBM) and corrupted and the box fell over. The times were between between 6am - 10am, which would not be a busy period . I have sent all 3 copies of the corrupted file to IBM This file was identified because the date/time stamp had been modified. The file was replaced with a good one the box rebooted and all ok. No other problems. This happened 3 times in 3 months so IBMs suggestion was to make the file read only. After that the edi script process started playimg up with those cant write to a read only file messages that i cant reproduce. However this is happening more regularly than the above. All the above only started happening in the last 3 months and the system has been in place for many years. Thanks for the interest shown. Here are some comments from IBM " There is a pattern, I just don't know how to interpret it. Best guess would be something (backup?) blocking access to 'C:\UV\UV\UVtemp' directory. Possibly a process that doesn't have write access to the directory. Maybe a defect where universe creates the temporary file with one name then tries to access using another key. Might ask the customer to check for capture04380aa and capture04948aa in 'C:\UV\UV\UVtemp' directory. I remember a problem long ago where the SYS.MESSAGE file was corrupted each evening. That was diagnosed to processes being spawned from cron. When the customer modified the job stream to instead of executing universe from cron to instead use cron to start phantoms, the problem went away. That was back at either release 7 or 8 of universe. The pattern is that all three files have corruption starting at address 0x0001B800 which would be group 55 of the SYS.MESSAGE file. In all three cases the error begins with There are currently 37 users logged on the system. (37 in second case is '2', and '16' for third case). This most likely is SYS.MESSAGE '001739' >CT SYS.MESSAGE 001739 0001 There are currently %i users logged on the system. 0002 > Where it gets interesting is that group 55 is always the beginning of the corruption, and this record hashes to group 54. >RECORD SYS.MESSAGE 001739 Record "001739" hashes to group 54 and was found. > The most common use of this message record would be with the USERS command: >USERS There are currently 2 users logged on the system. The fact the SYS.MESSAGE file is being corrupted is due to a defect in UniVerse. The defect being a situation that universe isn't dealing with. Were this my case, I would probably concentrate first on trying to isolate a routine that was doing a EXECUTE 'USERS' CAPTURING RESULTS Would expect something unusual with regard to the routine. Started by 'at', started as a 'batch' job etc.. Would check to see if the pid numbers being assigned to processes might be impacting the problem. There have been some strange things with regard to large pid numbers. Windows uses these though it usually takes weeks between boots to get into the high numbers. " jak ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
