Whether one is convinced by the messianic preaching or incurably sceptical, it is clear that Systems Application Architecture is the most important new concept introduced to the IBM computer world since the unveiling of Systems Network Architecture back in 1974 – when the company described that as its most important innovation since System 360. Indeed, if things work out the way IBM intends them to, SAA will prove to be even more important than SNA, so if we are serious about our profession, we are all going to have to get our heads around it. In CI No 1,049, Sophie Hanscombe introduced the basic elements of the system and looked in a little more detail at the Common Programming Interface. In CI No 1,052 she moved on to perhaps the most important element of all – the Common User Access, or the rules behind what appears on the screen when an SAA-compliant application is invoked. Today she wraps up the basics with a tour of the Common Communications Support, much of which mercifully turns out to consist of what we already know.
Common Communications Support: much of what’s needed is already in place
Within the subsequent column space dedicated to individual explorations of the three key components of Systems Application Architecture, the Common Programming Interface, Common User Access and Common Communications Support, by far the thinnest chapter – both literally and in terms of content – is given over to a discussion of Common Communications Support. At least three of the 16 pages, excluding nine half-page and two full page diagrams, are spent reaffirming the concept and role of Common Communications Support – essentially, as the introduction states, a set of interconnection and data interchange protocols for the projected Systems Application Architecture group of systems. Similarly, great and repeated emphasis is placed upon the way in which the component fits into the overall architecture and is accessed by the user: an underlying … goal, explains Dr Vijay Ahuja, is to avoid exposing a Systems Application Architecture application to the details of Common Communications Support protocols and formats. In other words, access to the specified protocols is provided transparently, through either the Common Programming Interface, or the Common User Access. As far as the protocols themselves are concerned, Common Communications Support is constituted primarily of elements of Systems Network Architecture – see, IBM wasn’t leading us all up the garden path all those many years ago when it advised us to pay especially close attention to SNA. For displays, IBM specifies that the 3270 Data Stream – also known as the 3270 Information Display Data Stream – should be used for data transmission between application program and terminal, while for printers, the company prescribes the Intelligent Printer Data Stream to trans.cw 8 mit all-points-addressable or APA data, via a set of controls that communicates between a host printer driver code and the microcode in the printer.
The distributed office environment
For the distributed office environment – of particular light shedding relevance to users of the AS/400 Office program (CI No 1,021) – communications support will be provided through Document Content Architecture, Document Interchange Architecture, and the SNA Distribution Services architecture – so DCA and DIA are carried forward into the emerging Office family, even though they were not mentioned in the AS/400 Office announcement. For those who have forgotten, Document Content Architecture is used to define the structure and meaning of a document’s content, while Document Interchange Architecture and SNA Distribution Services are used for document distribution and data interchange with other office automation systems. Meanwhile, there are no worries ahead for network managers: network management within Systems Application Architecture by-passes the Common Programming Interface, and is embraced by known and loved Systems Network Architecture facilities – Problem Management, Configuration Management, and Performance and A
Distributed data services
Overall, argues Dr Ahuja, while Systems Application Architecture programs access data as though the data were local, data residing in a remote location is, in reality, accessed via a number of distributed data services, with underlying connections provided – in both instances – by SNA Logical Unit Type 6.2 protocols. Distributed file processing, for example, is achieved using Distributed Data Management or DDM architecture, which in turn comprises three layers: the Data Manager; the Agent; and the Communication Manager. The Data Manager provides functions that pertain to both files and records in the files – file creation, deletion, renaming, locking, unlocking and attribute retrieval, along with record loading and unloading from a remote file for a whole file transfer. The Distributed Data Manager Agent – one provided for every application program – performs data conversion and parsing, enforces security, and provides cleanup or recovery processing, while the final interfacing with LU 6.2 protocols to accomplish the exchange of data between systems, is performed by the Communication Manager. Systems Application Architecture also stipulates the use of SNA LU 6.2 for defining distributed database and application formats and protocols, and Low Entry Network – SNA/LEN – and Type 2.1 protocols for network level support, enabling peer-to-peer connection of distributed processes, and providing the physical and logical connectivity required to support LU 6.2 sessions. IBM also notes that Systems Application Architecture systems can be connected to each other using local area networks, telecommunication links, or packet switched networks. For data link control, the architecture not surprisingly prescribes SDLC and Token Ring to support Systems Network Architecture attachments, and X25 to enable the participation of non-CAA systems. In conclusion, adds Dr Ahuja, the Common Communications Support has specified a list of IBM publications describing details of each element of the communications component, enabling users of non-SAA systems to generate appropriate data streams for data exchange and participation within the projected Enterprise Information System.