An application program written in PLII must consist of an external (MAIN) procedure. Internal t:rocedure CALLs are 'allowed in a PL/I program to be run under CICS/VS, but external CALLs are not.
Any CICS/VS macro instruction operand which defines a name or label of a storage area or routine should comply with the Assembler language restrictions of eight characters or less. This requirement is a result of preprocessing by the Asserrbler before PL/I statements are generated.
LINK-EDITING
separate ANS COBOL routines cannot be link-edited together. Neither can separate PL/I routines. Assembler-language routines may be
link-edited, but called routines must conform to CICS/VS application program requirements. Facilities comparable to link-editing are provided under CICS/VS through LINK and XCTL (transfer control) macro instructions, which the application programmer can use to set up communication between programs.
CONSIDERATIONS FOR ~ VIRTUAL STORAGE ENVIRONMENT
CICS/VS operates in a virtual storage environment. The key objective of programming techniques in a virtual storage system is the reduction of page faults--those cases in which a program refers to an instruction or data that does not reside in real storage. When this occurs, the page in virtual storage that contains the referenced instruction or data must be paged into real storage. The more paging required, the lower the overall system performance.
The application programmer who writes programs to be run in a virtual environment should understand the following concepts:
• locality of reference - the consistent reference, during a program's execution, to instructions and data within a relatively small number of pages (compared to the total number of pages in a program) for relatively long time periods
• working set - the number and combination of pages of a program needed for satisfactory performance (lOW paging rate) during a given time period
In general, the application programmer should use techniques to improve a program's locality of reference and to minimize the size of its working set at any time during execution of the program. Some guidelines are given below:
Chapter 1. Introduction 15
1. To achieve locality of reference, processing should be sequential for both code and data, insofar as possible.
a. Initialize data as close as possible to its first use.
b. Define new data items as close as possible to the items that use them.
c. Define arrays or other data structures in the order in which they will be referred to; refer to elements within structures in the order in which they are stored, for example, rowwise rather than columnwise when using PL/I.
d. Separate error-handling or unusual-situation routines from the main section of a ~rogram; they should be subprograms.
e. Subprograms that are short and used only once or twice (other than those in d above) should be coded inline in the calling program.
2. To achieve minimum use of real storage, the amount of storage that a program refers to in a given time ~eriod should be as lew as possible. A program should have small working sets.
a. Write highly modular code and then structure that code according to frequency and anticipated time of reference.
b. Use separate subprograms whenever the flow of your program suggests that execution will not be sequential.
3. Use techniques to ensure validity of reference, which means to ensure that few storage references retrieve useless data.
a. Avoid long searches for data.
b. Use data structures that can be addressed directly, such as arrays, rather than structures that must be searched, such as chains.
c. Avoid indirect addressing and any methcds that simulate indirect addressing.
When all page frames in a real storage environment are filled and another page must be loaded into storage, a page replacement operation is required. The operating system replaces first those pages that have not been referred to for the longest period of time. If a page to be replaced has been modified, that page must be paged out onto virtual storage before the required page can be read in. The more page-out operations required, the lower the overall performance of the system.
To avoid the necessity for page-out operations, the application programmer can code his program so that page-out operations are not required when a page containing a portion of his program must be replaced in real storage. He need only avoid modifying instructions or data within his program. A program in which neither instructions nor data is modified is said to be truly reentrant. As noted earlier, programs to be run in a CICS/vS environment must be quasi-reentrant.
For performance reasons, i t may be wise to take a further step: to make them truly reentrant programs.
The CICS/VS application programmer should not attempt to use
overlays, that is, to incorporate paging techniques within his programs.
System paging is automatic and works better anyway.
ASSEMBLY-TIME SERVICE
In addition to knowing the execution-time considerations discussed in this chapter, the application programmer should be aware of an assembly-time (or compile-time) service available under CICS/VS. The DFHCOVER macro instruction can be issued to request that the assembler or compiler in use print a cover page on each of two consecutive pages.
This ensures that the application Frogram listing may be torn off with one of the cover pages face up. Pertinent information (program name, date, time of assembly, remarks, and so on) may then be written on the cover page.
The DFHCOVER macro instruction requires no operands and nothing else should appear on the same coding line.
If the DFHCOVER macro instruction is coded as part of an
Assembler-language applicaticn program, i t should be coded as the first instruction in the program. If desired, however, this macro instruction may be coded after anything that is not vital to the listing (such as the TITLE line).
If the DFHCOVER macro instruction is coded as Fart of an ANS COBOL application program, i t should precede the IDENTIFICATION DIVISION statement.
The first card of a PL/I source deck is printed as a header on each page of the source listing. This means that when the DFHCOVER macro
instru(~ion is part of a PL/I apFlication program, the first card should be a comments card containing information that the application
prograrr~er wants printed as a header. The second card should contain the DFHCOVER macro instruction. The actual PL/I code should begin on the third card of the source deck.
Since column 1 is used by the DFHCOVER macro for line and page spacing under PL/I, column 1 must be defined as reserved for control characters and columns 2-12 must be defined as available for data.
This is accomplished through the *PROCESS card for CICS/DOS/VS and the EXEC card for CICS/OS/VS. For further informaticn concerning PL/I
compile-·time services, see the POS PLII optimizing Compiler Programmer's Guide,
9s
PL/I (!) Programmer's Guide, and OS PL/I Optimizing Compiler Programmer's Guide.The examples in Appendix A show how the DFHCOVER macro instruction is used.
Chapter 1. Introduction 11
CHAPTER~. STORAGE DEFINITICN
SYMBOLIC STORAGE DEFINITIONS
CICS/VS provides symbolic storage definitions (dummy sections) to describe the layouts of control sections of a number of storage areas.
These storage definitions are contained in the CICS/VS libraries and can be copied into applicaticn programs. When combined with
user-defined layouts of the user's sections of the storage areas, they provide symbolic addressing to the storage areas.
The storage areas for which symbolic storage definitions are provided are of three types:
1. Centrol areas 2. Work areas
3. Input/output areas
Some of the storage areas are statically created by CICS/VS during system initialization, and others are dynamically acquired and released during execution of the system. Some of the areas are acquired or created by CICS/VS; some are acquired directly by the application program; and some are acquired by either CICS/VS or the application program. Figure 2-1 lists the CICS/VS storage areas of interest to the application programmer, indicating which are centrol areas, which are work areas, and which are I/O areas; i t also indicates which are acquired by the user and which are acquired by CICS/VS.
Acq'd Acq'd Control Work I/O by by
~ Areas Areas ~ CICS/VS
Common System Area (CSA) X X X
Common Work Area (CWA) X X
Task Control Area (TCA) X X
Transaction Work Area (TWA) X X
Journal Control Area (JCA) X X X
File Work Area (FWA) X X X
VSAM Work Area (VSWA) X X X
Storage Accounting Area (SAA) X X X
Terminal I/O Area (TIOA) X X X
Transient Data Input Area (TelA) X X
Transient Data Output Area (TDOA) X X
Temporary Storage I/O Area (TSIOA) X X X
File I/O Area (FIOA) X X
Terminal Control Table
Terminal Entry (TCTTE) X X
Figure 2-1. CICS/VS Storage Areas
All CICS/VS storage areas, with the exception of the terminal control table terminal entry (TCTTE), the journal control area (JCA), and VSAM work areas (VSW~s), consist of two logical and unique sections. The control section is used primarily by CICS/VS; the user's section is defined and used exclusively by the application ~rogram. This logical division exists whether the storage is statically created (for example, the common system area) or dynamically acquired (fer example, a terminal input/output area).
Chapter 2. storage Definition 19