Dictionary/204 installation guide

Dictionary/204 Is a set of application subsystems (aka APSYs) running inside a Model 204 Online that provide full-screen and web-based tools to aid programmers, DBAs, and system managers to handle the complexities of User Language and file and system management.

Installing Dictionary/204 requires downloading the M204PROC file and restoring it to your environment, setting up some subsidiary Model 204 files, and verifying that the environment has the appropriate parameter settings.

Upgrades to UL/SPF can almost always be handled by restoring a fresh copy of the M204PROC file.

A summary of the Dictionary/204 installation steps

The following checklist specifies in brief the steps to follow installing Dictionary/204, whether for MVS, CMS or VSE. The sections Installing Dictionary/204 under VSE Installing UL/SPF under CMS and Installing UL/SPF under MVS describe these steps in greater detail for each operating system.

1. Allocate the space required for the M204PROC data set, and RESTORE it from the DUMP files found on the website.

   In addition, there may be any number of other data sets required for the Dictionary/204 components you are installing. These are listed in Installation checklist (VSE) ,Installation checklist (CMS) and Installation checklist (MVS).

2. Update the Online JCL or EXEC:
   • Add the DD cards, FILEDEFs or DLBLs for the Dictionary/204 files.
3. Update CCAIN parameters:
   • Increase NFILES, NDCBS, and NDIR for the Dictionary/204 files.
   • Verify the online has at least 10 SDAEMON threads (each typically defined as an IODEV15).
4. Start the Online, using an ONLINE load module that contains the Model 204 Version 7.5 or higher.
5. Open file M204PROC and execute the following command:

   INCLUDE DDRINST

   Follow the instructions presented on the installation screen (and in the Help text for the screen).

6. Verify success of the installation by compiling each Dictionary/204 APSY.
7. Use the APSY named DICTADMIN to customize the Dictionary/204 environment.

Preparing for Dictionary/204 installation

The Dictionary/204 products are implemented as Model 204 subsystems. The code for all the component subsystems resides in the file named M204PROC which is typically downloaded from the product section of the website.

Obtaining product installation files

The files necessary for the installation are available from the Rocket Software website.

To download product files from the Rocket website:

1. On the Rocket M204 Customer Care page, select the "Download Dictionary/204 files" link in the "Downloads and Uploads" section to access the "Dictionary/204 files for Rocket Software Inc." page.
2. After providing your registered customer login information, download the latest version of the Dictionary/204 file (which is labeled "Dictionary/204 products in one file" followed by a version number).

   A "Click here" link on this page provides Help on downloading format, some information about different browser behaviors, file sizing information, and more.

Determining eligible products

To download files or maintenance from the Rocket M204 Customer Care area of the Rocket website, you must have a registered Rocket user ID (contact Technical Support if you need an ID). The website will show only products for which your organization is up to date on maintenance or rental payments. If a product does not appear on your download page and you believe it should, contact Technical Support.

System requirements

• Dictionary/204 operates in a Model 204 Online region.

  In the rest of this document, "Online" refers to a region of Model 204 running an ONLINE load module containing Version 7.5 or higher

User privileges

The installing user must have:

• Update access to the JCL or EXECs that bring up the host Online.
• System Manager privileges, as well as access to the SUBSYSMGMT facility and the JCL or EXEC that runs the Online Model 204 region.

Full Install or Quick Install

• Sites that have never installed UL/SPF must use the full installation, as there are a number of files to allocate and Model 204 parameters to update.
• Sites that are re-installing the latest version of UL/SPF may use the quick-install or the full installation (some of whose steps would already be complete, such as the allocation and initialization of SIRLOCAL).
• If you are upgrading from a previous version or maintenance level, your site already has a SIRLOCAL file, which holds users' profiles and other local customizations. Your existing SIRLOCAL should be left intact and allocated to the Online, as the installation process uses SIRLOCAL information to determine which features should be upgraded.

A "Quick Install" for existing UL/SPF sites

You can verify the UL/SPF version either in the title of any UL/SPF Help screen, or by looking at the content of the VERSION procedure in the SIRIUS file.

Here are the "Quick Install" steps:

