Frequently Asked Questions

PHOENIX and PREFERENCE System/Utilities

• Releases that are supported by technical support
• PHOENIX/PREFERENCE user hierarchy 
• Installation vs. reinstallation
• How to convert system from numeric user IDs to alphanumeric user IDs
• How many concurrent users can the system accommodate
• Recommended maintenance flow
• Moving system datasets
• How to create a new program file
• How to increase the size of the user and auxiliary datasets
• Can I test the mainframe products for year 2000 compliance
• How to Calculate User File Sizes to Support Additional Users
• How to resolve a GC516 GOALSYS - Termination Due to CSA Buffer Shortage
• End-user gets GD024, and job log shows associated GC136 error messages in CBEEDITP
• How to move courses from development to production without losing class settings, roster files and mail files
• How to resolve GC150 - Disk Error condition after PHOENIX/PREFERENCE files have been moved
• How to calculate the total number of individuals who completed a particular CBT course within a specified time frame
  

RELEASES THAT ARE SUPPORTED BY TECHNICAL SUPPORT

Click here to view the release support policy.

[back to top]

PHOENIX/PREFERENCE USER HIERARCHY

[back to top]

INSTALLATION vs. REINSTALLATION
The Installation process is designed for new customers who are installing the system for the first time. The Reinstallation process is for existing customers who are upgrading their system.

[back to top]

HOW TO CONVERT SYSTEM FROM NUMERIC USER IDs TO ALPHANUMERIC USER IDs

• Stop system and back up User and Auxiliary datasets by using either GSPFASBK or GSPRESTR

• Modify the sample jobstream CONVERT in the SAMLIB dataset

• Submit modified jobstream

• Change the SUPCODE = parameter to identify the new supervisor ID (must begin with either a colon (:), a semicolon (;), or a backslash (\)).

• Restart system

• Sign on as a supervisor and issue WHAT? command. If the conversion was successful, the message Alphanumeric is displayed.

Note: Old numeric user IDs begin with a letter followed by 1 to 9 digits. The conversion deletes the initial letter but preserves the remaining digits as a unique user ID. Thus, an author who signed on as a101 before conversion would enter 101 to sign on after conversion.

Once you convert an alphanumeric system, you cannot change alphanumeric user IDs back to numeric format. However, you can restore the original numeric system (User and Auxiliary) from back-up tape.

[back to top]

HOW MANY CONCURRENT USERS CAN THE SYSTEM ACCOMMODATE?
The maximum concurrent users for a Non-XA system is 300-400. Maximum for system with XA support 2500-3000.

RECOMMENDED MAINTENANCE FLOW
Maintenance strategies are specific to each organization; however, the following flow provides the activities that should be included in your maintenance and backup process.

NIGHTLY/WEEKLY

• GSPFASBK - Back-up datasets

• GSPMUSER - Compress GSPUSER and GSPAUX datasets

• GSPBROS - Update, synchronize roster files with user file

• GSPSPLR - Archive Log and Recording file records

• GSPPDUMP - Print program dump to sysout class that purges after 3 days, reset dataset to empty state.

• GSPINTEG - Perform Integrity check on program files. If RC=4 or less, then

• GSPBATCH - (PREFERENCE only) Perform FORCETOC on volumes

• GSPMPROG - Batch reassemble courses/volumes with high entropy

• GSPFCOMP - Compress program files

WEEKLY/MONTHLY

• GSPFASBK - Back-up datasets

• GSPREPT1 - Produce system reports

[back to top]

MOVING SYSTEM DATASETS
The system datasets are divided into three separate categories: sensitive, nonsensitive, and partitioned. The following information identifies which dataset is associated with each category and the method that should be used when moving these datasets.

[back to top]

HOW TO CREATE A NEW PROGRAM FILE
Run GSPCLEAR to allocate and format a new program file. In the data definition statement include DSORG=DA in the DCB parameter. Add the new file to the system start-up JCL, then recycle the system.

Be sure to add a dd statement for the new file to your maintenance jobstreams as well.

[back to top]

