We're using a High Availability system that replicates our objects and data to a backup system. What do I have to do in relation to CoolSpools etc?

Software Replication

If you're using a Software Replication solution such as MaxAva *NOMAX, iCluster or MIMIX to replicate your objects and data from your live system to a backup system, please take note of the following points in relation to CoolSpools V7 and earlier versions of our software.

We cannot specify the exact configuration requirements for your H.A. system for the following reasons:

1. This will depend on your company or organization's specific replication needs
2. This will vary depending on the product being used and its capabilities

Below are some general pointers, which should guide you in the configuration requirements when read alongside your H.A. product's documentation.

CoolSpools is a licensed product, so it should be installed independently to both your production and backup servers prior to setup of mirroring.  You cannot rely on mirroring of the CoolSpools library from a production server to install CoolSpools to your HA/DR server, as this will result in an unusable copy of CoolSpools.

Licence keys

CoolSpools license keys are not affected by replication as they are managed by the IBM License Management system outside of the CoolSpools product library.

However, support keys are stored in a data area in the CoolSpools product library. The data area is COOLSPV6R1 in library COOLSPV6R1 or CP_PRDINFO in library COOLSPV7R1, and the object should be excluded from replication.

See this link if you are unclear of the difference between a license key and a support key

Objects that should not be replicated

The table below lists objects that should be excluded from replication

Data By "Data", we mean the contents of database files and data areas. The table below lists files and data areas that you may wish to replicate. The table indicates the nature of the data and in particular how frequently it is updated. You should decide your replication strategy in relation to each object listed here based on its data type and volatility. Data types are defined as follows: Data objects that form part of our software can be classified as follows: Non-data ObjectsBy "Non-data objects", we mean objects such as:

• programs (object type *PGM)
• service programs (*SRVPGM)
• display files (object type *FILE attribute DSPF)
• printer files (object type *FILE attribute PRTF)
• commands (*CMD)
• panel groups (*PNLGRP)
• message files (*MSGF)
• user spaces (*USRSPC). These are only used by CoolSpools for static information or (in the case of those created in QTEMP) for temporary information which does not need to be replicated.
• workstation customization objects (*WSCST)
• job descriptions (*JOBD)
• job queues (*JOBQ)
• subsystems descriptions (*SBSD)
• menus (*MENU)

These objects change relatively infrequently, typically only when a fix pack (PTF) or a new release is installed. In relation to objects of this type, you have two main choices so far as H.A./replication systems are concerned. Each choice has advantages and disadvantages.

• Install fixes (PTFs) on your live system only, rely on your H.A. software to replicate object changes

  This approach has the advantage of simplicity, in that you only need to install fix packs on the one system.

  However, this approach also has the significant disadvantage that OS/400 (IBM i) on the target system will not be aware that the fix (PTF) has been installed. This is because our fix packs are packaged as OS/400 PTFs and OS/400 tracks what PTFs have been installed. The H.A. software will not update OS/400's internal tables correctly to indicate that the PTF has been installed. This means that DSPPTF on the target system will display incorrect information and any attempt to install a fix pack on that system subsequently may fail.

• Install fixes (PTFs) on both systems and do not replicate object changes

  This approach has the disadvantage that it is more complex, as you need to be sure to install fix packs on both systems to keep objects in sync, but has the advantage that both systems will correctly indicate the PTF level of the software when you run DSPPTF.

  On balance, this is the approach we recommend.

Other itemsYou should be aware that CoolSpools V7 and earlier versions of our software use two other features of OS/400 (IBM i) which will probably not be replicated by your H.A. Software but which have a significant bearing on the operation of the system.

• Registered functions

  Registered functions are a feature of OS/400 (IBM i) which enable applications to control access to system functions in a similar way to object-level security. We use registered functions to allow users to manage access to items such as:

  • Spool Admin (CoolTools) standard and user defined options
  • Spool Admin features such as the ability to run commands at the command line in WRKSPLFPDM
  • Spool Converter report definitions and report maps
  • Database maps

  See these InfoCenter articles for further details of registered functions as a feature of OS/400 (IBM i):

  • http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/sec4.htm
  • http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzamv/rzamvlimitaccessprogfunc.htm

  So far as we are aware, registered functions are not replicated by any H.A. system and they are also not saved by IBM commands such as SAVSYS, SAVSECDTA or SAVE menu option 21.

  For this reason, CoolSpools V6 & V7 *BASE and CoolTools V2 include commands called SAVREGFNC (Save Registered Functions) and RSTREGFNC (Restore Registered Functions) which are intended to allow you to take a snapshot of the registered functions defined on your system and user authorities to those functions. The information is saved into a stream file. This stream file can be used to restore those registered functions and user authorities to another partition or system.

  It is recommended that you run SAVREGFNC regularly (and especially after changing registered function settings) to ensure that your registered functions and associated user authorities can be restored in the event of a system failure or duplicated to a backup system in the event of a failure.

• Environment variables

  Environment variables are a feature of OS/400 (IBM i) which provide a simple and convenient way of defining items of information at either a system- or job-level that applications can use to control aspects of processing. earlier software versions use environment variables to define things such as:

  • Spool Admin (CoolTools) standard and user defined options
  • Spool Admin features such as the ability to run commands at the command line in WRKSPLFPDM
  • Spool Converter report definitions and report maps
  • Database maps

  A full set of environment variables used by CoolSpools V6 & V7 is available in the Programmer's Guide.

  See this InfoCenter article for further details of environment variables as a feature of OS/400 (IBM i):

  • http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/unix1a.htm

  So far as we are aware, environment variables are not replicated by any H.A. system and they are also not saved by IBM commands such as SAVSYS or SAVE menu option 21.

  Although we do not provide a SAVENVVAR (Save Environment Variables) or RSTENVVAR (Restore Environment Variables) command as part of our licensed programs, we can provide such commands on request on an "as-is" unsupported basis. These commands work in a similar way to SAVREGFNC and RSTREGFNC in that they save system-level environment variable settings into a stream file. This stream file can be used to restore those system-level environment variable settings to another partition or system.

Hardware Replication

If you are using a Hardware Replication solution such as PowerHA to mirror your live server's disk image to a backup server, please take note of the following points in relation to CoolSpools V7 and earlier versions of our software.

Start by consulting the documentation provided with your Hardware Replication product for recommendations on how to manage licensed software applications.  These recommendations may vary between different HA/DR products, but since licence data will almost certainly be included in the information mirrored between servers, our recommended approach is to reapply the relevant CoolSpools licence keys after each switchover - apply the DR licences when you switch over to your backup server, and apply your live licenses when you switch back to your live system.

The command string(s) that you need to execute in order to apply license keys are those that were provided when you were last issued with license keys by Ariadne Software.  If you do not have these details to hand then please request these from Ariadne Support, providing the relevant serial numbers and LPAR numbers.

Note that there should be no need to reapply CoolSpools support keys as part of a switchover unless you are planning to apply a fix pack while running from your backup server.