On 03 May 2013 12:06, Jack Kingsley wrote:
What controls the system (analysis) as it pertains to entries that
end up in WRKPRB. Let's say someone removes the entries and you want
to re-evaluate the system for any errors.
I am not clear on what is being asked, but here is an overview for
the /problem/ support; followed by some other comments and a link:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/ddp/rbal1probover.htm
_i i5/OS problem handling overview i_
"The i5/OS® licensed program helps you manage problems for both
user-detected and system-detected problems that occur on local and
remote System i® platforms.
The i5/OS operating system tracks both user- and system-detected
problems using the problem log and the problem manager. A problem state
is maintained from when a problem is detected (OPENED) to when it is
resolved (CLOSED) to help you with tracking.
Problem handling support includes:
* Messages with initial problem handling information
* Automatic alerting of system-detected problems
* Integrated problem logging and tracking
* First-failure data capture (FFDC)
* Electronic customer-support service requisition
* Electronic customer support, program temporary fix (PTF) requisition
_System-detected problems_
The i5/OS operating system and its attached devices are able to detect
some types of problems. These are called system-detected problems. When
a problem is detected, several operations take place:
* An entry in the product activity log is created
* A problem record is created
* A message is sent to the QSYSOPR message queue
Information is recorded in the error log and in the problem record. When
serious problems are detected, a spooled file of FFDC information is
also created. The error log and the problem record might contain ..."
The first in the above list is with regard to LOGPRB(*YES) in
messages [ADDMSGD] whereby that message has an "error log identifier"
associated with which to record as a problem, its being sent.
The second deals with ALERTS [WRKALR; see also SC41-5413] which also
is available in messages [CHGMSGD] using Alert Options (ALROPT)
specifications.
The third I believe is general, referring to WRKPRB, ANZPRB, and
other infrastructure, including the APIs listed later\below.
The fourth is the OS components logging unexpected conditions\effects
using the APIs listed later; or possibly implicitly code with only as
much is provided by the Log Problem message feature when the error is
something just plain /bad/ versus software-detected anomalies within its
own processing.
The remainder [fifth and sixth] are ECS functions which are basically
problem analysis and pursuit of fixes; possibly for problem log entries,
though they need not be.
FWiW the "product activity log" [mentioned after that list of six
items] are often referred to as the PAL or PALs, which is different than
the VLogs.
Here is a list of some Problem Log APIs; knowing of them and review
of them may be helpful beyond just the overview to understand more about
system and user problem log entries:
* QsxAddProblemLogEntry
* QsxChangeProblemLogEntry
* QsxCreateProblemLogEntry
* QsxDeleteProblemLogEntry
* QsxRetrieveProblemLogEntry
FWiW: A link about FFDC [FFDC is noted in the first\overview link]
and text that names a system value required for its functionality:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/ddp/rbal1appxffdcdump.htm
_i First-failure data capture dump i_
"System-detected internal failures trigger first-failure data capture
(FFDC) data to be dumped. FFDC output can be disabled by setting the
QSFWERRLOG system value to *NOLOG, but it is strongly recommended that
you do not disable the FFDC dump process.
..."
midrange.com