HOW TO INCREASE THE SIZE OF THE USER AND AUXILIARY DATASETS
Run GSPMUSER to create new user and auxiliary datasets. Specify new dataset names and space requirement in the Newuser and Newaux DD statements. Rename the existing datasets with the extension .old and the new datasets with the original names.

[back to top]

CAN I TEST THE MAINFRAME PRODUCTS FOR YEAR 2000 COMPLIANCE?
Pathlore is providing a method for our customers to test the current releases of our mainframe products for Year 2000 compatibility. Generally, these test scenarios are provided at no cost. Some testing requirements at some customer sites have required additional licenses. Pathlore is evaluating each company's testing requirements on an individual basis. For more information, please contact Pathlore Customer Service at 800.829.9088.

[back to top]

HOW TO CALCULATE USER FILE SIZES TO SUPPORT ADDITIONAL USERS
The following shows how to calculate file sizes to support an additional 100,000 users in a hypthetical case where:

NOTE: These files are all increased by running the GSPMUSER system utility. See the PHOENIX System Utilities Guide sections on GSPMUSER for how to implement results from calculations below.

The information in the following list is referenced in the PHOENIX System Guide on the pages indicated. This list documents what the user must know in order to calculate the new required sizes for each file.

• By default Ease authored courses require 2 Aux blocks per registered user (page 6.11)

• The GSPAUX file has a record size of 512 bytes. (page 6.11)

• On a 3390 DASD device 1 cylinder will hold 735 Aux blocks (page 3.6)

• The GSPUSER file has a record size of 1536 bytes. (page 6.27)

• On a 3390 DASD device 1 cylinder will hold 390 User blocks (page 3.6)

• The GSPDIREC file has a record size of 512 bytes. (page 6.12)

• Each GSPDIREC file record can support 20 User IDs. (page 6.12)

• On a 3390 DASD device 1 cylinder will hold 735 blocks (page 3.6)

Perform the following to calculate the additional space required for the GSPUSER file (assume there is very little free space in the GSPUSER file now):

number of users to increase / number of user records per cylinder =
100,000 users / 390 users per cylinder =
256+ rounded up to 257 cylinders

Increase GSPUSER file by 257 cylinders

Perform the following to calculate the additional space required for the GSPAUX file (because there is 30,000 free blocks, we can reduce the amount of the increase):

