A fix is available
APAR status
Closed as program error.
Error description
CONTAINERERR is received when user program tries to delete container DFHWS-RESPCODES. Customer has application that issues 4 successive INVOKE WEBSERVICES commands, each making use of the same CHANNEL name. All is well until one INVOKE fails with an INVREQ condition. After that, all subsequent INVOKEs result in an INVREQ even though the subsequent webservices invoked were really successful. For example, webservice one is invoked successfully and a GET CONTAINER is issued for DFHWS-RESPCODES resulting in an NOTFND condition. This is ok as the invoke was successful thus no DFHWS-RESPCODES container exists at this point. Webservice two is then invoked with a bad URI resulting in an INVREQ condition being raised and a PUT is issued to container DFHWS-RESPCODES. A GET CONTAINER is issued for DFHWS-RESPCODES successfully, showing it now exists. Webservices three and four are then invoked and run successfully . Neither issue a PUT to DFHWS-RESPCODES as they did run ok. However, they both issue a GET for container DFHWS-RESPCODES which is passed back successfully. Because it is not empty Webservices three and four end up with INVREQ as well due to getting container DFHWS-RESPCODES created for the second invoked webservice that failed earlier. If a delete of container DFHWS-RESPCODES is attempted by the application, CONTAINERERR is received. . Additional Symptom(s) Search Keyword(s): KIXREVSCB
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All * **************************************************************** * PROBLEM DESCRIPTION: INVOKE WEBSERVICE command fails with an * * INVREQ condition after a previous * * INVOKE WEBSERVICE command failed with * * the same condition. * **************************************************************** * RECOMMENDATION: * **************************************************************** A series of INVOKE WEBSERVICE requests are issued, using the same channel. If one of the requests fails, for valid reasons, all subsequent INVOKE WEBSERVICE requests fail with INVREQ, even if the actual server code executed without error and returned a valid response. The mis-reporting of the error is due to the presence of a container, DFHWS-RESPCODES, on the channel that contains residual error information.
Problem conclusion
DFHPIIW has been amended to delete the DFHWS-RESPCODES container during the initial processing of an INVOKE WEBSERVICE request.
Temporary fix
FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PK68198
Reported component name
CICSTS V3 Z/OS
Reported component ID
5655M1500
Reported release
400
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2008-06-25
Closed date
2008-07-24
Last modified date
2008-08-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK38401
Modules/Macros
DESPIIW DFHPIIW
Fix information
Fixed component name
CICSTS V3 Z/OS
Fixed component ID
5655M1500
Applicable component levels
R400 PSY UK38401
UP08/07/30 P F807
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
01 August 2008