An application modernisation project by the IT wing of a big British builder saved its AS/400 from an untimely demise.
GrahamSystems is the IT arm of John Graham (Dromore) Ltd, a multi-faceted operator in Northern Ireland in construction and facilities management. The group has a turnover of over £266 million and more than 1000 employees. Its IT unit, based at its headquarters in Hillsborough, County Down, also provides services to a manufacturer in the region.
GrahamSystems looks after a large collection of business applications that have been developed in-house over decades, mostly in RPG. The applications, such as purchasing, sales, nominal ledger, accounts and payroll, are used throughout the John Graham group and its customers. Many have their origins in the days of the System 36 and its predecessors. The applications were running on a model 170, staff were beginning to baulk at green screen interfaces and management was talking seriously about a Microsoft alternative.
Senior systems developer Frank Doherty says: "We had a 170 and we were on 5.2 and basically the company had said that they wanted to move off it. A lot of the new QSs [quantity surveyors] and a lot of other people coming in weren’t used to the green screen. And once you saw the green screen, it looked as if it was on an ancient machine. All of our applications were on green screen and we basically wanted to improve them."
To say GrahamSystems' two-man development team embarked on a thorough search for an answer to their problem would be an understatement. From Big Blue itself, they looked firstly at good old Net.Data.
"It was OK, but IBM weren’t continuing any work on it so it was totally limited. We got IBM in but with our 170 we couldn’t do anything. We couldn’t run HATS. They said: 'Your next path is HATS but to do that you need to invest x amount of thousands to buy a new machine'. So HATS couldn’t run. We couldn’t run WebSphere. With the process of learning WebSphere and Java at the time, it was too much of an investment for two people to continue maintaining and developing applications and go away and learn all of that as well."
In the meantime, Doherty had developed a purchase order application using Visual Basic in a .Net environment. Its MS Access-type combo boxes, drop-down boxes and colour interface only increased the pressure to move off the i. What's more, the company favoured a move to SQL Server linking with SharePoint Portal and Services. As something of a Microsoft specialist himself, Doherty could see that this would be an expensive, let alone time-consuming option.
Having rejected ASP, screen scraper or Visual Basic using ODBC connector approaches, the developers investigated third-party tools before deciding on IceBreak distributed in the UK by Bedford-based SpaceTec. With IceBreak, they could still develop applications in RPG and COBOL and VB and JavaScript could be built into HTML pages for integration with Microsoft Office. Integration with one of SpaceTec's other offerings, InterForm, could handle forms as PDFs and save on the costs of printouts. Response times from the 170 were acceptable.
IceBreak did, however, require some knowledge of HTML and JavaScript. "Initially it’s hard, but once you get into it it’s so much easier because you’ve got total control of your RPG and the other stuff and you just learn," says Doherty.
As an example of how IceBreak works, he says: "I’m just re-doing one of our sub-contract payment entry screens and some of our files are the old fixed-length lines, 80 characters long, well some of them a bit longer than that but you used to have a fixed length and then you’d program-describe all your files – I’m using all of them in it. I haven’t even changed those files, they’ll sit and they’ll work in the old green screen applications which use them and then they’ll just fall into the IceBreak ones as well, which is another thing which we thought was very, good."
"Some of the screen scrapers that we’d looked at required us to change all of our old RPG II files, the old fixed record length – the old record length of 80 characters and you’d populate it whatever way you want, as long as the program knows what it’s looking for. It would have required all of those to be changed into RPG III files, the ones with the file-field descriptions. But IceBreak didn’t. You just use it as a program-described file and away you go."
The result? Happier users and applications that could be rolled out via web browser to more of them. So much so, in fact, that another member was added to the development team and the 170 replaced by a new model 525 that was upgraded to i OS 6.1 over the summer.