The promise and the problems on the road to Systems Application Architecture
The rapid assimilation of the term Systems Application Architecture into IBM’s current philosophy and vocabulary has led to a gradual realisation that the subject is deemed and destined to be Important. Yet despite a series of glowing, abstract IBM promises, little is known, and even less has been absorbed, about the implications and practicalities of the issue. Luckily, the current – Volume 32, No 3, 1988 – edition of the IBM Systems Journal is devoted to SAA, and, despite numerous split infinitives, it does manage to fill in the somewhat skeletal architecture with a number of practical bricks. Preambles to the subject – and this one is no exception – invariably revolve around historical inevitability-type arguments. Thanks to the drastic growth through the 1970s and 1980s of computing power and software sophistication, an evolutionary point has now been reached, so the argument goes, where key systems and environments – specifically OS/2, System 3X or the AS/400, VM and MVS – can and should be integrated. In other words, Systems Application Architecture is the envelope will one day protect user investment by offering consistency, upgradability and distributed processing power across a range of IBM product lines. At a more practical level, consistency comprises three distinct components: the Common User Access; Common Communications Support; and a Common Programming Interface. According to the Journal, the Common User Interface is designed to exploit the potential of the intelligent workstation, and to ensure that the way things look to the user and the actions required of the person by the system are familiar no matter what tasks are performed. When coupled with the ease of use and ease of learning criteria that IBM intends to introduce, skills will not merely be transferable, but the number of applications available to the user will, claims the company, be signi-ficantly augmented. Common Communications Support, the second element or interface of the architecture, focuses, rather obviously, on how systems communicate with each other, together with information storage and retrieval on a network. Facilities include data streams for the support of display devices, document text and printers, application services or network enhancers, session services reflecting the SNA LU 6.2 protocol, a network facility to support peer-to-peer commmunication across network nodes, and data link controls to provide Token Ring, X25 and Synchronous Data Link Control. Final and third component is the Common Programming Interface, which specifies Cobol, Fortran, RPG, REXX procedures language and the Cross System Product, CSP, application generator as the set of languages to be used for SAA compliant application development. A similar list, which includes the SQL database query language, a Query Interface, a Dialogue Interface, a Presentation Interface and the Common Programming Interface for Communications, is prescribed under the generic term of Programming Services. By enabling the application to be independent of the underlying system, argues the Systems Journal, return on code investment is maximised, and a programmer’s skill can be distributed across the SAA family, with corresponding productivity gains. Planned appendages to these three common interfaces are a family of integrated tools – with particular emphasis placed on a common data repository – and a set of Common Applications, Office and Decision Support being one practical and available example. At the end of the SAA tunnel lies the Enterprise Information System – IBMspeak for distributed processing, through the achievement of cross-system consistency. In broader terms, its goal is more of the same: to provide the base of usability, consistency, and connectivity required to make use of programming resources and user experience most effectively, thereby increasing productivity and protecting software investment.
The Common Programming Interface
Four key objectives are singled out for clos
er inspection in a subsequent – if brief – examination of the Common Programming Interface. The first, which he considers especially clear is summarised as consistency of the end user’s access – which, in turn, is closely linked to a second: the support by elements within the programming interface, of the Common User Access. Two such already specified are the Dialogue and the Presentation interfaces, which will enable the Common User Access, and, long term, offer enforcement of Common User Access conformance, writes Dean Wolford. Particular emphasis is also placed upon the ways in which the Common Programming Interface will help to enhance programmer productivity. Although he is quick to point out that there is no guarantee of complete application portability between the different environments – in that case, what’s it all for, for heaven’s sake – design, development and management of the Common Programming Interface is, he soothes, being conducted to minimise application rewriting. Similarly, thanks to the language – Fortran, C, Cobol, RPG, and the CSP Cross System Product applications generator and REXX procedures language – and service consistencies that will run, via the Common Programming Interface, across System 370 MVS and VM, OS/400, and OS/2 Extended Edition, application programmers will, so the theory goes, simply be able to transfer skills, without learning or relearning, from environment to environment. Key component, in both instances, is the inclusion within the Common Programming Interface of an Application Generator, and, in particular, the Cross System Product implementations. The Common Programming Interface will also provide languages and services for generation of applications requiring program-to-program linkage: the IMS/VS Data Communications and CICS/MVS transaction management subsystems have already been accepted in the programming interface, with underlying communications links provided by the LU 6.2 protocol. Wolford also anticipates that, eventually, the Common Programming Interface will support access – via SQL – to remote relational data, and – via unspecified high-level language file input and output language statements to so-called flat files. As a long-term or Enterprise Information System-style view, Wolford sees the role of the Interface as forming part of an integrated development environment for designing, modelling, developing, integrating, testing and maintaining application systems throughout their life cycle.
