NAT0082 when called from EntireX

, ,
1

(Bear with me, first EntireX project, so I may not ask or supply all the expected information)

Current running system has been in production for years. Web application that calls a mainframe
Natural program to store some data in a legacy system.
I’ve been tasked to store the Comments field from the web app on the mainframe also.
(i.e. a simple addition of a parameter in the mainframe app and web app, or so I thought)

I’ve added the comments parameter to the mainframe application and tested it successfully with
a small stub program that performed a CALLNAT with test data parameters.

I’ve modified the web app (Java), and used a debugger to verify my changes are appearing in the parameters
passed to the broker.

I verified that I didn’t “break” the current system by processing a record in the updated web app WITHOUT any data in the comments field.
The data was passed properly to the mainframe and stored as expected.
(here is the mainframe broker log file showing success)

********** *USER: @LGSCBT *LIBRARY-ID: SYSRPC
B *** Return from listen at 2014-03-17 10:44:28
FUNCTION: L RC: 0 SERVER: LIS024
00000000 Successful response
CID : 0000000000000002 CUID: @LGSCBT
REC-LEN : 429 BUFF-LEN: 28672
M *** Logon executed to library LISPROD for user @LGSCBT
M *** Convert to intern
M *** Execute callnat… LGI867 at 10:44:28
M *** Back from execute callnat LGI867 at 10:44:28
M *** Convert to extern
M *** Ready for reply to LGI867 at 10:44:28
********** *USER: @LGSCBT *LIBRARY-ID: LISPROD
B *** Reply sent for LGI867 at 10:44:28
FUNCTION: R RC: 0 SERVER: LIS024
SEND-LEN: 567

I then entered some data for the comments to test my changes and I get a NAT0082 error
in the broker portion running on the mainframe.
(here is the mainframe broker log)

********** *USER: @LGSCBT *LIBRARY-ID: SYSRPC
B *** Return from listen at 2014-03-17 10:42:28
FUNCTION: L RC: 0 SERVER: LIS024
00000000 Successful response
CID : 0000000000000001 CUID: @LGSCBT
REC-LEN : 429 BUFF-LEN: 28672
M NAT00082 3792 NAT3009 Last transaction backed out of database 24. Subcode 3
M .
M *** Ready for reply to LGI867 at 10:42:30
********** *USER: @LGSCBT *LIBRARY-ID: SYSRPC
B *** Reply sent for LGI867 at 10:42:30
FUNCTION: R RC: 0 SERVER: LIS024
00000000 Successful response
CID : 0000000000000001 CUID: @LGSCBT
SEND-LEN: 330

The mainframe broker never converts or passes the data onto my mainframe application (LGI867).
There is no line number 3792 in LGI867, and I can’t find (or don’t have access) to the broker source
to see the code on line number 3792.

I’m sure I’ve left out some data that will be helpful to diagnose my issue, and will supply anything that will help.

Thanks in advance. (sorry if this is something simple, but I’ve spent the last few days searching this site and Google for any answers.)

Roy King

2

For me the odd thing here is the 3009 subcode 3 - which is a timeout.
I would start by taking a close look at the logic you have added.
Finn

3

Finn, Thanks for the quick reply.

I’m assuming you are referring to the logic added to the mainframe program that’s received the COMMENT parameter and processes it.

Truthfully it couldn’t have been simpler.
I added 2 lines to the program…

#COMMENT (A50) (in the parameter list)
ASSIGN COMMENTS (3700) = #COMMENTS (in the program body to store the data in a legacy table)

My comments at the top of the program explaining the change take up more room than the code!

(FYI - after a little more digging I found the TRACE parameter for the mainframe broker. I will change the value from a 1 to a 2 and see if I get any more info in the log.)

Thanks again,
Roy

4

Roy, the problem is caused by an Adabas timeout on the FSEC.
You have two options to avoid this timeout:

  1. activate the Natural RPC exit NATRPC39 for the DBID 24 (the DBID on which the FSEC is located)
  2. use SYSSEC to set the “Close all Databases” option in the Session Parameters of the LISPROD library profile to F
    Wolfgang
5

Wolfgang, Thanks for the feedback.
I will have to communicate this to our Adabas System Admin. and have him look over it.
I will let you know of the results.

FYI - changing the TRACE option from ‘1’ to ‘2’ didn’t result in any more data in the mainframe log, so no new clues.

Thanks,
Roy