You can't afford not to belong to GUIDE or SHARE, if you have a large IBM system. These are the user groups for IBM 370 series, AS/400, and RS/6000 systems. Regular subgroup meetings are held in Europe throughout the year, but the conferences held several times a year usually attract up to a thousand users of these systems. If you join, you will receive a regular mailing of news, technical papers, and lists of outstanding issues raised with IBM.
The GUIDE Spring conference for Europe, the Middle East and Africa was held this year in Helsinki, at the start of June. The next GUIDE conference will be at Innsbruck in November.
The most exciting discussions in the conference were on object oriented programming, and on System Application Architecture (SAA). A lot of time was spent discussing areas around SAA, such as SystemView and AD/Cycle. IBM will be announcing a number of major enhancements to CUA and to SystemView in the next few months. I will come back to some of these in later columns, but for now, let's see why GUIDE is concerned about SAA.
SAA is IBM's answer to Open Systems. If you adopt SAA, then all of your SAA approved IBM systems will be able to intercommunicate, run the same applications, be centrally managed, and will (most important of all) look the same to end users. Time spent learning how to use SAA applications will allow you to learn a new SAA application much faster; the same as is true with transferring learned skills between, say, Macintosh applications.
SAA was announced on 17 March 1987. At the time, it was just a grouping of existing products, but it was also a plan, or 'road- map', for what would come, describing a style guide for developing future applications.
There are four components:
The last, Common Applications, are all of the 'approved' applications, developed by IBM, by third party software suppliers, and by all user installations.
The rest of the components are based on existing IBM hardware platforms, data-bases and interfaces (such as ISPF and GDDM), with SNA and ANSI standard languages.
A couple of announcements in 1989 expanded the architecture: OfficeVision, the first Common Application; and CUA-89, a redefinition of CUA dividing the standard into support for Programmable Work Stations (PWS), and Non-Programmable Terminals (NPT).
AD/Cycle and SystemView have both been proposed by IBM as systems management applications that also, like OfficeVision, conform to SAA. They adopt a common structure, which ensures that a central database, or 'Repository' of information can be accessed by PCs (or Programmable Work Stations, PWS, in SAA jargon) using an SAA graphical interface.
In the next few months, we expect to be told that CUA will be revised, to conform with OS/2 Release 2. This means that SAA includes CUA definitions to run on dumb terminals (3270s and 5250s), and on PWSs in both text and graphics modes. The latter is simply the current IBM OS/2 graphical user interface.
To the typical user, the only part of SAA that is visible is CUA. But CUA, so far, has changed dramatically every two years. If you really want to use CUA to minimise on staff training, then it should be as stable as possible.
GUIDE are concerned that the basic definitions of SAA, and CUA in particular, are changing too much and too fast. As soon as a new IBM product is announced (OfficeVision, OS/2 Release 2), then CUA is redefined.
Those of us who have used Windows 3, or Motif on Unix systems, know that there is a very close relationship between these interfaces. However, there are differences between these and IBM's CUA definition, and they are not listed by IBM as complying with CUA. Perhaps, if the definition is so flexible, they should be included.
In the TSO environment on MVS, and in VM/CMS, both mainframe operating environments, REXX can be used to automate any procedure, even going so far as to supply parameters to full- screen displays produced by application programs. REXX is a very sophisticated command scripting language, with much of the capabilities of the Unix shell. It is available on microcomputers for the Amiga and for OS/2. Any graphical user interface needs to have a command line equivalent to allow repetitive actions and mass loading of data to be carried out by a user.
However, the OS/2 version of REXX is severely restricted. It cannot directly access data fields within applications; the reason is that it has been left to application designers to include support for REXX data entry in their systems, and this just hasn't happened.
SAA will include both OS/2 1.3 and O/2 2.0 as supported PWS operating systems. This is so that older PWSs with 286 CPUs will continue to be supported after OS/2 2.0 is released. PL/I is one of the supported languages included in SAA. However, IBM have announced that PL/I will not be released for OS/2 1.3. I am not proposing that there is ever going to be a great demand for PL/I to run on OS/2, but one of the central ideas of SAA is that any fully compliant program can be compiled unchanged on any SAA platform; including OS/2 1.3. If you use PL/I, then that can't happen.
It seems that SAA isn't getting the commitment from IBM that is required to make it a 'blue' Open Systems architecture. There has been an encouraging amount of support from third-party vendors, on 370, AS/400, MS-DOS and OS/2. CUA is the only genuine standard for user interfaces, much more comprehensive that Motif or Open Look, and IBM are the only ones not taking it seriously.