Subject: | |
From: | |
Reply To: | |
Date: | Tue, 30 Mar 1999 13:47:36 -0800 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Perhaps, someone can shed some light on this. The question du jour
concerns the current use of extra data segments in our primary online
application and a couple of associated batch apps. We demo'd LPS's
"XDSMAP" a couple of years ago to intercept and convert the XDS calls to
mapped file access, but a problem soon appeared with respect to a limit on
tracking PINs (<=4000, I believe), and I don't know if that's ever been
addressed by the vendor. In the meantime, we want to try to reduce
overhead by building the segments as large as they'll ever need to be and
eliminating the ALTDSEG calls to shrink and resize the segments as needed.
What I can't discover is what, if any, impact this will have on transient
space and memory manager CPU utilization.
The HPRC has not answered the questions adequately (IMO) after two attempts
-- e.g., one response told us that ALTDSEG only causes a length field in
the DST, but elsewhere, the RCE says that the XDS virtual space is changed:
WARNING
Sizing an XDS up or down will cause the XDS to be copied to
Virtual Memory and then read back into 'main memory'. This
transfer will cause your program to wait for its completion.
For this reason ALTDSEG should be used infrequently, if at
all. When an XDS is created enough space should be allocated
initially to avoid the need to 'size' your XDS during its life
cycle.
...
When GETDSEG is called the entire virtual space is allocated for the
length specified. The space is allocated in system space and is
rounded
up to an even number of MPE pages.
...
??? When ALTDSEG is called only the length within the dst record is
altered, ???
??? this record is part of kso_dst_obj(#192). The virtual space allocated
???
??? initial (sic) is reduced or expanded with ALTDSEG (number is always
rounded up ???
??? to an even number of mpe pages).
???
Rewriting the application to use mapped file access is not a viable option
for some time. We could try to re-evaluate XDSMAP, again, but the question
still remains whether we should eliminate ALTDSEG calls as much as
possible. Any and all advice is appreciated.
TIA,
Lee Gunter
Regence BlueCross BlueShield of Oregon / Regence HMO Oregon
|
|
|