Add Problem Log Entry (QsxAddProblemLogEntry) API

Required Parameter Group:

1	Handle	Input	Binary(4)
2	Key structures	Input	Array of Pointers
3	Number of keys	Input	Binary(4)
4	Error code	I/O	Char(*)

  Default Public Authority: *USE

  Service Program: QSXSRUPL

  Threadsafe: No

The Add Problem Log Entry (QsxAddProblemLogEntry) API adds information to an existing problem log entry.

The API supports the following data types:

Keys 2001-2009 (field replaceable unit (FRU) entries) can be added to the problem log entry.
Keys 4001 and 4002 (supporting data) entries can be added. Do not add duplicate information because checking is not performed.
Key 6001 (history information) can be added.
Key 7001 (PTF ID) can be added to a problem log entry. If the PTF entry already exists, an error is signalled.

Authorities and Locks

API Public Authority: *USE

Required Parameter Group

Handle: INPUT; BINARY(4)
An identifier that associates the problem log services started by the Start Problem Log Services API.
Key structures: INPUT; ARRAY of POINTERS
An array of pointers that has the address of each key that contains data to be written into the problem log. The number of pointers passed in the array must equal the value passed by the Number of keys parameter. Keys not supported for the Add Problem Log Entry API cause error messages to be sent to the caller.
Number of keys: INPUT; BINARY(4)
Number of keys passed to the API.
Error code: I/O; CHAR(*)
The structure in which to return error information. For the format of the structure, see Error code parameter.

Rules for Key Usage

Key 1 (problem log ID) is required to identify the problem log entry to process.

Data can be added to an existing problem log entry with the Add Problem Log Entry API. The types of data that may be added with this API are:

