friedkiwi/ibm-information-center
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
0332907f0f
ibm-information-center/dist/eclipse/plugins/i5OS.ic.apis_5.4.0.1/qsxchgpl.htm

870 lines
25 KiB
HTML
Raw Normal View History

Add readme and dist folders
2024-04-02 14:02:31 +00:00
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Copyright" content="Copyright (c) 2006 by IBM Corporation">
<title>Change Problem Log Entry (QsxChangeProblemLogEntry) API</title>
<!-- Begin Header Records ========================================== -->
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<!-- QSXCHGPL SCRIPT A converted by B2H R4.1 (346) (CMS) by KENTALA -->
<!-- at RCHVMW2 on 2 Oct 1998 at 12:36:43 -->
<!-- Change History: -->
<!-- YYMMDD USERID Change description -->
<!--File Edited by Kersten Nov 2001 -->
<!--End Header Records -->
<link rel="stylesheet" type="text/css" href="../rzahg/ic.css">
</head>
<body>
<a name="Top_Of_Page"></a>
<!-- Java sync-link -->
<script language="Javascript" src="../rzahg/synch.js" type="text/javascript">
</script>
<h2>Change Problem Log Entry (QsxChangeProblemLogEntry) API</h2>
<div class="box" style="width: 80%;">
<br>
&nbsp;&nbsp;Required Parameter Group:<br>
<!-- iddvc RMBR -->
<br>
<table width="100%">
<tr>
<td align="center" valign="top" width="10%">1</td>
<td align="left" valign="top" width="50%">Handle</td>
<td align="left" valign="top" width="20%">Input</td>
<td align="left" valign="top" width="20%">Binary(4)</td>
</tr>
<tr>
<td align="center" valign="top">2</td>
<td align="left" valign="top">Key structures</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Array of Pointers</td>
</tr>
<tr>
<td align="center" valign="top">3</td>
<td align="left" valign="top">Number of keys</td>
<td align="left" valign="top">Input</td>
<td align="left" valign="top">Binary(4)</td>
</tr>
<tr>
<td align="center" valign="top">4</td>
<td align="left" valign="top">Error code</td>
<td align="left" valign="top">I/O</td>
<td align="left" valign="top">Char(*)</td>
</tr>
</table>
<br>
&nbsp;&nbsp;Default Public Authority: *EXCLUDE<br>
<!-- iddvc RMBR -->
<br>
&nbsp;&nbsp;Service Program: QSXSRVPL<br>
<!-- iddvc RMBR -->
<br>
&nbsp;&nbsp;Threadsafe: No<br>
<!-- iddvc RMBR -->
<br>
</div>
<p>The Change Problem Log Entry (QsxChangeProblemLogEntry) API updates an
existing problem entry by changing the information. Key 1 (problem log ID)
identifies the problem to be changed. Some data in the problem log entry can be
changed on a field by field basis while other data can only be changed as a
group and some data cannot be changed.</p>
<br>
<h3>Authorities and Locks</h3>
<dl>
<dt><em>API Public Authority</em></dt>
<dd>*USE</dd>
</dl>
<br>
<h3>Required Parameter Group</h3>
<dl>
<dt><strong>Handle</strong></dt>
<dd>INPUT; BINARY(4)
<p>An identifier that associates the problem log services started with the
QsxStartProblemLogServices API.</p>
</dd>
<dt><strong>Key structures</strong></dt>
<dd>INPUT; ARRAY of POINTERS
<p>An array of pointers to the key structures being passed to the API.</p>
</dd>
<dt><strong>Number of keys</strong></dt>
<dd>INPUT; BINARY(4)
<p>Number of keys passed to the API.</p>
</dd>
<dt><strong>Error code</strong></dt>
<dd>I/O; CHAR(*)
<p>The structure in which to return error information. For the format of the
structure, see <a href="../apiref/error.htm#hdrerrcod">Error Code Parameter</a>.</p>
</dd>
</dl>
<br>
<h3>Format of the Keys</h3>
The number of keys used varies depending on the type of problem log entry being
changed. You must select the keys applicable to the problem type with which you
are working. If the keys provided to the API do not match the requirements for
the problem log entry type you are changing, you are notified by the error
handling procedures.
<p>For details about the keys that can be used, see <a href="pmkeygroups.htm">Key
Groups for Problem Log APIs</a>.</p>
<br>
<h3><a name="HDRCHGRULE">Rules for Key Usage</a></h3>
<p>You can change the problem log data, the status, or both. The problems are
categorized into the following types:</p>
<table cellpadding="5">
<!-- cols="5 95" -->
<tr>
<td align="left" valign="top">1</td>
<td align="left" valign="top">Machine-detected problem</td>
</tr>
<tr>
<td align="left" valign="top">2</td>
<td align="left" valign="top">User-perceived hardware or software problem</td>
</tr>
<tr>
<td align="left" valign="top">3</td>
<td align="left" valign="top">PTF orders</td>
</tr>
<tr>
<td align="left" valign="top">4</td>
<td align="left" valign="top">User-perceived remote problem</td>
</tr>
<tr>
<td align="left" valign="top">5</td>
<td align="left" valign="top">Application-detected problem</td>
</tr>
<tr>
<td align="left" valign="top">6</td>
<td align="left" valign="top">Client machine-detected problem</td>
</tr>
<tr>
<td align="left" valign="top">7</td>
<td align="left" valign="top">Client user-detected problem</td>
</tr>
<tr>
<td align="left" valign="top">8</td>
<td align="left" valign="top">User-created general problem</td>
</tr>
</table>
<h4>Changing General Data</h4>
<p>General data is data that can be changed for any problem type without
affecting the status of the problem. Data of this class are:</p>
<ul>
<li>Key 4 (user assigned). The validity of this data is not checked.</li>
<li>Key 3001 (text entry) problem types 1, 2, and 4 can be changed.</li>
<li>Key 6001 (history information). Use the Add Problem Log Entry
(QsxAddProblemLogEntry) API.</li>
</ul>
<br>
<h4>Changing Problem Status</h4>
<p>To change the problem status, specific data is required. The amount of data
depends on the current or requested problem log status. Data that requires a
status change cannot be added unless key 3 (problem status) is provided. An
error is signaled if this occurs.</p>
<p>A problem can be changed to the following statuses:</p>
<ul>
<li>OPENED
<p>The beginning status of a problem.</p>
</li>
<li>OPENED-PREPARED
<p>Problem is staged for transmission to a service provider.</p>
</li>
<li>READY
<p>Problem entry has been analyzed and data is provided by keys that reflects
the analysis results.</p>
</li>
<li>READY-PREPARED
<p>Problem is staged for transmission to a service provider.</p>
</li>
<li>SENT
<p>Problem has been sent to a service provider and a solution was not
available.</p>
</li>
<li>SENT-PREPARED
<p>Problem is staged for transmission to a service provider.</p>
</li>
<li>ANSWERED
<p>Problem has been sent to a service provider and a solution was
available.</p>
</li>
<li>ANSWERED-PREPARED
<p>Problem is staged for transmission to a service provider.</p>
</li>
<li>VERIFIED
<p>User has applied and tested the solution provided. The results of the
testing are satisfactory. Once a problem is moved to VERIFIED status, it cannot
be returned to OPENED or READY status.</p>
</li>
<li>VERIFIED-PREPARED
<p>Problem is staged for transmission to a service provider.</p>
</li>
<li>CLOSED
<p>Problem is resolved and there is no longer a need for the problem entry.
Once this status is set, it cannot be returned to any other status. The problem
can only be retrieved.</p>
</li>
</ul>
<p>PREPARED, while displayed as a specific status, is actually an amplifier to
the previous status of the problem: OPENED, READY, SENT, ANSWERED or
VERIFIED.</p>
<p>The supplemental data needed to move a problem to PREPARED status are:</p>
<ul>
<li>Key 6 (operational data)
<ul>
<li>Prepared for system
<p>Required to define the system that this problem will be sent to.</p>
</li>
</ul>
</li>
<li>Key 1001 (problem severity)
<ul>
<li>Optional. If not provided, the API defaults it to None.</li>
<li>Prohibited for PTF orders (problem type 3).</li>
</ul>
</li>
<li>Key 1011 (PTF media selection)
<p>Optional. Defines the media on which a program fix can be delivered. If not
provided, the contact data is used as a default. Typically this is the tape
device type and model or a description of the media type on which PTFs are
delivered if the distribution size exceeds a predefined transmit size
limit.</p>
</li>
<li>Key 5001 (contact information)
<p>Optional. Used to override local service contact information.</p>
</li>
</ul>
<p>A problem can be set to PREPARED status by providing the required data keys
(if not already provided) and a key 3 (problem status) code of 5.</p>
<br>
<h4>Keys for Changing Problem Type 1 to Another Status</h4>
<p>Problem type 1 (machine-detected problems) requires data from two additional
key groups, 1000 and 2000.</p>
<p><strong>Note:</strong> When changing status and FRU entries are required,
use the Add Problem Log Entry API. To change status in general, you do not need
the key group 2000 data.</p>
<ul>
<li>Data for OPENED status
<p>A problem in OPENED status, with the exception of general data that does not
affect a status change, can only be changed to READY status. A problem may be
changed from OPENED status to PREPARED status if the problem is to be sent to
an iSeries server that has System Manager installed.</p>
</li>
<li>Data for READY status
<p>A problem can be changed from OPENED to READY status by including the
following data items:</p>
<ul>
<li>Key 3 (problem status) indicates READY status.</li>
<li>Key 1004 (reporting device) is always required to identify the product with
a maintenance contract, regardless of the problem.</li>
<li>Key 1006 (reporting code) is required for problems that were, on analysis,
determined to be caused by software.</li>
<li>Key 1010 (symptom string).</li>
<li>Key 1007 (problem analysis data).</li>
</ul>
</li>
<li>Data for SENT and ANSWERED status at the service requester
<p>A problem can be changed to SENT or ANSWERED status by including the
following data items:</p>
<ul>
<li>Key 3 (problem status) indicates SENT or ANSWERED status.</li>
<li>Key 8 (answer codes).
<p>At the service requester the answer code assigned field should be updated
with the answer received from a service provider that is not *IBMSRV.</p>
<p>If *IBMSRV was the service provider, the Problem number field should be
updated to reflect the problem management number that *IBMSRV has associated
with the problem.</p>
</li>
<li>Key 7001 (PTF ID) is used to change the Sent and Status fields.</li>
</ul>
<p>Once the problem is in SENT or ANSWERED status, text can be added that
defines the problem status. This is data that is added as a response to a query
of the problem status or as an answer the service provider sends to the
problem. This is done with key 3001 (text entry), type 3. Key 6001 (history
information) is required to indicate the action has taken place.</p>
<p>If the local system is acting as a service provider, the problem log entry
for the service requester can be updated to reflect the following
conditions:</p>
<ul>
<li>A response was sent</li>
<li>PTFs were sent</li>
<li>An answer was added to the problem log</li>
</ul>
<p>These actions do not require a status change. Add a history event to define
the action taken.</p>
</li>
<li>Data for ANSWERED status at the service provider
<p>When a service provider answers a problem, the status is changed from READY
status to ANSWERED status by including the following data items:</p>
<ul>
<li>Key 3 (problem status) indicates ANSWERED status.</li>
<li>Key 6001 (history information) can add a number of events depending on the
status change.</li>
<li>Key 7001 (PTF ID) is used to change the Sent and Status fields of the PTF
entry.</li>
</ul>
<p>Once the problem is in ANSWERED status, text can be added that defines the
problem status. This is data that is added as a response to a query of the
problem status or as an answer the service provider wants to add to the
problem. This is done with key 3001 (text entry), type 3. Key 6001 (history
information) is required to indicate the action has taken place.</p>
<p>When a response is sent to the service requester, key 6 (operational data)
is used to indicate that a response was sent. The following data items are
required:</p>
<ul>
<li>Key 8 (answer codes) is updated to indicate the answer that was sent to the
service requester.</li>
<li>Key 6001 (history information) can add a number of events depending on the
status change.</li>
<li>Key 7001 (PTF ID) is used to change the Sent and Status fields.</li>
</ul>
If PTFs were sent or an answer was added to the problem log, these actions do
not require a status change. Add a history event to define the action
taken.</li>
<li>Data for VERIFIED status
<p>A problem can be changed to VERIFIED status from READY, SENT or ANSWERED
status by including the following data items:</p>
<ul>
<li>Key 3 (problem status) indicates VERIFIED status.</li>
<li>Key 1008 (fix verification status) where the Status field and PDP field
must be provided.</li>
<li>Key 6001 (history information) can add a number of events depending on the
status change. The Remote verification ran field is required based on the
origin system location.</li>
<li>FRUs (key group 2000) are added for machine-detected problems and are added
with the Add Problem Log Entry API.</li>
</ul>
</li>
<li>Data for recovery
<p>Recovery data can be added from OPENED or READY by including the following
data items, and the status is not changed:</p>
<ul>
<li>Key 3 (problem status) is not permitted. The status does not change as a
result of running recovery procedures.</li>
<li>Key 1009 (fix recovery status) and problem determination procedures (PDP)
fields must be provided.</li>
<li>Key 6001 (history information) can add a number of events depending on the
status change. Remote recovery ran is required based on the origin system
location.</li>
</ul>
</li>
<li>Data for CLOSED status
<p>A problem can be changed to CLOSED status from any other status by including
the following data items:</p>
<ul>
<li>Key 3 (problem status) indicates that CLOSED status is the only key
allowed.<br>
</li>
<li>Key 6 (operational data) is updated by the API when the problem is
closed.</li>
</ul>
</li>
</ul>
<br>
<h4>Keys for Changing Problem Types 2, 4, 5, and 8</h4>
<p>Problem types 2 (User-perceived), 4 (User-perceived remote), 5
(Application-detected), and 8 (User-created general) require the following data
to achieve the following status:</p>
<ul>
<li>Data for OPENED status
<p>This does not apply because these problem types are created in READY
status.</p>
</li>
<li>Data for READY status
<p>This does not apply because these problems are created in READY status.</p>
</li>
<li>Data for SENT and ANSWERED status at the service requester
<p>A problem can be changed to SENT or ANSWERED status by including the
following data items:</p>
<ul>
<li>Key 3 (problem status) indicates SENT or ANSWERED status.</li>
<li>Key 8 (answer codes).
<p>At the service requester, the Answer code assigned field should be updated
with the answer received from a service provider that is not *IBMSRV.</p>
<p>If *IBMSRV was the service provider, the problem management number (PMR)
number field should be updated to reflect the problem management number that
*IBMSRV has associated with the problem.</p>
</li>
<li>Key 6001 (history information) can add a number of events depending on the
status change.</li>
<li>Key 7001 (PTF ID) is used to change the Sent and Status fields.</li>
</ul>
<p>Once the problem is in SENT or ANSWERED status, text can be added that
defines the problem status. This is data that is added as a response to a query
of the problem status or as an answer the service provider sends to the
problem. This is done with key 3001 (text entry), type 3. Key 6001 (history
information) is required to indicate the action has taken place.</p>
<p>If the local system is acting as a service provider, the problem log entry
for the service requester can be updated to reflect that a response was sent,
PTFs were sent, or that an answer is added to the problem log. These actions do
not require a status change. Add a history event to define the action
taken.</p>
</li>
<li>Data for ANSWERED status at the service provider
<p>When a service provider answers a problem, the status is changed from READY
status to ANSWERED status by including the following data items:</p>
<ul>
<li>Key 3 (problem status) indicates ANSWERED status.</li>
<li>Key 6001 (history information) can add a number of entries depending on the
status change.</li>
<li>Key 7001 (PTF ID) is used to change the Sent and Status fields.</li>
</ul>
<p>Once the problem is in ANSWERED status, text can be added that defines the
problem status. This is data that is added as a response to a query of the
problem status or as an answer the service provider wants to add to the
problem. This is done with key 3001 (text entry), type 3. Key 6001 (history
information) is required to indicate the action has taken place.</p>
<p>When a response is sent to the service requester, the problem log entry is
updated to reflect that a response was sent. The following data items are
required:</p>
<ul>
<li>Key 8 (answer codes) is updated to indicate the answer that was sent to the
service requester.</li>
<li>Key 6001 (history information) can add a number of events depending on the
status change.</li>
<li>Key 7001 (PTF ID) is used to change the Sent and Status fields.</li>
</ul>
If PTFs were sent or an answer was added to the problem log, these actions do
not require a status change. Add a history event to define the action
taken.</li>
<li>Data for CLOSED status
<p>A problem can be changed to CLOSED status from any other status by including
the following data items:</p>
<ul>
<li>Key 3 (problem status) indicates that CLOSED status is the only key
allowed.<br>
</li>
<li>Key 6 (operational data) is updated by the API when the problem is
closed.</li>
</ul>
</li>
</ul>
<br>
<h4>Keys for Changing Problem Type 3</h4>
<p>Problem type 3 (PTF order) requires the following data to achieve the
following status:</p>
<ul>
<li>Data for OPENED status
<p>This does not apply to PTF orders (problem type 3).</p>
</li>
<li>Data for READY status
<p>This does not apply to PTF orders (problem type 3) because they are created
in READY status.</p>
</li>
<li>Data for SENT and ANSWERED status at the service requester
<p>A problem can be changed to SENT or ANSWERED status by including the
following data items:</p>
<ul>
<li>Key 3 (problem status) indicates SENT or ANSWERED status.</li>
<li>Key 8 (answer codes).
<p>At the service requester the Answer code assigned field should be updated
with the answer received from a service provider that is not *IBMSRV.</p>
<p>If *IBMSRV was the service provider, the Problem number field should be
updated to reflect the problem management number that *IBMSRV has associated
with the problem.</p>
</li>
<li>Key 6001 (history information) can add a number of events depending on the
status change.</li>
<li>Key 7001 (PTF ID) is used to change the Sent and Status fields. This key is
also used to update the product and VRM fields of the PTFs, especially if the
default product, *ONLYPRD, and version, *ONLY, were used during the creation of
the problem or if the SNDPTFORD command used the defaults.</li>
</ul>
<p>Once the problem is in SENT or ANSWERED status, text can be added that
defines the problem status. This is data that is added as a response to a query
of the problem status or as an answer the service provider sends to the
problem. This is done with key 3001 (text entry), type 3. Key 6001 (history
information) is required to indicate the action has taken place.</p>
<p>If the local system is acting as a service provider, the problem log entry
for the service requester can be updated to reflect that a response was sent,
PTFs were sent, or that an answer is added to the problem log. These actions do
not require a status change. Add a history event to define the action
taken.</p>
</li>
<li>Data for ANSWERED status at the service provider
<p>When a service provider answers a problem, the status is changed from READY
status to ANSWERED status by including the following data items:</p>
<ul>
<li>Key 3 (problem status) indicates ANSWERED status.</li>
<li>Key 6001 (history information) can add a number of events depending on the
status change.</li>
<li>Key 7001 (PTF ID) is used to change the Sent and Status fields.</li>
</ul>
<p>Once the problem is in ANSWERED status, text can be added that defines the
problem status. This is data that is added as a response to a query of the
problem status or as an answer the service provider wants to add to the
problem. This is done with key 3001 (text entry), type 3. Key 6001 (history
information) is required to indicate the action has taken place.</p>
<p>When a response is sent to the service requester, the problem log entry is
updated to reflect that a response was sent. The following data items are
required:</p>
<ul>
<li>Key 8 (answer codes) is updated to indicate the answer that was sent to the
service requester.</li>
<li>Key 6001 (history information) can add a number of events depending on the
status change.</li>
<li>Key 7001 (PTF ID) is used to change the Sent and Status fields.</li>
</ul>
If PTFs were sent or an answer was added to the problem log, these actions do
not require a status change. Add a history event to define the action
taken.</li>
<li>Data for CLOSED status
<p>A problem can be changed to CLOSED status from any other status by including
the following data items:</p>
<ul>
<li>Key 3 (problem status) indicates that CLOSED status is the only key
allowed.<br>
</li>
<li>Key 6 (operational data) is updated by the API when the problem is
closed.</li>
</ul>
</li>
</ul>
<br>
<h4>Keys for Changing Problem Types 6 and 7</h4>
<p>Problem type 6 (client machine-detected) and problem type 7 (client
user-detected) require the Problem category field in key 1012 be set to 0
(Report) to move to PREPARED status.</p>
<br>
<h3>Error Messages</h3>
<table width="100%" cellpadding="5">
<!-- cols="15 85" -->
<tr>
<th align="left" valign="top">Message ID</th>
<th align="left" valign="top">Error Message Text</th>
</tr>
<tr>
<td width="15%" valign="top">CPF3C1E E</td>
<td width="85%" valign="top">Required parameter &amp;1 omitted.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3C90 E</td>
<td align="left" valign="top">Literal value cannot be changed.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3CF1 E</td>
<td align="left" valign="top">Error code parameter not valid.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3CF2 E</td>
<td align="left" valign="top">Error(s) occurred during running of &amp;1
API.</td>
</tr>
<tr>
<td align="left" valign="top">CPF7AAB E</td>
<td align="left" valign="top">Problem &amp;1 not found.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3C4D D</td>
<td align="left" valign="top">Length &amp;1 for key &amp;2 not valid.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3C82 D</td>
<td align="left" valign="top">Key &amp;1 not valid for API &amp;2.</td>
</tr>
<tr>
<td align="left" valign="top">CPF3C86 D</td>
<td align="left" valign="top">Required key &amp;1 not specified.</td>
</tr>
<tr>
<td align="left" valign="top">CPD7A82 D</td>
<td align="left" valign="top">Value not valid for key &amp;1. (char
string)</td>
</tr>
<tr>
<td align="left" valign="top">CPD7A83 D</td>
<td align="left" valign="top">Value not valid for key &amp;1. (integer)</td>
</tr>
<tr>
<td align="left" valign="top">CPD7A87 D</td>
<td align="left" valign="top">Key &amp;1 may be added only once.</td>
</tr>
<tr>
<td align="left" valign="top">CPD7A88 D</td>
<td align="left" valign="top">Incorrect DBCS field format found.</td>
</tr>
<tr>
<td align="left" valign="top">CPD7A8A D</td>
<td align="left" valign="top">Key value &amp;1 is not valid.</td>
</tr>
<tr>
<td align="left" valign="top">CPD7A8B D</td>
<td align="left" valign="top">Length of data not valid.</td>
</tr>
<tr>
<td align="left" valign="top">CPF7A89 E</td>
<td align="left" valign="top">Incorrect handle for this activation.</td>
</tr>
<tr>
<td align="left" valign="top">CPF7A8A E</td>
<td align="left" valign="top">Problem log services not started.</td>
</tr>
<tr>
<td align="left" valign="top">CPF7AA7 E</td>
<td align="left" valign="top">Problem &amp;1 not found.</td>
</tr>
<tr>
<td align="left" valign="top">CPF9821 E</td>
<td align="left" valign="top">Not authorized to program &amp;1 in library
&amp;2.</td>
</tr>
<tr>
<td align="left" valign="top">CPF9872 E</td>
<td align="left" valign="top">Program or service program &amp;1 in library
&amp;2 ended. Reason code &amp;3.</td>
</tr>
<tr>
<td align="left" valign="top">CPFA320 E</td>
<td align="left" valign="top">Pointer parameter is null.</td>
</tr>
</table>
<br>
<hr>
API introduced: V3R1
<hr>
<center>
<table cellpadding="2" cellspacing="2">
<tr align="center">
<td valign="middle" align="center"><a href="#top_of_page">Top</a> | <a href=
"pm1.htm">Problem Management API list</a><br>
<a href=
"aplist.htm">APIs by category</a></td>
</tr>
</table>
</center>
</body>
</html>
Reference in New Issue Copy Permalink