PI90163: STAGE2 ASSEMBLY FAILS WITH ASMA039S LOCATION COUNTER ERROR FOR DFSSMB

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• STAGE2 ASSEMBLY FAILS WITH ASMA039S LOCATION COUNTER ERROR FOR
  DFSSMB
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: IMS V13 USERS OF MODBLKS DATASETS            *
  ****************************************************************
  * PROBLEM DESCRIPTION: STAGE2 SYSGEN fails with assembly       *
  *                      error ASMA039S LOCATION COUNTER ERROR   *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  IMS system generation stage 2 fails with
  assembly error
  ASMA039S LOCATION COUNTER ERROR
  
  IBM provided a DFSASTP macro change to specify
  the HLASM EXEC GOFF parameter, so that the location
  counter supports up to 2G instead of just 16M.
  But the IMS system generation stage 2 still
  fails with assembly error
  ASMA039S LOCATION COUNTER ERROR
  on the 91,181st transaction.
  A MODBLKS PDS data set can contain a maximum of 91,180
  transactions.
  
  Sysgen builds transactions into the DFSSMB0x member of the
  MODBLKS data set, which must be a PDS.
  A PDS data set has a maximum member size of 16M
  (16777215 bytes).
  This limits the number of MODBLKS resources:
  16777215/184(V13 SMB length from SMBTOTSZ) = 91,180.
  16777215/112(V13 PDIR length from PDIRLEN) = 149,796.
  16777215/48(V13 RCTE length from RCTELEN) = 349,525
  16777215/200(V13 DDIR length from DDIRLEN) = 83,886.
  

Problem conclusion

