I agree about numberless and undocumented messages. Except from my code, of course.
How about determining what disks/filespaces are accessed my your server, then running a Pipe to read in every accessed ececutable file (MODULE, LOADLIB, EXEC, and XEDIT to start), run a LOCATE stage for that message string, and display the match with the matching file ID? Mike Walter Hewitt Associates (Sent from the wee keyboard on a Blackberry.) ----- Original Message ----- From: "Schuh, Richard" [[email protected]] Sent: 05/15/2009 04:13 PM MST To: [email protected] Subject: CSLCALL TRACE We have a SVM that periodically complains that "File CSLCALL TRACE not found" - note the lack of a message number, the quote is complete and exact. Would I be correct is concluding that this is a quirk/problem with the 3rd-party s/w running in that machine? I can find no file named CSLCALL banana anywhere on either CMS22 or CMS23. Neither can I find CSLCALL in the other vendor's documentation. It seems not to hurt anything, probably being a part of bug shooting code that is not active until it is turned on (possibly by the presence of the file), but it is annoying to have undocumented error messages from sourceless s/w. Regards, Richard Schuh The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