Keys 2001-2009 (FRU entries)
Supporting data entries (keys 4001 and 4002 (supporting data)
Key 6001 (history information)
Key 7001 (PTF ID)

The remaining data contained in a problem can be altered using the Change API. More information on the above keys can be found in Key Groups for Problem Log APIs.

Keys for Adding FRU Records

A FRU, field replaceable unit, entry defines an object that may have a specific machine-detected problem. FRUs have been broken into 9 types and represented by keys 2001 through 2009.

The types are:

2001	Device FRU type
2002	Code FRU type
2003	Media FRU type
2004	User FRU type
2005	FRU name
2006	Attached FRU
2007	Configuration FRU
2008	General FRU
2009	Channel attached FRU

In addition, a FRU or list of FRUs are associated with a problem based upon an analysis class. The analysis class implies the amount or type of analysis that has been done on the problem. FRUs are associated with a problem within the context of a class.

The classes of FRUs are:

1	Point of failure
2	Partial isolation
3	Isolation
4	Verification
5	Recovery
6	Answer

To add FRUs for a class of FRUs, the problem log entry must be identified, the class must be chosen, and the data must be added. These three actions need to be done for each FRU type. FRUs may be used in any combination, to add data about individual failing elements to a maximum of 21 FRUs per class.

This API adds FRU entries to the bottom of the list. If they need to be maintained in probability order, follow these steps:

Retrieve the group using the Retrieve Problem Log Entry API.
Modify the FRU records or append additional FRUs to the original list.
Delete the existing FRU entries of that class using the Delete Problem Log Entry API.
Add the new or updated FRU list using the Add Problem Log Entry API.

Keys for Adding Supporting Data

The addition of supporting data is not restricted. Any number of spooled or data base files can be associated with a problem log entry. Duplicate records are allowed. If you add a file twice, it is listed twice.

To add supporting data, define the type of record to be added using keys 4001 and 4002 (supporting data). They can be added in any combination.

Keys for Adding History Data

The addition of history data, or events, is restricted because specific events can occur only when the problem is in a specific status. Some history data types are applicable to specific problem log types. Any number of events can be associated with a problem log entry. Duplicate records are allowed since many events can be repeated. Events are added in the sequence that you supply them on the API call. The API makes no attempt to put them in order.

To add a history entry, use key 6001 (history information) to supply the needed data to reflect the action that was taken. If you are adding supporting data, you can add it in any combination. The time the event is added is entered by the API.

The history types are:

01	Problem entry opened. Can only be used when the problem is initially opened.
02	Service request received. Only applicable when a problem is received from another system.
03	Opened by an alert. Only applicable when the problem is opened due to an alert.
04	Reported by HMC.
05	Reported by service partition
06	Recovery procedure ran.
07	CIM indication was generated.
10	Problem analyzed. Applicable each time a problem is analyzed.
11	Verification test ran. Applicable each time a problem is verified.
12	Recovery procedure ran. Applicable each time recovery is run.
13	Problem analysis failed.
20	Prepared to report. Applicable each time a problem is prepared to be sent to a service provider.
21	Service request sent. Applicable only when a problem is sent to another system. This implies that the service request was sent, but the service provider has no solution to the problem.
22	Problem answered. Applicable only when a problem is sent to another system. This implies that the service request was sent, and the service provider has a solution to the problem.
23	Response sent. Implies that a reply has been received from a service provider.
24	Reported by voice. Used when a problem is reported manually.
25	Fixes transmitted. Implies that fixes have been sent to a service requester.
26	A change request was submitted for this problem.
27	The change request submitted for this problem has ended.
30	Fix verified. Applicable each time a problem is verified.
41	Remote analysis. Only applicable when a problem has been analyzed by a remote service representative.
42	Remote verification ran. Only applicable when this system has been used to analyze a problem on another system.
43	Remote recovery ran. Only applicable when this system has been used to perform recovery on another system.
50	Alert created. Only applicable when the system created an alert for this problem.
51	APAR created. Only applicable when APAR data is created during analysis.
52	APAR data collected. Only applicable when APAR data is collected during analysis.
54	APAR data restored. Only applicable when APAR data is restored during analysis.
55	APAR data deleted. Only applicable when APAR data is deleted during analysis.
60	Changed by CHGPRB. Only applicable when the problem was changed by the CHGPRB command or the QsxChangeProblemLogEntry API.
61	Deleted by DLTPRB. Only applicable when the problem was changed by the DLTPRB command or QsxDeleteProblemLogEntry API.
62	This problem has occurred multiple times.
70	Status changed. Only applicable when querying the status of a problem that has been reported to a service provider.
71	Status query sent. Only applicable when querying the status of a problem that has been reported to a service provider.
80	Automatic problem analysis has completed successfully.
81	Auto-PAR is not complete; the SRC flag is off. Problem analysis did not occur because the SRC was turned off.
82	Auto-PAR not complete, submit job to QSYSWRK failed.
83	Auto-PAR failed. Problem analysis failed because an unknown problem occurred.
86	Auto-Notify complete. Problem was sent automatically.
87	Auto-Notify not complete, SRC flag is off. Problem was not sent automatically, the SRC was turned off.
88	An attempt to automatically send the problem failed.
89	Auto-Notify failed.
99	Problem entry closed. Only applicable when the problem has been closed. Once this status is set, the problem can only be retrieved.

See the Basic system operations topic collection for more information about SRCs.

Keys for Adding PTF Entry

PTF entries can be added to the problem log at any time. Duplicate PTF records are not allowed and signal an exception condition. To ensure uniqueness, the PTF identifier and the product data are required.

To add a PTF record, use key 7001 (PTF ID) to add the data required. The PTF entry is added to the bottom of existing text.

To get the PTF records in a specific order, the records must be retrieved, sorted and then replaced after the existing PTF records are deleted.

PTF entries can be created using *ONLY*PRODUCT** as the constant for Product ID and *ONLY as the constant for version, release, and modification level.

Error Messages

Message ID	Error Message Text
CPF3C1E E	Required parameter &1 omitted.
CPF3C90 E	Literal value cannot be changed.
CPF3CF1 E	Error code parameter not valid.
CPF3CF2 E	Error(s) occurred during running of &1 API.
CPF7AAB E	Problem &1 not found.
CPF3C4D D	Length &1 for key &2 not valid.
CPF3C82 D	Key &1 not valid for API &2.
CPF3C86 D	Required key &1 not specified.
CPD7A82 D	Value not valid for key &1. (char string)
CPD7A83 D	Value not valid for key &1. (integer)
CPD7A88 D	Incorrect DBCS field format found.
CPD7A8A D	Key value &1 is not valid.
CPF7A89 E	Incorrect handle for this activation.
CPF7A8A E	Problem log services not started.
CPF7AA7 E	Problem &1 not found.
CPF9821 E	Not authorized to program &1 in library &2.
CPF9872 E	Program or service program &1 in library &2 ended. Reason code &3.
CPFA320 E	Pointer parameter is null.

API introduced: V3R1

[ Back to top | Problem Management APIs | APIs by category ]