LIB$RUN_PROGRAM (350 Views)
Reply
Visitor
-Rick-
Posts: 2
Registered: ‎02-05-2013
Message 1 of 4 (350 Views)
Accepted Solution

LIB$RUN_PROGRAM

Good day,

    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.

 

    Any ideas?

 

    Thanks,

-Rick-

 

Trusted Contributor
abrsvc
Posts: 367
Registered: ‎06-08-2010
Message 2 of 4 (346 Views)

Re: LIB$RUN_PROGRAM

Please realize that in the instance of using the "remote" database, the connections to that database must be extablished. This takes time. I would suspect that the difference is there. Look at the process using the SHO PROC/CONT and you won't see any activity on the process for that duration. It will likely be in LEF waiting for the database connection to be completed, at which time it will proceed.

Dan
Honored Contributor
Hein van den Heuvel
Posts: 6,588
Registered: ‎05-19-2003
Message 3 of 4 (332 Views)

Re: LIB$RUN_PROGRAM

>>  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

 

Good luck!

Hein.

 

 

Visitor
-Rick-
Posts: 2
Registered: ‎02-05-2013
Message 4 of 4 (328 Views)

Re: LIB$RUN_PROGRAM

Hi Hein,

    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.

 

    Thanks,

-Rick-

 

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.