Home The Company Publications Products Links Tips

Tips, Tricks, and Techniques

Is NATURAL 4.1.2 Stable?

Last update: 30 April 2004

Eric Schwartz reported on SAG-L on 30 April 2004

I have upgraded three of my customers to Natural V412 in the last couple of months. (That is test and production environments.) We are an IBM z/OS shop. We have a very small system which uses CICS/Natural, but most of our work is done thru Complete/Natural. We have had a few bumps in the road, but for the most part it has been fairly painless.

One of my customers upgraded their "DBA play" region to V412, a couple of weeks later they upgraded production and two weeks later they upgraded their two test regions. The thinking here was that V316 test routines could be migrated to a V412 production environment. But of course, V412 test routines could "not" be migrated to a V316 production environment. This particular customer did a CATALL on some of their applications.

For another customer, we ran parallel V316 and V412 systems on test and production for two weeks starting on Feb 01. The test system default was V412. The production default remained at V316. Both V316 and V412 code was migrated to the production database. At the end of this two weeks, production V316 access was removed and V412 was the *only* available version of Natural on the production database. All of the Natural V412 fixes that were available thru Feb 01 were applied to the test and production systems. This particular customer did a "STOW ALL" on *all* of their applications. This customer averages 650K transactions (enter keys) a day.

Here are some of the SAG-related issues/problems (and solutions) we have run across....

  1. Complete COMROLL0022 errors. These errors were caused by DELETE=OFF and RELO=OFF being set. A quick fix for this problem was to set DELETE=ON and RELO=ON. These are the setting we used when we went into production. SAG has released NP62019 for these problems and we have applied the is fix. However, we have not changed the DELETE/RELO parms back yet.

  2. "NAT0082 Invalid Command" invoking CMPGMSET. CMPGMSET is a callable routine which will invoke a non-Natural program at Natural termination time. Apparently under V412 CMPGMSET require the SYSEXT/USR4001N routine. We copied the SYSEXT/ USR4001N routine to the FUSER/SYSTEM library. This corrected the NAT0082 errors.

  3. Construct error "NAT0082 USC1057N 0780 Module name does not exist". If you are a Construct shop *and* you are starting off with brand new FNAT files, you'll have to invoke the Construct CVUSRCOP routine in order to copy the appropriate SYSEXT/USRnnnn routines to SYSLIBS and FNAT/SYSTEM.

  4. Batch jobs getting NAT0954/S0C4 on WRITE statement. I believe fixes NA62075, NA62101 and NA62126 fixed this NAT0954/S0C4 problem.

  5. "NAT3022 Invalid command IS. NAT3403 ADAMODE was changed from 2 to 0." We use the default ADAMODE=2 in batch. Prefetch/multi-fetch processing do not allow ADAMODE=2. As the message states, Natural V412 will automatically change ADAMODE from 2 to 0. We have not made any kind of parameter changes (locally or globally) to avoid this error message. Our production control people are basically ignoring the message.

  6. "NAT1147 Illegal use of DISPLAY GIVING SYSTEM FUNCTIONS". We got this message on PGMB if PGMA had SET CONTROL 'ENTR', FETCH 'PGMB' and PGMB had SET CONTROL 'ENTR'. This was fixed by NA62125.

  7. MAP SCALAR issue. When inserting an array field from an LDA into a MAP, typing ".a" to define the array caused the error "Do not apply .A command to a scalar value." This issue is unresolved. Our current work-around is to add the fields in a V316 environment and copy them back to a V412 environment. Natural V412 IUPD2 addressed part of the problem, however, if you page down the problem re-occurs.

  8. Complete/Natural U9999 errors in *UDUMP. Some Complete/Natural abends would generate 16 or 17 dumps on the Complete SD file. These recursive abends have been corrected by NA62159.

  9. NAT4611 in MAP ARRAY. This relates to dynamic parameters in a MAP. Defining an array causes the variable name to be replaced by numbers, giving the NAT4611 error. Fixed by NA62169.

  10. S0C1 in ULOG. I forget the details on this one and I am not even sure if it was related to Natural V412 or not. Nonetheless, I'd recommend being at Complete V621 PL05 and Complete APS271 PL05.

  11. Double spacing on Complete batch print. Some of our Natural output that was routed to a Complete servicing batch request was double spacing the output. This occurred when LS was defined > 133. NP62027 fixes these problems.

  12. NAT1320 MAP problem. This error was caused by the use of a variable as the upper bounds of an array in an LDA when the LDA was called in the MAP. This problem has been fixed by Natural V412 IUPD3.

  13. Printing a variable on line38/colum68 generates garbage. NA62157 fixes these problems.

  14. NAT4626 MAP error. When a field in a LDA is an ADABAS field and the name is > 24 characters long, inserting the field into a MAP rom the LDA produces the error. This log is still open.
Software AG had promised a CPU savings for Natural V412. ('Course they never said how much.)

Along these lines... Our V316 environment was basically Turbo, DELETE=OFF and RELO=OFF. We realized significant CPU saving from these parameters settings. Our V412 environment is Turbo (by default), DELETE=ON and RELO=ON. Even with these settings we realized a CPU savings of 6% to 8%. Please note all routines were CATALLed. I am hoping that DELETE=OFF and RELO=OFF will save us some more CPU time when we re-implement these settings.

Since we upgraded SAG has come out with V412 recommended fixes, NAT412 IUPD3 and NSC412 IUPD3.

The outstanding question is "would we do it again"?? My answer would be yes! We really did not encounter any problems that would be of the "show stopper" variety.

That's all........

Eric Schwartz