INSTALLATION INSTRUCTIONS

Transcription

1 Release 1408 Service Request INSTALLATION INSTRUCTIONS Document Number install.doc Adam Cohen Information Systems & Computing Office of the President University of California

2 Page 1 This document provides installation instructions for this release. Review these instructions carefully before proceeding with installation. Successful installation is dependent on the installation and verification of the following system software: OS/390 version 2 release 10 IBM HTTP Server release 5.3 IBM DB2 version 6 IBM Net.data version 2 release 2 The application requires the following web browser requirements: Netscape 4.5 or higher, PC or Mac Microsoft Internet Explorer 5.0 or higher, PC or Mac Prior versions of these browsers, or other browsers, may not format application pages precisely. In addition, the computer s display resolution must be set to 800x600 or higher. Resolutions lower than this will not provide enough screen area to display the application pages without scrolling. The installation of this release is dependent on the installation of release 1391, the DB2 AFP. System Software Requirements and Installation Certain features of the base system are dependent on the MVS security manager. The following instructions assume that RACF is the MVS security manager. If an alternate security product is being used, the campus installation may require additional or different installation steps. RACF Class Descriptor Table Successful installation of the application assumes that the RACF class descriptor table (CDT) has been customized to add the user-defined resource class $PPSFUNC. This class was established for the CICS EDB Inquiry application and should be in place for any campus already using CICS for EDB Inquiry. Create RACF profiles The screen-level authorization feature of Web Inquiry is controlled by a set of RACF profiles. These profiles are similar to the screen profiles created for EDB Inquiry under CICS. The profile name is composed of a prefix and screen name, separated by a period. The prefix portion of the name is determined at installation and the value used to create the profiles must be defined in the PPSPARMS file described later in this document. The screen name portion of the name is hardcoded in the application and must be taken from the list below. The prefix is customizable to allow campuses to create separate sets of RACF profiles for different copies of the Web Inquiry application. For example, for a test system, a prefix value of PPST may be used to differentiate screen profiles from a set of production profiles prefixed with PPSW. Create new RACF profiles in the general resource class $PPSFUNC with the names in the following table. Each profile represents a particular page in the application. The default security prefix value of PPSW is shown below. If this value needs to be changed, it must also be changed in the PPSPARMS file as described on page 12 of this document. Profile Name Description Created? PPSW.PPWWIADR Address Information

3 Page 2 PPSW.PPWWIAPP PPSW.PPWWIBEN PPSW.PPWWIBRS PPSW.PPWWICIT PPSW.PPWWIDSP PPSW.PPWWIEMP PPSW.PPWWIFAM PPSW.PPWWIFIN PPSW.PPWWIFUT PPSW.PPWWILAB PPSW.PPWWILIC PPSW.PPWWILVA PPSW.PPWWIPAY PPSW.PPWWIPER PPSW.PPWWIRET PPSW.PPWWITAX PPSW.PPWWIWRK PPSW.PPWWWLCM PPSW.WEI Appointments/Distributions Benefits Information Browse Page Citizenship Information Pay Disposition Information Employment Information Benefits-Family Members subpage Financial Aid Information Benefits-Future Enrollments subpage Labor Relations Information Licenses Information Leave Accrual Information Hours Balances Information Personal Information Retirement Information Taxes Information Work Study Information Welcome page Application access Permit access to these resource profiles to existing RACF groups as needed. Note that the profile PPSW.WEI controls access to the entire application. All users who will access the application should be permitted to access this profile, regardless of what individual page profiles they are permitted to access. Create surrogate ID For the purposes of the web application, a generic, or surrogate userid must be created to allow multiple web users to be mapped to a single userid. This userid is then given permission to access various objects in the DB2 and OS390 environments, thus avoiding the need to grant these permissions to each user of the web application. The steps to create the surrogate userid are shown below. In this example, PAYWEB is the name of the surrogate userid. PAYGRP is the name of the RACF group it belongs to. The surrogate userid should be assigned to the same RACF group as the ID performing the installation. xxx should be replaced by a unique UID value as assigned by campus OS390 procedures. WEBADM is the userid of the webserver. These identifiers should be reviewed and modified for campus requirements. 1. Activate surrogate resource class RACF command: SETROPTS CLASSACT(SURROGAT) 2. Create account PAYWEB with OMVS segment but no TSO segment. RACF command: ADDUSER PAYWEB DFLTGRP(PAYGRP) OMVS(UID(xxx) Home(@/@) PROG(@/bin/sh@)) 3. Define the PAYWEB account in class BPX.SRV RACF command: RDEFINE SURROGAT BPX.SRV.PAYWEB UACC(NONE) 4. Allow the webserver to use the surrogate ID: RACF command: PERMIT BPX.SRV.PAYWEB CLASS(SURROGAT) ID(WEBADM) ACCESS(READ)

