D
dbeavon
Guest
The only message is 14438. I thought about the possibility that this might be a STOP too (and was therefore bypassing my apperror CATCH statements.) But there were no lock wait timeout messages in the agent logs, and I can't imagine STOP coming up this frequently for any other reason. I'm fairly convinced now that these are Progress.Lang.Error which represent a .Net problem. We use .Net very little in abl, but it is possibly just enough to see a few of these 14438 messages every day. I suppose that if we are going to use the clr bridge more frequently (now that we are getting out of HpUx) then we should probably start adding the extra CATCH statements in order to handle anything based on the Progress.Lang.Error interface. Something came to my mind today about Progress errors. Don't you have a secret way to edit the PROMSGS file to incorporate special behaviors? Ie. so that an occurrence of a rare error, like 14438, will trigger memory dumps, stack traces (prostack and native) and give us better clues about the source of the problem? I think that the sysinternals "process monitor" is also able to show the stack trace for every file operation (eg at the moment that the 14438 message is written to the log) That would probably give an obscure native stack, But I doubt it would help identify the prostack. Ultimately I will probably just restart pasoe with 4gltrace level 2.
Continue reading...
Continue reading...