If Systems Network Architecture seemed a somewhat nebulous concept when it was first introduced – as IBM’s most important announcement since System 360 – in 1974, it was as clear as mud compared with what is currently visible of IBM’s Systems Application Architecture. The intention behind SAA is clear enough – write applications to the interfaces and they will run on all the machines and under all the operating systems that IBM has declared to be SAA products. In that list are MVS, needless to say; VM, equally unsurprisingly; and OS/2, whatever that may turn out to be when it finally arrives. And there will be an SAA operating system for the System 36/System 38 architecture – but it appears that it will be the new version of Control Program Facility from the 38 that will also run System 36 System Support Program applications.
Kick their heels
Which suggests that mid-range users will have to kick their heels for a quarter or several if they want to participate in the brave new SAA world. Moreover RPG II and RPG III are not among the languages in the first list of SAA compilers, leading to more uncertainty in the mid-range. The AIX implementation of Unix Plus Plus will also be included, although, it appears, as something of an afterthought. SAA consists of four components: common applications, common user access, common programming interface and common communications support. After looking at IBM’s chaotic line-up of products, the first reaction to Systems Applications Architecture is if you want to get to there, I shouldn’t start from here. The second is why the hell didn’t the company think of it 15 years ago? The third is the nagging question – isn’t it much too late? IBM has been able to impose its will on the commercial data processing world for two decades is part because of its overwhelming market dominance, but also because everyone was more or less agreed on what they wanted to do and how they were going to seek to get there. Over the last 10 years, IBM has progressively tightened its grip on the mainframe marketplace as one after another its competitors admitted defeat and threw in the sponge, or retreated into niche markets. But SAA will seek to impose its uniformity on a world where the consensus is breaking down, where the whole concept of the large monolithic mainframe site is being called into question, and where few are certain of exactly what will take its place. Equally, the devastating couple of years endured by IBM have shaken the confidence of many users who previously voted the IBM ticket without question. If IBM can really stumble that badly at a time when the recessionary forces so often cited as the cause of its problems appear to have miraculously passed DEC by completely, could it really be that the emperor has no clothes?
John Friedline, manager of software marketing at IBM, has been trying to lay some of these nagging concerns to rest – at least in the context of SAA and its probable evolution. Historically, applications programmers developed vertical applications optimised for one piece of hardware and its operating system, database and communications capabilities, he says. As we move to the 1990s, this applications development approach will change, and programmers will write horizontal applications that span different architectures. To achieve this goal, IBM had to design an architecture to meet the needs of applications programmers. Also, applications programmers are a scarce resource, and we had to make them more productive. Third, communications protocols have to support systems that talk to one another as intelligent devices, not dumb terminals. Finally, we needed a set of guidelines to ensure that when users bought programs, they would perform consistently on different processors. Although Systems Network Architecture has long been intended as the glue that ties everything Blue together, communications functions are supported differently at each machine level. On a mainframe, they are supported by VTAM, says Friedline. Communications functions are
built into the System 36 and 38 operating systems; they are extensions to a Personal Computer’s operating system. Such differences will continue to exist. However, we will add high-level programming services on top of the communications services to provide such things as peer-to-peer programming support or co-operative processing support. So, an applications programmer will write to the high-level programming services, which in turn will call either VTAM services or extensions to a Personal Computer. Acknowledging that SNA Logical Unit 6.2 implementations vary from IBM system to IBM system, SAA, he says, will also define a standard LU6.2. Not only will SAA define a more consistent interface, but the interface will operate at a higher level than current interfaces, he promised. On the issue of what’s in and what’s not, Friedline explains that in March, we announced only Step 1 in a long journey. We only included those products that everyone agreed would be part of the architecture and that we knew could be implemented on all three types of systems within a reasonable length of time. Clearly, we must add other items to SAA for data support and distributed processing. We are working on how to include them in the architecture.
Be all and end all
Making it clear that SAA will never be the be-all and end-all of IBM applications, Friedline explains some of the limitations. Compromises are always a concern when developing an architecture that spans multiple systems. With SAA, we’ve tried to address items that can be implemented on all systems, but we’ve left room for extensions. In most cases, communications protocols can be implemented in a consistent fashion for all of our systems. However, we can’t take a 3090 and make it act like a Personal Computer. Also, IBM intends to enhance products that run only on high-end systems. With SAA, we are building a set of bars, and our systems will be brought up to meet those bars, rather than vice versa. We will make our Personal Computers operate faster and increase their memory addressing to bring them closer to large system capability. And what has IBM put in place to manage the epic journey to a bright new SAA future? More than a year ago, says Friedline, we added a new organisation to develop the architecture. A senior vice-president of programming is in charge of the group. Vice-presidents from various IBM divisions, called interface managers, are in charge of each of the four components. Forgotten what they are already? Once more then – common applications, common user access, common programming interface and common communications support. For example, the person in charge of end-user access is a vice-president in the Entry Systems Division making Personal Computers, and communications issues are handled by a Communications Products Division vice-president. They have final approval for SAA specifications and new products.