II07968: JES3 MAINTENANCE PHILOSOPHY.

APAR status

• Closed as canceled.

Error description

• Maintaining JES3 is a periodic activity. As you receive updates
  or enhancements for your JES3 product, you must apply these
  updates to your JES3 component.  Although IBM delivers JES3 and
  MVS services in the same manner, how you install each service
  can differ.
  
  To minimize the impact of applying maintenance while maintaining
  continuous operations, you must understand the JES3 maintenance
  philosophy. Follow the JES3 maintenance philosophy when applying
  APARs/PTFs, which fix problems that can arise between your
  scheduled maintenance upgrades, using the PUT maintenance
  process.
  
  When installing JES3 APARs/PTFs, terminology is used which is
  explained in the following sections. The intent is to limit the
  number of complex-wide restarts required by installing JES3
  APARs/PTFs. Note that the restart information does not take into
  account a dynamic system interchange (DSI). Therefore, if you
  use a DSI, be aware that the term "GLOBAL" implies both the
  current GLOBAL  processor and all potential GLOBAL processors.
  
  General overview of JES3 service
  To maintain your JES3 component, you must understand how JES3
  structures its maintenance in a System Modification Program
  (SMP) environment. It is assumed that you are familiar with the
  terminology and operation of SMP.  Refer to SMP/E User's Guide
  User's Guide for more information on using SMP.
  
  JES3 is a source-maintained product, which means that corrective
  fixes (APARs) are distributed in source format, while preventive
  fixes (PTFs) are distributed in source (non-cumulative) and
  object code format. It is an SMP requirement that every new
  fix (SYSMOD) must either PRE-REQ (prerequisite) or SUP
  (supersede) all previous maintenance to the same module.  In
  this way, SMP can ensure that no previous service is dropped or
  regressed. For example, assume that PTF1 addresses a problem in
  module IATOSWD, which is the permanent fix for APAR1.  APAR2 is
  then created to address another problem in the same module,
  IATOSWD. PTF2, created for APAR2, must then PRE-REQ SUP PTF1,
  because both PTF1 and PTF2 apply to the same module, IATOSWD.
  
  JES3 APARs, however, do not follow this same SMP requirement. A
  JES3 APAR only PRE-REQs or SUPs the code (APAR) that is required
  to allow the fix to function correctly.  JES3 APARs never
  PRE-REQ or SUP PTFs.  Applying APARs in this manner allows the
  user to install APAR maintenance to the system regardless
  of the existing PTF level that is currently installed.
  
  During the application of JES3 APARs, SMP SYSMOD regression
  reports can indicate that other SYSMODs are being regressed.
  This regression occurs because the APAR did not PRE-REQ or SUP
  the previously applied maintenance PTF.  Each regression error
  message indicates the specific APAR that is doing the regress
  and the specific PTF that was previously applied. Regression
  error messages, GIM38201W and GIM31901I, issued during the
  application of JES3 APARs can be ignored when they list PTFs.
  You must not ignore these messages if they list APARs, and
  you must not ignore any other error messages.
  
  During the application of JES3 PTFs, regression error messages
  can be issued. If the regressed SYSMOD is another PTF, then the
  PTF currently being applied may be in error, or the already
  installed PTFs have been erroneously applied.  In either case,
  you must determine why the regression message was issued. If the
  SYSMOD being regressed is an APAR, the APAR needs to be
  restored, the new PTF applied, then the APAR reapplied.  Instead
  of giving you the choice to restore the APAR, SMP allows you to
  ACCEPT the APAR. JES3, however, recommends that APARs never
  be accepted.  Do not ignore any SMP error messages when
  processing PTFs.
  
  Note: For various reasons, FIXTEST APARs are provided to allow
  JES3 users to verify the fix before the formal PTF is
  distributed. JES3 assumes that the APAR fix is only APPLIED and
  never ACCEPTED by SMP, because the final fix can change based
  on the feedback received from the testing customers.  You must
  remove the FIXTEST version prior to application of the final
  APAR or PTF to avoid conflicts with the final fix.
  
  JES3 Restart Information
  After APAR or PTF maintenance has been applied to your JES3
  system, you must determine how JES3 is to be restarted. Each
  JES3 APAR and PTF includes installation and activiation
  information that define the type of JES3 and MVS restarts
  that are required to properly install the changes made
  by the APAR or PTF.  The information provided takes into
  account module residency, operating environment, and how the
  change interacts with control blocks and other data
  structures created before the installation of the change. This
  restart information must be followed to ensure proper
  implementation of the changes.  JES3 service will inform you of
  the processors that the APAR or PTF must be installed on, the
  order of installation, the order of activation, the type of
  JES3 restart required, the type of IPL required, and whether or
  not CLPA is required.  For example, the cover letter information
  found in the APAR will contain instructions similar to the
  to the following in the PROBLEM CONCLUSION:
  . Install on (All processors)
  . Order of installation (Any)
  . Order of activation (Any)
  . Type of JES3 restart (None)
  . Type of IPL (Rolling), CLPA (Yes)
  
  The following values can be specified for this information:
  
  RESTART Information - Install On
  This information describes which processors the APAR must be
  installed on. This process can only be one of the following:
  
  All processors with C/I FSS
    All processors in the complex with C/I FSS address spaces.
  
  All processors with WTR FSS
    All processors in the complex with WTR FSS address spaces.
  
  All processors with any FSS
    All processors in the complex with any FSS address spaces.
  
  All processors with a Netserv
    All processors in the complex that run a Netserv.
  
  Locals
    All local processors in the complex.
  
  Global
    The global processor and all potential global processors in
  the complex.
  
  All processors
    All processors in the complex regardless of whether C/I or WTR
  FSS is active on the processor.
  
  RESTART Information - Order of Installation
  This information describes the order that the APAR must be
  installed. This order can be one of the following:
  
  ANY
    The order of installation does not matter.
  
  Global first, then locals
    Install on the global processor first, then install on all
  local processors in the complex.
  
  Locals first, then Global
    Install on all local processors in the complex first, then
  install on the global processor.
  
  RESTART Information - Order of Activation
  This information describes the order that the APAR must be
  activated. This order can be one of the following:
  
  ANY
    The order of activation does not matter.
  
  Global first, then locals
    Activate on the global processor first, then activate on all
  local processors in the complex.
  
  Locals first, then Global
   Activate on all local processors in the complex first, then
  activate on the global processor.
  
  RESTART Information - Type of JES3 Restart Required
  This information describes the type of JES3 restart that is
  required. This restart can be one of the following:
  
  Note: To pick up a new level of the modules, you must do one of
  the following:
  
  . IPL the processor
  . If an IPL is not required, issue an F LLA,REFRESH or F
  LLA,UPDATE command.
  
  NONE
    No JES3 restart is needed.
  
  HOT
    Perform a hot start of the JES3 address space on the global
  processor.
  
  HOT/REFRESH
    Perform a hot start with refresh of the JES3 address space on
  the global processor.
  
  WARM
    Re-IPL all processors in the complex. Perform a warm start of
  the JES3 address space on the global processor. Perform a local
  start of all local processors in the complex.
  
  LOCAL
    Perform a local start of all local processors in the complex.
  
  C/I FSS
    Terminate and restart all C/I FSS address spaces in the
  complex. WTR FSS Terminate and restart all WTR FSS address
  spaces in the complex.
  
  ANY FSS
    Terminate and restart all FSS address spaces in the complex.
  Netserv Cancel and restart all Netservs in the complex.
  
  HOT/COMMAND
    The new level of the code can be activated by issuing a MODIFY
  LLA,REFRESH/UPDATE or MODIFY LLA,UPDATE=xx command, and then
  issuing a *MODIFY,X,M=modname,REFRESH command for each module
  shipped in the APAR. The *MODIFY,X command will delete the old
  version of the module and cause a new copy of the module to be
  loaded the next time it is used. MSGIAT8489 stating Refresh
  Pending indicates the new copy of the module cannot be loaded
  until all DSPs using it are stopped.
  
  No IPL Required
    In cases where you do not need to IPL and instead just restart
  the JES3 address space, issue a *MODIFY,X command to refresh the
  module within JES3 (or use the SETPROG command for Dynamic LPA).
  You still need to issue a MODIFY LLA,REFRESH or MODIFY
  LLA,UPDATE command first.
  
  RESTART Information - Type of IPL Required
  This information describes whether an IPL is required. If an IPL
  is required, this information indicates which systems should be
  IPLed after installing the APAR.  This information can be one of
  the following:
  
  NONE
    No IPL is required.
  
  ROLLING
    IPL one processor at a time until all processors in the
  complex have been IPLed.
  
  GLOBAL
    IPL the global processor only.
  
  LOCAL
    IPL the local processors only.
  
  GLOBAL TO LOCAL
    IPL the global processor first, then IPL the local processors.
  
  LOCAL TO GLOBAL
    IPL the local processors first, then IPL the global processor.
  
  ROLLING/DynLPA
    You can activate the change using the dynamic LPA facility and
  then perform a hot or local start without an IPL of the required
  processors. See on page 26 for more information.
  
  GLOBAL/DynLPA
    You can activate the change using the dynamic LPA facility and
  then perform a hot start without an IPL of the global processor.
  See on page 26 for more information.
  
  LOCAL/DynLPA
    You can activate the change using the dynamic LPA facility and
  then perform a local start without an IPL of the local
  processors. See on page 26 for more information.
  
  Dynamic LPA Facility
  New versions of JES3 LPA modules can be dynamically added to LPA
  by issuing the following commands:
  
    F LLA,REFRESH
      followed by:
    SETPROG LPA,ADD,MODNAME=IATSICA,DSN=LNKLST
  These commands can be issued while JES3 is active. The change
  does not take effect until JES3 is restarted. This allows you to
  back out the change if necessary.
  
  If the fix must be installed on more than one system, a SETPROG
  command must be issued for each system. Once the required
  modules have been added to LPA, perform a hot start or local
  start of JES3 (without an IPL of the system) to activate
  the change.  During initialization, JES3 picks up the new
  versions of the modules and issues the following:
  
    IAT3085 LPA MODULES CHANGED: IATSICA ...
  On the JES3 global processor, the prior message appears in
  JES3OUT only.
  On the JES3 local processors, the prior message appears on the
  console.
  
  Complex
    IPL all processors at the same time.
  
  Restart Information - CLPA required
  This information describes whether a CLPA (create link pack
  area) is required when teh system is IPLed after installing the
  APAR.  The information can be as follows:
  
  YES
    Perform a CLPA
  
  No
    No CLPA is required.
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• Info apar
  

APAR Information

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

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

Fix information

Applicable component levels