Hi

We have an interesting problem and it doesn’t occur all the time.

We make a Natural call via EntireX and at times we get a Broker 1014:1500. The work file name is unique for the session. It will work for a bit and then all of a sudden it will through this error.

What also happens after that is that when we call other programs after that we get a 1014:1586 or in some cases even a 1014:0082.
To solve the issue we then need to stop and start the server and it will continue for a day or two possibly three and then it will happen again and then the cycle continues.
The three modules in question comes from different applications; however all three sets the codepage encoding to setCharacterEncoding(“windows-1252”) and our Natural environment uses ISO-8859-01. All the modules in question doesn’t use the ON ERROR statement;
Another application that also uses the windows-1252 encoding, but has its own dedicated server doesn’t give issues. The server in question above is being used by multiple applications.

Some of the reading on the forums suggested that the “Environment” get “lost” somehow and one needs to “reset” it the original NatParm.

Obviously on asking the programmers what has changed - the answer is the normal - “…nothing has changed - this module has been running for years”

The 1014:1586 problem we to get from time to time for years now, but can’t seem to find a solution. Basically in these cases a natural run time error occurs and we then send the error to LPT31 which is a file output when the server runs in RPC or batch mode. These modules uses the ON ERROR and within this statement we send the error output to PR31=31.

Just some back ground:

1. Our RPC servers is not started up in BATCH MODE; which I see in the latest documentation is strongly suggested.
2. AUTORPC=ON; this is used as we do have Java routines that needs to be executed in some cases.
3. We don’t have Natural Security
4. I’ve tried implementing NATRPC01 and NATRPC02 on our DEV environment to see if I can catch the error to get more information, but this doesn’t seem to work.
5. We run Natural on Solaris
6. All calls are done the same way e.g:
   Stl086n3 nat4 = new Stl086n3(new Broker(Utils.getEtbIp(request.getServerName()), “JavaUser”), “RPC/SRV1/CALLNAT”);
   We did find in same cases we had to change the “JavaUser” to be more unique per call.

Regards
Werner van Tonder
Senior Analyst Programmer
Stellenbosch University, South Africa

Just wild guessing…

Could it be that the script used for starting the RPC-server has some error-handling that will restart the RPC-server - but perhaps starts it with another PARM=XXX where the workfile and printer is differently defined ?

Finn

Hi,
It seems like a Natural errors (in an RPC environment) so you should look what the nat1500 and nat1586 error messages suggests –
In the knowledge base I found this, for example :
Description:
A NAT1586 ‘Unable to submit print job’ is received on a WRITE statement.

Resolution:
After changing the Device Assignment, under Natural Execution Configuration in the Natural profile parameters, from previous value awk {print>>“$LOGS/diags.log”} to just the file name, including the environment variable, the error was resolved.

I would advise to see which work file or print file is being assigned in the Natparm or in the Natural script, and verify if it fits the requirement of all cases that this RPC Server should supply.

Sagi

Haha if it was like that…

All the scripts that are used to start the different servers is all the same - only with different NATPARM settings to indicated the server.

natural parm=RPC4NT$DBID udb=$DBID etid=$$ trace=1 >> /export/home/sag/natrpc/logs/$NATTRACE &

The work files are defined using one of the USR2* routines.

I thought at one point that the directory on UNIX where the files are written two perhaps gets its permission reset temporary for the *USER or the *USER are being reset to some other user. This is one of the reasons given when you look at the explanations for a NAT1500 or NAT1586 - all about permissions, but how is it even possible if that is indeed the case.

As per RPC suggestions the device setups for LPT10 and LPT31 are set to output to a file:

LPT10: /bin/sh -c cat>>/export/home/sag/natrpc/logs/$RPCTRACE
LPT31: /bin/sh -c cat>>/export/home/sag/natrpc/logs/$CMPRT31

These variables are being setup in the startup scripts of each RPC server before the server is started:

export RPCTRACE=EXX_$$.trace
export CMPRT31=EXX_$$.cmprt31
export NATTRACE=NAT_$DBID_$$.trace

So yea - it boggles the mind.

The problem is mots probablyl caused by the use of simulated batch.
1)
Define your LP10 and LPT31 as a file
2)
Start Natural in real batch mode by specifying the startup parameter batchmode:
natural batchmode parm=
In this case you must define CMPRINT, CMSYNIN, CMOBJIN .

Thank you Wolfgang.
That was one of my next steps in our DEVELOPMENT area to see if we don’t get any unexpected errors and then try it in PRODUCTION as it is difficult to simulate the problem in DEV.