acs@pccuts.pcc.amdahl.com (Tony Sumrall) (10/26/89)
Well, I finally had time to look into the problems that y'all've been
reporting with VT100 2.9. It appears that I screwed up. After suitably
punishing myself (vowed to watch 20/20 at least twice before the end of
the year with at least one attempt at watching Geraldo) I came up with
the following fix for Kermit BYE: replace the saybye() routine in kermit.c
with the following:
saybye()
{
int len, num, gotbuf = 0;
if(msgpkt == NULL) { /* No msgpkt buffer, create one */
msgpkt = (char *)AllocMem((long)(MAXLONGPKS+20), MEMF_PUBLIC|MEMF_CLEAR);
spackbuf = (char *)AllocMem((long)(MAXLONGPKS+20), MEMF_PUBLIC|MEMF_CLEAR);
if(msgpkt == NULL || spackbuf == NULL) {
InfoMsg1Line("KERMIT: Insufficient free memory, BYE bypassed");
return;
}
gotbuf = 1;
}
if(numreqs != 0) /* Requester's up... */
Delay(5L); /* ...so wait for Intuition, just in case. */
spack('G',n,1,"F"); /* shut down server no more files */
rpack(&len,&num,ackpkt);
if(gotbuf) {
FreeMem(spackbuf, (long)(MAXLONGPKS+20));
FreeMem(msgpkt, (long)(MAXLONGPKS+20));
msgpkt = spackbuf = NULL;
}
}
I've also gotten some details from folks on their script problems. What
I've seen so far has pointed out a (another?) failing in the VT100 script
language: its operation isn't intuitive. See, in 2.9 (and 2.8), VT100
won't execute a script command until AFTER processing some other event
(menu selection or serial data received, to name just 2). This would lead
to different operation of the script depending, for example, on how
quickly their host could emit data or whether they used the right
mouse-button. Needless to say, this caused ME a number of problems since
most folks don't relate mouse clicks or serial data to a script problem
("I can *see* the data that the script's waiting for right there on the
screen, how come my WAIT wasn't satisfied this time but was the last time
I tried it?!?"). I also have a fix for this but am not quite so willing
to share it with you just yet since it *does* change the way that VT100
works. This "fix" will cause VT100 to execute script commands to the
exclusion of processing serial data UNTIL the script has suspended itself
by either issuing the WAIT or the DELAY commands. The fix is trivial
but I'll hold onto it until some of the folks that have reported script
problems have had a chance to try it for a while. In the meantime I
suggest that you:
1. minimize your use of the WAIT command (or WAIT on shorter strings),
e.g. instead of WAIT "Password:" use WAIT "ord:"
2. not re-execute an ON command to establish an already existing ON
condition, e.g. instead of
A:
ON "login:" GOTO B
SEND "^M"
DELAY 2
GOTO A
Try
ON "login:" GOTO B
A:
SEND "^M"
DELAY 2
GOTO A
You need not take any action if your scripts are working OK. I expect to
have the final fix within a week or so and send Bob Page the kermit BYE
fix, the script fix and a new VT100 executable with the fixes incorporated.
Sorry for the problems.
---
Tony Sumrall author of VT100 2.9 (and 2.8a and 2.8 and...)
acs@pccuts.pcc.amdahl.com <=> amdahl!pccuts!acs
[ Opinions expressed herein are the author's and should not be construed
to reflect the views of Amdahl Corp. ]