Coping With New Technologies: A White Paper for ALCS Users
by Emir Garza
This document summarizes the options available to ALCS users when developing new functions on a Client/Server environment.
ALCS In The Client/Server World
"May you live in interesting times" - Ancient Chinese curse.
The times are very interesting indeed. Gone are the days when all applications were developed on the mainframe, and "new technology," for ALCS users, was COBOL/CICS. Today, the cost of computing on Client/Server platforms keeps falling, and there is a bewildering choice of hardware, operating systems, communications protocols, etc. to produce "mix and match" architectures. An IT manager faces the almost impossible task of guessing which architecture to use. Choose one too soon, and the use of immature technology results in costly project failures. Too late, and the competition will take advantage of a new technology first.
Paradoxically, the problem is less serious for an ALCS user: the SERVER side of the CLIENT/SERVER equation is, like it or not, solved. The server is ALCS, for a number of reasons:
The core applications have evolved over three decades, and are now so big and complex that re-writing them in a different platform is not a practical proposition. (The problem here is compounded by the classical killer of development projects: the ever-changing requirements of a very dynamic industry.)
The distributed processing world does not have a transaction monitor able to deliver the message rates, robustness, low cost per transaction, and low cost of maintenance of the mainframe transaction monitors (ALCS, CICS, IMS, TPF - the order is alphabetical).
This does not mean that ALCS users are "stuck" with it. It is true that, as it is running the core business applications, ALCS is the keeper of the business data. Getting to that data was, until recently, the privilege of the initiated in the intricacies of the ACP/TPF API. This is no longer the case. If it makes economic sense to develop new functions on a different platform, then it is possible for that platform to interact with ALCS using SQL, APPC, MQ, or TCP/IP. A brief description of each follows.
SQL
SQL (Structured Query Language) is many things:
Relational databases, over which SQL operates, have become the standard database architecture for decision support systems and many transaction processing systems. ALCS has an interface to DB2 (the MVS implementation of relational databases) that allows an ALCS application program to contain imbedded SQL statements. ALCS application programs can query relational databases or propagate ALCS data to relational databases.
APPC
APPC (Advanced Program-to-Program Communications) is a connection based protocol that
enables a transaction program (TP) to converse through an SNA network with peers running on
PCs, RS/6000, AS/400, S/390, and many non-IBM platforms. The APPC API is rather complex
(it consists of about 40 verbs), and requires specialized programming skills. But it provides robust
conversations and advanced functions such as password validation, automatic remote program
start, and distributed checkpoints.
ALCS programs can issue APPC calls to establish and carry out a conversation with another TP. When you only need APPC as a connection "pipe" to send and receive messages, you can ask ALCS to hold the conversation - when a message arrives, an ECB will be created in the standard fashion as if it had arrived from a terminal.
MQ
MQ (Message Queueing), hides the complexity of heterogeneous networks by providing a simple,
intuitive API, based on connectionless communications through message queues (like
communicating through the post or fax rather than having a telephone conversation). Application
programs only deal with essentially four verbs: Open or Close a message queue, Get a message
from a queue, Put a message on a queue.
Messages can be "hardened" to guarantee ONCE DELIVERY (that is, message delivery is guaranteed without duplication). Communications across queues is performed by Queue Managers, leaving the application unaware of the network topology and/or protocols. MQ is ideal for distributing transactions, and should be the protocol of choice if the application can tolerate time-independent responses. MQ is also ideal for distributing multiple parallel transactions. ALCS application programs can issue MQ calls (Open/Close queue, Put message, Get message).
TCP/IP
TCP/IP (Transmission Control Protocol / Internet Protocol) was designed for communication
between networks, and is very strong for internetworking between different LAN environments. It
is the protocol used in the Internet and runs on almost every operating system. It is the native
communications protocol of Unix systems.
SOCKETS is to TCP/IP what APPC is to SNA: it is an application-to-application protocol built on top of TCP/IP. ALCS supports TCP/IP in two ways:
RPC (Remote Procedure Call) is a TCP/IP application protocol that provides an alternative to APPC or MQ. It allows an application to issue "call" instructions to remote programs as if they were local subroutines (that is, the network location of the called program is transparent to the calling program). This is a very appealing concept, as the application programmer needs to have no knowledge of the network topology - not even message queues. The problem with RPC is that it does not guarantee ONCE DELIVERY. This places the responsibility for error recovery with the application programmer, leading to a complexity that outweighs the benefits of the call interface.
Which Platform? Which Protocol?
Here are some general criteria for choosing which platform and protocol to use when developing
new functions that need access to ALCS data.
Strange as it may sound, ALCS may not always be a more expensive choice. This is because your staff already knows ALCS, and the cost of development and maintenance is a well-known quantity. A new platform will need investment in training for both application programmers and systems specialists. This leads to the next consideration.
It is most cost-efficient to choose a platform that is in line with the rest of your IT strategy. This will let you draw from existing skills in the organisation, and will spread the cost of training and maintenance over many projects.
By the same reasoning, avoid having too many ifferent platforms. Although a particular platform may be the best fit for a particular application, having a different platform, protocol, or tool for each application will result in a logistics nightmare.
Client/Server allows almost limitless "mix and match" of heterogeneous components: RESIST THE TEMPTATION, keep your projects simple and your platforms and protocols to a minimum.
Before selecting a Client platform, make sure that you can develop not only the application, but also the technology for deploying distributed maintenance (fixes and upgrades). When you change a program in the mainframe, all your end users have automatic access to the new version, without any action required on their part - this is may not be the case with distributed processing.
Mainframes, and mainframe applications, have been around for decades. You can not say the same about any new technologies. The industry is moving so fast that many platforms become rapidly obsolete. This does not mean that you should not consider new platforms, but you should change the focus of your development strategy: do not build client software for posterity, but build disposable applications - cheap enough that you will not regret having to rewrite them in whatever becomes the winning architecture of the future.
Make your choice of platform not only on how good the platform is for the application code, but also for the data. The platform must meet the security, integrity, accessibility and compatibility requirements of the data you intend to place in it.
Make sure that the platform you choose is mature enough to use it for a development project. Always ask yourself the question: is it easy to develop on this platform? If the answer is yes, then it is safe to use it.
How do these general considerations apply to the interfaces to ALCS described earlier? First, it is safe to assume that those interfaces are mature and stable, so any of them passes the maturity test. Based on the recommendation to keep in line with your overall IT strategy: if your strategy is centered around Unix, then TCP/IP is your protocol of choice. But, which one should you choose if you have the freedom to start from scratch? ALL OTHER THINGS BEING EQUAL, I believe the choice is reduced to two options:
It is important to realize that the ALCS user community, being small, has always benefited from the exchange of software. It follows that one particularly good strategy is to do what other ALCS users do. I STRONGLY SUGGEST THAT THE ALCS USER GROUP DEFINE A COMMON STRATEGY FOR ALL ITS MEMBERS. This will enable the software exchange to continue for platforms other than ALCS.
The Future
New platforms and protocols continue to appear. Some are here to stay, others will only be a
temporary fashion. Some areas that may be of significance are:
Object-Oriented Technologies
Object-oriented design and development has established itself as a technology that truly increases a
software developer's productivity by enabling reuse and incremental development. Distributed
Objects, as specified by the DSOM (Distributed Structured Object Model) standard, may
eventually provide the transaction processing architecture of the future. ALCS development is
looking at the best way of linking object technologies with ALCS.
In the meantime, it is a good idea to invest in Object technology education and training for your staff. Even though any actual development you do will most probably be written in C++, it is advisable to train your developers in a pure object language, like SmallTalk.
Network-Centric Computing
In a way, one could think of Network-centric computing as a flavor of Client/Server where the
CLIENT is very "thin" - it is mainly concerned with presentation services, and the rest of the
intelligence resides in the network. Two factors contribute to the rise of Network-centric
computing:
The most conspicuous example of Network-centric computing is the Internet. The Internet is a big opportunity, as it is an entirely new channel for delivering services to your customer. ALCS development is looking at implementing an interface between existing ALCS applications and the World Wide Web.
Client/Server Groupware
Groupware is an example of what Client/Server can do that neither mainframes alone nor PCs
alone can. Groupware addresses the need to manage semi-structured information (text, image,
mail, etc.) and the flow of work. The leading example of this type of technology is Lotus Notes.
The new function, MQSeries Link for Lotus Notes, will allow ALCS applications to interface with
Lotus Notes through MQ.
Conclusion
There are many other technologies which were not mentioned here, and many more that will appear
in the future. You should rest assured that, once a technology becomes mature, ALCS WILL
PROVIDE ACCESS TO IT WITH MINIMUM DISRUPTION. An example of this is the new
TCP/IP support, added this year to ALCS V213: users connecting to ALCS through TELNET will
have access to UNMODIFIED transaction programs that were designed and written for ALC
1977 keyboard printers thirty years ago!
Emir Garza, World Wide Travel Industry, Transaction Processing
GARZAE at CROVM3; GBIBMC6K at IBMMAIL; emir_garza@uk.ibm.com
1 New Square, Bedfont Lakes, Feltham, Middlesex TW14 8HB UK
Phone +44 181 818-5016 Fax +44 181 818-5291