Native compilers on the Nonstop have been available for a long time. Yet, are you still running non-native COBOL programs limited by 128K in data space? Have you not been able to take advantage of the new tools like the PC-based cross compilers because you are not writing native mode programs? If so, you are not alone. You are probably like a lot of NonStop users out there, who still have not fully converted over to Native Mode yet.
Why is that the case? The first reason is probably that you, like many others, have been really busy with other more pressing matters, such as: trying to meet another project deadline or fighting production fires. The other reason may be that you are just not quite sure how to start. You may have questions like: What do I need to do? How difficult is it? Where can I find more information, etc.?
We at TIC Software have worked with many NonStop users in converting their programs to native mode. In this article series, I will share with you some quick pointers on how to get started. In this Part 1 installment, the discussion will focus on COBOL.
- Native requires Common Run-time Environment (CRE), so make sure you have the latest CRE/RTL software.
- Installing Native COBOL requires a cold load afterwards.
Compiler Directive Changes
- You will need to remove some directives like ?LIBRARY, ?HIGHPIN, ?ENV COMMON, etc.
- Native mode does not support the ?NOTRAP2 directive so if you depend on that for allowing a divide by 0 yield a 0 result, you will need to work on that.
- The behavior of the ?BLANK directive is exactly opposite for non-native. COBOL85 puts blanks in uninitialized fields; Native Mode COBOL does not!
- Add ?RUNNABLE if it is a runnable object. Default is NO.
- Replace Procedures as GETSTARTUPTEXT or GETPARAMTEXT with the SMU equivalent, SMU_STARTUP_GETTEXT_ or SMU_PARAM_GETTEXT
- SQL directive must be removed and stated instead in the Native COMPILE directive startup text
- Instead of using ?BLANK to initialize ALL the data fields to blank, you may choose to add code to initialize the fields that are needed to make the program execute more efficiently.
- Remove references of COBOLLIB, CLUBLIB, etc. No longer needed.
- Substitute COBOLEX0 with NMCOBEX0.
- If you have been moving Alphanumeric field to Numeric fields in your COBOL programs, you will find that Native Mode doesn’t allow you to do that. Fortunately, it is only a minor change by using the FUNCTION NUMVAL to do the same thing.
Other useful information
- Read COBOL Manual chapter on: “Migrating TNS Programs to Native Programs”
- There is a NMCOBOL ?DIAGNOSE-85 directive that’s helpful in pointing out differences
This list is by no means complete, but should cover a large part of what you need to do to convert your COBOL programs to native mode. In general, you should be able to convert a COBOL program to native mode in a matter of hours. Of course, thorough testing is critical to validate that the converted programs are indeed working correctly.
But… did I mention that this is the EASY part? Really!
If you are like most NonStop users, you probably also have a library of COBOL and/or TAL utility routines that your COBOL programs call to do lower level functions. Those TAL routines will need to be converted to pTAL before your COBOL calling program can be fully converted to native mode! There lies the bigger challenge: the conversion from TAL to pTAL. While most of it is quite straightforward, there can be some bumps along the way. In our next installment, we will discuss some of these pitfalls and gotchas in the TAL to pTAL conversion process.
Feedback pleaseDo 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 (top right-hand corner of this page) to get automatic email notification when a new blog is available.
Phil Ly is the president and founder of TIC Software, a New York-based company specializing in software and services that integrate NonStop with the latest technologies, including Web Services, .NET and Java. Prior to founding TIC in 1983, Phil worked for Tandem Computer in technical support and software development.