From: jsue@ncsa.uiuc.edu (Jeffrey L. Sue)
Subject: Sometimes documented things don't work (was: Running LOGINOUT)
Originator: jsue@pluto.ncsa.uiuc.edu
Organization: The Dow Chemical Company
Date: Tue, 5 Jan 1993 16:49:27 GMT

In article <9301051432.AA20133@uu3.psi.com> leichter@lrw.com (Jerry Leichter) writes:
>
>It would be nice if it were decently documented, rather than being hinted at.
>In general, it's clear in VMS when something is documented/supported, and
>when it just happens to work.  I can think of no other example in which the
>VMS documentation tip-toes around the edges but is unwilling to really
>commit itself...

Even stranger, though, are the cases where something is fully documented,
but still doesn't work - or at least, doesn't work properly.  Most notable
(notorius):

[get ready DEC]

1.  IO$M_FORCEPATH & IO$M_SETPRFPATH -
	This was introduced in VMS 5.4 and never really
	worked correctly for us.  Even under 5.5 DEC told us not to
	use it - although they didn't take the articles out of DSN
	that showed example programs of using it.

	What happens is that if you set the preferred path in a mixed-
	interconnect cluster, with dual-ported HSC-based disk, the
	satellite nodes will place the disk(s) into mount verification
	if the disk(s) ever fail over to an HSC not designated as the
	preferred path.

	To be fair, DEC *finally* did come up with a workaround whereby we
	are to set the preferred path, mount (or failover) the disks, and
	then clear the preferred path.  Clearing the preferred path is done
	by setting the preferred path to the current nodename.

2.  SYSMAN STARTUP vs INSTALL.EXE -
	In our VAXcluster we have a large, somewhat complex configuration
	of software, and having a database-driven interface for starting
	them seemed like a great idea.  Due to the large number of apps
	the best way to speed up STARTUP was to execute many of them
	concurrently - batch jobs in our case.

	Actually, we never actually implemented this under SYSMAN STARTUP,
	but our SYSTARTUP_V5.COM performed many SUBMIT commands in order
	to accomplish the same thing.  SYSMAN STARTUP was a future project
	that we intended to pursue to make managing the app startups
	easier (ie., reduce the number of IF...THEN statements necessary
	in SYSTARTUP_V5.COM).

	The problem is this:  Apparently since VMS 5.1 DEC has known that
	the INSTALL.EXE program would *sometimes* get into a deadlock
	situation if more than one process was trying to add or replace
	an image at the same time.  Somehow this never affected us (we've
	been doing submits for a couple of years) until we got faster
	processors (VAX 6000-510 & 6000-610), and upgraded to VMS 5.5.
	It seems to be completely a "timing" issue and I can't really
	explain why it never cropped up before, but it finally got to the
	point where we could *never* run INSTALL from multiple processes.
	This means that many of the benefits of SYSMAN STARTUP are lost
	to us until DEC fixes INSTALL.EXE... not likely to happen in my
	lifetime, so I understand.

NOTE:	SYSMAN STARTUP is **fully** documented and we are expected to
	take advantage of it... but it won't help us speed up our boot
	process - and the installation of about 200 software products.

	Also, some of our applications startup themselves via detached
	processes, making this kind of difficult to control.  What's even
	funnier (NOT!) is that we can no longer use the "documented"
	way to have decwindows startup - ie, it just happens automatically
	from VMS$CONFIG-050_VMS.COM & VMS$LPBEGIN-050_STARTUP.COM.  Instead
	we have to DEFINE DECW$IGNORE_DECWINDOWS TRUE, and then SUBMIT
	the DECW$STARTUP.COM file seperately.

The INSTALLE.EXE problem is a known bug, but not a problem, according
to DEC... GET A CLUE!!!
-- 
-----
Jeff Sue   
 - All opinions are mine -       (and you can't have any, nya nya nya)
Newsgroups: comp.os.vms