By Alan Yeo
Second of two parts
By the time we had our team of developers assembled to take a crack at giving Transact new life, we had a dilemma. WE had to refining our stakes under project deadlines
The realisation dawned on us just how difficult this all was, and I suspect for some of us walking away would have been the best solution. But by late Spring the following year the design had been refined and we had the prototype working. We were on a roll, and whilst it wasn’t full time for any of us, it kept progressing
This is where fate, coincidence or luck struck several times in quick succession. HP Germany upped the stakes by announcing that they knew several companies were starting to offer to convert Transact by various means, so they were going to issue a challenge to those companies. The competing companies would then do their conversions and submit them to HP. The company with the best solution would be endorsed by HP Germany and get access to the Transact user base in Europe.
We now knew we had potential competitors for the Transact market. With true marketing zeal we announced our solution and grab the attention high ground. So we went public with the product, which by now had a name T2C (Transact to COBOL).
However, reality has a habit of smacking you in the face. We took the HP Sample application, and we were dead in the water. Its not that we couldn’t convert it, we could and 75% of it was good. The unfortunate thing with programs is that even if 75 percent of the code is perfect, if you can’t execute through the bits that aren’t good, and get to the bits that are, you haven’t got a program. What you have is a pile of code. We didn’t submit the results back to HP.
But neither did anyone else. Someone had submitted some code, but obviously nearly all hand-written code. Not a migration solution, merely a willingness to undertake re-coding work.
The stakes were now higher, and we had announced a product in good faith. Others were going for the same tiny niche. So we redoubled our efforts to finish the solution fast. This was when fate struck again, backed up in parallel by some severe technical problems.
A very large potential customer needed a Transact Solution. Developing something speculatively with the thought there may be opportunities in the future is well and good. It’s completely different kettle of fish when there is a prospect of earning a crust. This was a Big Project, for a Big Customer, headed by a Big Computer Corporation, being done by a Big Migration Company. Big Opportunity, if the Pilot Project was successful.
At this time there were people who knew Transact. There were people who knew COBOL, there were a few who knew both — and only a couple of people in the world who understood the concept of mapping one on top of the other.
We were fortunate to introduce another player into the story, Roy Brown. Roy was one of the few people in the world who had also spent many years learning and hacking Transact, and even more years doing the same with COBOL. He joined the pilot project team to assist, and he and I spent furious months brainstorming with Dave about how to tackle and solve the serious problems.
We learnt a lot about the things that had never been documented about Transact. Roy even reconstructed the complete Transact Manual from the incomplete and incorrect fragments available from HP.
More than that, we got inventive with COBOL. We exploited every known technique and construct to try and get it do the necessary. We even found bugs or undocumented features that we could verify existed in all the main COBOLs to replicate within its procedural logic Transact’s ability to dynamically fly back (n) levels of perform from a given point, where (n) could be a dynamic value.
The project was completed on-time — and I understand on-budget. The core Transact Function Library just kept getting richer and more complete. We had got the basic design right.
The first site went live in 2006, followed by a rollout to dozens of sites over the following months. A year and only two minor bugs later we regard that solution as stable.
So given a stable working solution converting Transact to COBOL using a Transact Function Library, why on earth would anyone continue and do a source code replacement for Transact?
Well. On the technical side there were some issues that we weren’t completely happy with. To maintain the resultant code you had to understand the generated COBOL and the Transact syntax of the functions you were calling. Or if you wanted to continue developing in Transact rather than COBOL, the process was dependent on a COBOL generator. And this could fail if the Transact was amended to use different combinations of options. Whereas if we had a Compiler and a replacement for the Data Dictionary, the Transact Function Library could continue to be expanded to handle all Transact syntax. It also seemed a shame to let such a brilliant language die with the HP 3000.
From a migration perspective how much neater it would be to just pick up the Transact code and move it, and to continue to develop and or maintain the code exactly as it was before. Which meant it could be a solution for those customers that only had a few Transact programs, or didn’t or couldn’t afford the time and cost that a major conversion project costs.