resent, original reply bounced
There are several important things you need to know ...
The DB2 system is multi address space *MSTR, *DBM1, *IRLM, DIST
Messages can go to any of these address spaces.
Not all messages go to the system address spaces
Some go to
Application address space
Applications in the form of being passed back and forth in a control
block
Applications responsibility to externalize
Some to non zOS clients perhaps OMVS or a distributed service.
Sometimes messages go to system address spaces and sometimes identical
messages do not
For example command output id issued via the console is routed
differently than the same output via dsn processor
I would suggest first determining if the DB2 job log the data source you
need, it often is not.
For non system job log data the volume of records and configuration issues
can be quite complex ... there is no unified source or procedure to obtain
all DB2 messages and fortunately it is rarely required.
For non solicitude critical system events a logrec is usually cut.
Reviewing logrec may be the place to start.
Application errors are very tricky to catch.
There are a few papers floating around that suggest what messages should
have some automation associated with them.
The direction of the industry for many years has been to avoid console
dependencies.
Avram Friedman
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