(# users to increase * 2 blocks per user - excess free blocks / number of Aux records per cylinder =
(100,000 users * 2 blocks - 20,000 blocks) / 735 blocks per cylinder =
(200,000 blocks - 20,000 blocks) / 735 blocks per cylinder =
180,000 blocks / 735 blocks per cylinder =
244+ rounded up to 245 cylinders

Increase GSPAUX file by 245 cylinders

Perform the following to calculate the additional space required for the GSPDIREC file (because there a great deal of free space, we can reduce the amount of the increase):

(# users to increase - excess free space) / (#blocks per cylinder * # User IDs per block) =
(100,000 users - 26,500) / 735 * 20) =
73,500 users / 14700 =
5 cylinders

Increase the GSPDIREC file by 5 cylinders

Based upon the above calculations and the original file size numbers, the following recommendation is being given (allocation sizes are rounded up to nice numbers).

[back to top]

HOW TO RESOLVE A GC516 GOALSYS - TERMINATION DUE TO CSA BUFFER SHORTAGE
This situation may occur when the number of CSA Buffers is too small to accommodate the number of concurrent requests from the cross-region partner(s). Consider the following example:

• PHOENIX/PREFERENCE is running at a much lower priority than CICS

• A maximum of 100 cross-region users can concurrently access PHOENIX/PREFERENCE (XREGMAX=100)

• The number of LDAS= and # CSA Buffers may be default values (this would be 100/8 = 13 rounded)

• If multiple users request help, the first 13 will be assigned a CSA buffer.

• Until processing has completed for at least one of the first 13, new requests will be queued to retry for up to 90 seconds or when a CSA Buffer becomes available (which ever is shorter).

• If the system is busy and PHOENIX/PREFERENCE is not dispatched, then when the 90 seconds are up users receive a GC516.

• It is possible that some users are processed, but not all are processed within the 90 seconds waiting period due to the low priority of PHOENIX/PREFERENCE.

What can be done: First a bit of background. The number of CSA Buffers to be allocated is controlled by the XREGBN= startup operating parameter documented in the PHOENIX System Guide on page 3.31 and the PREFERENCE System Guide on page 3.24.

If the PHOENIX/PREFERENCE system is running at a priority equal to or higher than the cross-region partner(s) and both XREGBN= and LDAS= were not specified, then the default value for XREGBN= should be fine (maximum users/8).

If PHOENIX/PREFERENCE is running at a lower priority than its cross-region partner(s), then the default value for the XREGBN= parameter is too small. A value equal to the XREGMAX= parameter may be required to eliminate this termination condition. In the example above where XREGMAX=100, modify XREGBN so that XREGBN=100 instead of =8. This will not speed up the processing. It will only prevent the user's request from being terminated. To speed up the through put, the PHOENIX/PREFERENCE priority must be set equal to or higher than the cross-region partner(s).

[back to top]

END-USER GETS GD024, AND JOB LOG SHOWS ASSOCIATED GC136 ERROR MESSAGES IN CBEEDITP
This is generally an indication of a problem with a 3270 emulator passing Invalid 3270 data to PHOENIX/PREFERENCE. There is a special case for CICS terminal sessions on PREFERENCE where the user can trigger this error condition from a problem 3270 emulator. This can occur if the user presses the help request key multiple times before the Help screen is displayed.

We cannot work around the problem with the 3270 emulator. However, it is possible to to address one of the underlying conditions that causes the user to repeatedly press the help request key ..

Slow help key response time may be due to CICS having a higher dispatching priority than PREFERENCE. This condition will allow CICS users to queue requests to PREFERENCE faster than PREFERENCE can process them. To address this issue we recommend the following:

• check to see what the dispatching priority is for your PREFERENCE Region

• check to see what the dispatching priority is for each of the CICS Regions that communicate with PREFERENCE.

• compare the PREFERENCE Region dispatching priority to each of the selected CICS Regions.

• The dispatching priority of PREFERENCE must be at least as high as these CICS Regions.

• If PREFERENCE processing is slower for users connected through CICS, then you may want to consider setting the PREFERENCE priority a bit higher than CICS.

[back to top]

HOW TO MOVE COURSES FROM DEVELOPMENT TO PRODUCTION WITHOUT LOSING CLASS SETTINGS, ROSTER FILES AND MAIL FILES
Run the GSPCOPY utility using the RESTORE parameter to update an existing course on a program file. The RESTORE parameter preserves existing class, roster and mail files but allows the course to be updated with new unit and item files. If GSPCOPY is run when PHOENIX is online, the new version of the course will not be available until a supervisor issues the "dbuild" command or until PHOENIX is brought down and back up again. For this situation if the "dbuild" command is not executed or PHOENIX is not recycled, then users of the restored course may experience unpredictable results until this is rectified.

[back to top]

HOW TO RESOLVE GC150 - DISK ERROR CONDITION AFTER PHOENIX/PREFERENCE FILES HAVE BEEN MOVED
The GC150 DISK ERROR condition normally occurs because the PHOENIX/PREFERENCE files have not been formatted correctly for its use. This situation can arise when PHOENIX/PREFERENCE files have been moved with another vendor's utility. To resolve this problem choose one of the procedures below that most closely matches your current PHOENIX/PREFERENCE system condition.

Procedure 1 - IF the PHOENIX/PREFERENCE files still exist on the old system:
(please refer to the PHOENIX System Utilities Guide or PREFERENCE System Utilities Guide for details on how to execute the utilities identified below)

• Run the PHOENIX/PREFERENCE GSPFASBK utility to backup all files

• Run the PHOENIX/PREFERENCE GSPRESTR utility to restore the GSPFASBK files to the new files that you have already allocated via the non-PHOENIX/PREFERENCE utility.

• Run the PHOENIX/PREFERENCE GSPBDIR utility to build the GSPDIREC file previously allocated via the non-PHOENIX/PREFERENCE utility

The system should now have integrity.

Procedure 2 - IF the PHOENIX/PREFERENCE files no longer exist on the old system:
(please refer to the PHOENIX System Utilities Guide or PREFERENCE System Utilities Guide for details on how to execute the utilities identified below)

• Delete the new GSPDIREC, GSPPAGE and GSPROLL files created by the non-PHOENIX/PREFERENCE utility.

• Retain all other files created via the non-PHOENIX/PREFERENCE utility until the new system is up and running.

• Run the PHOENIX/PREFERENCE GSPCLEAR utility to create the following new files: GSPPAGE, GSPROLL, GSPUSER, GSPAUX, GSPDIREC, GSPTERM, GSP0100, GSP0xxx (all your program files) and GSP0199. Set the files sizes according to the size of the old files with a special note for the GSPPAGE and GSPROLL files. These two files must be allocated on a cylinder boundary in a single extent.

• Run the PHOENIX/PREFERENCE utility GSPRESTR to restore the newly created files using the non-PHOENIX/PREFERENCE utility allocated files as input to GSPRESTR on the INPxxxx DD statements. Specify the newly created files via GSPCLEAR on the GSPxxxx DD statements.

• Run the PHOENIX/PREFERENCE utility GSPBDIR to build the GSPDIREC file created via GSPCLEAR.

• All newly created files should now have integrity. Thus, the final step is to update the PHOENIX/PREFERENCE startup JCL dataset names or rename the newly GSPCLEAR created files to the production names.

[back to top]

HOW TO CALCULATE THE TOTAL NUMBER OF INDIVIDUALS WHO COMPLETED A PARTICULAR CBT COURSE WITHIN A SPECIFIED TIME FRAME
The easiest way to make this calculation is through the use of the GSPMFLMS utility (new with release 7.8.0). This utility was designed to export select PHOENIX student data for importing to the Pathlore LMS. The main idea of the MainFrame Bridge to LMS was to export data for students who have completed all required units of the course. Once a student's data was exported, their record was flagged so that it would not be exported again unless they had re-accessed the course to repeat a unit or to take an optional unit. However, a feature was included to allow a user to export data for all students that completed the selected course as of a specified date and time regardless of whether their data was previously exported. This feature will allow the user to get a report of all students who have completed a course as of a specified date and time. The count of the number of records contained in the export file represents the total count of users to complete the course as of the input date and time. The GSPPRINT report will provide a list of users who have completed the course. Here is an outline of the steps needed to determine the number of students who finish a course within a specific time frame:

1. use the GSPMFLMS utility to determine how many students have finished the course since the initial date of the time frame

2. Use the GSPMFLMS utility to determine how many students have finished the course since the last date of the time frame

3. Subtract the difference between the two results above to determine how many students finished the course within the specified time frame..

What follows is an example of how to determine the number of students that completed course "cmitst" in the year 2002.

Running the GSPMFLMS utility specifying the keyword "EXPDATE=(01/01/2002,00:00)" will cause the data for all students that completed course "cmitst" since the beginning of 2002 to be exported to the MFLMSOUT file and GSPPRINT report file. Thus, the MFLMSOUT file will contain one record for each student that has completed course "cmitst" since the beginning of 2002. At this point you need to record the total number of records in the MFLMSOUT file.

Running GSPMFLMS again with a date of (01/01/2003,00:00) would give you a total count of students that completed the course "cmitst" since the beginning of 2003. The difference between the counts would be the total number of students to compete the course for 2002.

Please refer to the PHOENIX System Utilities Guide pages 6.37 - 6.47 for details concerning the use of the GSPMFLMS utility. Since you would be using this utility for an alternate purpose, you would not need to specify the MAPUSER DD statement. Also you are not concerned about the COURSECD=. Thus, your control cards could be specified as follows for course name "cmitst":

* For the first execution of GSPMFLMS

PROG=CMITST,COURSECD=CMITST,EXPDATE=(01/01/2002,00:00)

* For the second execution of GSPMFLMS

PROG=CMITST,COURSECD=CMITST,EXPDATE=(01/01/2003,00:00)

[back to top]