A fix is available
APAR status
Closed as new function.
Error description
This APAR adds the following changes for IMS support of WLM mobile pricing: - Provide the port number, and the TPIPE name or LTERM override, to Workload Manager via the IWM4CLSY service. - Provide processor utilization information to Workload Manager via the IWM4MNTF service. - Ensure that the processor utilization information provided to log record. KEYWORDS: ZOS0201T/K ZOS0202T/K . <> Cross product information related PI51948. QCF APAR PI77687: ABEND0C4 DFSTMS00 NEAR X'19AC' WHEN A QCF UNLOAD JOB IS RUNNING AND AFTER IMS V14 APAR PI51948 IS INSTALLED . The QCF APAR PI77687 have to be installed after the PI51948 (PE-FIX PI84838). Please refer to the PI77687 for more details. (Add the information on June 27, 2018)
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * * All users of IMS V14 and IMS Connect who would like to use * * the Workload Manager mobile pricing option * **************************************************************** * PROBLEM DESCRIPTION: * * Support Workload Manager (WLM) Mobile Pricing option on IMS. * **************************************************************** * RECOMMENDATION: * * INSTALL CORRECTIVE SERVICE FOR APAR/PTF * **************************************************************** This is the second of two APARs (the first is preconditioning APAR pi46933) that are being used to deliver WLM mobile pricing support on IMS. The support consists of the following: -For existing IWM4CLSY (WLM Classify) service calls on transactions that arrive from IMS Connect, pass information on the CONNECTION and CLIENTTRXNM parameters. The port number associated with the transaction will be passed on the CONNECTION parameter. The CLIENTTRXNM parameter will specify the LTERM override, if one exists, or the TPIPE name, otherwise. -On the existing IWM4RPT (WLM Report) service call, pass processor usage data on the CPUTIME, TIMEONCP, and OFFLOADONCP parameters. TIMEONCP is the processor time used on standard CPs, OFFLOADONCP is the processor time eligible for offloading to a specialty engine, and CPUTIME is the sum of TIMEONCP and OFFLOADONCP. -Ensure that all processor usage data reported to WLM matches what is reported on the 56FA log record.
Problem conclusion
The code changes for this enhancement go well beyond the modules that directly call IWM4CLSY or IWMRPT. There are two main reasons for this: - The new IWM4CLSY parameters (that is, CONNECTION and CLIENTTRXNM) are only supported on the 64 bit version of the service call. This requires IMS to replace existing calls to the 31 bit service IWMCLSFY with calls to the corresponding 64 bit service. The 64 bit versions require the larger 64 bit save area (216 bytes instead of 72) and a larger parameter list work area. Additional code is required to satisfy these increased storage needs. IWM4RPT also must be changed to the 64 bit version, but this requires no code changes beyond DFSWLMN and DFSTMS00 (which calls DFSWLMN) because IWM4RPT does not use a parameter work area, and the expanded save area can be accommodated using storage already available to DFSTMS00. - The port number, to be passed as the CONNECTION on IWM4CLSY, must be obtained from OTMA. This requires enhancements to the DFSLUMIF service. Detailed descriptions of the code changes to each module appear below. This is divided into a number of sections based on the individual components of the overall WLM mobile pricing support (note that this summary includes the changes made in preconditioning apar pi46933): - Create and manage a work area, attached to the PST, to be used for the IWM4CLSY parameter list. - Enhance the DFLUMIF service to return the port number associated with a transaction. - Enhance DFSWLMY to support the new IWM4CLSY parameters - In relevant modules that call DFSWLMY (IWM4CLSY), pass the port number and LTERM override/TPIPE name to WLM. - Expand the DFSTLS block to provide temporary storage for 56FA log data. - Enhance DFSWLMN to support the new IWM4RPT parameters - Pass processor usage information on the DFSWLMN (IWM4RPT) call in DFSTMS00, and ensure that it is consistent with what is reported on the 56FA log record. Create and manage a work area, attached to the PST, to be used for the IWM4CLSY parameter list. IPST Define a new fullword field, PSTWLMB, to contain the address of the DFSWLMY parameter list work area. This field reuses the offset previously used by PSTORDLI, which is no longer used. DFSCBT00 Define a new BCB block type, WLMB, for the DFSWLMY parameter list work area. This is a BCB fast block with a length of I4CLPRML, which is the WLM constant that defines the length of the required parameter area. This block will be obtained using control region private, subpool 0 storage, during PST initialization and freed when the PST is released. Thus, the points in the flow where IWM4CLSY is called do not incur the overhead of obtaining and releasing the storage, and are not required to handle the case where storage cannot be obtained (as it does not need to allocate storage, just locate it using the address in PSTWLMB). DFSBCBIP Add the WLMB block to the list of valid block types, the CBTE_TYPES table, and the CBTE_FAST_FLAG table. DFSBCBPI Add the WLMB block to the list of valid block types and to the BLKINIT table. DFSASK00 Allocate the DFSWLMY parameter list work area using DFSBCB FUNC=GET and store the address in the PST in PSTWLMB. ISWITCH to the control region to make this call. DFSCWU00 While ISWITCHed to the control region, deallocate the DFSWLMY parameter list work area using DFSBCB FUNC=REL if there is a DFSWLMY parameter area attached to the PST (i.e., PSTWLMB is nonzero). Clear the PSTWLMB field. DFSCBT10 Add IWMYCON to the DSECTS section so that I4CLPRML, the length of the IWM4CLSY parameter list, can be used to define the size of the work area. DFSCBT20 Reassemble for changes to DFSCBT00. DFSCBT30 Reassemble for changes to DFSCBT00. DFSCBT40 Reassemble for changes to DFSCBT00. DFSCBT50 Reassemble for changes to DFSCBT00. Enhance the DFLUMIF service to return the port number associated with a transaction. DFSLUMIF Add a new output field, PORT=, to contain the port number associated with a transaction. This parameter is supported for FUNC=GU and FUNC=TIBINFO. Changes to this macro are made to both the PLX and Assembler sections, and include the code to copy the address of the port number into the parameter list, and updates to the block comments that document the macro?s function. DFSYLUS0 Support the new PORT= parameter added to DFSLUMIF. For FUNC=GU, code is added to the code paths for both CM0 and CM1 transactions. The port name is taken from field TMAMCTNM for CM1 transactions, and TMAMPORT for CM0 transactions, and is only returned if the transaction is from an ICON connection. If not, or if PORT= was not specified by the caller, return zero. For FUNC=TIBINFO, CM0 and CM1 can be handled on the same code path. As with FUNC=GU, the port number is taken from TMAMCTNM (CM1) or TMAMPORT (CM0), and is only returned for an ICON connection. DFS62DLA Add a new fullword field, DLAPORT, to contain the address of the port number returned on a call to DFSLUMIF. Enhance DFSWLMY to support the new IWM4CLSY parameters DFSWLMY This macro is not changed in PI51948, as all required changes were made in the preconditioning apar PI46933. Those changes added support for the 64 bit version of the WLM Classify service, and added three new parameters that are used for WLM mobile pricing support: CT, CTN, and CTNL, which are passed to IWM4CLSY as CONNECTION, CLIENTTRXNM, and CLIENTTRXNM_L, respectively. In relevant modules that call DFSWLMY (IWM4CLSY), pass the port number and LTERM override/TPIPE name to WLM. DFSP62XT Add a new eight byte field, P62PORT, to contain the port number returned by the DFSLUMIF FUNC=GU call in DFSDLA30. The contents of this field are passed to WLM on the DFSWLMY calls in DFSDLA30 and DFSNDMI0. DFSWLMWK Add a fifth fullword work area, IWLMWKA5, to this block. The additional work area is used by DFSDLA30 to store the pointer to the prechained save area during the call to DFSWLMY. DFSDLA30 In subroutine ISRTMSG, pass WLM mobile pricing information on the new DFSWLMY parameters CT=, CTN=, and CTNL=. Obtain the port number associated with the transaction by specifying PORT= on the DFSLUMIF FUNC=GU call. Store this port number in the new field P62PORT. Pass the port number on the DFSWLMY CT= parameter. Pass the contents of the field PSTSYMBO on the DFSWLMY CTN= parameter. PSTSYMBO contains the LTERM override, if one is defined, or the LUNAME if no LTERM OVERRIDE is defined. Pass the length of PSTSYMBO on the CTNL= parameter. The new IWM4CLSY parameters require that the 64 bit version of the Classify service be used instead of the existing 31 bit version. The 64 bit version uses a longer parameter list area (increased from 168 bytes to 480) and save area (increased from 72 bytes to 216). The 31 bit version of DFSWLMY used the PSTDCA work area for the parameter list area. This work area is 256 bytes in length, which is enough for the 31 bit parameter list area (168 bytes) but not long enough for the new 64 bit parameter list area. The 480 byte parameter list is accommodated by using the new parameter list work area pointed to by PSTWLMB. Because the 256 byte PSTDCA area is no longer used for the parameter list area, it is available to be used for the 216 byte save area required by the 64 bit version of DFSWLMY. If there is no PST extension available at PST62XTN, the port number is unavailable and a port number of zero is sent to WLM instead. The port number is copied into the MVS parameter list (MVSPL), just past the existing TTOKEN, prior to calling DFSWLMY. IWLMWKA5, which is newly defined in this apar, is used to save the address of the prechained save area across the DFSWLMY call. DFSNDMI0 This module is the interface to the non-discardable messages user exit. It contains a DFSWLMY call which must be enhanced in the same way as the DFSWLMY call in DFSDLA30. When this module gets control, the port number obtained from the DFSLUMIF FUNC=GU call in DFSDLA30 will still be present in the PST extension, so DFSNDMI0 can simply refer to P62PORT to get the port number. Just as in DFSDLA30, the work area pointed to by PSTWLMB is used for the 480 byte parameter list area, and the PSTDCA area is used for the 216 byte save area. The port number is copied into the MVS parameter list (MVSPL) just past the existing TTOKEN, and IWLMWKA5 is used to preserve the address of the prechained save area across the DFSWLMY call. DFSCMEI0 In subroutine WLMCLS, pass WLM mobile pricing information on the new DFSWLMY parameters CT=, CTN=, and CTNL=. The port number, passed on CT=, is obtained from DFSLUMIF as described below. The contents of MSNBDEST are passed on CTN=. The length of MSNBDEST is passed on CTNL=. Obtain the port number associated with the transaction by specifying PORT= on the DFSLUMIF FUNC=TIBINFO call. This call is only made if the message is from OTMA, and the origin name (MSNBORGN) is a TIB or QAB. If these conditions are not met, DFSLUMIF is not called and a zero port is passed to DFSWLMY. The storage for the DFSWLMY parameter list area is obtained from within DFSCMEI0 by calling subroutine HIOPGET. The preconditioning apar defined I4CLPRML so that this will obtain the required 480 bytes. The MVS parameter list, MVSPL, is used for the 216 byte save area. Although this storage is already used to receive the TTOKEN from DFSWLMY, the 256 byte length of the MVSPL is enough to fit both the save area and the 32 byte TTOKEN (248 bytes total). DFSYTIB0 In subroutine Get_service_class, pass WLM mobile pricing information on the new DFSWLMY parameters CT=, CTN=, and CTNL=. The port name is obtained directly, without a call to DFSLUMIF. The logic for obtaining the port number, and the conditions under which a valid port number may be obtained, are identical to what is done in DFSLUMIF. The PL/X version of DFSWLMY/IWM4CLSY uses dynamic storage for the parameter list area, so no special accommodation is required for this in DFSYTIB0. This is handled internally within the IWM4CLSY macro expansion. A dynamic storage area, declared within Get_service_class, is used for the 216 byte save area. Expand the DFSTLS block to provide temporary storage for 56FA log data. DFSTLS Add new fields to be used for the temporary storage of data to both be passed to DFSWLMR/IWM4RPT and written to the 56FA log record. Storing the data in this block ensures consistency between what is logged and what is reported to WLM. This APAR expands the size of this block by 96 bytes. - A new flag byte, which contains a flag indicating whether this section contains valid log data - Three bytes of reserved storage - The CPU execution time (standard CP only) - The CPU time eligible for offloading to a specialty engine - The total of the above two fields - The end time of the UOR, in STCKE format - The end time of the UOR, in UTC format - Sixteen bytes of reserved storage for future use Enhance DFSWLMN to support the new IWM4RPT parameters DFSWLMN This APAR corrects an error in a comment. The preconditioning apar, PI46933, added support for the 64-bit version of the WLM Notify service, and added three new parameters that are used for WLM mobile pricing support: CPUTIME, TIMEONCP, and OFFLOADONCP, which are passed to IWM4RPT under these same names. Pass processor usage information on the DFSWLMN (IWM4RPT) call in DFSTMS00, and ensure that it is consistent with what is reported on the 56FA log record. DFSTMS00 This module contains a call to DFSWLMN, on a code path which may or may not be exercised. If DFSWLMN is to be called, then processor usage data is calculated and stored in the newly defined DFSTLS fields. If running in the IMS control region, processor usage data is taken from DLRCPUTM; otherwise, it is calculated by calling TIMEUSED. The data stored in DFSTLS does not include everything that is logged in the 56FA log record, as most of the data is guaranteed not to change between DFSTMS00 entry and when 56FA is written. For example, the start time of the UOR cannot change at this point. Flag byte TLSLGVLD is set if and only if log data is stored in DFSTLS. Processor usage data is passed on the DFSWLMN (IWM4RPT) call by specifying CPUTIME=TLSTIME, TIMEONCP=TLSXTIME, and OFFLOADONCP=TLSZAAP to report the processor usage data that was stored in DFSTLS to Workload Manager. The PST volatile work area (PSTVOLWA) is used to contain the 216 byte save area required by IWM4RPT. The flag byte indicating validity of the log data in DFSTLS (TLSLGVLD) is cleared at all exit points from DFSTMS00. This includes labels TMS00050, TMSFPX40, and TMSFFX38. When writing the 56FA log record, check TLSLGVLD to determine whether there is valid processor usage data in DFSTLS. If not, the function is identical to what is done prior to this service, that is, processor usage data is calculated here. If DFSTLS does contain valid data, then it is copied into fields TPEXTIME, TPEZAAP, TPENDS, and TPENDU. DFSFXC30 When writing the 56FA log record, check TLSLGVLD to determine whether there is valid processor usage data in DFSTLS. If not, the function is identical to what is done prior to this service, that is, processor usage data is calculated here. If DFSTLS does contain valid data, then it is copied into fields TPEXTIME, TPEZAAP, TPENDS, and TPENDU. DFSDSC00 When writing the 56FA log record, check TLSLGVLD to determine whether there is valid processor usage data in DFSTLS. If not, the function is identical to what is done prior to this service, that is, processor usage data is calculated here. If DFSTLS does contain valid data, then it is copied into fields TPEXTIME, TPEZAAP, TPENDS, and TPENDU. DBFSLG20 When writing the 56FA log record, check TLSLGVLD to determine whether there is valid processor usage data in DFSTLS. If not, the function is identical to what is done prior to this service, that is, processor usage data is calculated here. If DFSTLS does contain valid data, then it is copied into fields TPEXTIME, TPEZAAP, TPENDS, and TPENDU. Recompiles for DFSTLS change The following modules are recompiled for the change to DFSP62XT: DFS3SCP1 DFS5SCP0 DBFHCAS0 DBFHGU10 DBFINTS0 DFSDGSR0 DFSTMED0
Temporary fix
Comments
×**** PE17/07/24 FIX IN ERROR. SEE APAR PI84838 FOR DESCRIPTION
APAR Information
APAR number
PI51948
Reported component name
IMS V14
Reported component ID
5635A0500
Reported release
400
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2015-11-05
Closed date
2016-11-15
Last modified date
2018-06-27
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI42428
Modules/Macros
DFSTLS DFSFXC30 DFS62DLA DFSYTIB0 DFSTMS00 DFSWLMWK DBFSLG20 DFSCMEI0 DFSKEYRC DFSWLMN DFSNDMI0 DFSLUMIF DFSDSC00 DFSDLA30 DFSYLUS0 DFSYPRE DFSQMGR IPST DFSCBT10 DFSBCBPI DFSCBT40 DFSCBT30 DFSCBT00 DFSCBT20 DFSCBT50 DFSCWU00 DFSP62XT DFS3SCP1 DFS5SCP0 DFSAPST0 DFSEF00F DBFHCAS0 DFSTMED0 DBFINTS0 DBFHGU10 DFSASK00
Fix information
Fixed component name
IMS V14
Fixed component ID
5635A0500
Applicable component levels
R400 PSY UI42428
UP16/11/18 P F611
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":"SSEPH2","label":"IMS"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"14.1","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
01 December 2023