1. In the Rocket M204 Customer Care page of the Rocket website, select the "Download SOUL files" link in the "Downloads and Uploads" section to access the "SOUL files for Sirius Software Inc." page.
2. Download the latest version of the SIRIUS file (which is labeled "All UL/SPF products in one file" followed by a version number).
3. Verify that the Online in which you are installing contains a version of the Sirius Mods equal to or greater than the UL/SPF version.
4. Restore the SIRIUS file into a 4200-page file on your mainframe. The DDNAME for this file in your Model 204 regions is also SIRIUS.

   If you are upgrading from a previous release, simply overlay your old SIRIUS file.

5. If your site uses the web version of SirMon, there is a change between Version 7.7 and 8.1 to the file that holds historical performance information. You should delete from the SirMon APSY definition the file MONDATA, and add the file SIRSTATS, allocated with at least 5000 pages.

   In file SIRIUS, run the procedure CREATE.SIRSTATS to define the fields in the SIRSTATS file.

The UL/SPF APSYs can be set to AUTOSTART if you like. SirScan, SirMon, and SirLib have SCLASS-sensitive code, so SCLASSes should not be renamed or redefined for these systems.

Use the APSY utility SIRADMIN to customize UL/SPF settings.

Installing UL/SPF under CMS

This section gives instructions for installing UL/SPF under CMS, including general system and software requirements. It assumes you have reviewed Preparing for UL/SPF installation for details about UL/SPF system requirements.

The SIRIUS Model 204 file, which contains the SOUL code that runs UL/SPF, can be obtained from the Rocket website or from a UL/SPF distribution tape. If working from a tape, it is shipped with a single tape file in VMFPLC2 DUMP format that includes these files:

File name	Contents
various	Files required for the installation of Sirius Mods. See the Sirius Mods Installation Guide for more details.
ULSPF DUMPSIRI	A Model 204 dump of the SIRIUS file, which is required for all the subsystems.
ULSPF DUMPFIX	A Model 204 dump of the SIRFIXES file, (the use of which is now deprecated).

Installation steps:

1. Install the Sirius Mods.

   UL/SPF requires a matching or greater version number of the Sirius Mods. For information about installing the Sirius Mods, see the Sirius Mods Installation Guide.

