A 10 Minute Guide on “Going Native” on Nonstop – Part 2: TAL to pTAL
Updated: Mar 26
In Part 1 of this series, I have provided some quick pointers on how to convert COBOL85 programs to native mode COBOL. I also pointed out that if the COBOL program calls routines in a TAL library, those routines will need to be converted to pTAL. In general, converting TAL code to pTAL code is pretty straightforward, and the process is well documented in the manual “pTAL Conversion Guide ” (Part Number 527302). A large part of the conversion process is pure methodical work by following the manual:
Replace TAL syntax with pTAL syntax
Compile and look for errors
Correct errors
Repeat until no more errors
But I also mentioned that there are some potential gotcha’s in migrating TAL to pTAL. The main reason is: unlike COBOL, TAL code is more flexible and allows programmers to write clever code for more efficiency. But that presents potential compatibility challenges when migrating to native mode.
Three Axioms
Here are my axioms on TAL to pTAL conversion potential pitfalls:
1. The level of difficulty of the conversion is proportional to the age of the code
The older the code, the more potential there is for hidden problems. If the TAL library code was written a long time ago, then chances are the developers who wrote that original code may no longer be available. In some cases, you may not fully aware of what the code is doing. That makes it difficult to analyze the effect of the conversion.
2. Be prepared to rewrite routines that contain “clever code”
In the old days, it was not uncommon for clever TAL programmers to develop code that exploited the hardware architecture to save some memory or make it run faster, such as:
Accessing the stack marker directly, i.e. G, L, S registers
Using the CODE statement to execute instructions
Building parameter masks for calls
These clever codes present an incompatibility in the pTAL world and will need to be rewritten.
3. You may need to find replacements for library code not written in-house
Does your library contain code from outside sources like ITUGLIB or Tandem Unsupported utility routines? If so, you may need to look for replacements for them. One common example we came across is the TAL “FORMAT^PRINT” routine that many of us have been using since our TAL training class. Guess what? It contains CODE statements in there!
Conversion Strategy
Here are a couple of practical pointers on what you should do when undertaking such a conversion effort:
Prepare in advance
Most of us developers (myself included) have a tendency to want to jump right in, and start our conversion work right away. However, in this case, I strongly recommend against doing that. Instead, doing some advanced preparation up front will make the job a whole lot easier later on.
Identify what really needs to be converted.
Which TAL routines are actually being used?
Which ones are obsolete?
This can be done by as simple as a scan operation like:
Using the utility “LOCATE” on NonStop
Running GREP or a simple PERL script on the PC
Running PROCESSH analysis on NonStop to determine exactly what routines are being used in production, if you are the really, really techie type
Look for the “clever code” culprits
Once you have identified a list of the TAL routines that need to be converted, scan through them again to look for incompatible code that will need to be rewritten and put them in a separate pile to be analyzed later.
Things to consider in this pile include:
Is there any new built-in function that can replace this routine? Some of those old functions may already be deprecated.
Will it be easier to rewrite this in C instead of pTAL? Remember: now you can run mixed languages in CRE.
Consider investing in developing a utility/script If you have a lot of routines that need to be converted, you should consider developing a TACL macro or a PC script to automate many of the straightforward replacements.
Develop Test Programs
We all know that testing is a critical part of the verifying the converted code is working properly. Resist the temptation to take the short cut by just using the calling COBOL program as a testing tool. Why? Firstly, stepping through the calling COBOL program to debug a library routine issue can be a tedious and time-consuming process because you will need to wade through the business logic of the calling program. Secondly, just because it works for one COBOL program doesn’t necessarily mean the converted routine is fully tested.
It is better to invest in developing standalone programs to test each one of those routines independently. That’s the best way to ensure that indeed the converted routine is working properly. By verifying the routines are working properly up front will save you a lot of time later on.
What’s next?
If you are also using User Library with your COBOL programs, then you would want to read my next installment of this series. In Part 3, I will discuss how to migrate from “User Library and BINSERV” to the brave, new native mode world of “DLL and eld.”
Read more Blogs
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don’t forget, you can subscribe to our blogs to get automatic email notification when a new blog is available.
Phil Ly is the president of TIC Software, a leading provider of software and services for the NonStop community focused on NonStop application modernization. Under Phil's guidance, TIC Software has a proven track record of helping clients seamlessly integrate NonStop with next-generation technologies. A recognized technical leader, Phil is passionate about empowering organizations to unlock the full potential and longevity of their NonStop platform through innovative solutions.