Just how easy and cost-effective is it to move from an IBM System/36 to an AS/400? The question seems particularly relevant in the wake of Computer Intelligence Inc’s October findings (CI No 1,042), which suggested that, at 33%, the largest proportion of 213 early AS/400 sites comprised ex-System/36 users. A $300m a-year US leasing company of our acquaintance reports that when it decided to replace its 50-terminal System/36 with a first day AS/400 Model 40, it found that the cost of the AS/400 software needed matched the substantial hardware costs. In addition, with the incorporation of the Distributed Data Management database, storage requirements soared to 1.5Gb on the AS/400 from some 200Mb on the System/36, while disk usage increased five-fold. It took the company until the end of October to transfer the original System/36 workload onto the new machine, delivered late in August. And once migration had been completed, it found that the response time at the terminals on the AS/400 was actually slower than it had been on the old System/36. Judging by a recent article in Computer Systems News, conversion disappointments of this kind are becoming commonplace amongst AS/400 pioneers within the System/36 user base. Thomas Marsh, a former System/36 user at the Vestal Central School District, New York is quoted as saying that, after four months of frustrated migration attempts, he wouldn’t convert again, while another ex-System/36 user, insistent upon remaining unidentified, concludes that, knowing what I now know, I’d stay in the System/36 world. Contributory causes cited include high user expectations, the relative inexperience of IBM field staff in handling migration problems, compatibility problems between AS/400 and System/36 peripherals, and a growing recognition that the AS/400 is designed first and foremost to act as a replacement for the System/38. Here in the UK, JBA International Plc’s Philip Hall, who recently presented a paper focussing on S/3X and AS/400 migration issues to the IBM Computer Users Association, agrees that the problems outlined above fit the bill of his customer-based experience. User pitfalls In addition to the extra memory and expertise required by the inclusion of the DDM database, Hall described locking and screen overlay differences as constant user pitfalls which often entailed some rewriting. A further frequently reported grievance is the AS/400’s inability to support a user-written Assembler subroutine. Hall also warned against inevitable price performance disappointments for customers attempting equivalent model moves. Price alone, he conceded, was a factor that might persuade a lot of smaller System/36 users to stay where they are. Only conversion time appears a less thorny issue in the UK, with an average, 500 – block – library – with – a – small – Ledger style site able to move over in two to three days – at worst a week. In-house, JBA claims that conversion to the AS/400 of 16 System/36-based software products took just 13 man-weeks of effort. Overall, claimed Hall, migration impressions are linked with profession. While reservations tend to stem from programmers and technicians, ease-of-use features have received a warm welcome from end-users. The benefits of moving over particularly the link into Systems Application Architecture – are enormous, but conversion should be a controlled and carefully planned business, he concluded. Since all the signs are that the majority of the System/38 user base appears to have already either ordered AS/400s or made up its mind to switch, while a substantially smaller proportion of System/36 have committed to the AS/400, the enormous demand for the AS/400 seen up to now may turn out to be a lot more shortlived than observers have assumed, and by about April, IBM may well have made all the easy sales, and find that it has to put a lot more effort into wooing the bulk of the System/36 base over to the machine.
