ALCS is IBM's Alternative to TPF
Application software gives user a TPF-like inferface under MVS
by Steve Hobson

I've been asked to say a little something about ALCS. I hope you will bear with me if I preface this by pointing out that although I work for IBM, this is not written for or on behalf of IBM. Also, any references to products, programs, and services do not imply that IBM intends to make them available in all countries in which IBM operates -- in particular, ALCS is not generally available in the USA.

The full alphabet spaghetti for the IBM Program Product is ALCSI MVS/ XA. ALCS stands for Airline Control Systems -- though by no means are all ALCS users airlines. I guess you know what MVS/XA stands for, but in this context it's slightly misleading since the product runs under either MVS/XA or MVS/ESA -- actually it runs rather better under MVS/ESA. So in this article I'11 just call it ALCS. And when I refer to MVS, I mean MVS/XA or MVS/ESA.

ALCS is designed to Provide a TPF-like application program environment under MVS. It's also designed to provide high performance -- both in terms of the number of transactions it can handle and the response times it can provide.

ALCS from the application programmer's point of view The application program environment provided by ALCS is very similar to the TPF application program environment. In practice, almost any assembler language application program written to run under TPF will also run under ALCS. And if you are used to writing TPF application programs, you will have no difficulty writing application programs for ALCS.

ALCS uses the same register conventions as TPF (register 8 is the program base register, register 9 is the ECB address, and so on). All the macros used in "normal" application programming are provided with ALCS and they take the same programming are defined in the ALCS ECB. And so on. But perhaps I should be more specific about what I mean by "normal." There are differences between the ALCS and TPF application environments. These are fully explained in the ALCS publications, but to give a flavor they include:

• ALCS application programs cannot enter supervisor state or use protect key zero. ALCS protects itself (and MVS) absolutely against modification by application programs - whether accidental or deliberate. There are not "clever tricks" which ALCS application programs can use to bypass this. This means that, for example, ALCS does not support the MONTC and CINFC W macros.
  
• ALCS macros expand differently from TPF macros. ALCS application programs must not include code that depends on the exact macro expansion -- like "B *+10" to branch round a macro. And they must not include "hand expanded" macros (SVCs, VL3s, and the like.)
  
• ALCS application programs are not restricted to 4k. They can be up to 32k. But we recommend that programmers stick to the 4k restriction so that ALCS programs can be ported to TPF without resegmentation.
  
• ALCS supports up to nine different storage block sizes (L0-L8) and eight corresponding DASD record sizes (L1-L8). To ensure compatibility with TPF, sizes L3 and L5 L8 can be exploited through the IBM TPFDF product which allows application programs to be independent of the physical record sizes used.
  
• ALCS "tapes" can be on (almost)any medium that MVS supports for sequential datasets. For example, an ALCS general "tape" can be a magnetic tape, a cartridge, a DASD dataset, a SYSOUT dataset (handled by MVS spooling and typically printed), or even a deck of punched cards (if you still have a card operations like write-tape-mark and rewind are not allowed because DASD, printers, and so on, don't like them.

Note that ALCS only provides source code compatibility. You must reassemble application programs when you port them from TPF to ALCS or vice versa. Also for the application programmer, ALCS provides a comprehensive set of testing and debugging facilities. These include:

• Interactive and batch mode macro traces and an interactive instruction step trace.
• A test data base facility which al lows multiple users to share a common test data base. Updates are kept separately so that each user's test data is protected against corruption by other user's testing.
• On-line program load facilities which allow (amongst other things) individual end-users to load their own private copies of programs during testing.

ALCS from the system programmer's point of view
In many ways, ALCS would appear very familiar to a TPF system programmer. He or she would immediately recognize such old friends as the CPU loop, VFA, the message router, the post processor, and so on (though they might wonder what happened to SAL because ALCS doesn't have one).

The most obvious difference between ALCS and TPF that a system programmer would notice is that ALCS uses other products to do much of the work that TPF does for itself. For example: MVS does the virtual storage support for ALCS. This includes managing DAT tables, paging (using DASD and/or expanded storage), and so on. In fact, MVS does most of the processor support. But to achieve good performance, ALCS does its own ECB scheduling and dispatching, including load-balancing in multiprocessors. ALCS also includes its own storage manager for ECBs, working storage, IOCBs, and so on.

ALCS exploits MVS fast Paths to optimize its performance. For MVS buffs, these include things like branch entry to supervisor functions.

VTAM does most of the communications support for ALCS, even for some "exotic" protocols such as ALC and World Trade Teletype (WTTY).

The only real exception is SLC which is a little too exotic for VTAM, so ALCS includes its own SLC support. As with MVS, ALCS exploits VTAM fast Paths (like SRB dispatched exit routines) to optimize performance.

NetView does most of the communications management for ALCS.

DFP does most of the I/O support for ALCS, including support for DASD and "tapes" (it's thanks to DFP that ALCS "tapes" can be on DASD). DFP also provides the support for things like the IBM 3990 fast write and dual copy ("hardware" duplication) functions. Since ALCS itself Provides "software" database duplication you can use either -- or both if you want a quadruplex database -- but hardware duplication gives you reduced CPU utilization.

ALCS includes the support for the "horizontal" organization of records. This spreads records across the DASD, to balance and optimize DASD accesses in much the same way that TPF does. But note that the ALCS realtime data base looks like a number of conventional VSAM datasets as far as DFP is concerned, so that you can use conventional DFP utilities for backup, restore, and so on. The datasets can also be protected using RACF in the normal way.

ALCS also includes its own data base update logging facility (similar to TPF logging and exception recording) so that backups can be done without interruption to ALCS transaction processing.

ALCS does not use DFP buffering facilities for the realtime database, general files, and general datasets. Instead, ALCS implements VFA. ALCS's VFA can exploit expanded storage if required, and is optimized for the access characteristics of its application programs. And (you guessed it) ALCS uses DFP fast paths to optimize performance.

ALCS from the operator's point of view
ALCS systems require very little specialized operator intervention. Much of the ALCS operation is done through MVS. But what little there is would also look pretty familiar to a TPF operator. Many of the ALCS commands are much the same as the corresponding TPF functional messages (ZDSYS, ZATIM, and so on). ALCS commands also provide on-line help which gives a brief summary of the function and syntax in response to a "?" operand. For example, "ZRECP ?" tells you how to enter the ZRECP command (if your keyboard doesn't have a "?" you can use "ZHELP RECP" instead).

ALCS from the end user's point of view
As with TPF systems, the end-user doesn't really "see" ALCS itself, Instead, he or she works almost exclusively with the application -- though increasingly often through an intelligent front end, and such as IBM's ACSP running in a PS/2. But end users are very much aware of the response times and availability that the system delivers. Our experience indicates that ALCS systems deliver excellent response times and availability.

Additional information on ALCS/MVS/XA can be obtained from either your local IBM representative, or by contacting the IBM International Airlines Support Centre in Brentford, United Kingdom.