EnterApp

Web Services Council

Enterprise Applications
Development Guidelines and Procedures

Programming Specifications & Standards

Standards For COBOL Source Code

COBOL85 should be used only when 4GL languages cannot accomplish the job readily. You must obtain manager approval before writing a production COBOL program.

  1. A remarks paragraph should contain program description, maxdata requirements, and an entry for each program modification designating programmer, date, and description of changes. For changes to COBOL source, QEDIT's SET X 'MMDDYY' command is also to be used with a standard MM/DD/YY format.
  2. Like elements of the variable section (Data Division) will be grouped together (e.g. tables, switches, counters).
  3. All level numbers will be "01", "88", or a multiple of "05". No "77" levels should be used.
  4. S9(4) or S9(9) should be used rather than PIC 99 for arithmetic computations. The former is a more efficient way for numeric fields to be manipulated.
  5. All picture clauses are to be aligned.
  6. A TOP DOWN structured coding approach with one entry point and one exit point will be followed. The use of the "GOTO" statement is not permitted.
  7. Code should be kept as simple as possible even if it requires more lines of code. Always use basic constructs for ease of maintenance.
  8. IF THEN ELSE Considerations and Nested IFs.

    The COBOL85 IF...ELSE...END-IF construct will be used to facilitate ease of reading nested IFs.

    Example #1: 

    IF	CONDITION-1
	STATEMENT-1
	IF	CONDITION-2
		STATEMENT-2
		IF	CONDITION-3
			STATEMENT-3
		ELSE
			STATEMENT-4
		END-IF
	ELSE
		STATEMENT-5
	END-IF
ELSE
	STATEMENT-6
END-IF.

    Example #2: 
    IF	CONDITION-1
	IF	CONDITION-2
		IF	CONDITION-3
			STATEMENT-1
			STATEMENT-2
		ELSE
			STATEMENT-3
		END-IF
	ELSE
		STATEMENT-4
	END-IF
END-IF.

    Note that the example above does not have a corresponding ELSE for the outermost IF. The END-IF still serves to terminate the IF statement, and thus improves readability.

    Example #3: 

    IF	CONDITION-1
	STATEMENT-1
ELSE IF	CONDITION-2
		STATEMENT-2
ELSE IF	CONDITION-3
		STATEMENT-3.

    Note that 'case processing' nesting of IFs is still acceptable without the END-IF construct when, because of mutually exclusive events, one (and only one) condition will occur. If possible, evaluate the logic to see if the COBOL85 CASE construct will function better in the situation.

  9. Continuation lines should be indented.

  10. Vulgar or derogatory remarks may be cause for disciplinary action. Humor is not enjoyed by most customers after repeated exposure. Thus humorous remarks should not be placed in production work.

  11. Some internal comments are required in each program. They should be placed where the programmer feels additional explanation would make the program easier to follow. These comments should be set off as illustrated below so they will not be mistaken for code. As COBOL is basically self documenting excessive or superfluous comments are not to be included.

    **
    ** This is a comment using upper and lower case for
    ** easy reading.
    **

  12. Programs should be segmented, if necessary, for improved performance.

  13. The program name should appear in the headings of report programs. An identifying name in screens is also required.

  14. Error and other messages to the customer should be kept out of the variable section (or in the procedure division) to avoid large stacks. Messages which are to be relayed to a DP staff member should contain the paragraph number from which it is executed following the message. Cryptic messages and technical jargon should be avoided.

Testing

Testing of changed or newly developed programs will proceed according to the following steps:

  1. Whenever possible testing should take place throughout the development cycle.

  2. Test data to be run against the program will be developed by the project leader and programmer in conjunction with the customer to ensure that as many conditions as possible are met.

  3. Test runs will be made using test data and any required test files. Testing may be done on production files only if the program does not do any updating, is not CPU intensive, and the production file is small.

  4. For critical jobs, parallel running will commence following testing with appropriate customer involvement.

  5. When parallel running or production testing has been completed to the satisfaction of the customer and project leader the program will be moved to production with completed and/or modified documentation.

FORMSPEC Standards

  1. Maximum limit of 128 fields per form.

  2. Use one form per forms file if at all possible.

  3. Maximum of 52 single character fields (mixed case).

  4. Error Enhancement:

    • Error enhancement none for display only fields (type "D").
    • Error enhancement none in global menu.

  5. Brackets are to surround unprotected fields; normal [ ], invisible esc [ esc ].

  6. Forms file names follow naming conventions discussed under Naming Conventions.
    7. (error?)

  7. Select commands or UDC's should access fast forms files.

  8. When possible and before going into production all forms files should be shrunk using MPEX's 
    !ALTFILE name;SQUEEZE
    command.

  9. All forms should contain a version number (date). This should be changed when modifications are made. The name of the program should also be placed on the form.

  10. The characters "V:" should be placed in the first two positions of a View error message. This identifies the message as coming from View and overcomes the problem we are experiencing with the first character chopped off by Skipper.

  11. Caution should be used in the use of Processing Specifications. Programs requiring large data segments may require smaller form files.

  12. Following are additional suggestions.

    • With forms files which only have a single form, the 'Head Form Name' and 'Next Form Name' should be the same as the 'Form Name'.
    • Change the 'Default Display Enhancement' as necessary to help in form development.
    • On the 'Terminal/Language selection Menu' put an 'X' in both the HP264X and HP262X Family boxes.
    • Use function key labels at the 'Form Menu' level to display function key uses.
    • Have 'Idaho State University' or 'ISU' as part of the form heading.
    • Use an asterisk (*) to identify and label all fields that can be used as part of the select criteria on a (S)how.
    • Display a version date on the form.
    • The pound(#) sign could be used to identify the field to be used on a (F)ind.
    • Display a menu of the main program processes on the screen when space allows, i.e. show, add, change, delete, post.
    • Attempt to make the form flow logically as well as be aesthetically appealing by lining up fields and field labels and placing dot leaders where possible to improve readability. Remember, someone is going to have to sit in front of the screen for many hours either appreciating or enduring what you create.
    • Keep field names simple.
    • The field length should be no longer than absolutely necessary.
    • Use 'I' as the (Enh)ancement for (R)equired fields.
    • The 'NUM(#)' data type is used only when a decimal is needed, otherwise, a 'DIG' data type is proper at all other times when only digits are to be entered into the field.
    • When a form has a large number of fields, processing specifications could cause a compile error if overdone, so take it easy.
    • When a large number of fields need the same edit, the edit is, in most cases, best put in the program.
    • Avoid placing the name of the form in the program.
    • When working with multiple forms, the switching of forms is most often best done in the form processing specifications.
    • Always print a forms file in portrait format (ie. ELITE, PICA) because it makes maximum use of the paper.
    • Save fields should be used sparingly and only with multiple forms.