(9894) Image INSTALL and Global Pages?

[User]

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 new 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 correct the problem, only a reboot of ERNIE removed the extra files in the $SHOW DEVICE/FILES/SYSTEM.

For example,

Executables in URS directory:

Code: Select all

AUMENU.EXE;2812
AUMENU.EXE;2811
AUMENU.EXE;2810
AUMENU.EXE;2809
URMENU.EXE;2538
URMENU.EXE;2537
URMENU.EXE;2536

ERNIE

Code: Select all

$ INSTALL LIST
URDATA4:<UNIRAD&g
AUMENU;2810     Open Hdr Shar
(could not get ;2812 installed)
URMENU;2538     Open Hdr Shar

BERT

Code: Select all

$INSTALL LIST
URDATA:<UNIRAD&g
AUMENU;2812     Open Hdr Shar
URMENU;2538     Open Hdr Shar

ERNIE

Code: Select all

$ 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

Code: Select all

$ SHOW DEV/FILES/SYS URS
PID=00000000
AUMENU;2809
AUMENU;2811
AUMENU;2812
URMENU;2537
URMENU;2538

ERNIE

Code: Select all

Open images via F$GETJPI
AUMENU;2809
AUMENU;2811
AUMENU;2812
URMENU;2537
URMENU;2538

BERT

Code: Select all

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

Code: Select all

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

Code: Select all

	1 	2	-	-	-	-	-	-

02oct

Code: Select all

$show before stop/id	1	2	-	-	-	-	-	-
f$getjpi	No	yes	-	-	-	-	-	-
$ show after stop/id	0	2	-	-	-	-	-	-

04oct

Code: Select all

$show before stop/id	-	2	-	-	-	-	-	-
f$getjpi	-	yes	-	-	-	-	-	-
$ show after stop/id	-	2	-	-	-	-	-	-

05oct

Code: Select all

$show before stop/id	-	2	1	-	-	-	-	-
f$getjpi	-	yes	yes	-	-	-	-	-
$ show after stop/id	-	1	1	-	-	-	-	-

06oct

Code: Select all

$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

Code: Select all

$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:

Code: Select all

AUMENU.EXE;2832
AUMENU.EXE;2831
AUMENU.EXE;2830
URMENU.EXE;2572
URMENU.EXE;2571
URMENU.EXE;2570

ERNIE

Code: Select all

SHOW/DEV/FILES/SYSTEM URS
PID=00000000
AUMENU;2818
AUMENU;2823
AUMENU

[Wizard]

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.