I got a NAT6226 and searched for the error for over an hour.
It seems to me that this error only occurs if a RETRY happens just after a REINPUT *9999. A REINPUT ‘text’ works.
Now I’m interested, if anyone can reproduce that error.
Please try the following.
Start this program to hold a single record:
define data local
01 view-name view of ddm-name
02 ab
01 #isn (P10) init <1> /* ISN to hold
end-define
get view-name #isn
update
input
'Record with ISN' #isn (AD=OZ)
'is now in hold.' /
'Please run the other Program now.' //
'Press ENTER to cancel.'
backout transaction
end
Then start another Natural-Session and run the following program. Press the key-sequence
PF1 - ENTER - PF2 - ENTER - PF3 - ENTER
and see, if you get a NAT6226.
define data local
01 view-name view of ddm-name
02 ab
*
01 #isn (P10) init <1> /* ISN to hold
01 #info (A4) init <'TEST'>
01 #cv (C) init <(AD=N)>
01 #visible (L) init <FALSE>
end-define
*
ON ERROR
IF *ERROR = 3145
set key all
input
'NAT3145' /
'-------' /
'PF1 = reinput "text"' /
'PF2 = reinput full "text"' /
'PF3 = reinput *0001' /
'PF4 = reinput full *0001' /
'ENTR = RETRY' /
'PF12 = Exit'
*
decide on first value of *PF-KEY
value 'PF1' reinput 'text'
value 'PF2' reinput full 'text'
value 'PF3' reinput *0001
value 'PF4' reinput full *0001
value 'ENTR' retry
*
none value
backout transaction
escape routine
end-decide
END-IF
END-ERROR
*
get view-name #isn
update
input 'Please start the other program first' /
'to produce a NAT3145' #isn (AD=O)
backout transaction
*
end
With NAT6.1.1.14, I followed your instructions and received the NAT6226 as you expected. I presume that the error is related to issuing another Adabas call during the 3145 - error messages are retrieved from Adabas. As you say, the REINPUT is successful with a text literal.
That would be strange, because as far as I know we don’t use Adabas for Error-Messaging. We are using the Natural-Feature SYSERR…
To prove it, i wrote the following code. And it also works without ADABAS.
set key all
*
input
'PF1 = reinput "text"' /
'PF2 = reinput full "text"' /
'PF3 = reinput *0001' /
'PF4 = reinput full *0001' /
'ENTR = Exit'
*
decide on first value of *PF-KEY
value 'PF1' reinput 'text'
value 'PF2' reinput full 'text'
value 'PF3' reinput *0001
value 'PF4' reinput full *0001
none value escape routine
end-decide
*
end
My apologies - I need to keep an eye on the Forum name. My repsonse pertains to Mainframes, where Natural messages are stored in Adabas.
By the way, although Natural messages are not stored in Adabas on OpenSystems platforms, your sample program alone does not prove this, unless you ran it while the database was inactive. If your program was run on a mainframe, Natural would issue Adabas calls on your behalf, under the covers, to retrieve error messages.
We need a DBLOG facility for OpenSystems to prove the existence or absence of Adabas calls.
I wrote the last code on Natural for Windows 6.1.1.17 without any connection to ADABAS.
BTW: To prove this, I use the following command on our Solaris-System:
adaopr db=12 es_id=6106 di=uq_full
… where 12 is my UDB-Parameter in Natural and 6106 is the value of *PID.
Here’s a sample-output:
%ADAOPR-I-STARTED, 11-APR-2006 13:17:05, Version 3.3.3.01 (Solaris 64Bit)
Database 12, startup at 11-APR-2006 12:20:51
ADANUC Version 3.3.3.01, PID 4550
ADANUC Version 3.3.3.01
Database 12 Full User Queue Entry on 11-APR-2006 13:17:01
User Entry: Id : 6 ES Id : 6106
Node Id : Login Id : kbar
User Id : 6105
User Type : ET User Status :
Time Stamps: Session Start : 11-APR-2006 12:40:51
Trans. Start : 11-APR-2006 13:01:01
Last Activity : 11-APR-2006 13:01:01
Time Limits: TT : 1,800 TNA : 36,000
Resources: ISN Lists : 0 ISNs Held : 1
Open Files : 8
Activity: ADABAS Calls : 373 Transactions : 8
%ADAOPR-I-TERMINATED, 11-APR-2006 13:17:05, elapsed time: 00:00:00
You can repeat this command a few times to see, if the number of ADABAS Calls are rising or not.
Matthias,
can you check the error state after reinput *0001 (e.g. show the *error and *error-line in the input-statement). I guess that after reinput (full) *0001 *error is no longer 3145 or *error-line does no longer point to the line with the get statement, so retry does no longer know what to retry.
Good idea! *ERROR-LINE remains the same, but *ERROR-NR is changed to 1 after the REINPUT *0001.
Maybe this all has to deal with the following description in the Natural Documentation:
It’s not allowed to modify the value of *ERROR-NR within an ON ERROR block. Ergo: It’s not allowed to use REINPUT *nnnn within ON ERROR, because this would modify *ERROR-NR, too.