4 Page 3 5. Allow the surrogate ID to use the SERVER class: (required for the security interface modules): RACF command: PERMIT BPX.SERVER CLASS(FACILITY) ID(PAYWEB) ACCESS(READ) 6. Refresh RACF RACF command: SETROPTS RACLIST(SURROGAT) REFRESH Security Interface Modules The application provides interfaces to MVS security using two application modules: In addition to the MVS security setup steps listed above, these modules must be installed and additional permissions must be granted in the MVS security manger. Module PPSLOGON interfaces with the MVS security manager to check passwords during sign-on to the Web EDB Inquiry application. This module also manages the change-password process that is provided by the application. Module PPSFUNC implements the function security feature of and allows the installer or administrator to restrict which users can access individual pages within the application. This feature is also used by to restrict access to the entire application through a special resource profile. Create New Libraries In order to provide DB2 with access to base dual-use programs that will be called from stored procedures, a load library must be concatenated to the STEPLIB DD of the DB2 stored procedure address space procedure. This should be a newly created library to hold specially-compiled versions of dual-use programs, now referred to as tri-use programs, as well as new stored procedure programs. After the new library is allocated and the stored procedure address space procedure is modified, the stored procedure address space (SPAS) must be restarted. New DBRM and BIND libraries should also be created to store DBRMs and BIND members for the tri-use and stored procedure programs. Download Release Libraries Download the following release libraries to the local system from the UCOP FTP server. PAYDIST.R1408.WMACRO PAYDIST.R1408.WINCLUDE PAYDIST.R1408.WIMAGES PAYDIST.R1408.WSOURCE PAYDIST.R1408.WHTML PAYDIST.R1408.JCL PAYDIST.R1408.DDL PAYDIST.R1408.COBOL PAYDIST.R1408.BIND PAYDIST.R1408.INCLUDE PAYDIST.R1408.CARDLIB DB2 Installation This portion of the installation creates DB2 objects and stored procedures for use by the Web Inquiry application.

5 Page 4 DDL Member Installation 1. Install the new DDL members listed in the following table, replacing *AUTHID*, *STOGROUP* and database *PPPPCD*, as necessary, with appropriate campus values. Once installed, execute each DDL member in the order shown below to create the new DB2 objects. The CURRENT SQLID must be set to the value of *AUTHID* when creating these objects. DDL Members Database Installed? Executed? TSSES00C PPPPCD TBSES00C PPPPCD IXSES00C PPPPCD IXSE200C PPPPCD UC0VZSES PPPPCD 2. Install and execute the new one-time DDL member listed in the following table, replacing *COLLID* with a new collection ID to be used only for. It is required that a new collection ID be established rather than using an existing collection ID from CICS EDB Inquiry. Replace *AUTHID* with the value of the authorization ID that will own the objects. DDL Members Installed? Executed? PPO1408A 3. Install the new DDL members listed in the following table, replacing *COLLID* with the new collection ID for. Once installed, execute each DDL member to create the new DB2 objects. The CURRENT SQLID must be set to the value of *AUTHID* when creating the stored procedure objects. DDL Members Installed? Executed? SPADD00C SPBRC00C SPBRS00C SPCTT00C SPDBL00C SPDLI00C SPEDB00C SPEPD00C SPFAU00C SPGSE00C SPHDR00C SPKSE00C SPSSE00C SPSSI00C SPSSN00C SPTCT00C SPXDI00C SPXHI00C SPXJD00C SPXLI00C SPXVI00C

