ALCS -- What's New in Version 2
by Steve Hobson

Since my first article about ALCS in ACP/TPF Today (Vol. II No. 2) IBM has announced ALCS Version 2. IBM has now shipped ALCS V2 to the customers who are participating in our early support program, so now seems a good time to give you an update.

Before I say more, I must mention that although I work for IBM, this is not written for or on behalf of IBM. And please note that when I refer to IBM products, programs, and services, it does 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 at the time of writing this article.

ALCS V2 is an IBM Program Product. The full product name is Airline Control System Version 2. (I'm going to save some space by not spelling out any other abbreviations.)

Like its predecessor (ALCS/MVS/XA) ALCS V2 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. And it's designed to provide high availability.

Unlike its predecessor, ALCS V2 does not run under MVS/XA -- it only runs under MVS/ESA.

OK - So What's New?
ALCS V2 includes more than 100 enhancements to ALCS/MVS/XA. For example, it addresses more than 40 ALCS User Group requirements (leaving 21 still open, so IBM can't relax yet). I cannot hope to give you the full picture here, so I have picked out just two topics for discussion that have interesting (I hope) implications. But first, to give you a flavor of what's new, here are some highlights of the new support in ALCS V2:

• SAA SQL access to relational databases.
• C language support, including TPF-C.
• Full APPC support, including SAA CPI-C and TPPC.
• Support for automated operation of ALCS and its guest applications.
• Very large (up to 34 gigabyte) VFA support.
• Integrated TPFDF support (replaces installation wide exits).
• Substantial performance improvements.

And you don't need to reassemble ALCS/MVS/XA application programs to run them under ALCS V2.

SQL Relational Data Base Support
ALCS V2 supports SQL for accessing relational databases. This is a full SAA implementation that includes both static and dynamic SQL. Actually, it's not really ALCS V2 that supports SQL. Those of you who read my previous ALCS article will not be surprised to hear that ALCS lets DB2 do most of the "hard work".

If you already know the SQL language, you can simply code "EXEC SQL ..." in your ALCS V2 applications, assembler or C, the same way that you would on any other platform. If you don't already know SQL, you'll need to read the DB2 SQL book

first. You can use SQL in ALCS V2 applications to look at, update, or add to any relational data base that DB2 has access to. This includes both data bases on the same MVS image and data bases on other MVS, OS/400, and OS/2 systems. This gives you a very wide choice of platforms on which to develop the applications that will use the data.

Even if you don't plan to share the data, your ALCS V2 applications may want to use the sophisticated data base services that SQL and DB2 offer. But before we get too carried away with this, it's obviously important to think about the performance and security implications. The arrival of SQL does not (yet) signal the demise of traditional and TPFDF data bases. Existing ALCS and TPF data bases contain a lot of highly-accessed data that is of little or no interest outside the ALCS or TPF system. It's probably not worth moving this type of stuff from the ALCS data base to a relational data base in a big hurry. (But it probably is worth moving it to TPFDF if you haven't already done so.)

As always, you must balance your requirements for performance and function. You cannot reasonably expect "EXEC SQL SELECT" to be as fast as "FINWC", because the SQL statement does a lot more work for you. And for security...

The relational data bases that DB2 has access to may well contain valuable data that needs protecting against accidental or deliberate corruption. And they may well contain sensitive data that must be protected (in some cases by law) against unauthorized "prying eyes".

Once again, those of you who read my previous ALCS article will not be surprised to hear that ALCS V2 cooperates with RACF and DB2 to provide comprehensive security for your relational data bases.

Telecommuting and Automated Operations
ALCS V2 provides an interface to the IBM NetView product. This allows you to allocate the function of any ALCS terminals (including Prime and RO CRAS) to NetView user-IDs. (It also allows ALCS to log communications errors on the NetView log.) This support in ALCS is capable of revolutionizing the operation of these kinds of system. You can, if you want, continue to operate ALCS as a separate entity -- with dedicated terminals for Prime, RO, and Alternate CRASs. But I anticipate that most users will want to direct RO CRAS output to NetView, and use NetView user-IDs for Prime and Alternate CRASs. This allows any NetView user (with the appropriate RACF authority) to monitor and control not only the ALCS system and its guest applications, but also MVS itself and other MVS sub-systems such as VTAM.

Since NetView terminals can be connected on dial-up lines, coverage programmers can provide a 24-hour service remotely. In the event of a crisis, they can review all aspects of the operation of the system leading up to the crisis. Then they can either advise operations what to do next or intervene directly. And they can continue to monitor the system in real time -- all from the comfort (I hope!) of home. The advent of "soft copy" documentation means that if you plan to go in for this telecommuting you don't need to build a library at home. You can access the reference books from the same PS/2 that you use to access NetView.

Since you can run SAA Rexx procedures under NetView user-IDs, you can also partially or completely automate many aspects of operation. You can easily develop programmed procedures to automate tedious and error-prone maintenance and batch-type jobs that require coordinating application, system, and off-line processes. By the way, I almost forgot to mention that you don't need any program changes at all to interface existing applications with NetView.

What Do Our Customers Think?
ALCS V2 is being evaluated by customers who are participating in the ALCS early support program. I can't say anything about specific participants, because this type of information is protected by confidentiality agreements. But I can report that initial feedback is very encouraging. For a typical ALCS/MVS/XA user with a modern full-function airline application, it is taking around two weeks to evaluate and migrate all local customization (user-written exit code, modifications, and so on) and get the application up and running on ALCS V2. This is exactly the kind of result that I expected -- and the ALCS team are very proud of it!

The following terms are trademarks of service marks of IBM corporation in the United States or other countries: IBM, MVS/XA, MVS/ESA, DB2, SAA, OS/400, OS/2, NetView