2. Allocate space for the UL/SPF files, and restore them from the distribution tape or from the dump files downloaded from the Rocket website.
   1. Define and format a minidisk to hold the UL/SPF installation files. 3400 4096-byte CMS blocks should be sufficient in all cases. This requires a 44-cylinder CMS minidisk on a 3390.
   2. Attach a tape drive at virtual address 181 to the owner of the installation minidisk defined in step A. Mount the UL/SPF distribution tape on this tape drive.
   3. Load the files appropriate to your site with the VMFPLC2 LOAD command. This can be done most simply with the following sequence of commands:

      TAPE REW VMFPLC2 LOAD (EOT

   4. Allocate space for the required Model 204 data sets. A skeleton exec, ULSPFAL, is provided for this purpose. Modify this exec to perform the allocations on the appropriate minidisks. Allocate space for the following data sets:

      SIRIUS	4200 pages; must always be allocated.
      SIRLOCAL	1200 pages; must always be allocated.
      SIRSTATS or MONDATA	60000 pages; only if you are installing SirMon. Use MONDATA for versions 7.7 and earlier. Use SIRSTATS for versions 8.1 and later.
      SIRFILED	1200 pages; only if you are installing SirFile.
      SIRLIBD	1200 pages; only if you are installing SirLib.
      SIRLIBP	1200 pages; only if you are installing SirLib.
      SIRTPROC	2000 pages; only if you are installing SirLib. This file can and should be sized much larger if you maintain hundreds or thousands of concurrent change decks in SirLib.
      JANCAT	1200 pages; only if you are installing Janus OMNI.
      JANSSL	1200 pages; only if you are installing Janus Network Security.

      Attention: If you are upgrading from a previous release, keep your old copy of SIRLOCAL and any application-specific data files, like JANCAT, SIRLIBD, SIRFILED, or SIRSTATS. The installation process uses these files to determine whether to perform upgrade actions or new-installation actions.

   5. Restore the SIRIUS file with the LOADPROC exec.

      To restore, customize the FILEDEF inside the LOADPROC exec to conform to local standards. In addition, modify LOADPROC CCAIN to contain a valid login ID and password. If, for example, you are using the SIRIUS file for the first time, make sure it is created, opened, and initialized before the RESTORE.

      To run the LOADPROC exec, make sure the Online execs and load modules are on an accessed disk, then enter this command:

      ONLINE LOADPROC

3. Complete steps 3 through the end in the "Installing UL/SPF under MVS" section, below.

Installing UL/SPF under MVS

This section gives instructions for installing UL/SPF under MVS, including the general system and software requirements. If you received your product on tape, the following instructions apply. If like most sites, you download products and updates from the Rocket website, see the instructions in A "Quick Install" for existing UL/SPF sites.

Note: The product installation tape for MVS has an internal label of SIRIUS, and it contains UL/SPF files in an IEBCOPY-unloaded PDS on file 3 of the tape. Before continuing, unless you have downloaded the product files from the website, you must load to disk the unloaded PDS before you can RESTORE the individual members to Model 204 files.

The following JCL loads the UL/SPF files to disk:

//LOADSIR JOB 0,CLASS=A,MSGCLASS=X,NOTIFY=ME //* //* Load UL/SPF products from tape //* //LIB EXEC PGM=IEBCOPY,REGION=0M //T1 DD UNIT=TAPE,LABEL=(1,SL),DSN=SIRIUS.LIB, // DISP=(OLD,PASS),VOL=SER=SIRIUS //T2 DD UNIT=TAPE,LABEL=(2,SL),DSN=SIRIUS.LOAD, // DISP=(OLD,PASS),VOL=SER=SIRIUS //T3 DD UNIT=TAPE,LABEL=(3,SL),DSN=SIRIUS.ULSPF, // DISP=(OLD,PASS),VOL=SER=SIRIUS //* //D1 DD DISP=(,CATLG),SPACE=(CYL,(10,0,5), // DSN=SIRIUS.LIB,UNIT=SYSDA //D2 DD DISP=(,CATLG),SPACE=(CYL,(5,0,2), // DSN=SIRIUS.LOAD,UNIT=SYSDA //D3 DD DISP=(,CATLG),SPACE=(CYL,(44,0,2), // DSN=SIRIUS.ULSPF,UNIT=SYSDA //SYSPRINT DD SYSOUT=* //SYSIN DD * COPY INDD=T1,OUTDD=D1 COPY INDD=T2,OUTDD=D2 COPY INDD=T3,OUTDD=D3 /*

The JCL includes references to these files:

File Num / Name	Contents
1 / SIRIUS.LIB	File required for the installation of Sirius Mods. See the Sirius Mods Installation Guide for more details.
3 / SIRIUS.ULSPF(DUMPSIRI)	A Model 204 DUMP of the SIRIUS file that is required for all the subsystems.
3 / SIRIUS.ULSPF(DUMPFIX)	A Model 204 DUMP of the SIRFIXES file. This file is deprecated and not necessary for this installation.

Installation checklist (MVS)

1. Install the Sirius Mods. Refer to the Sirius Mods Installation Guide for details.

   Note: The Online in which UL/SPF will run must point to a load module containing the Sirius Mods. Also, UL/SPF releases require a matching or greater version number of the Sirius Mods.

2. Allocate the space required for the UL/SPF files. Note that the SIRIUS file has X'0221' privileges, which does not allow RESTORE. If you are creating a new SIRIUS file from scratch, this will not be a problem. But if you are restoring into your existing SIRIUS file, you will have to CREATE the file first (to wipe out existing content) before you execute the RESTORE. The command sequence is something like:

   CREATE FILE SIRIUS END CREATE OPEN FILE SIRIUS IN SIRIUS RESTORE 192 FROM <whatever>

   SIRIUS	4200 pages; must always be allocated.
   SIRLOCAL	1200 pages; must always be allocated.
   SIRSTATS or MONDATA	4000 pages; only if you are installing SirMon. Use MONDATA for versions 7.7 and earlier. Use SIRSTATS for versions 8.1 and later.
   SIRFILED	1200 pages; only if you are installing SirFile.
   SIRLIBD	1200 pages; only if you are installing SirLib.
   SIRLIBP	1200 pages; only if you are installing SirLib.
   SIRTPROC	2000 pages; only if you are installing SirLib. This file can and should be sized much larger if you maintain hundreds or thousands of concurrent change decks in SirLib.
   JANCAT	1200 pages; only if you are installing Janus OMNI.
   JANSSL	1200 pages; only if you are installing Janus SSL.

   Attention: If you are upgrading from a previous release, keep your old copies of SIRLOCAL and any application-specific data files, like JANCAT, SIRLIBD, SIRFILED, or SIRSTATS. The installation process uses these files to determine whether to perform upgrade actions or new-installation actions.

3. Restore SIRIUS, noting the following:
   • Modify LOADPROC in the JCL library created during the $functions installation (usually SIRIUS.Vxxx.LIB, where xxx is a version number) to refer to an appropriate load module and CCAxxxxx files. Note that LOADPROC may have been customized for your site to include only those files relevant to your installation process.
   • Rename database DSNs to conform to local standards.
   • Provide a valid logon ID and password for the CCAIN stream for this job. If, for example, you are using the SIRIUS file for the first time, make sure it is created, opened, and initialized before the RESTORE.
4. Update the Online JCL or EXEC:
   1. Add DD (MVS) cards or FILEDEFs (CMS) for the UL/SPF files. The following list identifies the files for which DD cards or FILEDEFs may be needed:

      SIRIUS	Must always be allocated.
      SIRLOCAL	Must always be allocated.
      SIRSTATS or MONDATA	If installing SirMon and using the web interface. Use MONDATA for UL/SPF versions 7.7 and prior. Use SIRSTATS for UL/SPF versions 8.1 and later.
      SIRFILED	If installing SirFile.
      SIRLIBD, SIRLIBP, SIRTPROC	If installing SirLib.
      JANCAT	If installing JANUS OMNI Access Module.
      JANSSL	If installing JANUS SSL Module.

   2. Verify that the Online environment allows the use of file groups and APSY subsystems.
      • To use permanent file groups, the Online must have allocated an initialized CCAGRP file, and the SYSOPT parameter must contain the 2 bit.
      • To use APSYs, an Online must have allocated an initialized CCASYS file (with all fields defined), and the SYSOPT parameter must contain the 1 bit.
      For more information about APSYs and file groups, see File groups and System requirements for Application Subsystems.
5. Verify the Online has a minimum of 10 Sdaemon threads allocated. Each of these threads is typically defined as IODEV15.
6. Modify the User 0 stream.

   Adjust these parameters:

   NFILES	Increase by the number of UL/SPF files.
   NDCBS	Increase by the number of UL/SPF files.
   NDIR	Increase by the number of UL/SPF files.
   NORQS	Verify setting is at least 5.

7. Start the Model 204 Online region, verifying that it points to a load module containing the Sirius Mods.
8. Issue OPEN FILE SIRIUS (no password is required), and execute the following command:

   INCLUDE SETUP.EXE

   This procedure performs all installation functions for new users, and all upgrade functions for reinstalling users. No user profiles or other site-specific customization will be lost. If any problems are encountered while running this procedure, correct the problem and re-execute.

   The procedure SETUP.EXE also builds an APSY subsystem called SETUP.EXE. If installations need to be re-run, the subsystem may be invoked rather than the procedure.

   During APSY execution, some error messages are not suppressed to aid in diagnosing any installation problems.

   For example, you will be able to see if an installation failed because a file was enqueued in a different Online, etc.
9. Add users to the appropriate SCLASSes for any private or semi-public UL/SPF APSYs.

   The installing user is automatically added to the administration SCLASS in all UL/SPF APSYs.

10. Verify the installation of the subsystem(s) by compiling all of the subsystems.

    Enter ...	To test the ...
    SIRSCAN START	Journal scanner
    SIRFILE START	File monitoring subsystem
    SIRPRO START	Developers' environment
    SIRMON START	Online performance monitor
    SIRLIB START	Change management system
    JANCAT START	Janus OMNI Table manager
    JANSSL START	Janus SSL certificate management system

    If any of these subsystems fails to compile, ensure that the subsystem is STOPped, and run it under TEST DEBUG mode. For example, to determine why SIRSCAN failed to compile, enter:

    TEST DEBUG SIRSCAN

11. This step is optional. Modify the online input stream so User 0 initializes (compiles) the UL/SPF subsystems. Do this by placing one or more of the following in User 0's input stream:

    SIRSCAN START SIRFILE START SIRPRO START SIRMON START SIRLIB START JANMAN START JANCAT START START SUBSYSTEM ULSPF

    This ensures that the subsystems are started for non-administrative users, and it shifts the overhead of compilation to a non-peak computing period.

12. Review the UL/SPF server size and additional customization section, below, for specific requirements of individual APSY components of UL/SPF.

Note: CCATEMP usage may increase with UL/SPF. CCATEMP should be monitored (VIEW TEMPSIZE, VIEW TEMPMAX) to ensure that sufficient space is allocated to accommodate the additional activity.

UL/SPF server size and additional customization

The minimum UL/SPF server size requirements are listed below. The actual server size requirements may vary slightly, because of table settings in the local Online Model 204 regions, and because of slight differences between UTABLE requirements in different versions of Model 204.

Subsystem name	Minimum server
SIRSCAN	180K
SIRDBA	180K
SIRFILE	230K
SIRPRO	380K
SIRLIB	135K
SIRADMIN	150K
SIRMON	120K
ULSPF	135K

UTABLE and other parameter settings

As of UL/SPF version 8.1 (June 2013), all UL/SPF subsystems can be set to bypass UTABLE resets. Use the SIRADMIN subsystem to set this feature. For versions prior to 8.1, and for those who choose to leave the UTABLE resets in place, UL/SPF will capture local UTABLE settings before they reset them to those required by UL/SPF.

Initial problems with UL/SPF subsystems are usually associated with one or two extremely small default UTABLE settings. Running the failing APSY in TEST DEBUG mode will highlight UTABLE parameters that need to be increased.

Note: One parameter that must be set for SIRMON, SIRPRO, and SIRSCAN is SCRNSTBL, which is necessary for the use of screen objects.

UL/SPF required parameter minimums
Parameter	Value
SCRNSTBL	12000

Additional setup for SirLib

Read and follow the instructions in the appendix "Getting Started" in the SirLib User's Guide.

Additional setup for SirScan

The SirScan administrator may use SIRADMIN option 4 to set default I/O and record maximums for users in the various SirScan SCLASSes. This is described at the beginning of the SirScan User's Guide.

Additional setup for SirMon

When users are added to SCLASSes, note that there is a special BUMP SCLASS. Any user added to this SCLASS gains the ability to BUMP other users. This class does not provide access to customizing options in SirMon. Only users in the ADMIN SCLASS are able to add custom screen definitions to SirMon.

If the SirMon background monitor is to be used, add the following line to User 0's input stream:

SIRMON BACKGROUND

The background monitor may also be started automatically in a BATCH2 thread or an sdaemon thread. Consult the SirMon User's Guide for details.

You can customize statistic thresholds or use the supplied defaults to establish problem conditions.

As of UL/SPF Version 6.8, SirMon has a feature to send warnings to e-mail addresses and cell phones (via e-mail). This feature requires Janus Sockets and a started Janus Sockets port.

Additional setup for SirFile

If the SirFile background monitor is to be used, add the following line to User 0's input stream:

SIRFILE BACKGROUND

As with SirMon, the background monitor may be started automatically in a BATCH2 thread or in an sdaemon thread, and you can consult the SirFile User's Guide for details.

You can customize the system and file-specific thresholds or use the supplied defaults to establish problem conditions.

UL/SPF access privileges and SCLASSes

Each component application of UL/SPF has its own APSY definition and privileges associated with SCLASSes. If you have a good reason for doing so, you can redefine any of the UL/SPF APSYs as PUBLIC, SEMI-PUBLIC, or PRIVATE. Contact Rocket Software if you are unsure of the effect of a proposed change.

UL/SPF on the Web

Web-specific versions of the UL/SPF subsystems are actively being developed and supported, and they are available to sites that own Janus Web Server.

All the UL/SPF APSYs can be used on the web via Janus Web Legacy Support, which simply translates the 3270 screens of the underlying product into HTML. Web-specific versions of both SirScan and SirMon can be invoked by setting up some Janus Web Server web rules.

Setup for web-based SirScan

Web-based SirScan is very lightweight, and requires a minimum of web rules to run.

1. Define a Janus Web Server port.
2. Define the following rule to invoke SirScan:

   JANUS WEB portname ON /SIRSCAN/* CMD 'SIRSCAN *'

3. The above rule will make SirScan available, but it will not necessarily require a logon to the system, so you will need to add rules to force users to log in as well:

   JANUS WEB portname DISALLOW /SIRSCAN/* JANUS WEB portname ALLOW /SIRSCAN/* USER *

4. Because the above rules force users to login, the port on which SirScan runs should either:
   • Be only on a company intranet.
   • Be SSL protected, to prevent userids and passwords from being sent over the internet in clear text format.

   The above rules will work on an unprotected port, but it is very strongly recommended that this feature only be used when SSL protection is in effect.

Setup for web-based SirMon

This applies only to UL/SPF Version 8.1 and later.

Because web-based SirMon employs XML, XSLT, Javascript, a stylesheet and some graphics, the web rules needed to run SirMon on the web are a little more complex:

1. Define a Janus Web Server port.
2. Define the following rules to invoke SirMon:

   JANUS WEB portname TYPE ANY *.PNG IMAGE/PNG JANUS WEB portname TYPE ANY *.CSS TEXT/CSS JANUS WEB portname TYPE ANY *.JS APPLICATION/X-JAVASCRIPT JANUS WEB portname ON /*.CSS OPEN SIRIUS SEND *.CSS JANUS WEB portname ON /SIRMON/* CMD SIRMON JANUS WEB portname ON /SIRMON/*.GIF OPEN SIRIUS SEND *.GIF EXPIRE +2147483 JANUS WEB portname ON /SIRMON/*.PNG OPEN SIRIUS SEND *.PNG EXPIRE +2147483 JANUS WEB portname ON /SIRMON/*.JS OPEN SIRIUS SEND *.JS BINARY EXPIRE +2147483 JANUS WEB portname ON /AJAX/* OPEN SIRIUS SEND * JANUS WEB portname ON /AJAX/*.JS OPEN SIRIUS SEND *.JS TEXT JANUS WEB portname ON /AJAX/*.UL OPEN SIRIUS CMD 'INCLUDE *.UL' JANUS WEB portname DISALLOW /SIRMON/* JANUS WEB portname ALLOW /SIRMON/* USER * JANUS WEB portname TYPE ANY *.XML TEXT/XML JANUS WEB portname TYPE ANY *.XSL TEXT/XSL JANUS WEB portname ON /SIRMON/*.XSL OPEN SIRIUS SEND *.XSL EXPIRE +2147483 JANUS WEB portname ON /SIRMON/*.CSS OPEN SIRIUS SEND *.CSS EXPIRE +2147483 JANUS WEB portname ON /SIRMON/TEXTJS/*.JS OPEN SIRIUS SEND *.JS TEXT EXPIRE +2147483 JANUS WEB portname ON /SIRMON/BUILDJS/*.JS CMD SIRMON OPEN SIRSTATS IN SIRSTATS INITIALIZE KEEPDEFS

3. The above rules will make SirMon available, but they will not necessarily require a logon to the system, so you will need to add rules to force users to log in as well:

   JANUS WEB portname DISALLOW /SIRMON/* JANUS WEB portname ALLOW /SIRMON/* USER *

4. Because the above rules force users to login, the port on which SirMon runs should either:
   • Be only on a company intranet.
   • Be SSL protected, to prevent userids and passwords from being sent over the internet in clear text format.

   The above rules will work on an unprotected port, but it is very strongly recommended that this feature only be used when SSL protection is in effect.

   Note: Using SirMon on the web also requires the SIRSTATS file. As shown in the above web rules, SIRSTATS can be re-initialized each time the Online comes up. SIRSTATS contains historical snapshots of system performance, and the file will fill up if not archived or reinitialized on occasion.