|
HP OpenVMS Systemsask the wizard |
|
The Question is: Is there any limitation to RMS I/O from a shared image? I have a program (in c) that works correctly when linked with /image. This program has a main() that calls a (soon to be global) routine that calls printf(). These same printf() calls don't work when that source is linked with /share and a linker options file that names the above mentioned global entry point. The caller of LIB$FIND_IMAGE_SYMBOL (?) might be loading the image from EXEC mode. I didn't write the loader, and I have no access to its source. I've tried fprintf to stderr, but no luck. I've redirected stdout to a file, but no joy. The Answer is : You will first need to determine what processor mode the application is operating in -- most standard language run-time libraries and even the OpenVMS system run-time libraries are not supported for inner-mode operations. Applications executing in inner processor modes will usually use only OpenVMS system services and/or entry points directly in the OpenVMS executive -- while a subset of the C run-time library is available to inner mode code in recent OpenVMS Alpha releases, this is not the default C run-time and it requires an explicitly and deliberately different linking procedure. (See the OpenVMS Alpha device driver documentation for details of the kernel-mode C run-time interface.) The standard C (user-mode) run-time library routines require explicit initialization when not used with a C main program -- please see the details of the VAXC$CRTL_INIT call included in the C documentation. There are a large number of (user-mode) shareable images written in C, and a cookbook for the creation of a shareable image is included in the Ask The Wizard area -- these (user-mode) shareable images do work just fine... A full source example of a C shareable image is included in topic 2486 here in Ask The Wizard, including a call to lib$find_image_symbol to activate the shareable image, and the use of printf from within the shareable image.
|