• GEN:
   IOGEN
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  The IMS system definition stage 2 process is changed to
  specify the GOFF parameter on the HLASM EXEC statement, so
  so that the location counter supports up to 2G instead of just
  16M.  This supports genning the maximum number of transactions
  that can be genned into the MODBLKS PDS data set = 91,180.
  The GOFF parameter is also specified with the LIST(133)
  parameter, so that the stage 2 assembly doesn't issue
  warning message ASMA434N and complete with a return code of 2.
  
  IMS is also changed to support a MODBLKS PDSE data set,
  which can contain many more resources than PDS data sets.
  MODBLKSs PDSs are still supported.  It is up to
  the user to define the MODBLKS data sets as PDSEs
  (DSNTYPE=LIBRARY).
  Some of the code changes are needed because PDSEs don't
  behave in the same way as PDSs, regarding the z/OS
  LOAD and IEBCOPY functions.
  
  A problem was found during unit test where
  emergency restart lost all of the Fast Path exclusive
  transactions, when 10,000 programs were genned, and
  20,000 Fast Path exclusive transactions (which
  creates 20,000 routing codes by the same name)
  were genned.
  
  DBFRRT00 is changed to load the MODBLKS DFSRCTEx member using
  the z/OS load macro instead of IMS's internal IMODULE LOAD,
  so that the load works for PDSs and PDSEs.
  It is also changed to delete the MODBLKS DFSRCTEx member
  storage using z/OS's delete macro, instead of IMS's internal
  IMODULE DELETE.
  It is also changed to use mvcle in a loop instead of mvcl,
  to move the member data into local storage, since the data
  can be larger than 16M if from a PDSE.
  
  DFSASTP is changed to specify the GOFF parameter
  (instructs the assembler to produce a Generalized Object
  File Format data set) on the HLASM EXEC statement,
  so that the location counter supports up to 2G instead of
  just 16M.
  The GOFF parameter is specified with the LIST(133) parameter,
  so that the stage 2 assembly doesn't issue warning message
  and complete with a return code of 2.
  The LIST(133) parameter tells the assembler to produce the
  listing in 133-character format.
  
  Several lines in DFSASTP cannot contain an SDC, because
  it causes the HLASM to return an error.
  
  When genning large numbers of transactions, you may need to
  code the IMSGEN macro with ONEJOB=(YES,NO|YES), so that
  the stage 2 assembly doesn't fail because of step 2
  running in parallel with step 1, causing step 2 to fail
  intermittently.
  
  DFSRDB00 is changed to load the MODBLKS DFSDDIRx member using
  the z/OS load macro instead of IMS's internal IMODULE LOAD,
  so that the load works for PDSs and PDSEs.
  It is also changed to delete the MODBLKS DFSDDIRx member
  storage using z/OS's delete macro, instead of IMS's internal
  IMODULE DELETE.
  It is also changed to use mvcle in a loop instead of mvcl,
  to move the member data into local storage, since the data
  can be larger than 16M if from a PDSE.
  
  DFSRMPD0 is changed in the prepare clean up routine to
  delete the inactive MODBLKS DFSPDIRx member.
  This must be done under the prepare task that z/OS loaded
  the DFSPDIRx member, for the z/OS delete to work.
  The inactive MODBLKS DFSPDIRx member is no longer needed
  after prepare completes anyway.
  This is skipped if ACBLIB online change is also being
  performed, because the inactive DFSPDIRx member is needed
  to build the PSB BLDL list.
  
  DFSRMPS0 is changed in the prepare clean up routine to
  delete the inactive MODBLKS DFSPDIRx member.
  This must be done under the prepare task that z/OS loaded
  the DFSPDIRx member, for the z/OS delete to work.
  The inactive MODBLKS DFSPDIRx member is no longer needed
  after prepare completes anyway.
  
  DFSRMSM0 is changed in subroutine MSCINIT to return the address
  of the transaction SMB with an invalid SYSID, so that the
  DFS2498W SMB smbname SID NUMBER IS INVALID message shows
  the transaction name instead of garbage.
  This problem was encountered while unit testing the fix.
  
  DFSRMS00 is changed to load the MODBLKS members using the
  z/OS load macro instead of calling DFSSTS10 to load the
  member with IMS's internal IMODULE LOAD,
  so that the load works for PDSs and PDSEs.
  It is changed to delete the MODBLKS members using the
  z/OS delete macro instead of calling DFSSTS10 to delete
  the member with IMS's internal IMODULE DELETE.
  It changes message DFS3435 text to no longer mention
  IMODULE LOCATE, and to also include the z/OS load
  return code.
  
  DFSRPG00 is changed to load the MODBLKS DFSPDIRx member using
  the z/OS load macro instead of IMS's internal IMODULE LOAD,
  so that the load works for PDSs and PDSEs.
  It is also changed to delete the MODBLKS DFSPDIRx member
  storage using z/OS's delete macro, instead of IMS's internal
  IMODULE DELETE.
  It is also changed to use mvcle in a loop instead of mvcl,
  to move the member data into local storage, since the data
  can be larger than 16M if from a PDSE.
  
  DFSRTR00 is changed to load the MODBLKS DFSSMB0x member using
  the z/OS load macro instead of IMS's internal IMODULE LOAD,
  so that the load works for PDSs and PDSEs.
  It is also changed to delete the MODBLKS DFSSMB0x member
  storage using z/OS's delete macro, instead of IMS's internal
  IMODULE DELETE.
  It is also changed to use mvcle in a loop instead of mvcl,
  to move the member data into local storage, since the data
  can be larger than 16M if from a PDSE.
  
  DFSRTR20 is changed to see if the Fast Path exclusive
  transaction routing code by the same name already exists,
  and if it does, use it instead of creating the
  Fast Path routing code and trying to chain it.
  If the Fast Path exclusive transaction was added by
  online change, its routing code may already have
  been created when processing the x'22' log record
  for the routing code.
  This problem was encountered while unit testing the fix.
  
  DFSTOCMD is changed to add TOCM_02MVSDEL, to indicate that
  the MVS DELETE service failed for the trace entry.
  
  DFSUOCU0 is changed to skip the XDAP, READ, NOTE, TRKCALC,
  and POINT macro calls if either the input or output dataset
  is defined as a PDSE.
  
  LKSTEP is changed to code FETCHOPT=(PACK,PRIME) to linkedit
  MODBLKS, so that the z/OS load macro will return the actual
  DFSDDIRx, DFSPDIRx, DFSRCTEx, and DFSSMB0x member size, instead
  of rounding up the member size to the next page boundary, in
  the case where the member is bigger than 16M.
  The z/OS load macro rounds the member size up to a page
  boundary for members bigger than 16M.
  The exact member size is needed for IMS coldstart to
  calculate the number of resources in the member.
  
  The documentation doesn't fit in this write-up and
  is only available in the DOC hold card.
  The following publications are changed:
  IMS Version 13 Messages and Codes, Volume 1:
    DFS Messages (GC19-4240-02)
  
  IMS Version 13 Messages and Codes, Volume 3:
    IMS Abend Codes (GC19-4242-03)
  
  IMS Version 13 System Definition (GC19-3660-03)
  
  IMS Version 13 Release Planning Guide (GC19-3658-05)
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  PI90413 PI90417 UI56391 UI56392

Modules/Macros

• DBFRRT00 DFSASTP  DFSRDB00 DFSRMPD0 DFSRMPS0
  DFSRMSM0 DFSRMS00 DFSRPG00 DFSRTR00 DFSRTR20 DFSUOCU0 LKSTEP
  

Fix information

• Fixed component name

  IMS V13

• Fixed component ID

  5635A0400

Applicable component levels

• R300 PSY UI56391

     UP18/06/15 P F806

• R302 PSY UI56392

     UP18/06/15 P F806

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.