C506634@UMCVMB.MISSOURI.EDU (Eric Edwards) (09/23/90)
I'm having trouble with the following piece of vt100 2.8a scripting. Depending
on the rest of the script (what I don't know) if KR (Kermit receive) fails,
the script will terminate rather then executing the next line.
ON # turn off MORE trapping
ON "term" GOTO EndLoop1
WAIT "xyzzy"
#--------download loop ------------
SEND ^M /* signal back to mainframe that we are ready */
TopLoop1:
WAIT "file(s)."
KR
delay 1
SEND ^Q /* clear parity error */
SEND ^M /* signal exec that we're ready */
goto TopLoop1
EndLoop1:
SEND ^M
This code is supposed to be self contained and as best I can tell, it is.
But. I've got three large scripts that contain this exact code. In one it
works, and in the the other two a failed kermit receive will abort the script.
Does anyone know what causes this and perferably could suggest a work around?
Now, before I get flooded with replies telling me to upgrade to 2.9xx, that
won't work. This code cannot function without the ability for an ON statement
to interupt a WAIT. The inability of an ON in vt100 2.9xx to interupt a wait
statement is IHMO the biggest misfeature of the program.
Eric Edwards: c506634 @ "The 3090. Proof that by applying state of the
Inet: umcvmb.missouri.edu art technology to an obsolete architecture,
Bitnet: umcvmb.bitnet one can achieve mediocre performance."plav@cup.portal.com (Rick M Plavnicky) (09/25/90)
In a recent article C506634@UMCVMB.MISSOURI.EDU (Eric Edwards) writes: >I'm having trouble with the following piece of vt100 2.8a scripting. Dependin on the rest of the script (what I don't know) if KR (Kermit receive) fails, >the script will terminate rather then executing the next line. [script code deleted] >Now, before I get flooded with replies telling me to upgrade to 2.9xx, that >won't work. This code cannot function without the ability for an ON statement >to interupt a WAIT. The inability of an ON in vt100 2.9xx to interupt a wait >statement is IHMO the biggest misfeature of the program. Despite your statement, I'll point you at 2.9B anyway :-). Its ARexx port can provide a good deal more flexibility than the built-in script language. Have you checked it out before condemning it? /* Rick Plavnicky ...!sun!cup.portal.com!plav -or- plav@cup.portal.com */
C506634@UMCVMB.MISSOURI.EDU (Eric Edwards) (09/25/90)
In Message-ID: <34239@cup.portal.com>
plav@cup.portal.com (Rick M Plavnicky) said:
>In a recent article C506634@UMCVMB.MISSOURI.EDU (Eric Edwards) writes:
>>Now, before I get flooded with replies telling me to upgrade to 2.9xx, that
>>won't work. This code cannot function without the ability for an ON statement
>>to interupt a WAIT. The inability of an ON in vt100 2.9xx to interupt a wait
>>statement is IHMO the biggest misfeature of the program.
>
>Despite your statement, I'll point you at 2.9B anyway :-). Its ARexx
>port can provide a good deal more flexibility than the built-in script
>language. Have you checked it out before condemning it?
Are you just stating this as a general case or do you actually have code in
mind? I, for one, don't see how Arexx is going to fix this. There's also
the problem of detecting "more..." and clearing the screen. This stuff runs
of a script hostile CMS system not the warm fuzzy Unix box you're probably used
to.
Eric Edwards: c506634 @ "The 3090. Proof that by applying state of the
Inet: umcvmb.missouri.edu art technology to an obsolete architecture,
Bitnet: umcvmb.bitnet one can achieve mediocre performance."