Natural 9 and the 3270 interface


Which mainframe Natural version is the last version that supports the 3270 interface ?

I believe that is Natural 827


Hi Anton,

It’s only the Natural editor functions that do not work under the 3270 environment in versions 9.1.1 and higher. All other Natural 3270 functionality works in all versions of Natural (e.g., runtime, commands, etc.). Editor work under v9.1.1+ must be done in NaturalONE, and you are correct that v8.2.7 is the highest version of Natural that allows you to do all editing in a 3270 session.



Hi Anton,

Possibly one correction will be needed to what I just said. According to the roadmap for ADABAS/Natural on z/OS, there is a version 8.2.8 of Natural that is slated to be released in April 2021 (same time as Natural v9.1.2 will be released). I am guessing with that version numbering scheme that v8.2.8 will also support 3270-based editing.



My understanding is that the editor is shipped with 9.1.x, but your license key will prevent its use. This applies to Natural mainframe and LUW. My Natural Studio (i.e. Windows) license allows editing but my Linux license does not.

I don’t think it will be included with 9.2. Until then, the theory is that you can get the character editor with some level of pleading, sobbing, blood letting, and an offspring or two. But I wouldn’t bet on it.


I have heard that, also. Basically if your CIO is willing to sign a letter saying he/she knows that you’re choosing to do the wrong thing (along with the pleading, sobbing, blood letting, and offspring part) and keep using the 3270-based editors under Natural 9.1, you may get a key or a zap that restores them.

In my way of thinking, if you’re going to do that, stay on 8.2.7 or 8.2.8 when it is released. Only go to 9.x if you’re ready to go to NaturalONE. The end-of-support date for 8.2.8 should give you enough time to prepare for this. No excuses! :slight_smile:


Or eliminate three-quarters of the learning curve of Natural for AJAX (aka NaturalONE) and implement Natural Studio (aka Natural for Windows) as the editor instead.

Natural for AJAX (NJX) and ONE are two pairs of shoes.

You can still use the built-in NJX Application Designer when you dislike the ONE Layout painter :wink:

Sorry for the long response, but “losing the 3270 editor in mainframe Natural” is a HUGE deal for experienced Natural programmers and so they will understandably drag their heals to convert to using NaturalONE (ONE) simply because it is a significant change to how they are used to editing Natural modules.

In our shop, we Natural Administrators and one programmer started implementing NaturalONE (ONE) in 2011, because we were interested in the RPC Service Development functions available in the Software AG Designer toolset, but, at that time, ONE still had some issues with supporting editing of some of our Natural for DB2 code.

So, we’ve worked with SAG’s ONE developers in Germany since 2011, reporting code editing issues and getting a lot of fixes delivered, installed and tested. Once we were on a certain fix level of ONE V8, we got that release level installed, configured and tested on a few more programmers’ laptops for a final review to determine it was ready to be used by all Natural programmers in our shop.

We wanted to deploy this release out to all of our programmers so they could “start” the learning curve of working in ONE’s Eclipse environment, which was foreign to most programmers who were used to working in a 3270 environment, and, because we were still on Natural V8.2.7 on our mainframe, the programmers could jump back into the mainframe 3270 editor if they ran across any new issues in which ONE could not handle the code editing of a particular Natural for DB2 program, etc.

To get our programmers started on using ONE, we established some SYSPARM profiles that made it very easy to map to the various mainframe Natural environments in ONE’s server view, and then we created the necessary install images and scripts and worked with a Desktop support team who uses a software install tool to push out client software to the masses.

When we sent information to our Natural programmers about installing and using ONE, we included a chart of server mappings with the appropriate SYSPARM profile for them to use to establish connection from their ONE client to each of the mainframe Natural environments they will work in.

We also highly recommended, to everyone, the use of filters in ONE so users would have better performance since the Server view rendering will essentially perform a LIST ALL for each object type, and a LIST ALL with filters defined performs MUCH better than a simple default LIST ALL.

We also documented some tech notes on what the programmers needed to do to configure their ONE client to work in Server mode, such as setting preferences like “Read from Server” and ensuring the mainframe SYSSEC defined Steplibs were being used. These notes helped them to eliminate the red X’s they would see while editing Natural source in the ONE editors.

If you give the programmers enough information for them to establish a ONE editing environment that actually works for them in a more problem-free manner, they are more likely to hop in and start learning to maintain Natural code using ONE.

After many months of our programmers “having the opportunity to start working in ONE”, and several months before we were scheduled to upgrade to ONE 9.1.1 and mainframe Natural V9, we informed our programmers that when we upgrade to Natural 9, the mainframe batch and CICS Natural environments would no longer have the 3270 editor enabled, so those programmers who had not already started editing Natural code from ONE, had better start using it before they lose the 3270 editor in the mainframe environments.

However, we did request and receive from SAG a license key to enable the 3270 editor in Natural V9, due to having a few Natural modules for which ONE was still not able to properly maintain the code. However, we made a conscious decision to install the “3270 editor enabling” license key ONLY in our mainframe Natural/TSO environment as a back door to allow programmers to edit source that still will not correctly edit using the ONE editor.

Well……word travels fast and all the programmers now know that we do have that “back door”, so you can imagine how many might be tempted to simply always used the back door since it provides an editor with which they are used to maintaining their Natural code.

So….we also informed the programmers that we will be running reports to identify who is still editing Natural source using the 3270 editor instead of from ONE. At some time in the future, we will be more actively working with all programmers’ managers to progress to a point in which no one shows up on the “still editing Natural code using the 3270 editor” report.

You can determine who is still editing code from a Natural environment that has the 3270 editor still enabled by performing a LIST DIRECTORY (L D) command on any Natural object. The transaction name will tell you from which environment this version was SAVEd/CATaloged.

When editing from ONE via an NDV server using the CICS adapter, the transaction name listed in the Directory of an object will be NRFE (the Natural CICS remote front-end module NDV passes all edit commands to for processing code edit transactions). If editing from ONE via a batch NDV server, the transaction name listed in the Directory will be your NDV batch nucleus name. If editing from a Natural TSO session (a.k.a. “the back door”), the transaction name will be the Natural TSO environment’s nucleus name.

We also informed our programmers that they must have an open support ticket in our local incident management software in order to justify editing a particular Natural source object using the “back door” (i.e. the editor in the 3270 environment) once we actually upgraded to Natural V9. We “should” have an open support incident with SAG for any objects the programmers are still editing via the 3270 editor, because they should only be editing via 3270 editor when ONE cannot successfully edit that module.

Finally, when we get close to upgrading to Natural V9.2, we will start running the “whose editing via the 3270 editor” report more often and will start a more aggressive enforcement of getting everyone to use only ONE for editing all Natural code. We are not yet at that point because we still have a couple of open support incidents with SAG, but we hope to get to that point before we upgrade to Natural V9.2.

1 Like