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....

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.

"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.

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.

"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.

"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.

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.

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.

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.

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.

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.

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.

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.