6 Page 5 4. Install and execute the new one-time DDL member listed in the following table, replacing *WEBID* with the surrogate ID crated in the System Software Requirements and Installation section of this document. Once installed, execute the DDL member to grant database permissions to the Web surrogate ID. DDL Members Installed? Executed? PPO1408B 5. Once the new stored procedures have been created with the DDL in step 3, the procedures must be started using the DB2 START command (from SPUFI or in batch) as shown below: -START PROCEDURE (*AUTHID*.*) Replace *AUTHID* in the above command with the value of *AUTHID* used to modify the DDL members in step 1. Include Member Installation 1. Install the following new include members listed in the following table. Include Members UC0VZSES Installed? Bind Member Installation 1. Install the new bind member listed in the following table for the stored procedures. Modify these bind members replacing the existing collection ID value with the new collection ID created for Web EDB Inquiry and the owner ID as needed. Bind Members Installed? Collection ID modified? PPWWIHDR PPWWUBRC PPWWUBRS PPWWUDBL PPWWUFAU PPWWUSSI PPWWUSSN PPWWUGSE PPWWUSSE PPWWUKSI 2. Copy the existing Bind members listed in the following table, replacing the existing collection ID value with the new collection ID created for and the owner ID as needed. Bind Members Copied? Collection ID modified? UCPPPEDB PPBENADD PPBENDLI PPBENEPD PPBENXDI PPBENXHI

7 Page 6 PPBENXJD PPBENXLI PPBENXVI PPCTTUTL PPTCTUTL PPPRMUT2 These bind members will be executed during program preparation in a later installation step. Program Preparation Note: At UCOP, all COBOL programs pass through the DB2 pre-compiler, whether or not the program contains embedded SQL, to resolve INCLUDE references. Your site may have different requirements. Note: This release introduces two new categories of programs, tri-use, or TRI and stored procedure, or SPROC. TRI programs are certain COBOL programs that were formerly dual-use but are now also called by DB2 stored procedures. TRI programs must be compiled three times and linked into batch, online and stored procedure libraries respectively. SPROC programs must be compiled once and linked into the stored procedure load library. 1. Install, compile and link the new programs listed in the following table to create DB2 stored procedures. Package bind using the bind members listed above. Program DB2? Compile Package Bind? Done? PPBADDSP No SPROC No PPBDLISP No SPROC No PPBEPDSP No SPROC No PPBXDISP No SPROC No PPBXHISP No SPROC No PPBXJDSP No SPROC No PPBXLISP No SPROC No PPBXVISP No SPROC No PPCTTSPR No SPROC No PPTCTSPR No SPROC No PPWWIHDR Yes SPROC Yes PPWWUBRC Yes SPROC Yes PPWWUBRS Yes SPROC Yes PPWWUDBL Yes SPROC Yes PPWWUFAU Yes SPROC Yes PPWWUSSI Yes SPROC Yes PPWWUSSN Yes SPROC Yes PPWWUGSE Yes SPROC Yes PPWWUKSE Yes SPROC Yes PPWWUSSE Yes SPROC Yes 2. Compile and link the existing, unmodified programs listed in the following table to create versions for use by DB2 stored procedures. Package bind using the bind members listed above. Program DB2? Compile Package Bind? Done? UCPPPEDB Yes TRI Yes

8 Page 7 PPBENADD Yes TRI Yes PPBENDLI Yes TRI Yes PPBENEPD Yes TRI Yes PPBENXDI Yes TRI Yes PPBENXHI Yes TRI Yes PPBENXJD Yes TRI Yes PPBENXLI Yes TRI Yes PPBENXVI Yes TRI Yes PPCTTUTL Yes TRI Yes PPTCTUTL Yes TRI Yes PPXWHC No TRI No PPPRMUT2 Yes TRI Yes Note: The compile methods SPROC and TRI utilize a special compile for tri-use and stored procedure COBOL programs. Sample JCL for this compile can be found in JCL member COMPSP. Plan Binds 1. A special plan bind is required for the Net.data plan, DTWGAV22. The plan must be rebound to include the application collection ID referenced in the stored procedure create DDL. JCL member BINDDTW may be used as an example, however this job must be modified to insert the proper collection ID, and retain any existing collection IDs already in the plan. The bind must be run from an ID with appropriate DB2 privileges. Web Application Installation This portion of the installation assumes that the OS/390 environment is established and that the installer can successfully log on to the OMVS environment. Create Directory Structure Identify a root directory for the application somewhere in the OS/390 filesystem. From this root, create the following subdirectories: macro include images bin source For example, if the root directory chosen is /prod/pps, the directory structure should be: /prod/pps/macro /prod/pps/include /prod/pps/images /prod/pps/bin /prod/pps/source Once the directories files have been created, use the chmod command from the OMVS environment to set permissions on all directories to 755. The group ownership of all files may be left as-is, assigned to the group associated with the installer ID.

