This document describes changes included within:

Modul Changes	Rebuilt	Current	Version
TPS	Minor	Yes	19990803
PTE	Major	Yes	19990806 3.9.13

PTE means both the Run-Time System (RTS) and the Simulator (SIM).
PTE, RTS, CEM and SIM mean all Platforms.

Overview

1.1.1 TYX Programming Support.

1.1.2 PAWS Test Executive

PTE and RTS Text Segments (16-Bit Windows only).
Multiple CEM Controllers. DEVDAT Structure.
RTS-to-CEM Information Message - Device Information.
RTS-to-CEM Information Message - Controller Information.
CEM Driver Access to Bus Configuration Information.
Multiple IFC/DCL Sequences. Abnormal Termination of CEM User Functions.
CEM User Stub Functions. userStubRESET() (during IFC/DCL Sequence).
userStubDEVICECLEAR(). 1.2 Problem Reports. PR 98-128 CEM Errors during IFC/DCL Sequence lost.
PR 99-024 CEM Multiple Errors lost.
PR 99-029 Directory Name with ASCII Spaces not handled.
PR 99-053 CEM Error 1030 (Fatal Unload) does not cause IFC/DCL Sequence.

1.3 Error Codes and Associated RTS Actions

Detailed Description

2.1.1 TYX Programming Support.

2.1.1.1 Channel File Name in Bus Configuration File.

With this release, the File Name of a Channel Bus is forced to be "Channel" only if no File Name is specified in the Bus Configuration File.

2.1.2 PAWS Test Executive.

2.1.2.1 PTE and RTS Text Segments (16-Bit Windows only).

Prior to this release, PTE Common Source Code was compiled into two Text Segments: TEXT_INTERP1 and TEXT_INTERP2; and RTS Source Code was compiled into a single Text Segment: TEXT_RTS. (These Text Segments are for PTE and RTS Source Code only; other Modules (e.g., TPS) are compiled into their own Text Segments.) A recent build of the RTS w/DataLogger overflowed the TEXT_RTS Text Segment. Analysis of RTS Map Files also revealed that the TEXT_INTERP2 Segment was getting close to overflowing.

With this release, the following changes were made:

The TEXT_RTS Segment was reduced in size by compiling various sections of RTS Source Code into their own new Text Segments:

New Text Segment RTS Source Code Section
TEXT_RTSBIFS Built-In Functions (BIFS)
TEXT_RTSDL Data Logger
TEXT_IEEEVXI IEEE-488 and VXI Interface

2.1.2.2 Multiple CEM Controllers.

With this release, multiple CEM Controllers are fully supported. The RTS supports up to a maximum of ten (10) Bus Controllers of different types (including "Channel"). Those "slots" not typed as "Channel" limit the number of multiple CEM Controllers accordingly.

2.1.2.2.1 DEVDAT Structure.

A new Member (short a_ctl) has been added to the DEVDAT Structure to hold the number of the Controller associated with the Device/Channel Entry.

2.1.2.2.2 RTS-to-CEM Information Message - Device Information.

With this release, the syntax of this Message has been expanded to include the Device's Controller Number (as defined in the Bus Configuration File after the Keyword "BUS"). The new syntax of the RTS-to-CEM Device Information Message is:

MI MTA:Dev=MTA MLA:Dev=MLA MSA:Dev=MSA CTL:Dev=Ctl

where Dev is the Device Name;
MTA, MLA and MSA are the Device's Talk, Listen and Secondary Bus Addresses, respectively; and

For example:

MI MTA:DMM=3 MLA:DMM=3 MSA:=12 CTL=1

Note The original design of RTS-to-CEM Information Messages specified that Fields (i.e., KeyWord:Label=Data) have no order dependency. Unfortunately, a programming error in the CEM Kernel Information Message processing causes Message processing to terminate if an unrecognizable KeyWord is detected. (Unrecognizable KeyWords may occur when a new RTS runs with an old CEM Module.) Although this error has been corrected in this release, the RTS should append any new Fields to existing Messages (just to be safe).

2.1.2.2.3 RTS-to-CEM Information Message - Controller Information.

MI CTLNAM:Ctl=Name CTLMTA:Ctl=MTA CTLMLA:Ctl=MLA

where Ctl is the Controller Number;
Name is the Controller File Name; and
MTA and MLA are the Controller's Talk and Listen Bus Addresses, respectively.

For example:

Note The Controller File Name (as defined in the Bus Configuration File) is used by the RTS and the CEM Kernel for information purposes only. CEM User's may specify whatever is desired - a real Vendor-specified File Name, or, as in the example, a String which indicates the type of Bus the CEM Driver(s) will be accessing.

2.1.2.2.4 CEM Driver Access to Bus Configuration Information.

2.1.2.2.5 Multiple IFC/DCL Sequences.

