- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Quadword relocations - what are they?
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
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
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-25-2008 02:47 PM
тАО02-25-2008 02:47 PM
Re: Quadword relocations - what are they?
By making this clear maybe I'll save respondents going down certain useless paths.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 03:30 PM
тАО02-25-2008 03:30 PM
Re: Quadword relocations - what are they?
of overall system operation.
see this section in the linker manual
http://h71000.www7.hp.com/doc/83final/4548/4548pro_021.html#index_x_559
The link option /shared=address_data may help but I have never used this
option.
You should (depending on available memory) make sure all shared images are
installed, and the more frequently used executable images.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 03:44 PM
тАО02-25-2008 03:44 PM
Re: Quadword relocations - what are they?
For C programs calling external routines (actually ANY program calling external routines), the compiler and linker don't know where LIB$GET_VM will eventually reside. So the compiler allocates a quadword in the $LINKAGE$ section and asks the linker to put the address of LIB$GET_VM there. Of course, the linker doesn't know either so it leaves relocation info for the image activator. You have these on all systems (do man ld and man loader on your Unix/Linux system).
For COBOL... COBOL likes address constants, no wait, thats wrong. COBOL LOVES address constants. COBOL is addicted to address constants!
Besides the data structures to re-initialized variables for CANCEL, there are two other big areas.
- For regular initialization, the compiler passes the start/end addresses to a DCOB$ initialization routine (or LIBOTS routine). Since the compiler doesn't know the final address of your data, it allocates quadwords in the $LINKAGE$ section and asks the linker to compute the final address. For regular images, the linker can figure it out. For shareable images, even it doesn't know. It leaves relocations for the image activator.
- For PERFORM, COBOL paragraphs don't know if they should "return" or "fall through". Consider:
PERFORM A.
PERFORM A THRU B.
On the first call to A, it needs to "go back". On the second call, it needs to "fall through" to B. How does it know? You guessed it. Address constants!
At each PERFORM, the compiler shoves the address of the "last" paragraph into a special compiler-generated location. Each paragraph checks this special location against its own address to see where to go next. The result, lots of address constants for code labels.
As mentioned earlier, these relocations are only done once at image activation time. If the program stays running for any length of time, the overhead isn't large. If you run over and over again, it can be noticable.
You might want to install with /OPEN /HEADER and /SHARED. You might also want /RESIDENT (which requires linking with /SECTION_BINDING). A larger XFC cache can't hurt either.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 03:54 PM
тАО02-25-2008 03:54 PM
Re: Quadword relocations - what are they?
We did so some work on I64 to reduce the number of address constants since there is a relatively small limit in the short-data section. However, on Alpha, there is no actual limit, just your gag reflex on the size and overhead for the address constant relocations. We didn't take that support back to Alpha (it was platform-specific inside the code-generator).
COBOL in shareable images is just painful with respect to address constant relocations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 03:56 PM
тАО02-25-2008 03:56 PM
Re: Quadword relocations - what are they?
I've spent the last few hours discovering what you've just told me. Either Grace Hopper or some Digital people have a lot to answer for ;-)
Many of these images will be installed /OPEN/HEADER/SHARED but what does that really save apart from the disk I/O and the potential ability to share the data (if we want that)? I also can't see exactly what advantage /RESIDENT gives apart from what seems to be a contiguous chunk of virtual memory.
Is $IMGFIX run across the images when they are installed in order to resolve as many references as possible? That's the kind of thing we need.
I'd rather not have to break the news that we need to radically redesign of our business processes and code so that more work is done per image activation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 05:06 PM
тАО02-25-2008 05:06 PM
Re: Quadword relocations - what are they?
Once the image activation processing starts in earnest, the $imgfix then occurs, since the fix-ups aren't known until the images are mapped into the process address space. AFAIK, there's no way to perform the fix-ups until after the executable image and all of the constituent (installed or otherwise) shareable images are all stacked into process virtual address space, and that doesn't happen during the INSTALL processing.
http://h71000.www7.hp.com/doc/83final/4548/4548pro_020.html#fixup_sec
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 05:17 PM
тАО02-25-2008 05:17 PM
Solution>installed /OPEN/HEADER/SHARED but what
>does that really save apart from the disk
>I/O and
Sharing writeable data is a special case, but sharing code and readonly data can be a big win if you have many processes executing the same images simultaneously. You save on memory, because there's only one copy, and pagefaults because a page you want may be in the working set of another process, so you get a global valid fault rather than a hard fault.
> I also can't see exactly what
>advantage /RESIDENT gives apart from what
>seems to be a contiguous chunk of virtual
>memory.
The code is physically resident, so it's paged in at INSTALL time. No pagefaults required for references. It's also mapped into S0/S1 space, so the addresses are the same for all processes and fixed at installation time. That means you it's not necessary to perform relocations. The cost is physical memory, which is getting cheaper and cheaper.
Also look at /SHARED=ADDRESS_DATA. From HELP:
"When you use the ADDRESS_DATA keyword with the /SHARED qualifier, P1 space addresses are assigned for shareable images. With the assigned addresses, the Install utility can determine the content of an address data section when the image is installed rather than when it is activated, reducing CPU and I/O time. A global section is created to allow shared access to address data image sections."
All this presupposes that the time to perform the fixups and the number of image activations are significant enough to worry about.
Try writing a test program that just activates your shareable images then exits immediately. Compare the execution times with different combinations of installed images and different options.
Depending on what the images do, it may be better to try to keep the image running longer (for example, put a menu or event loop into the image, rather than in a DCL jacket). As Hoff suggests, another approach is to go "client server". Have the heavy weight processing in a long lived server process, with a lightweight client feeding it requests and catching results. The (lower) cost of starting and stopping the client may compensate for the cost of interprocess communications.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 05:44 PM
тАО02-25-2008 05:44 PM
Re: Quadword relocations - what are they?
I realised what I was asking after I had posted. Life would be a lot easier if, as John R said, Cobol used offsets. Even the literals are set up with .ADDRESS and can't be resolved until activation.
To John G,
I've used installed images many times in the last 29 years :-) but I haven't worked with /RESIDENT images. I understood that the only way to replace them was with a reboot but that's not an option here because changes are frequently made to the shareable images and they need to be replaced.
The use of /SHARED_ADDRESS looks potentially useful but I wonder how well it works with COBOL. It's something I'll try today or tomorrow, likewise a test program that accesses these COBOL shareable images and then exits (to determine what the activation overhead really is).
Your other suggestions refer to a major redesign. We'd prefer not to go that way but it looks like we may not have a choice.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 06:08 PM
тАО02-25-2008 06:08 PM
Re: Quadword relocations - what are they?
Do you have lots (more than 100) of symbol_vectors in the link options for your sharable images?
Phil
To JR
on the other side of the world we usually stick the reply text in our paste buffer for when itrc fails (again) I thought you might get better response locally.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-25-2008 06:29 PM
тАО02-25-2008 06:29 PM
Re: Quadword relocations - what are they?
When the number of quadword relocations is over 5000 I think there's a good chance that activation will be time-consuming, and we have plenty of such images. By the way, that figure comes from the shareable image so any image that references it will also have its own quadword relocations to be resolved.
We have quite a number of Symbol Vectors defined for the Link of the shareable image but I don't believe it would above 50 in any one shareable. Would that really make a difference when the activation can't distinguish the entry points that we might access from those that we don't?