9 Page 8 $ cd /prod/pps $ chmod 755 * Copy Web Application Files Review and edit the job PDS2HFS in the JCL library to transfer the web application files to the application directory structure created above. Edit the control statements to supply the local directory names created above. Run this jobstream once the necessary customization has been made. After running the PDS2HFS jobstream, verify that the following Net.data files were copied to the macro directory (/prod/pps/macro based on the example given above): Filename ppsbframe.d2w ppsdetail.d2w ppsnframe.d2w ppsprint.d2w ppsrouter.d2w ppstframe.d2w ppsmenu.d2w ppslogon.d2w ppsexit.d2w ppsauth.d2w ppschgpw.d2w Description Bottom frame program Detail frame program Navigation frame program Printable format driver program Main navigation program Top frame program PPS applications main menu program PPS logon page PPS exit message page Logon authorization module Change password page Once the macro files have been copied, use the chmod command from the OMVS environment to set permissions on all files to 755. The group ownership of all files may be left as-is, assigned to the group associated with the installer ID. $ chmod 755 * Verify that the following Net.data files were copied to the include directory (/prod/pps/macro/include based on the example given above): Filename ppwwiadr.d2w ppwwiapp.d2w ppwwiben.d2w ppwwibrs.d2w ppwwicit.d2w ppwwidsp.d2w ppwwiemp.d2w ppwwifam.d2w ppwwifin.d2w ppwwifut.d2w ppwwilab.d2w ppwwilic.d2w ppwwilva.d2w ppwwipay.d2w ppwwiper.d2w ppwwiret.d2w Description Address page Appointments/Distributions page Benefits page Browse page Citizenship page Check disposition page Employment page Benefits subpage Family member enrollments Financial aid page Benefits subpage Future enrollments page Labor relations page Licenses page Leave accrual page Hours balances page Personal page Retirement page

10 Page 9 ppwwitax.d2w ppwwiwrk.d2w ppwwwlcm.d2w ppsparms.d2w ppsphead.d2w ppsutil.d2w pps_css_hdr.hti pps_js_hdr.hti Tax page Work study page Welcome page System parameter definitions Printable format header program Common utility routines CSS (style-sheet) HTML definitions Header file for Javascript routines Once the include files have been copied, use the chmod command from the OMVS environment to set permissions on all files to 755. The group ownership of all files may be left as-is, assigned to the group associated with the installer ID. $ chmod 755 * Verify that the following graphics files were copied to the images directory (/prod/pps/images based on the example given above): Filename address.gif appointments.gif background.gif benefits.gif browse.gif Citizenship.gif employment.gif financialaid.gif footerline.gif laborrelations.gif leaveaccrual.gif licenses.gif logout.gif mainmenu.gif paydisposition.gif payhours.gif PayPersSys3A.jpg personal.gif printer.gif retirement.gif taxes.gif workstudy.gif uc.gif Description Background image Background image Header frame logo Background image Once the image files have been copied, use the chmod command from the OMVS environment to set permissions on all files to 755. The group ownership of all files may be left as-is, assigned to the group associated with the installer ID. $ chmod 755 * Verify that the following HTML file was copied to the root directory (/prod/pps based on the example given above):

11 Page 10 Filename Welcome.html Description Default page which redirects user to initial application page Once the HTML file has been copied, use the chmod command from the OMVS environment to set permissions on the file to 755. The group ownership of the file may be left as-is, assigned to the group associated with the installer ID. $ chmod 755 * Verify that the following C program source files were copied to the source directory (/prod/pps/source based on the example given above): Filename ppsfunc.c ppslogon.c Description Screen level authorization checking program Logon authorization checking program Install security interface programs After the C program source files are copied to the source directory, the programs must be compiled using the OS/390 C89 compiler. 1. The compiler can be invoked using the following command from the OMVS environment: $ cd /prod/pps/source $ cc ppsfunc.c 2. After successful compilation, the executable file will be created with the name a.out. This file must be moved to the bin directory (/prod/pps/bin based on the example given above) and renamed with the following command: $ mv a.out /prod/pps/bin/ppsfunc 3. The final executable must be flagged as program controlled. This may be accomplished using the extattr command. In order to execute the extattr command, the userid issuing the command must have at least READ permission to a special RACF profile, BPX.FILEATTR.PROGCTL. $ cd /prod/pps/bin $ extattr +p ppsfunc Repeat steps 1-3 for the the ppslogon.c program. Replace references to ppsfunc in steps 1-3 with ppslogon. Program Compiled? Moved? Flagged? ppsfunc.c ppslogon.c Once the executable files have been copied, use the chmod command to set permissions on all files to 755. The group ownership of all files may be left as-is, assigned to the group associated with the installer ID. $ chmod 755 *

