Subscribe by Email

Your email:

TIC Solutions

TIC Software Blog

Current Articles | RSS Feed RSS Feed

A 10 Minute Guide on "Going Native" on Nonstop - Part 1: COBOL

  
  
  

describe the image

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.

Advanced Preparation
  • 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.
Code Changes
  • 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, Part 2, we will discuss some of these pitfalls and gotchas in the TAL to pTAL conversion process.

Click here for Part 2: TAL to pTAL

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 (top right-hand corner of this page) to get automatic Email notification when a new blog is available.

describe the image 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 
   

describe the image

Comments

Hi, 
 
I am porting an application from TNS to TNS/R. The problem that I am facing is that the native objects are exceptionally large. I feel that it is due to the difference in which the NMCOBOL compiler treats SEARCH directive when compared to COBOL85. Secondly when I try to create a runnable object I am getting 2015 abend. 
 
Can you please give some pointers as to what am I doing wrong
Posted @ Friday, December 03, 2010 3:34 PM by Rahul
Hello. Yes, ?SEARCH works differently in NMCOBOL as NLD is used instead of BINSERV in COBOL85. While BINSERV only brings in the needed procedures, NLD links in the entire object file.  
 
What is the detail error message that came with the 2015 ABEND?
Posted @ Friday, December 03, 2010 3:58 PM by Phil Ly
Please find the actual error below 
 
**** ERROR **** [2015]: 
Cannot relocate a gp-relative reference to the data item named 
'ZZ301233$SB', because the target address is too far away from the 
value of the gp register, even though this data item is 'small' data, 
as it should be. The address of the data item is 0x8075354. This 
occurred for entry number 229915 in the relocation table for the .text 
section of the input object file named 
'\<NODE>.<FILENAME>', and the reference is at byte offset 
0x5ab724 within that section 
 
 
Please note that <FILENAME> is the file I intend to compile and ZZ301233 is an IO Module which is part of an on object file ZZ30120 which has 50 programs. 
Posted @ Sunday, December 05, 2010 9:10 AM by Rahul Burman
The error message basically tells you that you have run out of small data space probably because of the increased size of the object file.  
 
Here are a couple of suggestions: 
1. Create new, smaller I/O module.object files with only the modules that this COBOL calling program needs.  
2. Or move some of the data items to LARGEDATA.
Posted @ Monday, December 06, 2010 11:08 AM by Phil Ly
Comments have been closed for this article.