It is well-chronicled that when increasing density of integrated circuitry spawned the micro-computer, IBM tried to ignore it. When it launched its first unexciting 'PC', the product's mere appearance guaranteed the success of the already well-established 'PC' market. IBM's purpose with the PC was to ensure that in all three segments of the interconnected computing world, there was pressure to buy their product. The mainframe market was already predominantly IBM-dictated, SNA had established the communications framework, and the IBM-PC was intended to ensure the company's dominance at the network peripheries. The PC Division could afford to be a low-margin operation, provided it did not make significant losses, and ensured that buying decisions remained heavily biassed toward the blue alternative.

However, two things went very wrong with the plan. The first was that, although IBM quickly replaced CP/M-based 8-bit machines as the standard, the PC became, and the PS/2 is quickly becoming, a mere commodity. In a commodity market, entry is easy, prices stay down, and there is no prolonged period of protected market where high contribution margins enable R&D and market development costs to be amortised, and the 'cash cow' milked. There also tend to be unwelcome perturbations, as small operators carve out short-term local monopolies, and unstable competitors sell off stock at below their own cost price. On top of that, commoditisation prevented IBM from keeping more than half of the PC-compatible market.

The second problem for IBM was that the three-pronged attack was undermined by the maturation of the mini-computer. For some years now, the market has been been characterised by three levels (mainframe, mini or midrange, and connected device), connected by two levels of communications (wide-area and local area). In addition to a wide variety of output apparatus, the 'connected device' arena has moved beyond terminals and PCs to include workstations with more MIPS and storage, high-quality bit-mapped graphics, and high bandwidth to fast networks. Mainframe and mini have been joined by multi-user supermicros, and those architecture-based terms supplanted by more usefully descriptive ones like 'data-server' and 'process-server'. All this in just 5-7 years.

Although increasingly dominant in the large-processor marketplace (or at least in that large segment of it which is concerned with high transaction volumes), IBM has never successfully competed in the midrange. During the last decade, it has ceded the field to DEC's VAX range, and its competitors such as PRIME, HP and DG. Those conventional mini's have been joined by a host of Unix machines like Pyramid, with hardware architectures derived as much from the micro as the mini era, and some closely-coupled multi-processor machines like the Sequent.

The reason IBM has failed to protect its midriff is that when integrated circuitry spawned the 'mini-computer' at the close of the 1960's, IBM's mainstream spurned it. It was left to the Office Products Division, the guardians of the once-ubiquitous Selectric typewriter, to produce IBM's mini. The intriguing thing is that the System/3 of 1970, one of the blackest of IBM's black sheep, is the ancestor of the newly-announced AS/400 series.

'IBM's worst-kept secret', as the salesman delightedly called it, was announced on June 22 with worldwide flourish. At least, that was when it was announced to the great unwashed. Some 1500 user organisations around the world have apparently been enjoying ß-testing the machine, ensuring that the rest of us receive a substantially debugged machine.

This article is a review by a commentator with not a little bigotry and bias, and it is as well that that bias and bigotry be explicit. I have been a long-term critic of mainframes in general, and IBM's in particular. Of their human-unfriendliness, of their heavyhandedness, their ever-increasing layers of systems software and terminological complexity, and their insatiable appetite for support staff and for housekeeping MIPS.

I have also been a serious critic of the attempt to inflict the 370-series nightmare on the midrange via the 9370. I went on record soon after its release (Computing Australia, November 1986) that even if it were to prove attractive to large American corporations as a 'departmental processor', it was irrelevant to Australia's needs. The failure of the 9370 to penetrate the Australian market has shown that we agreed nearly unanimously on that point. On the other hand, I have been a long-term fan of the S/38, with its far more human face, and data administration and DBMS capabilities embedded in its Operating System. It is no darling of the computing science whizz, based on a mixed-up language as it is. But used properly, it can be very effective.

I have also been critical on occasions of IBM's manipulation of the marketplace (such as FUD to undermine competitors, 'no-one ever got fired for buying IBM' to encourage timid EDP managers, and visits to the Finance Director to undermine self-confident ones). Admittedly, at the same time I have been even more critical of IBM's competitors, for allowing it to become so dominant in computing matters, simply by following the essential tenets of the free-enterprise system with more conviction and more consistency than anyone else. The mostly negative pre-disposition I bring to matters IBMish should be borne in mind as you read these comments.

