- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- LIB$RUN_PROGRAM
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-05-2013 09:57 AM
02-05-2013 09:57 AM
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-
Solved! Go to Solution.
- Tags:
- Oracle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-05-2013 10:19 AM
02-05-2013 10:19 AM
SolutionDan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-05-2013 12:17 PM
02-05-2013 12:17 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-05-2013 12:35 PM
02-05-2013 12:35 PM
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-
- Tags:
- SQL