A fix is available
APAR status
Closed as program error.
Error description
For a synchronous callout scenario for user message exit SMPL0, When the isUseCM0AckNoWait() method is set to true for a RESUMETPIPE request through the API to get a Modname along with the ICAL request, the Connect API for Java is getting timed out at a socket receive state and no output request is given out by the API in the OutMessage object.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All IMS Enterprise Suite V2R2 * * IMS Connect API users. * **************************************************************** * PROBLEM DESCRIPTION: For a synchronous callout scenario for * * user message exit HWSSMPL0, When the * * setReturnMfsModname method is set to * * true for a RESUMETPIPE request through * * the API to get an MFS Modname along * * with the ICAL request, the Connect API * * for Java is getting timed out at a * * socket receive state and no output * * request is given out by the API in the * * OutputMessage object. * **************************************************************** * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF * **************************************************************** If the MFS modname is requested with the message reply (i.e IRM_F1_MFSREQ set as result of setReturnMfsModname method set to true) user message exit HWSSMPL0 returns the MFS modname in the RMM (Request Mod Message) header. The RMM header follows the correlation token and has a 2 byte length field. The Connect API always looks for 4 byte length field to follow the correlation token when it knows that it is receiving a Syncronous callout request. The issue is that it does not consider that an RMM header may exist so assumes a 4 byte length. This has caused the API to wait for a longer RMM header which in turn caused the API to wait for a longer message at the socket receive and thus timing out.
Problem conclusion
GEN: KEYWORDS: *** END IMS KEYWORDS *** For a Synchronous callout scenario using user message exit HWSSMPL0, when setReturnMfsModname method is set to true, the receive method has been modified to expect the presence of an RMM header with a 2 byte LL field after the correlation token. This code change has solved the surfaced problem and is now parsing the obtained output from IMS Connect and providing it to the client through the OutputMessage object. The modname can be received through the getMfsModname() method in the OutputMessage object.
Temporary fix
Comments
APAR Information
APAR number
PM77947
Reported component name
IMS ENTERPRISE
Reported component ID
5655T6200
Reported release
223
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2012-11-28
Closed date
2013-01-17
Last modified date
2013-02-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK91004
Modules/Macros
HWSCAJJ HWSCAJS
Fix information
Fixed component name
IMS ENTERPRISE
Fixed component ID
5655T6200
Applicable component levels
R223 PSY UK91004
UP13/01/24 P F301
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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"223","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
04 February 2013