CMSTPF/XA and Source View - Conforming to the TPF Architecture
by Thiru Thirupuvanum

This is the first in a series of articles on CMSTPF/XA and its usage for TPF Application Development. For those of you who are not familiar with CMSTPF/XA and Source View, these are two products of TPF Software Inc. which enable TPF Application Programmers to test application code developed for the TPF environment.

This article is on protection keys and their usage by CMSTPF/XA to ensure that TPF Applications conform to the TPF architecture. The usage of protection keys by CMSTPF/XA not only ensures that the TPF application program conforms to the TPF architecture, but also ensures the high quality of the code being implemented on a native TPF system.

Protection keys are hardware keys associated with the main storage of a processor. Attempts to modify storage areas, or reference storage areas for which the application does not have the proper protection key, causes a protection exception to occur. Two types of protection exceptions can occur, they are:

Store Protection
This is an attempt to store data into an area of main storage for which the application (entry/ECB) does not have the corresponding key.

Fetch Protection
This is an attempt to address/access data from an area of main storage for which the application (entry/ECB) does not have addressability, or no longer has addressability.

Examples of a Protection Exception (Store type) occurring in CMSTPF/XA are:

• An attempt to store data into a block, once the block has been released.
• An attempt to store data beyond the end a block.
• An attempt to store data into a record between the FILNC and WAITC.
• An attempt to modify one's program (TPF programs are expected to be re-entrant!).

Examples of a Protection Exception (Fetch type) occurring in CMSTPF/XA are:

• An attempt to access data from a block, once the block has been released.
• An attempt to access data beyond the end of the block.
• An attempt to access data from an area for which the ECB has no addressability.
• An attempt to access a 31 bit address when the ECB is operating in 24 bit mode.
• An attempt to access an invalid 24 bit address when the ECB is operating in 31 bit mode.
• An attempt to access data from an earlier called program, when it is no longer in use by the ECB.

Any one of these cases will cause CMSTPF/XA to stop the entry from executing and inform the user that a Protection Exception has occurred. Users can use some of the following CMSTPF/XA commands to diagnose the problem. They are:

TRACE DISPLAY command - to examine the Trace-Back table to determine the execution path of the failing ECB.

DPSW command - to examine the PSW of the TPF ECB. The DPSW command displays the current PSW of the ECB, specifying the protection key associated with the entry, the condition code, etc. The protection key associated with the ECB should match the key associated with the storage area being modified or accessed.

DKEY command - This command enables users to determine the key associated with the storage area being modified or accessed. If this is a store protection exception, the key for the storage area being modified does not match the key associated with the ECB (DPSW command). If this is a fetch protection exception, the Fetch Protection bit is set for the storage area, and is usually X'08'. The 8 bit of the second half byte implies this area is not available for access.

Usage of these commands and other CMSTPF/XA trace and diagnostic commands will assist the TPF programmer in diagnosing and solving the problem to ensure that TPF programs tested in this manner conform to the TPF architecture. We hope this article will benefit our users in being more productive and writing higher quality code for their TPF systems.