|
|
| Author |
Message |
Jim Kellom
New User
Joined: 12 Aug 2008
Posts: 4
Location: Grand Blanc, MI
|
|
|
|
We have been run REXEC commands using IKJEFT01 to load data into an SYBASE data base. Lately on some of the larger tables we are loading we are receiving a Condition code 001 returned.
I can't tell whether the condition code is coming from the server or if it is something from REXEC or IKJEFT01.
Any thoughts or insight will be greatly appreciated. |
|
| Back to top |
|
 |
References
|
|
 |
Srihari Gonugunta
Active User
Joined: 14 Sep 2007
Posts: 184
Location: Pune
|
|
|
|
try to trace the error by using the option -d
REXEC -d |
|
| Back to top |
|
|
 Moved: Wed Aug 13, 2008 5:30 pm by superk From JCL to Other Mainframe Topics |
Robert Sample
Senior Member
Joined: 06 Jun 2008
Posts: 963
Location: Atlanta, GA
|
|
|
|
| What message(s) are returned from REXEC on the batch log? i would think a condition code 1 would be from the remote server since REXEC is going to throw a 12 if it has problems; anything else is usually coming from the other side of the connection. You might also check the SYBASE log to see what's showing up there. |
|
| Back to top |
|
|
Jim Kellom
New User
Joined: 12 Aug 2008
Posts: 4
Location: Grand Blanc, MI
|
|
|
|
| Robert Sample wrote: |
| What message(s) are returned from REXEC on the batch log? i would think a condition code 1 would be from the remote server since REXEC is going to throw a 12 if it has problems; anything else is usually coming from the other side of the connection. You might also check the SYBASE log to see what's showing up there. |
The REXEC messages show that the SYBASE table is loaded and that the alternate index is being built then it just stops. I have had our SYBASE support team look at the logs and they do not find anything wrong. |
|
| Back to top |
|
|
Robert Sample
Senior Member
Joined: 06 Jun 2008
Posts: 963
Location: Atlanta, GA
|
|
|
|
| Sounds like a time out issue. Maybe related to a firewall? |
|
| Back to top |
|
|
Jim Kellom
New User
Joined: 12 Aug 2008
Posts: 4
Location: Grand Blanc, MI
|
|
|
|
| Robert Sample wrote: |
| Sounds like a time out issue. Maybe related to a firewall? |
That's what makes sense, but it doesn't happen everytime the job runs. |
|
| Back to top |
|
|
Robert Sample
Senior Member
Joined: 06 Jun 2008
Posts: 963
Location: Atlanta, GA
|
|
|
|
| If it's not happening every time the job runs, it even more sounds like a time out issue; amount of data to be indexed could be causing the time out, perhaps. There are TCP/IP parameters for keep alive and inactive times; contact your systems programmer to double-check what these are set to. I'd definitely run with the debug tracing option to get more information. |
|
| Back to top |
|
|
Jim Kellom
New User
Joined: 12 Aug 2008
Posts: 4
Location: Grand Blanc, MI
|
|
|
|
| Robert Sample wrote: |
| If it's not happening every time the job runs, it even more sounds like a time out issue; amount of data to be indexed could be causing the time out, perhaps. There are TCP/IP parameters for keep alive and inactive times; contact your systems programmer to double-check what these are set to. I'd definitely run with the debug tracing option to get more information. |
I did and did not get any additional information.
Thanks for your input, it re-enforces that we are looking at the correct things. Just not finding what changed. |
|
| Back to top |
|
|
Robert Sample
Senior Member
Joined: 06 Jun 2008
Posts: 963
Location: Atlanta, GA
|
|
|
|
| I wonder if a TCP/IP trace would show anything more than the other system starting the indexing and going away; it sounds like there's something going on with the other system that needs investigating. Maybe IT has a time out associated with tasks? |
|
| Back to top |
|
|
|
|
