Idaho State University

• Academics
• Prospective Students
• Current Students
• Faculty & Staff
• Alumni & Visitors

• Information
  • Access Security
    • Department Information
    • HP3000 Server Account Information
    • Network Services Account Information
    • Responsible Account Holder Information
    • Application System Responsibility
    • Department/Group Info
  • User Guide
    • Table of Contents
  • Networked Printers
  • Miscellaneous System Info
    • HP1 (HPe3000) Server Scheduled Down Time
    • Powerhouse Web Queue Management Values
    • Portal Web Services Availability Schedule
• Our Staff
  • Support by System
  • Primary Support
  • Backup Support
• Project Management
  • Staff Responsibilities
    • Support by System
    • Primary Support
    • Backup Support
• Information Technology Services
• DEACON Project

Enterprise Applications
Development Guidelines and Procedures

Standards For Powerhouse Source Code

1. QUICK Source Code
1. Comments will be placed at the beginning of each QUICK source code file. For an example see XYQUEXAM.SOURCESY.DESIGN.
2. Wherever possible like statements will be placed together in sections and set off by a blank line or comment line (;).
3. To improve readability of code continuation lines should be uniformly indented in increments such as two spaces. Multiple lines of similar code should have like words aligned as is reasonable.
4. Readability can also be improved through utilization of lower vs upper case letters. The recommendation is for Powerhouse commands to use lower case with item names and record names in upper case.
5. Source code for screens will be maintained in separate files in most cases even when they will be accessed as a unit. However, when multiple screens are maintained in a single file they must be clearly marked with dividers which will facilitate quick separation into distinct files for testing or modification. Subscreens which receive data from a higher level screen shall be named with a letter suffix, e.g. PRQU201A.
6. When multiple screens are maintained in a single file the name of the source code file must be chosen to reflect the series of screens which it creates:
7. PRQU000 contains the source for PRQS000 through PRQS099, typically maintenance screens. PRQU100 will contain the source for the 100 series screens. PRQUA00 contains the source for screens PRQSA00 through PRQSA99. If necessary PRQUAA0 may be source for screens PRQSAA0 through PRQSAAZ.
8. The DESCRIPTION statement will be used to provide a description of the screen when the operator enters '??' in the Action field. Help screens and messages to the customer will be in mixed case for reading ease.
9. QUICK screens will not be written which permit the customer to do sequential searches on a large dataset. The use of the 'ACCESS' command will help eliminate the serial select. Also, the placement of the option 'NO SEQUENTIAL' on the SCREEN command will reduce the possibility of sequential searches on the primary file.
10. When more than two levels of subscreens exist, menu screens should be made stop screens to facilitate the use of '^^' to get back to the menus.
11. The ability to use both upper and lower case should be built into all screens with automatic upshifting where appropriate.
12. Default procedures should be removed from source code. Thus the existence of code would make it immediately clear that something other than default was used. However, Powerhouse recommendations for always keeping code for PATH and FIND procedures together should be followed.
13. Powerhouse QUICK source code segments, similar to COBOL copylibs, will be created when a section of code will be used in multiple screens to reduce overhead. A good example with Quick is screen hilite options. Files of this type will be stored in the system's SOURCExy group on DESIGN.
14. Function Key (FKey) standards in Quick are difficult to establish because of the difference between systems and screens. However, every attempt should be made to conform to the following suggestions in an attempt to bring consistency to the procedures for screen usage which will benefit not only the customer but the support personnel as well. (See Chapter 12 of the Powerhouse Quick Manual on setting up Dynamic Function Keys.)

    Recommended Standards:

    • All screens using FKeys must have an associated QKGO file.
    • Use XYQKEXAM.SOURCESY.DESIGN as an example QKGO file.
    • Never define more than 2 levels of FKeys without approval.
    • Avoid setting up more FKeys than will realistically be used.
    • FKeys defined for a screen must be valid functions for same. In other words, if an FKey for Entry Mode is defined then Entry Mode must be a valid Action for the screen. Example: A menu screen should never have an Entry Mode FKey defined. Use the DISABLE option of the key statement as required.
    • All FKeys must have an associated descriptive Label centered and in mixed case.
    • The second line of a label should normally show the command which can be entered to perform function without using the FKey.
    • Group KEY statements together in data section of source code.
    • On KEY statements override inheritance rules (use LOCAL option).
    • All FKeys should be context-sensitive.
    • Be consistent in the use of FKeys throughout screens for a single system.
    • Use FKeys to access subscreens when appropriate.
    • When possible have FKeys relate to ID numbers for designer procedures. Example: To access subscreen '03' from a menu use FKey #3 (f3). On a Main Menu Screen 'f8' should always exit the system.
    • On a Subscreen 'f8' should always go to the previous screen.
    • Setup 'f7' to return to a stop screen or exit on subscreens.
    • In most cases 'f4' should refresh all active screens.
    • Reserve 'f1' to be used for extended help to coincide with basic software standards.
    • If there is any question on setting FKeys, use the default.
    • The 'Save Function Keys' option should be set to 'y'.
2. QUIZ Source Code
1. Comments will be placed at the beginning of each QUIZ source code file. For an example see XYQREXAM.PRODQ.ADMIN.
2. Like statements will be placed in sections and set off by a row of blanks or other characters of your choice. Separation lines and comments will be preceded by a semicolon (;).
3. Continuation lines will be uniformly indented in increments of two spaces or more.
4. A uniform sequence of statements should be followed:

   ACCESS
   DEFINE
   SELECT/CHOOSE
   SORT
   SET REPORT
   SET PAGE
   SET SUBFILE
   SET ...
   HEADING
   REPORT
   FOOTING
   

   This sequence is a guideline only.

5. All Quiz code should be fully documented, even if that code will be placed in a customer group.
6. Powerhouse QUIZ source code segments, similar to COBOL copylibs, will be created when a section of code will be used in multiple powerhouse source files to reduce overhead. A good example with Quiz is a set of defines to determine a student's gpa. Files of this type will be stored in the USEPH.hpaccount group (See naming conventions for guidelines).
3. QTP Source Code

Generally speaking, Qtp can follow the same guidelines as Quiz. For an example of comments placed at the beginning of each source file see Appendix F.