Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!purdue!decwrl!ucbvax!CITHEX.CALTECH.EDU!carl
From: carl@CITHEX.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Weirdness from SYSGEN
Message-ID: <880501110824.b5d@CitHex.Caltech.Edu>
Date: 1 May 88 18:28:52 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38


 > Has anyone ever seen this very inappropriate behavior before?  Any ideas
 > as to what would cause this?
 > 
 > $ run sys$system:sysgen
 > SYSGEN>  USE CURRENT
 > %SYSGEN-W-SETMIN, value set to minimum for parameter IJOBLIM
 > SYSGEN>
 > 
 > It's my understanding that this error message is only appropriate as a
 > response to a SET command that tries to set a sysgen parameter to less
 > than its legal minimum.  Call me paranoid, but this causes me some
 > concern.  Ideas, please.

This error message is appropriate any time SYSGEN encounters a parameter
whose value has been set to less than its legal minimum.  The two ways this
can happen are:
	1)  In response to a SYSGEN SET command; or
	2)  Upon reading the parameters from a file (this includes boot time)
In light of this, the behavior you describe seems quite appropriate: somehow
you've generated a parameter file with IJOBLIM set to too low a value, and
SYSGEN is correcting this when it reads the file.

What SHOULD be causing you concern is the question of how IJBOLIM got set
to 0 in your parameter file.  Your three basic possibilities there (along
with my guesses as to likelihood) are:
	1)  Hardware failure (pretty unlikely, unless VAXVMSSYS.PAR has
	    a suspected bad block in it, in which case it becomes very likely)
	2)  Software failure (not very likely, given that SYSGEN only
	    complained about one parameter having a bad value, but still
	    a possibility)
	3)  Somebody modified VAXVMSSYS.PAR using something other than SYSGEN
	    (seems somewhat unlikely, since there are other SYSGEN parameters
	    a muncher would be more interested in changing [e.g., UAFALTERNATE])
To check out the first two, I recommend that you
	$ ANALYZE/DISK_STRUCTURE/NOREPAIR/READ SYS$SYSDEVICE:
As to the third, now might be a good time to look over your system very
carefully for other signs of munching.