NaturalONE 9.1.3
Are “command line” and “search” tools for Natural Server available on Natural One 9.1.3 ?
If yes, how can I find it? I can see it only on Natural 9.
NaturalONE defers its searching functionality to Eclipse, which is pretty good at it. Use the Search entry on the menu bar to get started. Within the editor view, use ctrl-f to find/replace.
Eclipse has no command line interface and NaturalONE is an Eclipse plug-in. Software AG has made it clear they will not provide such functionality in NaturalONE. There is an exception for those of you using a mainframe Natural server: Natural Command Console for Mainframes. It is limited in functionality, but may suit your needs. A previous thread touches on this. Next Prompt For more information click Help → Help Contents. Then search for mainframe console and open Using the Natural Command Console for Mainframes.
Thanks for you reply. I try to explain better:
CTRL+F works on local naturalOne project, not on Server Side ( NDV ). Our Server is linux based.
It means that I need the whole project ( in my case several thousands natural objects ) on my workspace and this is not viable.
You do not need to copy all your objects to your workspace. You need to work in “Natural server mode.” In the Natural Server view, highlight al the Natural libraries that you want to search.
From the context menu (right-click a selected library), select Create a New Project. This project will contain only temporary copies of source objects as they are edited, not the entire contents of the “real” library. But when you invoke a File search of your workspace, this project will cause the NDV server contents to be searched. Search results will appear in a new tab in the Properties view (bottom-right corner of your NaturalONE window).
While this does enable searching of those libraries, it still loads a copy of all the source objects on your disk in the project. The search is done locally, not in NDV. If any object is added/updated/deleted outside of the user’s NaturalONE project, the changes will not be reflected in the user’s project and the searches will not be complete.
Hi Douglas,
I haven’t experimented with this option myself yet, but I am wondering how well manual refreshes of the workspace perform. If they perform like the server view in which the refresh function only pulls in updates since the last refresh, this might still be a viable option for programmers who work in only a handful of Natural libraries……if their workspace size will accommodate the full source of all the libraries they work in.
The option to perform all work in the code developers IDE seems to be pretty attractive to code developers. And another pro in this method is getting scan cycles off the mainframe. The con, of course, is remembering to refresh.
Kathy Jackson
Natural Administrator/Mainframe Technical Support
Information Technology Division
Texas Comptroller of Public Accounts
Email: Kathy.Jackson@cpa.texas.gov
Work Phone: 512-463-4346
Thank you, Douglas. I stand corrected. Axt, I was mistaken and apologize for the misinformation.
I had searched my workspace for temporary sources and had found none. Hence my conclusion. After Douglas’ post, I re-executed the search and found therm in a temp sub-directory. Go figure.
So I have another reason to stay with Natural Studio (a component of Natural for Windows) rather than switch to ONE. I can perform server searches without copying entire FUSERs to my local environment.
A “refresh” of the workspace reloads it from disk, not the server. The only option I’ve seen for a “refresh” of the workspace from the server is to re-select those libraries and “add to existing project” again - which appears to overwrite existing objects in the existing project (no option to “skip all” - a C/E opportunity!).
I love working in NaturalONE compared to the green screen, but I will admit it has taken me a while to get all the way there! My “refresh” doesn’t have a lot of objects, but as the mainframe is across the pond, it does take a few minutes to do (~200 objects took about 3 min to load).
Hi Douglas,
Thanks for the updates on your tests of Ralph’s search/scan method. I have one programmer who is experimenting with it now. I’m off working on another long needed admin process. So I’ll defer to those of you who have attempted to find a valid search across all libraries function in ONE.
Another option is to use Natural Engineer to document Test and Prod environments and keep the Natural Engineer repository updated as new version of code get migrated into each of those environments. Then the searching/scanning could be done in Natural Engineer as well as other functions Natural Engineer offers.
OR….SAG Developers can add the Find function to the ‘User Libraries’ node such that a Find performed on that level searches all libraries in that server environment (or just those libraries the user has included in the applied filter….or perhaps give the user the choice to scan with or without the applied filter). I realize that search will still occur on the server, but it seems like a Find function should be allowed no matter where the current focus is set.
If choosing to Find as a right-click function on a server node, search in the server. If choosing to Find as a right-click function in a project in the Navigator, then search only in the objects included in the Project.
I’m sure there will be a lot of CE’s submitted once more SAG customers begin to use ONE. At a minimum, we all want to still have all the same features we had when working in the mainframe environment to edit code.
Hi,
here are my 2 cents.
NatOne has a difrerent view on the source code:
The one and only source of truth is the (git-) repository. It doesn’t matter which code is on the server. If it isn’t in the repository, it doesn’t matter.
That’s why you have to bring all sources in one or more repositories. You have to checkout this repository and all depending repositories to work.
If the repositories are very big, it is quite hard to work with them. Best way to split them up. Checkout only the repositories that are needed.
For different enviorments (test, prod) you can make different projects. Projects can be closed indiivtually, for better performance.
Another way is to build a workspace for each project. You can switch between the workspaces or start another NatOne instance.
To get better performance with NatOne I did:
I turn on the auto build and it works very good. The usage of the “Magic Bottom” is very rare.
NatOne has a hook on windows. If files are changed, its starts a refresh (and a build). It is working, but not as good as the auto build, but it works.
Working with NatOne is a mindshift. If you are not doing this, you will never be more productive as with the green screen editor.
Regards
Markus Wessjohann
Hi,
I realize other shops work quite differently than ours does. Since we are a Natural for DB2 shop, I’m sure we have other considerations than Natural for Adabas shops do. And since we are also a PAC shop, we have to consider the application development life cycle we have working very well already on our mainframe as we implement NaturalONE as our new code development IDE in an environment in which many developers all work on the same large mainframe applications and in which dual development on the same single Natural object may need to occur from time to time. I would imagine that shops which use N2O also have the same considerations to make.
These are the reasons we chose to implement NaturalONE first in server mode. In our shop, PAC is our one and only source of truth as far as the version of source that gets compiled and deployed to our Acceptance/QA Test and Production environments.
Developers check out the Production to start coding a new release for a module. They work on that checked out version in Development Natural and, when the changes are ready, they compile it back into PAC. PAC stows the object so as to keep a matching S/C (source and cataloged object) in its repository, and then deploys this new version to the Acceptance/QA Test environment for the business user to verify. While this new version is being developed and/or tested, another quick fix might need to be done to the version that is still in Production and that fix might need to go into Production before the new release that the business user is testing is ready. So the application life cycle must accommodate this. Our programmers use a Maintenance environment to perform quick fixes to Production code that must get deployed into Production before the “next release” code being tested by the business user is ready to be deployed to Production. They also communicate the “Maintenance fix/change” to the programmer responsible for the “next release” change to ensure the “Maintenance fix/change” gets incorporated into the “next release” version before the business user approves the next release getting deployed into Production.
Our programmers have been extremely productive used this application life cycle on the mainframe for many years. So introducing a new development IDE has to come with the fewest shifts to the way they are used to working until they learn the new IDE features and functions.
Where we struggle with introducing use of a git, or other, source versioning repository is how to map the git source versions to the PAC versions. Which git version number relates to the current Production PAC version and which git version number relates to the new release version which PAC just compiled and deployed to the Acceptance/QA Test environment?
PAC knows which compiled version in its repository is in each Natural runtime deployment environment. I’m not sure how git would know which git version has been deployed to each of our Natural deployment environments using the PAC compile and migrate process so that the programmers would know which git version to grab to start a “Maintenance change” as oppose to which git version to grab to start additional changes to the “Next release” version of the source.
PAC ensures that the same version it compiled and deployed to the Acceptance/QA Test environment and got tested by the business user is the exact same version deployed to Production. No new version is “compiled into Production”. The exact version that was tested is unloaded and loaded into the Production environments with no changes to the code and no recompiles when deploying the code into Production.
I am not seeing how to integrate the git repository, or any other repository, into the PAC code compile and migration application life cycle process on the mainframe. But if anyone has successfully done this in an environment in which many programmers all work on a large mainframe application together, I would love to hear how the entire application lifecycle has been architected.
Perhaps SAG Development can pull in the git (or other repository flavors) source version numbers into the source compiled and managed by PAC? Maybe then there might be a way for the programmer to know they are starting with the same source whose compiled version is currently being executed in Production when needing to introduce a small fix to the code, or know they are starting with the same source whose compiled version is currently being executed in the Acceptance/QA Test environment as the next release version when needing to add more changes to the next release version before the user confirms the next release they approve to be deployed into Production.
Even if this is done, if PAC is still in the architecture to compile the new version of source that contains the fix and place the new S/C (source/cataloged objects) into its repository, the programmer would still need to check that version out of PAC before migrating it back into PAC Control to get it compiled….at least in our current application life cycle.
Looking forward to more discussions on use of source versioning repositories such as git with NaturalONE. I always wanted to be a “professional student”, and working in IT, we all get to be just that. I love learning new ways to do things….as long as the new methods improve the end result and don’t degrade the end product.
This is my “ten cents”….a bit more than two cents I think. Lol.
Regards,
Kathy Jackson
Natural Administrator
Texas Comptroller of Public Accounts
(512) 463-4346
E-mail: Kathy.Jackson@CPA.TEXAS.GOV
z/OS 2.4 mainframe, DB2 V12
NAT911/NOC835/NSC911/NTI827/NDB842/NVS827
NCI834/CICS TS 5.4
NDV911/NaturalONE913 Fix#1/Software AG Designer 10.7
Natural Engineer 9.1
PRD851/PAC261/ADA852
EXX10.5(Broker Kernel in RedHat Linux 7.5 environment)
EXX10.3(ACI & RPC Servers in MF environment)
Hi,
Thank you for the insight, very good and an intressting.
I haven’t worked with PAC, so I can be wrong and maybe we should discuss this in a new thread 
I would stay at PAC. Your development process, your developer and maybe your auditing(?) department is building on this tool, so don’t leave it, but I want to show you some possibilities, when you add git in your development process.
Only add git in the development environment. The git repository should always exactly the same as the development environment. What I mean is: if all development stops, then you can switch to a new development server, just by changing the connection parameters in NatOne. This one is the hardest part.
Building the PAC-File etc works as before, but maybe you can add the PAC-File into the git repository as documentation or you can “tag” the git repository with a PAC-ID.
When you are tagging, you get a complete overview, which source went to the next stage. You can see the changed lines event 10 years afterwards, to reproduce bugs very helpful.
That are the basics.
The full power you get, if you can pull out the source code from the different stages into git. Maybe automatically after pushing a new PAC into the environment.
Then your developer have the possibility to compare the files in development with production (Yes, sometimes there are differences ;-). The developer can also checkout the complete production environment (Don’t do this, if you haven’t a seperate environment for this!!!) to find a bug in production.
We are using a Version Control System over 10 years and this very helpful to rewind a few years back. I can create the production environment 5 years before or I can tell you, which lines in which files I changed on 5.8.2015 and compare it to the current environment.
If you get used to this information, you can’t work without them. Sometimes it is preventing you from mistakes you made in the past 
I think you can introduce it everywhere, but not in the same way.
Regards
Markus Wessjohann
Hi,
I agree that I’ve strayed to another topic, so better in a new thread. Our Development environment has only the objects being worked on and steplibs to the Acceptance Test/QA environment and then to Production for used/called objects. So Searching for text strings AND using a source versioning repository other than PAC with NaturalONE will continue to be a question of exactly how to implement and keep mapped and in sync somehow with our mainframe application development life cycle.
But, I’d love to brainstorm with SAG Development for ideas on how to improve upon what we’ve already got working that could actually make the programmers more productive than they already are in our current application development life cycle. For the time being, working in server mode is working quite nicely. If we change, it would have to provide a benefit of something we can’t already do in server mode.
Regards,
Kathy Jackson
Natural Administrator
Texas Comptroller of Public Accounts
E-mail: Kathy.Jackson@CPA.TEXAS.GOV
z/OS 2.4 mainframe, DB2 V12
NAT911/NOC835/NSC911/NTI827/NDB842/NVS827
NCI834/CICS TS 5.4
NDV911/NaturalONE913 Fix#1/Software AG Designer 10.7
Natural Engineer 9.1
PRD851/PAC261/ADA852
EXX10.5(Broker Kernel in RedHat Linux 7.5 environment)
EXX10.3(ACI & RPC Servers in MF environment)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.