SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (05/24/88)
Info-Kermit Digest Tue, 24 May 1988 Volume 7 : Number 13
Today's Topics:
Help Sheet on Recent MS-Kermit 2.31-test5 22 May 1988 Code
Extended ASCII with Kermit, For Kermit Developers
Re: VAX/VMS Kermit "SET LINE" command
Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.
Kermit files may be obtained over networks and by mail order. On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:. You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV). To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.
----------------------------------------------------------------------
Date: Sun, 22 May 88 21:08 MDT
From: <JRD%USU.BITNET@CUVMA.COLUMBIA.EDU> (Joe Doupnik)
Subject: Help Sheet on Recent MS-Kermit 2.31-test5 22 May 1988 Code
Keywords: MS-DOS Kermit 2.31-test5
The following MSTIBM.BOO, 2.31-test5 22 May 1987, corrects some problems
and adds some new features.
A quick update on a new script feature, long overdue. Now present are the
new commands:
IF [NOT] {SUCCESS | FAILURE | ALARM | COUNT | DEFINED | ERRORLEVEL | EXIST}
<Kermit command>
GOTO [:]<label>
:text text is a label, a la Batch files
REINPUT <timeout> <match string>
SET ALARM <time>
SET COUNT number
POP
STOP
Let's start with labels. They are like the Batch variety and are identified by
a line starting with a colon and then the label text proper (any non-spacing
text should be ok). Material following the label on that line is ignored.
GOTO is the way to jump to a label. The label name in a GOTO command may
optionally have the leading colon; however, the labeled line must begin with
a colon to be recognized as a label. A label is known only within it's home
Take file or Macro and cannot be referenced from outside. Thus, nested Take
files or Macros can use labels of the same name without confusion. See the
discussion of IF DEFINED for a way to retain information between Take files
or Macros.
GOTO <label> does pretty much as expected. It goes to the line following the
indicated label. The technique is to rewind the Take file (or the Macro) and
search for the label, so the GOTO's can be forward or backward. Since scripts
are relatively short files there is not much time lost. If no such label then
there is a message saying
?Label ":text" was not found
and the current Take file or Macro is exited; i.e., there is no place to
continue the execution thread. (No bomb box, no crashing noises.)
Giving a label by hand to the Kermit prompt is a no op (is ignored without
comment). This is done to let script control flow run across labels without
producing messages en route. GOTO has meaning only within Take files and
Macros.
REINPUT is very much like the script INPUT command, except it attempts to
reread the 128-character script serial port buffer for material matching the
user's string and does not consume the buffer in the process. Thus, several
REINPUT commands can have a chance to examine the same buffer. Regular INPUT
discards buffer characters as they are examined, REINPUT does not. And,
REINPUT can request newly arrived characters, until the buffer fills, as
needed while seeking the desired pattern; that's where the timeout is
effective.
The IF statements look like
IF [NOT] <condition> <command>
where NOT is optional (yes, NOT NOT NOT.. flips back and forth)
<condition> is one of the following:
FAILURE (of previous Kermit command)
SUCCESS ( ditto )
ERRORLEVEL number (true when ERRORLEVEL >= number)
EXIST filespec (with path and wild cards)
COUNT (decrement COUNT, but not below 0,
then if COUNT is still greater than 0
do the indicated command)
ALARM (true if present time >= alarm time)
DEFINED macro/variable name (true if macro/variable exists)
<command> is any legal Kermit command, including another IF statement.
When an IF statement logical test yields False control passes to the Kermit
command on the next line. IF statments themselves do not produce testable
status so that several IF statements can test a previous main Kermit command.
The command
SET COUNT number (0 to 65535 decimal)
presets a variable COUNT to the value of number so that it and the IF COUNT
statement can form a loop. There is an separate internal copy of COUNT for
each nested Take file and Macro. SET COUNT has meaning only when given in
Take files and Macros. COUNT is initialized by SET COUNT and it is both
decreased and then examined by IF COUNT. For example, the loop below executes
the interior commands four times -
SET COUNT 4 ; do this loop four times
:TOP ; a label for IF COUNT
<various commands go here>
IF COUNT GOTO TOP ; decrement COUNT. If COUNT is still
; non-zero then go to label TOP
The command
SET ALARM time
sets an internal alarm clock for use by IF ALARM. Time can be stated as the
number of seconds from now or as HH:MM:SS to specify a time of day. Trailing
SS seconds and MM minutes are optional; a 24 hour clock is used. Times should
not be more that 12 hours in the future so that Kermit can distinguish early
from late. The alarm time is zero until changed by this command, and IF ALARM
does not modify the alarm time. (Right. Now we need "set coffee-pot on"!)
When an IF statement is typed by hand the line is quietly absorbed if the
conditional test fails; otherwise, the line is broken automatically and the
<command> part is then entered at the normal Kermit prompt.
Examples:
IF NOT DEF \%3 DEF \%3 FOO.BAR ; supply a missing filename
IF DEF IBM DO IBM ; or "Don't DO nothing" (poor English)
IF NOT EXIST c:\dumm*.txt IF EXIST mskermit.ini RUN copy hither yon
One not so obvious use for the IF DEFINED command is to communicate status
between Take files or Macros. That is, a "DEFINE name text" command executed
in one can let another test that name for existence or not. DEFINE name no-text
undefines the macro. Thus, macro names can be used as semaphores or flags (one
bit variables).
Recall, the command "GOTO label" is needed to jump.
Here is a small example looking for modem text CONNECT 1200 or CONNECT 2400:
set speed 2400
output AT\13 ; awaken modem at desired speed
pause
output atdt 555-1212\13 ; dial the telephone
input 30 CONNECT ; first part of normal response
if failure goto hangup ; here "hangup" is a label
reinput 3 2400 ; did we connect at 2400 baud
if success goto login ; if so jump to login label
reinput 2 1200 ; how about 1200 baud
if fail goto hangup ; neither so quit
set speed 1200 ; slow down Kermit
:login
<do login stuff>
:hangup ; a label rather than a command
hangup ; disconnect telephone
echo \13That's all folks!\13\10
The commands
POP
STOP
provide clear exits from a Take file or a Macro. POP exits the current
Take file or Macro, and STOP exits all of them and gets back to the Kermit
prompt.
Before there are too many helpful suggestions in this area, and we could
use plenty, please note that the construction of Kermit command lines and the
parsing code impose limits on what can be accomplished. The command structure
is inadequate to support the syntax and notions of a modern programming
language without a complete redesign of much of MS Kermit. Plus, simplicity
does have a few benefits.
The INPUT command used to be the only one that began with "I", so many existing
scripts and macro definitions abbreviate INPUT this way. To preserve and
protect this work, I is recognized as an acceptable non-unique abbreviation for
INPUT.
The constructions shown above also work ok in Macros, given the 128 byte length
limit of a macro. GOTO produces a warning message if given by hand. Task
size increase has been reasonably small so far.
I think this is a close enough mimicry of Batch to control most scripts for
communications while avoiding the language development snarl. I'll let the
Hayes folks bask in the glory of auto-scripting.
On another front, I finally was able to borrow a PS/2 Model 50 for an evening.
First, I too saw the message that COM1 was not available. Thirty minutes later
everything was fine. That's the difference of being able to do rapid probes.
The new MSTIBM.BOO works well on the Model 50.
The problem area was in the recent code to automatically detect the IRQ value
for a serial port. Apparently PS/2's have enough differences in the timing
in that section to have confused the test code; the new material passes on
that machine and on my AT clone. Defensive action is indicated below.
The current test MS Kermit, dated 22 May 1988, still performs the automatic
IRQ test to assist unusually configured boards; but if the tests fail it
now reverts to choosing an IRQ value of 4, 3, 4, 3 for ports COM1, 2, 3, 4,
respectively, as was the case in version 2.30. PS/2 machines, Models 50 and
greater, will use IRQ 3 for COM2 in accordance with IBM specifications.
Second, reports of very large transfers not surviving a trip through some
recent test Kermits probably resulted from the receiver section tripping out
when a timeout or similar condition occurred. That produces an internal 'T'
packet but the receiver was not fully educated on them; it is ok now. I sent a
1.2MB file back and forth several times and pushed the Return key many times on
both sides, and so on with no premature failures. That's with recent code;
earlier stuff had the attribute of stopping after the first difficulty.
Third, incoming responses to REMOTE commands are now preceeded by a blank line
prevent some hosts from overwriting the local command line.
This is a good place to remark that some IBM hosts which recognize attributes
packets may send a file with a date but no time field. MS Kermit records the
time as all zeros and DOS interprets that as no time at all; this is a proper
result under the circumstances. Recognition of attributes packets can be
turned off by SET ATTRIBUTES OFF.
Fourth, the Tektronix emulator now recognizes ANSI.SYS style escape sequences
to change drawing colors. These are the same as in the VT102 emulator; vis
ESC [ Pn ; Pn ; .. m
where Pn represents an ascii number:
0 = set medium intensity white on black
1 = set high intensity foreground
30-37 = set foreground drawing color, 30 + sum of colors
40-47 = set background color, 40 + sum of colors
colors are 1 for red, 2 for green, 4 for blue, sum to get others.
Parameters are applied in the order received.
The Tektronix emulator assumes the colors of the VT102 emulator until given
it's own set, as above. Resetting the emulator (\Kreset or ALT =) returns to
the VT102 coloring set. Clearing the screen (reception of ESC Control-L)
employs the new background color.
The following MSTIBM.BOO can be posted for public inspection, with the reminder
that the script enhancements are still under active development and will
hopefully be improved soon.
Regards,
Joe D.
[Ed. - Once again, Joe, many thanks for all your careful and patient work.
We hope that the features described in this message, and the previous one
about "2.31-test4" will comprise the major changes for version 2.31, and
a formal announcement will appear soon, once the kinks are worked out of
the new code. Please test it on IBM PC's, compatibles, and near-compatibles
like the DG/1 and report any problems. The files are in MSTIBM.BOO and
MSTIBM.HLP in the Kermit distribution.]
------------------------------
Date: Fri, 20 May 88 15:26:25 +0200
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Extended ASCII with Kermit, For Kermit Developers
Keywords: Extended ASCII
ABSTRACT
In the course of implementing our own national character sets with Kermit
for terminal mode and file transfer, my understanding of the problem evolved
from confusion to (near) simplicity and from national to international. I
think my findings will be of much interest to those having to deal with the
Spanish, French, German, Italian, well, the American continent, Western
Europe and many other languages. That's, for them, really interconnecting
the majority of computers existing to-day.
On request, I've tried to be as short as possible at the risk of skimming
here and there. I sure won't blame those getting bored with the subject.
They can skip to the conclusion and see just what it takes in Kermit terms.
Conversely, those really interested will get more information from the
standards and the ISO8859 list of BITNET's LISTSERV @ JHUVM and its
archives.
Finally I take the occasion to praise all those devoting much of their time
to straightening things that had run havoc. It's their ideas I am conveying.
But I am sure glad to help. I just hope my limited English will carry the
message precisely.
DETAIL
In the process of implementing extended characters transfer between micros
and IBM mainframes, I relied on the extended capabilities of Kermit 370
conversion (thanks John!). I came to the conclusion that, for the sole IBM
PC, I should set up to 9 different tables in order to support 3 EBCDIC
tables x 3 "ASCII" tables. For the Macintosh, that's 3 more tables with the
IBM host. I was unable to have Kermit do Mac to IBM PC conversion, unless
endeavouring translation on the PC, 3 more tables or so.
I hacked some limited national characters support for IBMPC terminal mode
through the 7171, but our Mac users were left with a dumb nice keyboard and
a deaf screen.
Kermit implements two main files transfer modes.
Binary mode defines how to transport a continuous string of bytes containing
values only required to be meaningful to the originating and receiving final
systems. No matter how stored on an intermediate one, it should forward or
return the same byte string on the communication line. The point here is
that each node operation is clearly defined, making it the best method when
appropriate.
Text mode, in contrast, defines how to transport *records* containing codes
for "readable" characters intended to be usable -- and stored as such -- on
any system. The protocol rules how to, on the line, stream the records in a
system independent manner. Again, every node should forward the data
unaltered, that is equivalent communication line encoding.
The Kermit protocol wisely says that the ANSI X3.4 (ASCII) standard is to be
used to represent these characters. It is the code used on most computers
and those (IBM, Commodore) not using it have to deal with their own problem
of code conversion.
Most modern computers now implement an 8-bit extended character set in order
to support, to various extents, languages requiring characters not found in
ANSI X3.4 (I intentionally disregard the obsolete 7-bit remapping methods).
Almost each does it its own way however, because there was no standard at
the time they were devised (IBM even has multiple ones within a single
system).
Clearly, translation must occur somewhere to transmit extended text usefully
between them. If it is done say by running a program in the receiving
system, one must know and use the right table according to the sender. The
mere at least 7 codes that I have to deal with make for 5040 tables in
theory. In practice, what was a crystal clear matter as long as only X3.4
was used becomes a real puzzle with extended codes. As the number of tables
grows, so does the problem factorially.
To a lesser extent, the same problem holds for terminal mode. It occurs
only when a computer supports remote terminals, but we must fiddle with a
7-bit data path, an issue solved per se by the Kermit protocol in the first
case.
It is evident that the problem lies in each machine's dealing with the
others' own business, and that the solution is to have them talk a common
code on the line, as it is now with X3.4 and for those not using it.
Imposing them to use that code internally is impractical, although
recommendable. But having each convert the data to/from that common code
before/after transmission reduces the above example to a mere 6 tables
pairs.
What is striking is the technical simplicity of translating every character
data byte that flows on a communication line to a common code everyone
agrees about. What is sorry is that we have to. What is moot is what common
code should be used on the line.
It is my strong feeling that Kermit itself translating national codes to
make up for the lack of its host system using a standard will be *extremely*
useful for people having to use these codes. This feature must be optional,
because incompatible with previous use. It would be a shame to have two
Kermit implementations for the same system corrupt data because one uses
this feature and the other lacks it.
The cause of the problem, a missing standard, does no longer exist. ISO
8859/1 = ANSI X3.134.2 = ECMA 94 has been defined and gathers every possible
character extension for Latin group 1 users, by far the largest, plus other
common symbols satisfying many computer brands. It looks like a very well
thought out thing and several leading manufacturers have adopted it, or a
pre- release because they couldn't wait, or modified their previous codes to
conform to ISO (have exactly the same graphics, but use other codes points,
in line with this proposition). That's IBM, DEC, Microsoft and Lotus for
what I gathered. It looks like the future many, international and US, are
working for.
The on-the-way-ISO8859/x users should not be left out. The problem is
parallel, but their codes will be untranslatable to ours. They might be
expected to start with pure ISO right off. Until the 16 bits (some say 32)
codes sets will be devised, but that's our children's Kermit probably.
CONCLUSION
In summary, a Kermit implementation would be much enhanced for many people
if simply:
- it was optionally translating bytes during text mode file transfer (at the
file I/O or equivalent level). Nothing elaborate is required to start this.
Just a pair of null translation tables, easily found and patched, and a
couple of code lines will cover both the "translation" and "optional"
topics.
- it was doing the same at the communication line I/O level during terminal
mode and, when using 7-bits wide data path, implementing the ISO 2022 SO/SI
feature to use the upper half of the set (shift out) and revert to the lower
one (shift in). Several already do.
That's all. But a welcome leap further would be to:
- if a particular system does not conform to ISO (like the Mac, misses some
of its graphics or uses others), define a best fit one to one correspondence
between its character set(s) and ISO (there should be total agreement as to
which, up to with the manufacturer). It must involve the 256 codes in a
revertible way.
- have systems supporting terminals do it in ISO mode, preferrably on an
8-bit wide line.
- have these features bundled in options.
Thanks for your patience in reading.
Andr). Oops, not yet. Andre'.
[From Frank - This message is the tip of a large iceberg. Kermit does
indeed use 7-bit US ASCII with CRLF-terminated lines as the common
intermediate representation, or "transfer syntax", for text files. This has
been a great strength of Kermit, allowing text files to be transferred in
useful form between arbitrary systems. But the years since Kermit was
designed have witnessed the growth of widespread computing based on
non-ASCII alphabets, many of them 8-bit or 16-bit character sets that cannot
be mapped to 7-bit ASCII. Therefore, it would seem appropriate to do as
Andre and many others have suggested: allow for a selection of transfer
syntaxes. The mechanism would be something like SET TEXT {ASCII, ISO8859/1,
JIS, etc}, where the default would be ASCII, as now. This command would
select the character set to be used on the communication line during file
transfer. Similarly, a SET TERMINAL CHARACTER-SET command would govern the
transmission and display of text during terminal emulation. This would not
necessarily be the same as the one used in file transfer. Since not all
Kermit programs could be expected to support the same character sets (other
than ASCII), this could be a parameter specified in the Attributes packet
under the "encoding" attribute, which already includes an "A" parameter for
ASCII. New symbols would have to be defined for each alphabet, such as I1
for ISO8859/1, I2 for ISO8859/2, etc, J for JIS (is there more than one
variety of JIS), etc. Suggestions and discussion are welcome.]
------------------------------
Date: Tue, 5 Apr 88 15:28 EDT
From: CARTER%MITBATES.BITNET@CUVMA.COLUMBIA.EDU
Subject: Re: VAX/VMS Kermit "SET LINE" command
Keywords: VAX/VMS Kermit
Mike Rego asks:
>When trying to use the VAX/VMS "set line" command on KERMIT, I encounter a
>"no privilege for attempted operation". Does anybody know what VAX/VMS
>category privilege (e.g. netmbx,share) I must allow a user to enable the
>terminal line to be accessible to the user's processes?
READALL is not a privilege that you want to give out casually, as it allows
a user to read *any* file on the system regardless of access protections.
What we do here is to set the protection on the particular device such that
the world has read access. This allows a user with no special privileges to
connect to the device. The command is:
$ SET PROTECTION=(W:R) ddcu:/DEVICE
where ddcu: is the device you want users to have access to. I do not know of
any major security problems this creates.
Tony Carter
MIT Bates Linac
CARTER@MITBATES.BITNET
[Ed. - We received many replies similar to this one. Among them was the
suggestion that the above technique might make it possible for one user to
spy on another, with the workaround being something like:
$ SET PROTECTION=(W:RWLP)/DEVICE/OWNER=[1,4] TXA0:
There was also the idea of using access control lists for the dialout devices:
$ SET ACL/OBJECT=DEVICE/ACL=(IDENTIFIER=INTERACTIVE,OPTIONS=NONE,-
ACCESS=READ+WRITE) TXA10:
This technique also allows you to grant access to only certain authorized
users. In no case should users need to be given special privileges to assign
an external TTY line.]
------------------------------
End of Info-Kermit Digest
*************************
-------