Xref: utzoo comp.sys.att:10678 comp.graphics:14074
Newsgroups: comp.sys.att,comp.graphics,comp.terminals.tty5620
Path: utzoo!telly!eci386!woods
From: woods@eci386.uucp (Greg A. Woods)
Subject: Re: Download to AT&T 630MTG "hanging"
Message-ID: <1990Oct26.201542.775@eci386.uucp>
Summary: "known" bug....
Keywords: att 630 mtg download dmd 5620
Reply-To: woods@eci386.UUCP (Greg A. Woods)
Organization: Elegant Communications Inc.
References: <1990Oct25.222835.14538@uncecs.edu>
Date: Fri, 26 Oct 90 20:15:42 GMT

[ I've appended comp.terminals.tty5620 to the newsgroups line, which
  BTW, was "inadvertently" set to poster (though I didn't remove
  comp.graphics.  The download-hang problem, in my experience, is
  common to other "blit" (or DMD) terminals. ]

In article <1990Oct25.222835.14538@uncecs.edu> khj@ms.appstate.edu writes:
> We are having problems downloading a 630MTG application from a 3B2/500.
> 
> Everything worked fine on earlier versions of the application.  But
> after adding more code, re-compiling, etc. the next download just
> "hung."  I'll try and describe the symptoms a bit better ...

Your descriptions follow exactly with my experience with a tty5620 DMD
terminal.  The downloads, particularly of large programmes,
periodically hang.  On the 5620 the hung layer must be deleted,
thereby killing the 32ld on the host.  My most recent experience was
with xproof, with which I would have to try three or four times
consecutively before it succeeded.

This seems to be a problem in either the download protocol, or in the
xt(7) driver itself.  This is the first time I've heard of this
problem occuring on the 630's.

On my 3b2/400, any burst of (integral) disk activity sharply increased
the chances of failure.  Even the disk activity associated with
loading the 32ld programme, and the binary to be downloaded, was often
enough to trigger a hang.

Rumors have it that a re-implementation of 32ld done locally for 386
based machines doesn't experience these lock-ups quite so often.

A significant number of people in the Toronto area will be running
5620's on a variety of systems in the near future.  I'm sure we will
be investigating this problem further.

One task I've set for myself is to port dmdld to support the 5620
(i.e. to replace 32ld), and be portable across several host
architectures.  Since dmdld is in the 630-pkg stuff from the
Toolchest, it will allow non-3b2 users (such as myself when I'm at the
office :-) to benefit from the 5620 (and the [67]30-MTG's) (given
they/I port the host-side software, and have a 5620/630 development
package handy).
-- 
						Greg A. Woods

woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP
+1-416-443-1734 [h]  +1-416-595-5425 [w]    VE3-TCP	Toronto, Ontario CANADA