870 lines
25 KiB
HTML
870 lines
25 KiB
HTML
<!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>
|
|
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>
|
|
Default Public Authority: *EXCLUDE<br>
|
|
<!-- iddvc RMBR -->
|
|
<br>
|
|
Service Program: QSXSRVPL<br>
|
|
<!-- iddvc RMBR -->
|
|
<br>
|
|
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 &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 &1
|
|
API.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left" valign="top">CPF7AAB E</td>
|
|
<td align="left" valign="top">Problem &1 not found.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left" valign="top">CPF3C4D D</td>
|
|
<td align="left" valign="top">Length &1 for key &2 not valid.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left" valign="top">CPF3C82 D</td>
|
|
<td align="left" valign="top">Key &1 not valid for API &2.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left" valign="top">CPF3C86 D</td>
|
|
<td align="left" valign="top">Required key &1 not specified.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left" valign="top">CPD7A82 D</td>
|
|
<td align="left" valign="top">Value not valid for key &1. (char
|
|
string)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left" valign="top">CPD7A83 D</td>
|
|
<td align="left" valign="top">Value not valid for key &1. (integer)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left" valign="top">CPD7A87 D</td>
|
|
<td align="left" valign="top">Key &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 &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 &1 not found.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left" valign="top">CPF9821 E</td>
|
|
<td align="left" valign="top">Not authorized to program &1 in library
|
|
&2.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left" valign="top">CPF9872 E</td>
|
|
<td align="left" valign="top">Program or service program &1 in library
|
|
&2 ended. Reason code &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>
|
|
|