The 4GL entering decade No. 4 is becoming TransAction
By Alan Yeo
Actually, there can’t be a short history of Transact. Like the HP 3000, the language is now in its fourth decade of life. Even my exposure to Transact goes back more than 25 years.
Transact was hot when I first started working on the HP 3000 in the early 1980s. It was being pushed by HP as their Fourth Generation Language (4GL) for the 3000, with tight integration to IMAGE, VPlus and supported by a Data Dictionary — the last of which was also hot technology back then.
But HP had a habit of taking good software and applications, hyping them for a couple of years, then letting them slowly drown through lack of investment and development as something new came along. This often happened just as there seemed to be enough people using the older product to warrant the exact opposite approach.
The wonder product that made HP stop pushing the Rapid products was the Allbase database and a 4GL called TODAY. HP may have re-badged Today as Allbase/4GL. The 4GL portion was dead within a couple of years. Transact, already forgotten by HP, carried on in many sites for many years to come.
We developed some really beautiful applications using those Rapid products. For a couple of years I earned a good living consulting on Transact projects. Having a good understanding of Transact was one of the reasons that I became involved in the evolution.
In 2003, nearly two years after HP’s fateful 14th November 3000 announcement, I was attending an HP-hosted 3000 Migration Partner event in Germany. Until this time in the migration sphere, if anyone mentioned Transact, heads were shaken sadly and the only option offered was scrap it and re-write. So I was slightly surprised to see there was going to be a paper on a solution for Transact conversion from Enno Richter.
Richer’s company had written a successful RPG to COBOL conversion tool, and had been involved in RPG migrations and conversions for a couple of decades. With some encouragement from HP Germany he offered to start writing a Transact to COBOL converter. After all, if you can convert RPG how difficult could a procedural language be, especially one that at first glace looked a bit like COBOL?
Well, for those of us who knew Transact and all its wonderful “Push”, “Pop” stack manipulations, LEVELS, RETURN(n) and all the accumulating match criteria and data access verbs, our answer would have been “way too difficult.”
In Enno, I met someone who although knowing virtually nothing about Transact or the HP 3000, was genuine about having a go. So I spent some time trying to convince him it was impossible and explain all the insoluble problems I could see. I finally left with an offer to forward some Transact documentation and examples to explain why I didn’t think it could be done.
However, after leaving I realised that the notion of migrating Transact was rather like getting a call from your first true love after 20 years’ absence, asking for assistance. It’s something hard to ignore.
The more I dredged from my memory how we had used Transact, the more I became convinced that it was impossible to write a converter from Transact to COBOL. For many Transact programs I would defy another Transact programmer to even work out easily what was going on, let alone to write a converter that could do it. And then there was the data mapping and all those Offsets. Nope, impossible!
Hey. What if it was possible in COBOL to do the procedural, data access and display handling, but have it call a subroutine to emulate the clever Transact Stack Handling (which believe me is like nothing else on earth).
But who on earth would know if such a thing was possible? Who wrote Transact in the first place? Dave Dummer, who lives in Canada but would habitually holiday in the fall in the Cotswolds in England, not 30 miles from my offices.
I put Enno togther with Dave, and we all met up within a few weeks. We got out a sketchy agreement that it might be done and that we would work together on developing the concept.