1.0 Overview

This document describes changes included within:

Note: SysConf is used by TPS, PORF, Targetter, XUtil, WinUtil, PLI, PTE and CEM

TPS is used by PORF, Targetter, XUtil, WinUtil, PLI, PTE and CEM.

XUtil and WinUtil are used by PLI and PTE.

PTE means both the Run-Time System (RTS) and the Simulator (SIM).

PTE, RTS, CEM and SIM mean all Platforms.

UPTE, URTS, UCEM and USIM mean UNIX Platforms only.

WPTE, WRTS, WCEM and WSIM mean MS-Windows Platforms only.

XPTE, XRTS and XSIM mean X-Window Platforms only.

This version of the RTS is compatible with CEM Modules built with CEM Files distributed with RTS Version 19980714 3.9.7 and later. You may install this version of the RTS without rebuilding your CEM Module. However, in order to make use of the new CEM capabilities, you MUST install this version of the RTS, and then you MUST recompile and relink your CEM Module(s) with the TYX-supplied CEM Files distributed with this version of the RTS.

As time goes on, RTS/CEM testing to provide error-free backwards-compatibility becomes increasingly difficult. Therefore, TYX Corporation very strongly recommends that CEM Users recompile and relink their CEM Modules after installing a new version of the RTS.

1.1 Enhancements

The RTS sends Text Messages to the CEM Kernel requesting the CEM Kernel to perform various actions. These Text Messages are parsed by the Message Syntax Processor (MSP) portion of the CEM Kernel. The MSP Source Code is written in the YACC (Yet Another Compiler Compiler) Language, which is read by a YACC Application, which in turn produces C Language Source Code.

Prior to this release, TYX Corporation did not have a YACC Application that ran on a Windows or DOS System. The YACC Application used to generate the MSP C Language Source Code was the one provided with one of TYX Corporation’s LINUX Systems.

TYX Corporation has acquired a YACC Application that runs on a Windows/DOS System.

With this release, MSP C Language Source Code is generated by a YACC Application that runs on a Windows System.

1.2 Problem Reports

None

1.3 Problems Detected In-House

CEM - Macro GetCurCtlMLA() Sometimes Returns Invalid Address During ATLAS Action Processing

There are three protocols (all of which are currently supported by the CEM Kernel) defining how an RTS can pass Controller Addresses to the CEM Kernel:

Protocol 1 This protocol is the original one whereby the CEM Kernel extracts the Controller MTA or MLA from the RTS-to-CEM Command Message pertaining to the Current Device and saves it for use by the CEM Driver handling the Current Device. When the CEM Kernel receives a Command Message specifying a different Device, the Controller Addresses are reset.

Limitation No Controller Addresses are available until the ATLAS Program has started execution.

Protocol 2 This protocol was designed to correct the limitation of Protocol 1 by defining a "1st CEM Bus" RTS-to-CEM Information Messages that allows an RTS to send the MTA and MLA of the "First Controller" to the CEM Kernel. These Messages are sent after the Non-ATLAS CONNECT Action and before the Non-ATLAS OPEN Action, thereby making these Addresses available to a CEM Driver prior to starting execution of the ATLAS Program. The CEM Kernel saves these Addresses in the same location in which it saves the Addresses received as per Protocol 1.

Limitation The CEM Kernel correctly supports only one Controller.

Protocol 3 This protocol was to designed to correct all known Controller Address limitations by defining RTS-to-CEM Information Messages that allow an RTS to send MTA’s and MLA’s for all Controllers to the CEM Kernel.

The UNIX RTS and WMENU RTS use Protocol 3. The Studio RTS (which requires that different Controllers must be handled by different CEM Modules) uses Protocol 2.

Prior to this release, the CEM Kernel saved Controller Addresses received as per Protocol 2 only in the same location in which it saved those received as per Protocol 1. During its first ATLAS Action processing (normally SETUP) for a particular Device, a CEM Driver would see a valid Controller MTA but an invalid Controller MLA (as a result of the "different Device reset").

With this release, the CEM Kernel saves Controller Addresses received as per Protocol 2 in unique locations that do not get reset (in addition to where it was previously saving them).