From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 22-JAN-1991 19:50:09.06
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	Re: lat 5.4-1: further bad experiences

Received:  by crdgw1.ge.com (5.57/GE 1.80)
	 id AA10182; Tue, 22 Jan 91 19:34:48 EST
Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Tue, 22 JAN 91 15:08:15 PST
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA13110; Tue, 22 Jan 91 14:56:13 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 22 Jan 91 20:37:37 GMT
From: ecsgate!stat.appstate.edu!combstm@mcnc.org
Organization: Appalachian State University
Subject: Re: lat 5.4-1: further bad experiences
Message-Id: <371.279c6a52@stat.appstate.edu>
References: <D1B455DEDE5F81DF18@Gems.VCU.EDU>, <28068.279bfc32@kuhub.cc.ukans.edu>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

In article <28068.279bfc32@kuhub.cc.ukans.edu>, paul@kuhub.cc.ukans.edu writes:
.
 (deleted previous stuff)
.
> We encountered some other bugs with the new LAT: it crashed our 9000.
> RDC had to provide a patch. Even after the patch, and having changed
> the port numbers to a higher numbers, systartup hung creating print queues
> which use LAT ports.
> 
> We immediately returned to LAT 5.4 and are awaiting word from Colorado
> regarding a crash/dump we initiated so that they could trace the
> systartup print queue problem.
>
We have just recently gone to VMS 5.4-1 and the new LAT software.
We have a 3 node cluster, and each node has a varying number of LAT printer
ports.  Two of the three nodes booted successfully after the upgrade, but the
third did not.  Here is the problem we encountered and the solution:

Problem:

Machine will not boot due to LAT$systartup errors.  Errors are reported as ACP
resource errors for user SYSTEM.  The procedure we were using was to set up the
LATCP.EXE as a foreign command (i.e.  $LCP := $LATCP).   Then we were creating
the terminal ports necessary for later use by the printing software.  Example
of commands:

$ LCP CREATE PORT LTA162: /NOLOG
$ LCP SET PORT LTA162: /APPLICATION /NODE=DS16 /PORT=DS162

As each of these foreign commands was executed, there were at least 65 blank
lines written to the startup log file along with the echoed command.  Since we
were creating a number (35) of print queues, this process soon exhausted the
resources of the SYSTEM user and subsequently stopped the startup process.

Solution:

Do away with the foreign command for LCP and instead use:

$Run SYS$SYSTEM:LATCP.EXE
CREATE PORT LTA162: /NOLOG
SET PORT LTA162: /APPLICATION /NODE=DS16 /PORT=DS162
..
This procedure will only put out the number of blank lines necessary to fill
out the last page, and allows the machine to boot to completion.  The problem
is with the screen management routines used by LATCP in this case.  The problem
has been sent to "software engineering" for evaluation.

I hope this extended explanation is of some help...

- Terry               
  Bitnet:    COMBSTM@APPSTATE
  Internet:  COMBSTM@Conrad.Appstate.Edu