12 Page 11 Net.data customization The Net.data initialization file DB2WWW.INI, must be customized by specifying the application paths in the MACRO_PATH and INCLUDE_PATH variables. We assume that the INI file has already been properly configured to connect to the appropriate DB2 subsystem, and that the Net.data plan has been bound into that subsystem. An example of the customized DB2WWW.INI file is shown below: MACRO_PATH /prod/pps/macro; INCLUDE_PATH /prod/pps/include; EXEC_PATH /prod/pps/bin; Note that additional paths may already be present on these variables. The application paths for this release should be concatenated to any existing paths using a semicolon as a separator. Web server customization The webserver configuration must be customized to define the PPS application paths. The configuration file httpd.conf requires the following modifications: 1. Add a Pass directive to define the application top-level qualifier and map it to the root directory in the filesystem created above. Pass /pps/* /prod/pps/* For example, if the server name is payroll.ucop.edu, and the desired top-level qualifier is PPS, then the full URL will be which will point to the application path created above 2. Verify that an Exec statement exists for Net.data. An example of the correct Exec statement is: Exec /netdata-cgi/* /usr/lpp/netdata/cgi-bin/* 3. Create a protection setup for the application in the webserver configuration. This setup defines security behavior for the application. Protection PPS_EDB_Inquiry { ServerID PPS_EDB_Inquiry UserID PAYWEB Mask Anybody In this example, PAYWEB is the surrogate ID created in the System Software Requirements and Installation section of this document. 4. Apply the protection setup for the application to the application directories so that the webserver does not prompt for logon information when executing Net.data macros. Protect /pps/* PPS_EDB_Inquiry PAYWEB Protect /netdata-cgi/* PPS_EDB_Inquiry PAYWEB If Net.data was installed with a different path specified in the Exec directive, use that path in the Protect directive above, instead.

13 Page 12 Application Customization Points 1. Customize the Welcome.html file in the web application root directory to provide the full path to the Net.data executables. For example, based on the default installation of Net.data shown above, the full URL to execute a Net.data macro on the campus system would be (The URL portion is an example and should be replaced by the correct URL for the campus web server running PPS applications.) The Welcome.html file should be reviewed for modifications to the server name and Net.data path name. The initial application macro name and section name do not need to be modified. 2. Module PPSPARMS.D2W (stored in the INCLUDE directory) This module is a Net.data macro that establishes values for certain operational parameters of the Web EDB Inquiry application. Customization of the first parameter in this module is required for the application to work correctly in the campus environment. Parameter Name Description Default Value authid DB2 AUTHID that will be used to qualify all object references including views and stored procedures. Should be set to the owner of the DB2 views and stored procedures. NONE - MUST BE SUPPLIED DURING INSTALLATION header_logo Name of the GIF or JPG file that holds the graphic logo to be displayed on the header area. The maximum size of this graphic is 300x49 pixels. PayPersSys3A..jpg ssn_display session_timeout Controls whether the data element EDB 0111 (Employee SSN) is displayed on the browse page. Set to FALSE to suppress display of this element. SSN will always be displayed in the page header if the user has ARSM permission to access the employee record. This parameter is the number of minutes that a Web EDB Inquiry session can be inactive before it will be timed out, requiring the user to log in to the application again. TRUE 30 subsystem securityprefix This value is the subsystem identifier for the Web EDB Inquiry application. A row with this value should be present on the UC0SSI table to allow the application administrator to control access to during batch processing. This value will be used to prefix all screen names when they are sent to the PPSFUNC module for screen-level authorization checking. EI (the same value used for CICS EDB Inquiry) PPSW qualifier This value should be set to the first level of the URL of the application, matching the value of the application top-level qualifier specified in step 1 of Web Server Customization. /pps

14 Page Module PPWWUFAU This value is used to qualify URL references to files in the image directory. This module is a stored procedure that retrieves account names for display on the appointments/distributions page. The base version of this module reads account information from the new DB2 AFP issued as release Campuses should review the comments in the module for further information on how to customize the module for local needs. Testing Perform installation verification testing as described in the Test Plan. In addition perform any further local testing. Install in Production 1. Run PPP004 to update the following DB2 CTL tables: Code Translation Table (38) - Use the transactions in CARDLIB(CTTPROD), or key from the provided UPAY814 facsimile in cttprod.pdf. System Messages Table (08) Use the transactions in CARDLIB(MSGPROD), or key from the provided UPAY554 facsimile in msgprod.pdf.