 |
The Question is:
We are running OpenVMS V7.1 on a cluster with two Alpha systems (BERT and
ERNIE). We have in-house programs that we INSTALL so they are shared.
Modified executables are created almost daily, often multiple times a day and
INSTALLed (/OPEN/HEADER/SHARED)
using REPLACE. Occasionally, the INSTALL fails on ERNIE due to insufficient
global pages/sections. This happens when previous versions of the executables
appear open and users are accessing them because they have not yet exited and
restarted with the n
ew executable. By restarting users, we are eventually able to INSTALL the new
executable. While investigating the issue, we encountered the same scenario
stated in Wizard Entry #6781. However, the solution indicated in the answer
to #6781 did not corre
ct the problem, only a reboot of ERNIE removed the extra files in the $SHOW
DEVICE/FILES/SYSTEM.
For example,
Executables in URS directory:
AUMENU.EXE;2812
AUMENU.EXE;2811
AUMENU.EXE;2810
AUMENU.EXE;2809
URMENU.EXE;2538
URMENU.EXE;2537
URMENU.EXE;2536
ERNIE
$ INSTALL LIST
URDATA4:<UNIRAD>.EXE
AUMENU;2810 Open Hdr Shar
(could not get ;2812 installed)
URMENU;2538 Open Hdr Shar
BERT
$INSTALL LIST
URDATA:<UNIRAD>.EXE
AUMENU;2812 Open Hdr Shar
URMENU;2538 Open Hdr Shar
ERNIE
$ SHOW DEV/FILES/SYS URS
PID=00000000
AUMENU;2750
AUMENU;2764
AUMENU;2766
AUMENU;2775
AUMENU;2795
AUMENU;2797
AUMENU;2797
AUMENU;2797
AUMENU;2797
AUMENU;2797
AUMENU;2797
AUMENU;2797
AUMENU;2797
AUMENU;2798
AUMENU;2802
AUMENU;2803
AUMENU;2805
AUMENU;2805
AUMENU;2806
AUMENU;2806
AUMENU;2806
AUMENU;2806
AUMENU;2806
AUMENU;2806
AUMENU;2806
AUMENU;2806
AUMENU;2806
AUMENU;2806
AUMENU;2809
AUMENU;2810
AUMENU;2811
URMENU;2488
URMENU;2494
URMENU;2503
URMENU;2528
URMENU;2529
URMENU;2534
URMENU;2535
URMENU;2535
URMENU;2536
URMENU;2537
URMENU;2538
BERT
$ SHOW DEV/FILES/SYS URS
PID=00000000
AUMENU;2809
AUMENU;2811
AUMENU;2812
URMENU;2537
URMENU;2538
ERNIE
Open images via F$GETJPI
AUMENU;2809
AUMENU;2811
AUMENU;2812
URMENU;2537
URMENU;2538
BERT
Open images via F$GETJPI
AUMENU;2809
AUMENU;2811
AUMENU;2812
URMENU;2537
URMENUl2538
Using the solution to #6781, on ERNIE I attempted to do an INSTALL DELETE of
the obsolete/old versions of AUMENU and received the error Known File Entry
not found
After rebooting ERNIE, only the latest versions of AUMENU and URMENU were shown
with
$ INSTALL LIST, $ SHOW DEV/FILES/SYS URS and F$GETJPI. After our nightly
backup runs which log off all users first, BERT was the same with the latest
versions.
Since the reboot of ERNIE, we have started a similar pattern:
This is for AUMENU.EXE on node ERNIE only.
URS:*.EXEs are purged to three versions each night.
This tables indicates the # of versions via a $show dev/files/sys urs as well
as if a user is running as shown with f$getjpi
Version#: ;2817 ;2818 ;2820 ;2821 ;2822 ;2823 ;2824 ;2825
Created: 20sep 01oct 04oct 05oct 8:42 05oct 10:45 05oct
12:35 06oct 10:24 06oct 11:08
01oct 1 2 - - - - - -
02oct
$show before stop/id 1 2 - - - - - -
f$getjpi No yes - - - - - -
$ show after stop/id 0 2 - - - - - -
04oct
$show before stop/id - 2 - - - - - -
f$getjpi - yes - - - - - -
$ show after stop/id - 2 - - - - - -
05oct
$show before stop/id - 2 1 - - - - -
f$getjpi - yes yes - - - - -
$ show after stop/id - 1 1 - - - - -
06oct
$show before stop/id - 1 1 0 1 3 - -
f$getjpi - no no yes no yes - -
$ show after stop/id - 1 0 0 1 3 - -
07oct
$show before stop/id - 1 - - - 2 - 1
f$getjpi - no - - - yes yes yes
$ show after stop/id - 1 - - - 2 - 1
10/13/04 16:00
Executables in URS directory latest version# is INSTALLed:
AUMENU.EXE;2832
AUMENU.EXE;2831
AUMENU.EXE;2830
URMENU.EXE;2572
URMENU.EXE;2571
URMENU.EXE;2570
ERNIE
SHOW/DEV/FILES/SYSTEM URS
PID=00000000
AUMENU;2818
AUMENU;2823
AUMENU
The Answer is :
As you have discovered, delete-pending global sections are not actually
deleted until all current accessors close the section. So, the only way
to ensure the section is deleted is to close the application.
Since this is clearly (very!) volatile code, consider adding a mechanism
to the application to inform active processes that the section has been
updated. Perhaps a regular timer AST that samples a system logical
name? Set the logical name to the version number of the current
image. If a particular instance sees a change, issue a message to the
user to exit, or just force an exit. Set the timer interval long
enough so it isn't a performance drain, but short enough so you get
your resource back in a reasonable time (say, 30 mins?). Better
would be a lock-based communications mechanism, indicating the
application should be restarted.
GBLSECTIONS and GBLPAGES are both relatively "cheap", so given your
usage pattern, it shouldn't be too much of a problem to increase both
parameters to take into account your worst case consumption. Adding
(say) an extra 100 GBLSECTIONS is not unreasonable. It's difficult to
suggest a value for GBLPAGES without knowing the sizes of the images,
but consider that each increase of 262144 GBLPAGES costs only 1 page of
physical memory. As long as the resources are eventually returned, all
you need to do is allocate sufficient resource to make sure you never
hit the limit. Consider it as a cost of your usage requirements, and
of your current relatively high frequency of software updates.
Do also consider what is being updated, as -- if this is data stored
in a COMMON, for instance -- approaches based on mapping and remapping
global sections, and on shared data. (For related information on
COMMONs, please see topic (2486).) This avoids the restart entirely,
and the application can be updated to map the data as required, or
could be modified to update the data directly and avoid the restart
and the remapping and the reinstallation entirely.
Topic (6781) is specific to specification of the version number on
an installed image, and that discussion has no particular relationship
to this delete-pending environment.
|
|
|
|
|