The first thing to be said about the AS/400 launch is that the company overloaded it with symbolism and cute entertainment. We were assured that the development team worked hard, because in Rochester, Minnesota (near the famous Silver Lake - geddit?) "it's so cold in winter it's more attractive to stay inside where it's warm". As if anyone would really believe that a serious product can be produced in a 4-month winter ...

And that other leaked code-name, Olympic, was worked to death with repeated images of such things as Britain's black decathlete, Daley Thompson, Pole-vaulting. (Was this meant to be a multi-dimensional appeal to the ethnic vote?). The electronic music was hackneyed, and the less said about Julie Anthony and Stingo singing to the same up-beat Coca-Cola Muzak music the better.

In between the entertainment, IBM'ers read their carefully prepared lines, and flashed past us the professionally prepared and carefully over-loaded visuals. These left us all bloated with semi-meaningless but obviously very important information, and duped us all into looking forward to the next entertainment slot.

So what can be discerned about this new wonder-drug. Is it a 370/115, 8100, PC/3270 or 9370, awaiting consignment to oblivion, or another 360 or SNA, about to take a vital place in IBM's and the whole industry's history?

The hardware design certainly seems impressive. For those who understand such things, the multi-processor design features IBM's own high-density memory chips using FET DRAM technology, VLSI logic using CMOS II technology, a 32-bit data path, and 48-bit addressing.

Six models have been announced, in two different casings, and bearing a remarkably coherent numbering system. (No doubt that aberration will be corrected shortly). Software is claimed to run without change on any model. The smallest model (9404 Model B10) is contained in a compact, under-the-desk cabinet, and is field-upgradeable to the second model. Unlike so many of IBM's 'entry point' configurations, it looks sufficiently useful that it might even get delivered. The four larger models (comprising the 9406) use multiple buses, and are mounted in between one and five cabinets, each the size of a four-drawer filing cabinet.

Power requirements are only the standard 240-volt supply for the two smaller models, and single-phase 240-volts for the larger models. An office environment (i.e. mediocre air-conditioning) is good enough, although the presenter suggested that many organisations may wish to place the machine in its own room for "security reasons" (like not wanting to drown the workers in halon gas every time the smoke-detector catches out the naughty person having a puff behind the partition?).

Only 15 minutes are required to install and bring up an AS/400, because no system generation is required, and configuration is automated. In other words, the hitherto standard IBM 'feature' of having to close down the service in order to reconfigure I/O devices is no more. Better still, the machine appears to be able to examine its own innards and limbs, and prepare and run its own configuration procedures.

So IBM computers have finally caught up with networks, which have been doing the same for some time! To stop being sarcastic, this is a very important forward step, particularly in a country of predominantly small businesses like Australia. For more complex circumstances, the tables of defaults are externally visible to, and modifiable by, the system administrator.

