|
HP OpenVMS Systemsask the wizard |
|
The Question is: We are upgrading from VMS 6.1 to VMS 6.2 and have programs that are mostly PASCAL and C. We have been experiencing some performance problems. I have noticed that when the programs are linked using VMS 6.2, they are smaller and have a channel open to DEC C$RTL.EXE when running. (Anal/SYS, set proc/index=xxxxx, show proc/chan) I was able to improve performance by adding SYS$LIBRARY:DECC$CRTL.OLB to my link statement. I also seem to be able to force the Pascal routines to use linked libraries (as opposed to run-time) by adding a /NOSYSSHR to the link statement. My problem is that I cannot link C routines with /NOSYSSHR, so when I have both PASCAL and C routines, I can't get the PASCAL linked libraries. When using DECC 6.0, I try linking with /include=C$ CMA_TIS, but I get undefined symbols. When I was using DECC 4.0, I tried the /include=CMA$TIS and got similar problems? Is there a way to force a link to linked libraries as opposed to run-time libraries? Is there a way to get DECC 6.0 to link with the /NOSYSSHR option? Kind regards -- Harvey Moyer The Answer is : The Wizard is skeptical that there would be a measurable performance difference between a program linked against shareable images versus the same program linked against object code. Especially with an image such as DECC$RTL, which is installed resident. Further, if any of your programs are ever run simultaneously by more than one process, the non-shared version will use substantially more physical memory, which may result in increased page faulting and thereby *decrease* overall performance. Rather than assuming the problem is due to shareable images and attempting to force the linker to perform unnatural acts, the Wizard would recommend profiling the application to determine the exact nature of the performance problem. As an initial suggestion, acquire and apply any available relevent (or mandatory) ECO kits for the OpenVMS version in use, particularly for the languages in question. Also ensure that you have sufficient available physical memory configured on the system, that the process quotas and working set are set to appropriate values, that AUTOGEN with FEEDBACK has been run (with all uncorroberated dreck removed from MODPARAMS.DAT), and that the instructions in the performance manual around localizing the application performance bottleneck(s) have been followed. For further assistance, please log a call with your local customer support centre with a more detailed description of "experiencing some performance problems".
|