IBM CL/SuperSession migration from V1.4.7 to V2.1
Information to help you migrate from CL/SuperSession V1.4.7 to V2.1.
IBM CL/SuperSession V2.1 provides a customizable and streamlined out-of-the-box installation process.
Before you start your migration you should have the following:
User ID for the default administrator
APPLID naming standards for IBM CL/SuperSession entry point access
- (Example: HOSTGATEs)
APPLID naming standards for IBM CL/SuperSession virtual terminals
Naming conventions for sequential, PDS, and VSAM datasets
Note: Depending on your role in your organization, you may need to involve a security administrator and VTAM systems programmer.
The CL/SS started task procedure includes 3 libraries that are meant to assist in the migration from CL/SuperSession v1.4.7:
Note: Any CL/SuperSession V1.4.7 configuration or modified panel member should be carefully examined before being copied into the corresponding CL/SuperSession V2.1 migration library.
Invoke -SSPROC- procedure to run CL/SuperSession V2.1.
The technique for migrating from a prior release of CL/SuperSession is similar whether or not you expect to run both versions at the same time.
If you are NOT anticipating running both address spaces concurrently, most of the same runtime files and naming conventions can be used; be sure to specify these, for instance the APPLIDs, during installation.
If you *DO* plan on maintaining both versions for a period of time, you will have specified new initialization values at install that generate unique APPLIDs and files.
Steps to consider:
1. Review your current CL/SuperSession started task and identify your custom runtime libraries, e.g., "RLS*"
2. Review Customizations
a. Review any customizations you may have made to product dialogs (those beginning with KL*), these changes may need to be refit to current versions of these same dialogs.
b. Copy your other user dialogs AS IS, V2.1 is completely back-level compatible.
3. Copy or reassemble any security exits you may have enabled if applicable.
4. On the prior release, run the SAMPLIB dialog KLSTBCLN to check for old or unused profiles and optionally delete them. (IBM CL/SuperSession clean up tools)
5. REPRO the NAM and TDB from the current address space to the V2.1 files.
Expanded details regarding migrating some or all of your existing IBM CL/SuperSession V1.4.7 environment to the new IBM CL/SuperSession V2.1 installation.
The Tables Database. This VSAM dataset is specified via the DD TLVPARM member name KLVINTB and reported at startup in the message KLVTB053. It contains most of the data associated with IBM CL/SuperSession users like their individual permission's, trigger preferences and session modifications. Many users prefer to simply REPRO this file from their existing production system to their new installation. However, as there is no provision for selecting individual tables, it is possible some of the information in your “TDB” is obsolete. This is a harmless condition but you may want to use this opportunity to either pare-down the users defined in it prior to the REPRO or start with a fresh TDB.
The NAM (Network Access Manager) Database. This VSAM dataset is specified via the DD TLVPARM member name KLVINNAM and reported at startup in the message KLVNA007. This file contains user validation information if you are using “local security” as well as some extended user information (data from the “Preferences” pulldown). While this file may be REPRO’ed, IBM recommends your new install use a fresh dataset unless you are using the HelpDesk SPE.
NAM Control Points. Control Points define the security requirements for each IBM CL/SuperSession Network Entry Point and are specified in the KLVINNAM member described above. You should review your existing security configuration and update your CL/SuperSession V2.1 KLVINNAM member accordingly.
NOTE: If you have specified a different naming convention for your V2.1 APPLs than for your current CL/SuperSession V147 APPLs, you cannot simply copy this member.
Virtual Terminals. IBM CL/SuperSession uses a pool of virtual terminals to establish sessions with applications on behalf of a user. These terminals are defined, usually at startup and usually in a member of the DD TLVCMDS named KLS$VSMS. If you have customized this member, for instance, by defining different pool names, you will need to migrate that configuration to CL/SuperSession V2.1. Be aware that one of the parameters in the V2.1 installation is the prefix for virtual terminals and this is included in the sample VTAMLST member created at that time.
HOSTGATE definitions. If you have site-specific HOSTGATE customizations (DD TLVCMDS, member name KLGCHGGW) these should be reviewed against what is provided out-of-the-box in V2.1. CL/SuperSession V2.1 includes a provision for Passphrase.
User Exits. IBM CL/SuperSession permits two types of assembler exits. One is invoked by the LINK() dialog function and requires no special handling in V2.1 beyond copying from the V147 TLVLOAD to the V2.1 TLVLOAD. The other type are security user exits specified via the EXIT=PARM in the aforementioned Control Point definitions.
Depending on your specific security configuration these may need to be reassembled or may not be required at all (if, for example, a SAF call for entry point validation is adequate).
Dialog modifications. SSPL is the programming language of IBM CL/SuperSession. Members in the TLVPNLS DD may represent a complete executable “dialog” or a common segment copied into another dialog which can be executed.
Many customers have created their own stand-alone applications or used “Presentation Space Manager” GUI tools to transform a legacy green-screen application. Further, because a large part of IBM CL/SuperSession is “open” for customer tailoring, it is possible you may have taken a product dialog and modified it for your site. V2.1 is back-level compatible. Dialogs you may have *created* can be copied over to your new install.
However, if you have tailored product dialogs (those prefixed with “KL”) you will need to review your changes and REAPPLY those modifications to the current V2.1 version of that same dialog as it is possible the base code on which you made your changes differs from
the refreshed CL/SuperSession V2.1 base.
NOTE: This list is not exhaustive, there are other customizations you may need to review including unique storage definitions and/or entry points for user developed SSPL applications. Please review *all* members in your V147 RLS* libraries. If you have the “High Availability Option” offering or the “HelpDesk” SPE, addition steps may be required.
SSPL - Structured Session Procedure Language. A high-level programming interface.
IBM CL/SuperSession home page.
(C) COPYRIGHT IBM CORPORATION 2016