The range of power between the top and bottom of the range is claimed to be a factor of 50, but this claim is very confused and confusing. It could be based on the argument that between 4 and 200 active users can be supported (assuming you accept the company's assertion that the smallest model, at c.$65000 for a workable configuration, is cost-effective for four users). Yet elsewhere the company claims that the 50-fold performance difference applies only to the four models of the upper (9406) range.

If it were based on the more reasonable criterion of claimed performance when running the RAMP-C benchmark, the performance span would be only about 7.5. But then the factor is a rotten measure anyway, open as it is to manipulation. It is far more preferable to understand and use the RAMP-C benchmark, measured in IBM's traditional 'number of active commercial users', or the equivalent, and I think more readily understood 'transactions per minute' (see Figure 1).

The disks are 630MB or 945MB 5-1/4 inch spindles on the 9404 models, and 855MB drives on the 9406's. Channel speed for the 855MB drive is 3MB/sec, but no indication of access speed was given for either device. Support for most existing S/3X terminals, printers and disk-drives protects much of the user-base's existing investment.

On IBM's assumptions, the AS/400 provides an effective entry point at around or below the bottom end of the existing S/36 range, and a (current) upper end overlapping into the 3081 range. The B50 is marginally more powerful than the current S/38 top-of-the-line Model 700, and the B60 offers 70% more on top of that, which should stave off the most processor-limited users' capacity problems for a while at least.

The future of the existing midrange machines is unclear. The S/36 Model 5363 has been enhanced at the same time as the AS/400 release. It is marginally less powerful than the new AS/400 entry-level product, the 9404 Model B10. However, nothing has been said about the Series 1, PC-RT, 51XX, 8100, S/23, S/32, S/34, S/38 and the other models of the S/36. The 9370 and 4300 are also considered by IBM to be part of their midrange offering.

Naturally in a tightly controlled launch, the last thing that you get to do is use the thing. But just to prove I can quibble with the best of them, the fan noise emanating from the Model B30 10 yards from me, was starting to get annoying by the end of the session. To be fair, if I was sitting doing nothing but stare at an audience for an hour-and-a-half, I might get cantankerous too.

                            ----  9404  ----	---  9406  --------
				B10	B20	B30	B40	B50	B60
Active Commercial Users
     (IBM RAMP-C)		28	40	53	80	119	200
Trans. per min.		105	150	199	300	446	750
Equivalently powered
     S/36 models		5363	5360D	-	-	-	-
     S/38 models		38/100	38/200	38/300	38/600	38/700	-

Memory (MB)			4-8	4-16	4-36	8-40	16-48	32-96
Max. Disk (GB)		1	1	7	7	13	27
Comms Lines			1-8	1-8	2-16	2-32	2-32	2-32
Local Workstations		40	40	120	200	320	480
Token Rings			0-1	0-1	0-2	0-2	0-2	0-2

The presentation claimed that their S/3X user base of 300,000 worldwide and 3,000 in Australia had told IBM that their most crucial requirements were ready-made applications, and ease of migration of existing custom-built software. It is therefore appropriate to discuss these matters before embarking on a Cook's tour of the product.

To satisfy the need for packaged application software, IBM has worked with its associated software houses ('business partners' in current parlance), and claims to have 250 packages available at launch (including 20 Australian products converted at its North Sydney premises in May and June), with a further 450 planned by the end of the year.

For its own part, IBM has announced a version of its own financial system IMAS, with some modules available 3Q'88 and others in 1Q'89. It has also promised OS/400 Office. Or has it delivered OS/400 Office? The language has been so debased by salesmen (not just from IBM) that I tend to be sceptical about the word "is". Office offers/will offer Displaywriter-based WP, and multiple language dictionaries and proof-reading aids. It also includes mail, personal (and also shared?) calendar, personal directory facilities, and access to electronic document distribution facilities based on DCA/DIA and (later?) SNADS. The existing menu-driven Query product, intended only for casual users, has been enhanced.

The existing PC Support product is also available on the AS/400, enabling data interchange between midrange and micro, and use by the PC of the AS/400's disk storage much as if it were a directly attached disk. Menus on the PC can offer a mix of processes, some of which will run on the PC and others on the host to which it is attached, without the user being aware of any difference (other than perhaps response time). It is not clear whether processes on some other server on a local or wide-area network will be able to be similarly invoked (what IBM refers to as Display Station Pass-through). As always, a conservative assumption is appropriate until and unless a clear statement is made.

The extent of the support for graphics is limited at this stage to the generation of business presentation graphics and their incorporation in text documents. The machine is claimed to have the capacity to later support 64-bit addressing and thereby enable some kinds of image processing in the future. Many organisations are moving beyond mere presentation graphics, to use general-purpose diagramming tools, CASE and image storage and management. CAD/CAM and its ilk need not run on the same machine as an organisation's commercial and administrative applications, but high organisational effectiveness and productivity demand seamless interchange of data, whatever its form.

The ease of migration of existing software was of course what made the impressive list of packages possible. My long-standing prediction had been that the new series would involve VM as host operating system, with a variety of possible guest operating systems, especially S/36 and S/38 emulations, a native operating system designed to migrate S/3X toward 370-series operating systems, an OS/2 emulation, superset or companion, and a promise of restricted VSE, AIX and/or MVS versions.

Long-term I may not have been so far from the mark, but at face value I was wrong. There are three alternative modes of operation, or 'operational environments', one native and one each for the two existing S/3X lines. It is not stated what the pedigree of the native mode is, but it seems to be more like a descendant of the S/38's CPF with some VM features than son-of-VM.

IBM has accumulated experience both overseas and in Australia in migrating S/36 and S/38 applications, and migration aids are available. It would appear that S/38 applications which were even moderately cleanly implemented should move to the AS/400 very easily indeed. S/36 applications should move with far less heartburn and cost that used to be attendant upon such activities (e.g. to the S/38). Physical transfer may use any of several alternative media. The smaller and/or older installations in particular will encounter some difficulties or expense in this regard.

The efficiency of the non-native modes is unclear so far, but the industry has learnt much in the last twenty years about emulation of old instruction-sets, and the physical machine is now powerful enough to support multiple logical machines (dare I call it 'virtual architecture'). So if the right elements are in micro-code, the efficiency penalty for running old applications should be quite bearable. No data was provided at the launch, but the trailblazers will doubtless learn quite soon.

S/36 applications require preparation and re-compilation. S/38 applications are (mostly) a case of save and restore, from which it is reasonable to infer that the AS/400 is object-code-compatible with the S/38, not only for processing code, but also for CL procedures, data schemas and screen and print formats. One very positive aspect is that an application may use functions from any of the three operating environments. Existing applications may therefore be progressively migrated, rather than having to be converted in a single project. In short, IBM has taken great care to provide a support framework for its existing client-base.

It is impossible to consider any strategic IBM product without carefully relating it to Systems Applications Architecture (SAA), announced in March 1987. SAA promises a set of consistent environments in each of the OS/2, OS/400 and VM/MVS environments. Judging by the lack of action until now, most of us sceptics have felt justified in anticipating the delivery of SAA-compliant environments around the turn of the century.

Well, the shape of SAA was one of the factors which had convinced me that the new machine would be VM-based. SAA, as originally announced, and for 15 months little modified, did not feel like a S/3X environment. Of course, this could have been a classic case of IBM throwing the opposition a red herring. On the other hand, the June 22 presentation include the words "We've added RPG to SAA - we've been listening to you". So perhaps they just changed their minds.

So now, SAA's Common Programmer Interface is to include RPG (and also its Common Communications System is to include the S/38 DDM). However, "SAA RPG is [i.e. will be?] based largely on the IBM RPG III language implemented on the IBM System/38", which means that it will not be entirely compatible with any existing RPG. Significantly, IBM is converting its own IMAS into S/38 RPG III, not directly into the new native code.

Intriguingly, the presentation claimed that the AS/400 is the first system "to fully meet [the SAA] standard". Now ISO OSI never claimed it was a standard, merely a framework, within which a set of (international, multi-organisational) standards could be conceived and developed. SAA is similar in that it is not in any sense a standard, but an umbrella for a set of standards (although in this case international, single-supplier). Yes, perhaps a few of the components of SAA are well-specified and standard products (it's very hard to tell, given the vagueness of the March 1987 documents). But most of the commitments in SAA are to be "based on" products like REXX, CSP, SQL and GDDM, rather than being those products. And the standards will not be a 'set' until they have all been revised or re-developed to comply with common user, programming, communications and data interfaces. In short, the 'product' still falls far short of the rhetoric.

I continue to applaud SAA as a statement of direction, and consider that many of the right products have been chosen as the basis for future development. But I continue to criticise its close-endedness and its vagueness on many key points, and am not going to hold my breath awaiting specification of the components, or delivery of compliant products.

Meanwhile, announcements of convenience, like the incorporation of 'RPG' and DDM, make clear that SAA is a purely marketing notion, intended to give the company's wide range of disparate products an appearance of familial relationships, but entirely lacking the enormous insight and technical contribution of SNA.

A feature which was very prominent in the launch was the machine's sub-second response time. Interestingly, the detailed graphs suggest that the machine has been optimised to deliver precisely that across a wide range of load, but to then degrade dramatically. The steep degradation curve is presumably a result of the multi-processor architecture. Image-swapping seems less likely, since all code is reentrant.

Personally, I remain unconvinced that 'sub-second response' is actually a critical feature. Too-prompt responses startle any but the most skilled and quick-thinking computer-whizz, and hinder organisational productivity as much as they help it. I interpret this new buzz-phrase as another brilliant piece of marketing communications, of the same order of brilliance as James Martin's completely unhelpful yet seemingly all-encompassing concept of 'backlogs'.

What is actually needed is consistently quick response, say of the order of 1.5 to 2 seconds from transmit to receive, with near-instantaneous screen-fill. Only a dummy like me would try to communicate such a complicated idea - IBM calls it 'sub-second response', and everyone says yes! yes! yes!, and buys. Maybe that's why I'm in an ivory tower and they're in business.

At the marketing level this 'sub-second response' feature is clearly intended to attack the known problems of minicomputer architectures which degrade more gradually, but all too noticeably. This has been particularly apparent with DEC's VAXen, whose ever-growing VMS has chewed up ever-increasing amounts of processor and real memory, and actually decreased any given machine's responsiveness under constant load.

The features discussed so far have been abstract constructs, and now it's time to look under the bonnet. The Operating System is presented as 'a fully integrated set of services'. Now that has a certain appeal, in the sense that I would like to ignore what's under the bonnet. Most of the time. But an external description of the OS architecture remains important. One problem I set myself was to assess the extent to which third party tools (particularly 4GLs) and locally developed utilities (e.g. security menu systems, and directory management systems) are usable under OS/400, and so far it's not easy.

The words 'fully integrated' can also mean 'closed system' or 'closed shop', and for medium-sized organisations who have significant D.P. competence, and depend on it to ensure that their I.T. investment supports their competitive advantage, a closed system may not be as attractive as an open-ended VMS, Unix or PRIMOS system.

In particular, the claim was made that "a truly relational DBMS" is in the hardware, and SQL is within the OS. Anyone who has studied Codd's works knows that 'truly relational' is a phrase used casually only be salesmen, never by database specialists. I am happy to go out on a limb and assert that the last word in DBMS is a long way away (I'd even say why, but this article is already too long).

The launch documents also made the all too common mistake of using the term 'relational' to apply to the physical level of data storage. All of the relational concepts apply at the logical levels of shared organisational model and application views. What physical techniques are used to map the relations onto a physical storage device (silicon, magnetic disk, optical disk, or anything else), are another matter entirely.

As regards SQL, I am on record as being highly critical of its design, particularly as an end-user tool (Computing Australia, 2 June 1986). It is increasingly seen as a reasonable-enough 'deep language'. Front-end query products designed to support particular kinds of users in performing particular kinds of work could usefully generate SQL as intermediate code.

IBM now appears to concur with the view that its use as a query language is secondary. Its overview of AS/400 SQL refers to interactive use of SQL only after describing the use of 'embedded SQL'. Embedded SQL enables programmers to access data maintained by an SQL-driven database. It was an accident, not a design-objective, and yet it has become the normal data access mechanism in IBM's mainframe DBMS DB2 and SQL/DS, and is now to become the norm on the midrange machines as well.

We have therefore experienced the comical sequence of events of a language designed for interactive query failing that task, but gravitating into the data-handling sub-set of a professional's programming language. On the positive side, at least a trained programmer using embedded SQL is less likely to fall foul of the language's traps than is mere end-user applying it interactively.

But where does this leave the question of hardware and microcode implementation of relational DBMS and SQL? IBM says that "machine performance and resources can be optimised by implementing function within the layer in which it operates most efficiently". This sounds like classic computer scientists' sub-optimisation. Commitment of a feature too deeply creates inflexibility which will inevitably affect supplier, 'business partners' and user organisations alike. Choosing what to embed and what to keep flexible is the real techno-business skill in midrange machine design. We don't yet know whether IBM has chosen well for themselves and the rest of us. But I am happy to assert that a contemporary DBMS and SQL embedded in silicon are liabilities rather than assets.

A further reservation about the AS/400's data management is that it is unclear whether a database specified using a conventional S/36 or S/38 data definition facility will be accessible using either interactive or embedded SQL.

Another concern is the extent to which standalone OS/400's are able to cooperate as components of a distributed operating system, and hence support distributed database management. It has been stated that SAA Distributed Relational Data is planned for a future release, i.e. is not yet available. Distributed Data Management (DDM) appears to be applicable only within peer-to-peer networks (i.e. among AS/400's and S/36's, with a few additional midrange and low-range machines like the S/38 as end-nodes). In any case, will that much be available at release date? And when will mainframe operating systems and OS/2 be able to collaborate?

I must admit that, when it comes to connecting amongst the vast range of IBM machines, I try to say very little and leave it to the specialists. At this stage, I am happy to accept IBM's claims, that the AS/400 range provides 'connectivity without complexity', with only the usual measure of salt. The communications lines support bisynch, asynch, X.25 (possibly - it is mentioned in some places but not in others) and SNA protocols at up to 64Kbps. The language of computing sales reaches new lows with the assurance that an "integrated Token Ring adapter may be fitted ..." - if it's integrated, surely it doesn't need to be fitted!

Properly configured, the machine will clearly function not only stand-alone, but also as a host for local networks (at least of PC- and PS/2-compatibles). It is explicitly stated that "an AS/400 can be installed in an existing S/36 and/or S/38 network without impacting on that network".

As a node within a S/370-based SNA network, an AS/400 can support 3270 sessions, including CICS, either on 5250 terminals by emulation, or on 3270's attached to it via a 3174 or 3274 controller. S/370 RJE is available, and using RSCS/PROFS bridge, mail and file interchange among AS/400 and S/370 users is possible.

On the other hand, the extent and nature of the AS/400's current compatibility with non-IBM terminals and PCs (particularly standalone Macintoshes), with existing corporate SNA networks (particularly those including non-IBM nodes), with Appletalk- and Ethernet-networked Macintoshes, and with workstations (such as Apollo, DEC VAXstations, IBM-PC/RT, MacII and Sun) should not be blithely assumed.

At what I refer to as the Access Level, OS/400 supports traditional tailorable menus with mnemonic fastpath, and formatted screens. In addition, a 'natural language help' system is available, presumably in addition to an unnamed but conventional command language.

Nothing was said about direct support for WIMP interfaces, suggesting that users of terminals, PCs and workstations will continue to have very different working environments for some time yet. However, there was an interesting comment that "multi-tasking on PCs is to be supported from OS/400", suggesting that individual users may be able to make more effective use of multi-tasking, as they can on mainstream minicomputer command languages. The now ritual promise was made that voice input was coming "real soon now".

In the still-vital area of development and maintenance productivity, the machine promises an "interactive programming and testing environment with interactive symbolic debug and formatted dump". That was where the minicomputer manufacturers were about 1982. The name of the game now is CASE - 'life-cycle support products' which are as useful to the analyst and designer as the programmer.

CASE is often represented as auto-diagramming and data cataloguing for analysts and designers, with some syntax and completeness tests thrown in for good measure, and the promise of auto-generation of schemas and processing code if not yet, then "real soon now". But a mature CASE product must be built around much more than a data dictionary, what I refer to as a full-scale 'meta-data manager'.

Many years ago, the S/38 made a big advance similar to that which Dick Pick made, by embedding DBMS and Data Dictionary primitives in the Operating System. Unfortunately there is no sign that the AS/400 has matured beyond these mid-1970's insights. A mere data element catalogue, or a central record register, is not a Data Dictionary. To have a genuine Data Dictionary, you must support both logical and physical definitions for both active elements (functions and processes) and static elements (entities, relations and attributes; and data items, records/screens/print formats, and files/datasets); and where-used queries must be answerable for all such elements. It is not yet clear to me whether the AS/400 Data Dictionary supports the full functionality which was specified as long ago as the early 1970's.

It is also unclear from the announcement what support is provided for managing the large number of forms and versions of the large number of components (process source and object, data schema source and object, I/O formats, compilation and execution OCL/CL procedures, etc) that make up an application, and software pre-requisites such as systems subroutine libraries and OS utilities. Configuration management has become a well-defined discipline, and is a mandatory for U.S. DOD tenders. The AS/400 ADT (Application Development Tool) PDM (Programming Development Manager) appears to provide only a very rudimentary capability.

What native command language is currently available is unclear, since the SAA procedures language, based on the VM product REXX, is not planned to be available for some time yet. On the positive side, it was stated that all users have command-language transparency available to them, enabling for example printer queue inspection and manipulation without having to exit from the current task.

The full-screen editor incorporates some line-oriented commands, and a split-screen capability to enable display of other documents. The editor is also to support syntax-checking "through interfaces to language syntax checkers". I infer from this that the editor contains the necessary hooks to allow future syntax checking, but none is actually delivered yet. Perhaps I'm being unduly bloody-minded, but on the basis of past performance, such scepticism is more often justified than not. Syntax-aware editors are quickly becoming the norm in the minicomputer world.

Other application development tools are a data file utility, a screen design aid and a printer configuration utility. This set of tools, posturing under the grand title of Application Development Environment (ADE) seems to fall far short of a Programming Support Environment of the late 1970's, let alone a Computer-Aided Software Engineering Environment of the early 1990's.

The AS/400 Office software is claimed to be capable of integration with application software. Hopefully this would enable such capabilities as debtors systems sending decreasingly polite reminders to slow payers, on company letterhead, with names, addresses and salutations auto-merged. Another heartening feature was that the presentation expressly referred to portability not only of software, but also of 'programming talent', at last reflecting a facet of application software technology that some of us have been emphasising since at least the beginning of the decade.

Probably the silliest re-announcement in the package is that the "software architecture relieves the programmer of the job of managing main storage or auxiliary storage". Perhaps I'm getting older, and/or the copy-writers are getting younger, but I did believe that we got that out of the applications programmer's hair a long, long time ago. Or is IBM admitting that it had fallen years behind the rest of the market, and that the physical location and nature of program and data storage has until now remained a programmer problem, rather than one for the system administrator? Now that would be uncharacteristic frankness!

Alternatively, the writer may have been trying to explain the system's 'object-oriented single-level storage'. In one sense that's hardly new for IBM machines, since directory hierarchies were available for years on minicomputers before IBM (and other mainframers) caught up. Now the vogue is once again to store all components in a large flat space. The computer scientists will love it.

But many commercial developers feel comfortable about their object's names having suffixes which reflect the types of objects (source, executable, compile-procedure, execute-procedure, etc) that they are, especially since their tools automatically seek out the file with the appropriate suffix (e.g. the compile-procedure adds the appropriate suffix to the file-name the developer provides). Given that the time of programmers and designers is our scarcest commodity, I have yet to be convinced that imposing a heavy naming discipline on developers, which is what a flat space implies, is the right objective.

The SAA languages which the AS/400 "will initially support" (does that mean "at release date" or not??) are the new RPG, a mere subset of mere Intermediate ANSI'85 COBOL, and a mere subset of ANS/IBM SQL. Non-SAA languages will be Pascal, BASIC, and, surprisingly, the dying PL/1. C is planned, and so is an extended version of the 370-series 4GL CSP, and its run-time interpreter. There is considerable ambiguity about just what is available and when. Embedded SQL appears not to be available for Pascal, BASIC or C. All in all, the programming language offering is not terribly exciting for any dyed-in-the-wool software engineer, nor for a boss wanting clever things done. DEC's home territory, the mixed scientific/technical/commercial/administrative installation, may be under threat from Unix, but it certainly isn't from the AS/400.

Suppliers of development products, such as the Australian Lamda from Aspect and the British Synon from Strategic Computing, will be immediately usable in the emulated environments. Their developers should not take long to deliver versions running in and for OS/400's native operating environment. They are therefore likely to be in the AS/400 marketplace with 4GLs long before IBM itself. IBM's record in 4GLs is uniformly poor, and user organisations would do well to assess the presently available third-party products, rather than await salvation by an IBM product.

On the positive side, subprogram calls are linked by 'dynamic binding', from which I infer that preparing and running a procedure, with appropriate parameters embedded or passed to it, to link the compiled images together, is a thing of the past. Good riddance, say we all. It also appears that subprograms may be written in any language which the machine supports.

The launch presentation included a claim that the S/38 was already so productive that Expo's 220-device machine had been programmed by "one manager and four permanent staff". That left some of us sceptics pondering how many contractors had been employed for how long. Meanwhile, one particular member of the audience was pondering why IBM had failed to mention that the software had been developed using his Australian-developed 4GL, Lamda.

Another standard supplier ploy has been to continually re-announce the 'don't call us, we'll call you' approach to machine maintenance. We have heard for well over a decade that engineers are expensive, and that the machine should self-diagnose, and order its own spare parts and the maintenance call at the same time.

What we hear this time is more convincing, because the AS/400's Electronic Customer Support uses a line adapter, modem and communications software which are incorporated in the base machine (bundled even!), and a 008 (local call fee only) number is provided. When the maintenance organisation budgets for these items, I start believing in the service! However, users should avoid getting too excited about how cheap the service will be until the full facts are made known. It is reasonable to assume that some portions of the service, probably crucial ones, will involve user costs.

The first element of the service is that on-line queries can be made into an on-site database, and into national and international IBM databases containing AS/400 announcements and technical bulletins, and perhaps later also information about approved third party products. This seems to be tantamount to saying 'if you can't find your copy of the relevant manual, please access our copy before you interrupt our support desk'. Which may be no bad thing, from either party's viewpoint.

In addition, screen images may be displayed on a second workstation, local or remote, to facilitate problem-solving. Mail can be exchanged with the support organisation. However, electronic Incident or Fault Reporting appears to be part of an optional additional (and presumably charged) service, along the lines of the RETAIN system operated for its S/370 clientele.

Another feature which deserves attention is System-Delivered Education (SDE). This comprises tutorial software, dealing with introductory topics, conceptual material and operational education, some including exercises. These tutorials (cutely referred to as a 'built-in classroom') are said to be callable from any point within a live application, enabling a user to suspend their productive work while they learn the next step. Ah, the benefits of multi-tasking.

In addition, context-sensitive help is provided, together with a documentation indexing system which supports synonyms. The authoring software is available to IBM customers to create their own courseware.

With more than 10% of the working population now using computers, effective 'interactive documentation' is now a vital requirement of all populist systems. If the tutorial material for OS/400 and IBM's own applications is of sufficiently high quality, and the authoring software more approachable than conventional products, then highly desirable pressure will be brought to bear on third party software suppliers to themselves install the authoring software, and invest in the full range of documentation their users need.

So to sum it all up, was the excessive symbolism and cute entertainment at the AS/400 launch really necessary? No, sir. IBM have a well-designed product which preserves the S/38's advantages, catches up with competitors in some areas where their previous products were deficient, and even gets ahead in a few areas. It has deferred the product's announcement until it is very close to being deliverable, and it has provided marketing documentation, which although occasionally evasive, is of good quality and more readily accessible than usual.

The several serious debits noted above must be weighed against the advantages. In some market segments, I would expect the AS/400 to make no headway whatsoever. In others my first impression is that it will be very competitive.

IBM were at pains to stress the cost-competitiveness of their previous midrange offerings, quoting an independent survey which showed their 5-year 'costs of ownership' to be at least comparable to other suppliers, and in most cases at least marginally better. The effective prices of AS/400's (the company is at pains to stress that list price is not necessarily final price) are awaited with interest. Certainly if IBM is able to be cost-competitive with Unix suppliers, we will see a most interesting head-on clash between software engineering- and business-oriented thinking.

IBM's previous attempts to address the midrange have been either half-hearted or poorly conceived. The AS/400 provides S/34 and S/36 users with an escape path into proper midrange computing, and S/38 users a growth path and some very worthwhile product improvements. For non-IBM users, the AS/400 represents a genuine competitor with DEC and the other midrange CHAPS*, particularly in some market segments. And in the long term, it is conceivable that the AS/400 could be the 360 of the 1990's, sweeping even MVS, VM and AIX from the field. But maybe not until early next century ...

* With apologies to Wang, Pyramid, DG, Tandem and a number of others, CHAPS is of course Convergent, HP, Astra, Prime and Sequent.

Go to Roger's Home Page.

Go to the contents-page for this segment.

Send an email to Roger

Last Amended: 15 October 1995

These community service pages are a joint offering of the Australian National University (which provides the infrastructure), and Roger Clarke (who provides the content).