The ClearPath Extension Kit for MCP is an integral part of the existing MCP security model. The MCP architecture continues to protect the MCP operating environment as discussed in Secure MCP Environment. In particular, everything is written in a high level language.
At a usercode level, two granulated privileges control access to the Windows platform environment, PLATFORMACCESS and PLATFORMADMIN as described in “Granulated Authorization Access” topic of Access Rights Designated in the SYSTEM/USERDATAFILE. The granulated privileges may also be applied to a codefile by a security administrator using the MP (Mark Program) system command.
At a minimum, PLATFORMACCESS is required to build Docker images and run them in containers. The PLATFORMADMIN granulated privilege allows access to the powerful Run External Utility (*SYSTEM/RUNX) when visible to the user. Because the RUNX utility may be used to run Windows programs outside of a container, the PLATFORMADMIN privilege requires additional consideration before assignment to a usercode or program.
Building a Docker Image
When using the ClearPath Extension Kit for MCP, a high level language in a Dockerfile defines how the Docker image is to be built. The BUILDX compiler builds the Docker image from the Dockerfile and creates the DOCKERCODE codefile for instantiating that image in a container. It is an MCP executable codefile and therefore fully integrated with the MCP security model as discussed in Secure MCP Environment.
Running a Container
When the DOCKERCODE codefile executes, it uses its IMAGEID file attribute to launch a new container for the corresponding Docker image in the underlying Windows environment. The MCP firmware redirects the container's STDIN, STDOUT, and STDERR files to MCP remote files when initiated from a remote station, however normal file equation is also available.
Library Linkage to a Container
When the DOCKERCODE codefile is instantiated as a library, entrypoints are exported providing a mechanism to send and receive data corresponding to STDIN, STDOUT, and STDERR through a procedural interface rather than a file interface.
Logging Container Activity
The ClearPath Extension Kit for MCP provides security logging via Major Type 20 (Security Entry), Minor Type 6 (MCP Extension Kit). A user with sufficient privileges can view these entries with various LOGANALYZER commands. For example, to isolate the security entries associated with the Extension Kit use:
LOG SECURITY (RUNX)
Tracing Container Activity
Simple User Logging
Simple tracing is provided when REMOTE file is not used, such as running through WFL or setting STATION=0 (and no other file equation is done on the STDIN, STDOUT, and STDERR files). In this case, the user may use the AX command to send data through STDIN to the container. When the container sends data through STDOUT and STDERR, the program will do a DISPLAY of the data received. Note that when this mechanism is invoked, all data sent to and received from the container is automatically entered into the SUMLOG. This mechanism is particularly useful when logging of input and output is preferred.
User Selectable Diagnostics
You can set the SW1, SW2, and SW3 task attributes to capture additional diagnostics when running a DOCKERCODE codefile.
-
SW1
Setting this switch enables the logging of diagnostic trace entries, Major Type 19 (Diagnostics Entry), Minor Type 46 (MCP Extension Kit).
-
SW2
Setting this switch generates log entries for the data sent to and from STDIN, STDOUT, and STDERR. Using this switch differs from when no remote file is present, in that the data from STDOUT and STDERR is not displayed, but it is logged. This gives ClearPath Extension Kit for MCP users the ability to retain in the SUMLOG all the data interactions that occurred with the container during a specific run. However, the number of log entries generated may be extremely large depending on the amount of data sent to and from the container. Significant overhead may be incurred when this switch is enabled.
Note: This switch is particularly useful when debugging a DOCKERCODE codefile which has been instantiated as a library, as it provides a mechanism to trace precisely what was sent and received from STDIN, STDOUT, and STDERR. -
SW3
Setting this switch instructs the program to take a program dump to disk on error.
The following LOGANALYZER commands allow you to view the diagnostic log records generated from the user selectable logging:
LOG DIAG (RUNX) LOG DIAG (RUNX(<subtype>))
Where subtypes are set as follows:
When SW1 is set:
TRACE RUNX BUILDX UTILX DOCKERRUN
When SW2 is set:
STDIN STDOUT STDERR STDIO
