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.
#CONNX#Mainframe-Integration#webMethods