With this release, the RTS initiates an IFC/DCL Sequence only for the first CEM Controller. (It does not matter which CEM Controller is used because there is no Controller Information associated with the IFC/DCL Sequence.)

2.1.2.3 Abnormal Termination of CEM User Functions.

With this release, CEM Drivers may abnormally terminate their processing (i.e., return control directly to the CEM Kernel) by calling a new CEM Macro AbortUserAction(). Refer to Section 3 in this document for a full description of this CEM Macro.

2.1.2.4 CEM User Stub Functions.

With this release, the format of these Action Lines have been changed.

2.1.2.4.1 userStubRESET() (during IFC/DCL Sequence).

This Function now prints Device and Controller Bus Addresses in the following format:

C=CN T=DT L=DL S=DS / FN T=CT L=CL

where: CN is the Device's Controller Number;
DT, DL and DS are the Device's Talk, Listen and Secondary Bus Addresses, respectively;
FN is the Device's Controller's File Name; and
CT and CL are the Device's Controller's Talk and Listen Bus Addresses, respectively.

Note This information is printed only when the Current Verb is zero. This situation occurs at least twice for an ATLAS Program: the first time is shortly after the ATLAS Program is loaded; and the second time is shortly before the ATLAS Program is unloaded.

2.1.2.4.2 userStubDEVICECLEAR() Function.

This Function no longer prints Controller Bus Addresses.

2.2 Problem Reports.

2.2.1 PR 98-128 CEM Errors during IFC/DCL Sequence lost.

With this release, CEM Driver calls to CEM Macro ErrMsg() result in the error being queued. The error will be reported back to the RTS the next time the RTS requests input from the CEM Module.

Notes Although errors are no longer lost, they are not reported back to the RTS in a timely manner. It is anticipated that this limitation will be corrected in a future release.

When the CEM User INTERFACE CLEAR and DEVICE CLEAR Functions are called, the Current Device is now set to "the Controller".

This Problem Report has been closed.

2.2.2 PR 99-024 CEM Multiple Errors lost.

With this release, the CEM Module queues errors. The CEM Module and RTS processing is as follows:

• A CEM Driver calls ErrMsg() to record an error. The CEM Kernel formats and queues a CEM Error Message consisting of the Current Device/Channel Name, the Current Module Name, the Current Line Number, the ATLAS Statement Number, and the CEM Driver Error Message.
• The next time the RTS requests input from the CEM Module (a FETCH, INITIATE or STATUS Request), the CEM Module responds with the first CEM Error Message in the queue. The RTS processes the CEM Error Message.
• The RTS fabricates and sends a STATUS Request to the CEM Module. The CEM Module returns the next queued CEM Error Message. The RTS processes the CEM Error Message. This series of actions continues until the CEM Module returns a Good Status.
• The RTS takes whatever action is necessary as a result of the most serious Error Code received. (Refer to Section 4 in this Document to see Error Codes and their associated RTS actions.)

Notes CEM Error Messages are no longer stored on a Device/Channel basis; they are queued in the CEM Error Message Buffer. This Buffer is currently 1,000 Bytes, which should hold at least ten (10) CEM Error Messages.

If the RTS receives twenty (20) consecutive Error Responses when in the loop described above, no further STATUS Requestes are sent to the CEM Module and an IFC/DCL Sequence is initiated immediately. (This is done for safety purposes. Given the size of the CEM Error Message Buffer, the CEM Module should never generate this many consecutive Error Responses.)

If the RTS receives an Error Code that requests the RTS to perform an IFC/DCL Sequence, no further STATUS Requests are sent to the CEM Module and an IFC/DCL Sequence is initiated immediately.

When the CEM Module receives an IFC Request, the CEM Module discards all queued CEM Error Messages.

When the CEM Module receives a fabricated STATUS Request, the CEM User STATUS Function is NOT called.

This Problem Report has been closed.

2.2.3 PR 99-029 Directory Name with ASCII Spaces not handled.

• Skip leading Whitespace Characters (if any).
• Extract all Characters up to (but not including) the next Whitespace Character.

With this release, the 32-Bit Windows OSmain() algorithm for extracting an Argument from an Argument File is:

• Skip leading Whitespace Characters (if any).
• Examine the first Character of the Argument. If this Character is an ASCII Double Quote ("), define the Argument Delimiter to be this Character, and skip it. If not, define the Argument Delimiter to be an ASCII Space.
• Extract all Characters up to (but not including) the Argument Delimiter (or an ASCII Carriage Return or Line Feed).
• Skip the Argument Delimiter (or the ASCII Carriage Return or Line Feed).

This Problem Report has been closed.

2.2.4 PR 99-053 CEM Error 1030 (Fatal Unload) does not cause IFC/DCL Sequence.

With this release, RTS performs an IFC/DCL Sequence when a Fatal Unload Error is received from the CEM Module.

This Problem Report has been closed.