02-05-2013 09:57 AM
We are running OpenVMS V7.2-1 running COBOL programs accessing a local Oracle 8.0.5 database.
We want to start using an Oracle10g database on a Linux server.
We have figured everything out and there is no problem with connectivity.
We have a menu system that uses the LIB$RUN_PROGRAM to run the selected Cobol executable.
When we run against the local database programs start up within 1 to 10 seconds depending on size.
When we run against the foreign 10g database on the Linux server it takes 10 to 60 seconds to start up the same programs.
The executables are all running on the VMS server. Why would there be such a large difference in startup times?
I have definitely tracked it down to the LIB$RUN_PROGRAM call.
Solved! Go to Solution.
02-05-2013 10:19 AM
02-05-2013 12:17 PM
>> I have definitely tracked it down to the LIB$RUN_PROGRAM call.
>> Any ideas?
Yes... it definitely has nothing to do with LIB$RUN_PROGRAM.
Please explain what makes you think otherwise.
To verify can you just try with a simple DCL 'run' command.
(If the activated program used LIB$GET_COMMON, then you may need a helper image to do a LIB$PUT_COMMON)
The most more than a few seconds delays sounds unreasonable to activate Oracle even on a slow, overloaded target.
My guess woudl be an improper network configuration, notably with the old box respoding to probes back.
I've seen this with 'telnet' where it took 'forever' to get going but worked fine once connected, while 'ping' was quick.
In that case we fixed it with a corrected local 'hosts' definition.
Essentially the system was timing out on DNS lookups.
When you use say SQLplus (or TNSping) to connect to the new target, how slow (or fast) is that compared to the run_program??
Finally, I suppose image activation could play a role, but not to the tune of tens of seconds.
Still.. Make sure all shareables are installed, and verify with SET WATCH FILE/CLA=MAJOR
02-05-2013 12:35 PM
You are correct, it was not the LIB$RUN_PROGRAM call.
The program does start immediately, and the connection to the remote database is also immediate.
It turns out the problem is with the embedded SQL in the Cobol programs.
In certain cases we need to "prepare" and "compile" cursors where straight embedded SQL cursors won't do.
These prepared cursors run quickly against the native database, but take forever against the remote database.
We don't see any lag with normal embedded SQL statements.