ALCS Application Development - Making the Change
by Lloyd Hirst
ALCS (Airline Control System) is a high performance and availability database and communications monitor subsystem which runs in an MVS environment. ALCS offers an alternative to the TPF operating system. Tightly coupled multiprocessors enables ALCS to be a viable option for all but the very largest users. Providing an Application Programming
Interface and performance characteristics similar to TPF, ALCS enables applications designed to run in a TPF environment to execute under control of the ALCS monitor in an MVS environment.
ALCS/MVS/XA (Airline Control System/MVS/XA) will operate under MVS/XA or MVS/ESA while ALCS Version 2, an enhancement of ALCS/MVS/XA will only operate under MVS/ESA. ALCS Version 2 has a planned General Availability date of April 1992 in countries where ALCS has been announced. At time of writing, neither ALCS/MVS/XA or ALCS Version 2 were announced in the USA.
It is not possible to adequately discuss all aspects of ALCS in one article. Instead, some of the advantages and differences that may interest applications developers not familiar with ALCS are explored. The first thing an applications programmer will notice when switching from a TPF or ACP environment to ALCS/MVS is the similarity. Since ALCS is designed to provide an API similar to TPF and ACP, the transition to coding for ALCS is fairly painless. ALCS is largely source code compatible with TPF. Programmers will find themselves very much at home with everything from the BEGIN to the FINIS statements.
The ECB storage blocks, macros and conventions are very similar. In many ways, an ALCS system looks and "feels" like a TPF system. Prime, Read Only, and Alternate CRAS consoles have been retained. Many of the Z functional entries are very similar, and are supported by an online help facility. While most changes are under the covers, there are still significant advantages for the application developer. A wide range of "user friendly" macro formats are supported.
Monitor request macros coded in ECB controlled programs generate calls to ALCS monitor service routines in place of SVC instructions. Most ALCS monitor service request macros support TPF/ACP formats for compatibility, as well as alternative ALCS macro formats using keyword parameters and the option of supplying parameter values in registers for greater flexibility.
For example - The RELCC macro may be coded in TPF format,
{label} RELCC Dn ---- where Dn is the level symbol
or in alternative ALCS formats:
{label} RELCC LEVEL=Dn{,TYPE=COND} --or--
{label} RELCC LEVEL=(reg){,TYPE=COND}
where reg is the register containing the level value. The optional TYPE=COND prevents an error if no block is held.
Programs are assembled and link edited into load modules containing one or more programs. At initialization time ALCS loads into storage load modules specified in the Program Configuration Table. Programs may be up to 32K in size unless it must run in 24 bit mode in which case the limit is 4K. This flexibility saves segmenting programs for that "2 additional instructions" modification.
Load modules may be loaded dynamically via functional entry directly from the load library. No tape mounts are required. Program names do not have to be defined to the system before a program can be loaded. Transfer vectors may be defined via the TRANV macro within the program segment. No SAL table updates are required. In fact, the SAL table does not exist. When a load module is being loaded or unloaded, ALCS keeps track of the creation time of each ECB and ensures that the copy of the program which was active at creation time is executed for the life of the ECB.
Combining related programs in a single load module provides for easy load and unload of changes. In the development environment, a programmer can maintain a single load module containing all the programs being modified for the package, assembling selected programs and relinking into the existing module as required. The load module may then be loaded or unloaded with one funtional entry. Load modules may be loaded with Test Status, to be executed only by ECB's associated with selected terminals.
Where database changes are required to support testing of modifications and/or it is desirable to prevent test programs from updating the database, ALCS provides a Test Database Facility. An ALCS system using the Test Database Facility requires only Read access to a complete (Primary) Database and Read/Write access to a VSAM KSDS, the Test Database. Multiple Test Database Facility systems can share a single Primary Database providing totally separate ALCS test environments. Updated records are written to the Test Database. Records are read from the Test Database, or if not found there, from the Primary Database. The Test Database(s) can be backed up, restored, or reinitialized as required without changing the Primary Database. If required, the Test Database may be merged with the Primary Database, using standard VSAM and ALCS utilities. The VPARS user will no doubt see similarities here.
ALCS uses MVS Sequential File Access Methods to access and create sequential files on any supported media. Files may be (and typically are) cataloged not only permitting a revolution in the management of data management (compared to TPF), and also make life easier for the application developer. From the comfort of your workbench it is possible
to test programs writing data to sequential DASD files, run batch jobs to process files and/or create and load new files without operator intervention or delay. This means goodbye to tape if you want!
Close to the heart of every programmer is their favorite test and development tool, program trace. ALCS trace facilities inspire "love it" or "hate it" reactions from programmers from a TPF or ACP shop, depending on the facilities previously available to them. ALCS provides three trace modes: Conversational, Diagnostic, and System Macro Block.
Conversation trace allows the tracing of ECB's associated with entries from the users terminal, for all or selective programs, suspending execution at all or selected groups of macros, references to specified file addresses, selective record IDs, system errors, and EXITC.
At each trace point, the information presented on the screen depends on a range of display options defined when starting the trace, or modified at previous trace points. Trace commands may be issued at any trace point to, display additional formatted trace data, to modify display or trace control options, issue Z functional commands or application entries. Register values, Condition Code, Next Sequential Instruction Address, Program Instructions (Test Programs only) may be modified together with a range of symbolically addressed storage locations within the ECB and working storage, without needing to calculate the storage address. For example the command "SET SB2,DISP=11C 00" stores the value hex 00 at offset hex 11C into the storage block on level 2 without the need to calculate the storage address. Address stops may be set to suspend execution at specified offsets in programs and tracing is suspended until that location is reached.
At any trace point instruction step trace may be invoked to execute one instruction at a time displaying (as a minimum default) program name, offset, symbolic operation code, operands, and operand contents. All ECB's created by the original ECB may be traced. The SWAP command allows swapping between ECB's being traced. While the functionality available while tracing an entry generates most of the "love it" reaction, the inability to conversationally trace ECB's that are system created, CRET'ed, or associated with a terminal other than the tracing terminal generates most of the "hate it" reactions.
Diagnostic trace permits ECB's to be traced without suspending processing. Trace data is written to the Diagnostic File (DIA) for post-processing. The Diagnostic file is a realtime sequential file similar to the RTA, but used exclusively for ALCS diagnostic data and performance data. The RTA is reserved exclusively for application data under ALCS.
Diagnostic Trace provides similar "display" and control options as conversational trace. ECB's associated with entries from a particular terminal or group of terminals or every ECB (including system created) that executed the selected program(s) may be traced.
Diagnostic Trace can be a valuable tool in solving production system problems. Providing care is taken in selecting programs and terminals to be traced, and data to be collected, diagnostic trace is nondisruptive. However, did you here the one about the coverage programmer who accidentally attempted to trace all availability entries from all terminals on the network?
System Macro Block trace allows tracing of macro calls from all ECB's in the system to a system control block. The macro trace control block may be displayed or printed, and more importantly, it is recorded in system error dumps. This facility is only required for diagnosing problems associated with multiple ECB's. In addition to this optional centralized macro trace facility, ALCS traces monitor request macros for each ECB separately. This trace data is available in dumps, providing substantially improved foot prints compared to the traditional system macro trace.
MVS facilities SLIP TRAP and GTF trace provide additional diagnostic tools. Although not appropriate for many ALCS application problems, they can sometimes provide simple solutions to tricky situations. For example, if fields in the global area are being corrupted, the offending program can be quickly identified by a simple Storage Alteration SLIP TRAP triggering a GTF trace.
The Diagnostic File is used to record many types of trace, error, exception, and performance data which is not discussed in this article. However, of particular interest to the application programmer are System Error Dumps and Long Term Pool Diagnostic Errors.
System Error dumps generated by SERRC and SYSRA macros and from error conditions detected by the ALCS monitor are written to the Diagnostic file for post-processing in a similar manner as the Diagnostic Trace information. Post-processing is a very quick and simple process providing the Diagnostic files are written to DASD. ALCS does not have an online mini dump facility, but exit points are provided to enable user written dump and error reporting facilities to be installed, just like TPF.
Long Term Pool handling in ALCS is a substantial improvement over that available in TPF, with Recoup providing only part of the function. Recoup descriptor macros are used to describe the database (in a similar manner to TPF0, allowing most record structures to be chain chased without the need to write executable code. Exits are available for specialized processing requirements and unusual data structures. Recoup is nondisruptive and may be run entirely in NORM state. Once started, it requires no further operator intervention. Using ALCS dynamic load control mechanisms, Recoup adjusts its resource usage to system load making it possible to run during peak operating times.
The major advance in ALCS pool handling is achieved by recording usage information in every long term pool record. Each long term pool record contains time stamps indicating the record dispense time, last write time, last Recoup chain chase time, and release time, together with the name of the program initiating the action. Using these time stamps and the start time of the last successful and current Recoup, ALCS is able to detect and report a wide range of errors that might otherwise be difficult to detect. Pool diagnostic error reports not only indicate the record of the type of error that occurred (e.g. Read of a Released Record), but a history of the time and program that last dispensed, wrote, chain chased, or released the record.
Pool handling logic is integrated into not only pool dispense, release, and Recoup facilities, but complimented by checks in read and write functions. Not only does this provide comprehensive error detection and reporting, but substantial protection against data loss through pool handling errors. For example, if file address dispense processing detects that the record being dispensed is a lost address (i.e. not found by the last Recoup chain chase and hence available in the pool directory, but never released), ALCS will record the error on the diagnostic file and bypass dispensing of the address. The record will not be used until a complete cycle of the pool directories has occurred, typically a few days and at least one Recoup later. Modifying Recoup descriptors to ensure the record is chain chased provides permanent protection. These facilities provide warning of erroneous conditions and time to correct the problem, in situations which would otherwise result in data loss.
ALCS provides a high degree of protection (compared to TPF) against system outages caused by application programming errors. It is difficult (but not impossible) for an ECB controlled program to bring down ALCS, if reasonable resource control limits are set in place.
Storage Protection
ALCS uses storage protect keys 7 and 8 (Tables and Entry key). ECB controlled programs
execute in Entry Key and are not able to change protect key. The ECB's working storage and the
global area are in Entry Key. ALCS programs, monitor control blocks, and tables are in Tables
Key and cannot be updated from ECB controlled programs.
Storage Isolation
Working storage is divided into storage units separated by a 4K page of protected storage. ECB's
reside in storage units, and storage obtained by the ECB is allocated from the storage unit
containing the ECB or other storage units associated with that ECB. Corrunpting storage by
"running off the end" of a storage block only corrupts storage in the ECB's own storage unit, or
results in a CTL-3 if attempting to update the buffer separating storage units. Some system data
relating to the ECB is stored in the ECB prefix area located before the ECB in the storage unit,
while the most critical information (usage details, chaining, control fields, etc.) is kept in the storage
unit descriptor in protected (Tables) storage.
Resource Usage Limits
The ALCS system Configuration contains limits, a default and absolute maximum as the amount of
storage, duration of ECB life, number of system errors, and number of get files an ECB may use
without being terminated by the monitor. The default value may be altered via the SLIMC macro
up to the absolute limit. These limits are an important defense against runaway entries monopolizing
system resources.
Deadlock Protection
ALCS prevents "deadly embraces". When an ECB attempts to hold a resource which is not
available, a check is made to see if the ECB holding the resource is either directly or indirectly
waiting on resources held by the requesting ECB. The ECB attempting the hold is terminated if the
hold would have resulted in a deadly embrace.
Load Control
ECB's doing an excessive number of writes without explicitly issuing a delay or defer are
automatically deferred based on system configuration parameters. Resource usage by individual
ECB is controlled by the limits mentioned above. Multiple ECB tasks are more difficult to control.
ALCS provides a LODIC macro for applications to test for available resources to prevent the
system being overloaded with an excessive number of entries.
If an application creates many new entries without testing for available resources it is still possible to "overload" ALCS. In these circumstances, ALCS will not accept new input messages into the system until the bottleneck is cleared. ECB's attempting to create new ECB's when insufficient storage is available are deferred until resources are available. In a worst case scenario, where all ECB's cannot proceed due to storage shortages, resources will be freed by ECB's exceeding their maximum permitted life, being terminated by the monitor.
While ALCS cannot resolve the most extreme overload conditions caused by poor coding practices, without interruption to normal service, a correctly configured system should recover from most abnormal situations. Individual entries will fail, but the system will recover.
ALCS provides many features and facilities to assist the application programmer, and many other attributes worthy of discussion. The availability of ALCS Version 2 expands facilities, opens up the interfaces and allows greater application and operational integration by providing most notably:
Lloyd Hirst is a Systems Consultant with Amdahl Australia specializing in ALCS Systems. He is currently working on assignment at Ansett Australia, leading the ALCS Systems Programming team. Since switching from TPF in December 1987 for Ansett's conversion from TPF1, Lloyd has had extensive experience with ALCS.