OWEN@AUDUCVAX.BITNET (Larry Owen) (04/27/88)
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.
Thanks,
Larry Owen
Academic Computing Services
Auburn University
OWEN@AUDUCVAX.BITNETcarl@CITHEX.CALTECH.EDU (Carl J Lydick) (05/02/88)
> 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.
root@helios.toronto.edu (Operator) (05/03/88)
In article <8804301802.AA01586@ucbvax.Berkeley.EDU> OWEN@AUDUCVAX.BITNET (Larry Owen) writes: >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> > IJOBLIM is the parameter that controls the number of interactive jobs (i.e. logged-in users). The "minimum" in this case is 1. What it means is that, at some point in history, someone did a SET LOGIN/INTERACTIVE=1 and, at some point after that, did a USE ACTIVE and WRITE CURRENT in SYSGEN (or some other combination that resulted in this value being stored). Therefore, when you go to USE CURRENT again, the minimum value is still there. It is of course easy to fix. Just USE CURRENT, SET IJOBLIM nn (pick your usual number), and WRITE CURRENT. The key here is that there is a DCL command to modify this parameter. Most other parameters cannot be modified so easily. -- Ruth Milner UUCP - {uunet,pyramid}!utai!helios.physics!sysruth Systems Manager BITNET - sysruth@utorphys U. of Toronto INTERNET - sysruth@helios.physics.toronto.edu Physics/Astronomy/CITA Computing Consortium
JML4@support.vax-vms.cambridge.ac.UK (05/10/88)
So far, I've seen only one response to the message asking why SYSGEN might say %SYSGEN-W-SETMIN, value set to minimum for parameter IJOBLIM in response to a USE command, and the most likely cause wasn't mentioned. The SET LOGIN/INTERACTIVE=n command updates the value of IJOBLIM in the ACTIVE set of SYSGEN parameters. If you save the ACTIVE parameters while it is set (say) to zero, then you will get a warning any time you reload the saved parameters. The original message said that the problem occurred in response to a USE CURRENT command, which suggests that the ACTIVE parameters were saved as the CURRENT set while logins were disabled (WRITE CURRENT after an intentional update, without having done USE CURRENT at the start, perhaps). John Line