A fix is available
APAR status
Closed as program error.
Error description
Your web request arrives from a web server and DFHWBBLI is started directly. This fails with a DFHPG0001 0C4, but the transaction appears to execute anyway. The DFHPG0001 dump slows things down a bit; but it can be suppressed by coding the PG0001 in the system dump table (SYD) and putting NOSYS to suppress the dump. The incoming request to CICS may look something like this: GET /APPL/CICS/CSMI/DFHWBTTA/TR01 where TR01 is the transaction to be invoked. . CICS TS 3.2 has added the CREATE_POOL call which stores a token in the wrb, but then a GET_TOKEN is done and it also stores the token in the wrb, which overwrites the previous token. Then when the PUT_CONTAINER is done by DFHWBQM (called from DFHWBBLI), it is no longer a container token in the wrb and DFHPGCR later program checks due to an ebcdic value (sysid - in the above example it would be APPL) in the WRB_REPOSITORY_TOKEN. Additional Symptom(s) Search Keyword(s): KIXREVSCB
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All. * **************************************************************** * PROBLEM DESCRIPTION: MSGDFHPG0001 an abend 0C4 has occurred * * in DFHPGCR or DFHPGCP. * **************************************************************** * RECOMMENDATION: * **************************************************************** An HTTP request is sent to CICS via the HTTP Server Plugin (DFHWBDLL). When the request gets to CICS it is processed by DFHWBBLI. DFHWBBLI has to put the contents of the HTTP request into various containers for use by the WEB API commands. To do this it first creates a container pool and saves the pool token in field wrb_repository_token. Just before the request is saved a redundant call is made to the GET_TOKEN function of DFHWBQM. That call returns an 8 byte token consisting of the SYSID followed by the WRB address. That 8 byte token is then saved in field wrb_repository_token overwriting the container pool token that was stored there. When the request is finally being put into a container then two 0C4 abends occur in DFHPGCR followed by an 0C4 abend in DFHPGCP. Additional keywords: S0C4 ABENDS0C4 ABEND0C4 PG0001 DFHPG0001 OFFSET 0530 04EC
Problem conclusion
DFHWBBLI has been changed to no longer issue the redundant GET_TOKEN call.
Temporary fix
FIX AVAILABLE BY PTF ONLY
Comments
APAR Information
APAR number
PK57564
Reported component name
CICSTS V3 Z/OS
Reported component ID
5655M1500
Reported release
500
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2007-12-04
Closed date
2008-01-14
Last modified date
2008-02-02
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK32926
Modules/Macros
DESWBBLI DESWBRQ DFHWBBLI DFHWBRQS
Fix information
Fixed component name
CICSTS V3 Z/OS
Fixed component ID
5655M1500
Applicable component levels
R500 PSY UK32926
UP08/01/17 P F801
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.2","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.2","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
02 February 2008