[fa.info-vax] Corruption of JBCSYSQUE.dat

info-vax@ucbvax.ARPA (08/14/85)

From: boulder!jon (Jon Corbet)

	We have recently (finally!) upgraded to VMS V4.1 + new XQP, and a
new problem has developed.  In SYSTARTUP.COM, there is a line of the form:

		$ start /queue /default=(burst=one) lpa0

where LPA0 is a basic, vanilla print queue.  Nothing fancy about it.  Every
now and then, this command simply hangs.  It seems to get caught in one of
two types of loops.  The first one looks like some sort of wait -- no CPU
time or other activity.  The other one looks like it is trying to shake the
disk drive apart.  In either case, it will not work until a brand new
JBCSYSQUE.DAT is created.
	Has anybody else seen this one?  I can't see that we are doing
anything nonstandard, and we aren't even running a cluster.  Any ideas would
be much appreciated.

Thanks,
	jon
---
Jonathan Corbet
National Center for Atmospheric Research, Field Observing Facility
{seismo|hplabs}!hao!boulder!jon		(Thanks to CU CS department)

info-vax@ucbvax.ARPA (08/15/85)

From: Richard Garland <OC.GARLAND@CU20B.ARPA>

Mail-From: OC.GARLAND created at 14-Aug-85 14:00:36
Date: Wed 14 Aug 85 14:00:35-EDT
From: Richard Garland <OC.GARLAND@CU20B.ARPA>
Subject: Re: Corruption of JBCSYSQUE.DAT
To: OC.GARLAND@CU20B.ARPA
In-Reply-To: Message from "boulder!jon@UCB-VAX.BERKELEY.EDU (Jon Corbet)" of Wed 14 Aug 85 11:47:38-EDT

We had a similar problem on a microVAX-I using microVMS V4.1
initializing a terminal print Queue.  It seems to work after the
queue file was deleted the first time or 2.  No similar problems
in several months.
					Rg
-------
-------

info-vax@ucbvax.ARPA (08/15/85)

From: MRL%MIT.MFENET@LLL-MFE.ARPA



We recently also had a problem with our SYSTARTUP.COM hanging on an attempt
to start a print queue.  We believe our problem was that we had recently
changed the SCSNODE definition (we do not yet have a cluster, however).
This causes device names to be displayed with SCSNODE preceeding them,
i.e. _SCSNODE$DEVICE.  We think the job queue got confused on this.  The
problem was solved by creating a new JBCSYSQUE.DAT.  The weird thing was
that before we did that, we were able to start the queues running by simply
stopping and then restarting the job manager WITHOUT creating a new
JBCSYSQUE.DAT .