HP3000-L Archives

March 1999, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Lee Gunter <[log in to unmask]>
Reply To:
Lee Gunter <[log in to unmask]>
Date:
Tue, 30 Mar 1999 13:47:36 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
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

ATOM RSS1 RSS2