Hello all!
We got the following problem:
There’s a standard-ON-ERROR-RETRY-copycode throwing a NAT1310 sometimes. We know that the original error is a NAT3145. Natural’s ON-ERROR-traceback-function (which finds this standard-RETRY-copycode in one of the calling programs) changes NAT3145 to NAT1310.
To get rid of NAT1310 we have to know the original program which causes the NAT3145 and place an ON-ERROR-Block there.
But the question is: How to find out the original program within a confusingly nested calling sequence?
Of course, USR0600N in ERROR-TA doesn’t work.
And USR0600N+Logging just before the RETRY creates a big logfile…
Any ideas?
Thankx
Matthias
Hi Matthias,
Assuming you ensured that the RETRY is only ever executed when you know the error number was 3145, about the only way to do this is to check in any module that could be below this one where a 3145 is possible and doesn’t have an ON ERROR block to handle it.
Predict XREF data or Natural Engineer can help you to locate such possible called modules.
I know of no easy way to do that if this creates a convoluted structure. However, one trick that reduces the chance of being in this situation is to always provide an ON ERROR routine checking for the 145 rsp code in every module with update logic.
Common copycode members are also helpful when making this standardization apply.
Best of luck!
You can try out USR4214N - this allows you to report the stack trace - the set of programs in the call sequence. You can add a report showing the stack, for example:
CALL STACK:
1 LEVEL: 4 SYSTEM / USR4214N N (0000)
2 LEVEL: 3 SYSTEM / ERRINFO N (1130)
3 LEVEL: 2 RPCLIB / ID010N1 N (5240)
4 LEVEL: 1 RPCLIB / CALLID10 P (0090)
In the example above, the error was thrown in ID010N1, which was called originally from CALLID10 (ERRINFO is called from the ON ERROR, which calls USR4214N to get the stack).
Thanks to you both for answering that quick.
“stack trace” sounds good to me. But there is no USR4214N on my System. We are on Natural 6.3.9 for Solaris… 
Even on my Natural for Windows: There is no USR4214…
As far as I can see this info is part of the third block from the call to USR2026N on open systems.
Finn
Hi Finn!
Thanks for answering.
USR2026N is similar to USR0600N. And that doesn’t really help. Try the following:
MYPROG is:
include myretry
*ERROR-TA := 'myerrta'
fetch return 'myprog1'
fetch return 'myprog2'
fetch return 'myprog3'
end
MYRETRY is:
on error
if *ERROR-NR = 3145
input "record in hold - Press ENTR to retry"
retry
end-if
end-error
MYPROG1 is:
define data local
01 file32 view file32-ddm
02 tks
end-define
get file32 139175 /* which is in hold by another session
update
backout transaction
end
MYERRTA is:
define data local
1 #ERROR-NR (N5)
1 #LINE (N4)
1 #STATUS-CODE (A1)
1 #PROGRAM (A8)
1 #LEVEL (N2)
*
1 TECH-BLOCK1
2 NAT-TIME (T)
2 NAT-DATE (D)
2 NAT-USER (A8)
2 NAT-LIB (A8)
2 NAT-VERSION (A2)
2 NAT-LEVEL (A4)
2 START-UP (A8)
2 SECURITY (A3)
2 NAT-OS (A32)
2 NAT-OSVERS (A16)
2 NAT-MACHINE-CLASS (A16)
2 NAT-HARDWARE (A15)
2 NAT-TPSYS (A8)
2 NAT-DEVICE (A8)
2 NAT-INIT-ID (A8)
2 LAST-CMD (A32)
*
1 TECH-BLOCK2
2 ERROR-NUM (N7)
2 ERROR-LINE (N4)
2 ERROR-PROGRAM (A8)
2 ERROR-PGM-TYPE (A1)
2 ERROR-PGM-TYPE-LONG (A11)
2 ERROR-LEVEL (I4)
2 ERROR-LIB (A8)
2 ERROR-DBID (I4)
2 ERROR-FNR (I4)
2 ERROR-CLASS (A6)
2 ERROR-TYPE (A25)
2 ERROR-TIME (A19)
2 ERROR-TA (A8)
*
1 TECH-BLOCK3
2 STEP-LIB (A8/1:11)
2 STEP-DBID (A5/1:11)
2 STEP-FNR (A5/1:11)
2 OBJ-NAME (A8/1:10)
2 OBJ-TYPE (A1/1:10)
2 OBJ-LEVEL (N3/1:10)
2 OBJ-LINE (A4/1:10)
*
1 TECH-BLOCK4
2 RETURN-CODE (I4)
2 ADDITIONALS (A1/1:100)
2 REDEFINE ADDITIONALS
3 ADD-VERSION (N2)
*
end-define
INPUT #ERROR-NR #LINE #STATUS-CODE #PROGRAM #LEVEL
write 'ERROR-TA' / '=' #ERROR-NR '=' #LINE '=' #PROGRAM '=' #LEVEL //
ADD-VERSION := 3
CALLNAT 'USR2026N' TECH-BLOCK1 TECH-BLOCK2 TECH-BLOCK3 TECH-BLOCK4
*
display OBJ-NAME(*) OBJ-TYPE(*) OBJ-LEVEL(*) OBJ-LINE(*)
end
The output of MYPROG is:
OBJ-NAME OBJ-TYPE OBJ-LEVEL OBJ-LINE
-------- -------- --------- --------
ERROR-TA
#ERROR-NR: 1310 #LINE: 40 #PROGRAM: MYRETRY #LEVEL: 1
MYERRTA P 1 0600
USR2026N N 2 0750
0
0
0
0
0
0
0
0
… so it’s not clear that MYPROG1 causes the problem.