home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
boo
/
boo-file.hints
next >
Wrap
Text File
|
1988-08-01
|
5KB
|
125 lines
11-Nov-87 11:01:04-EST,5187;000000000001
Return-Path: <FDCCU@CUVMA.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 11 Nov 87 11:00:57-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 11 Nov 87 11:00:16 EST
Received: by CUVMA (Mailer X1.25) id 3149; Wed, 11 Nov 87 11:00:12 EST
Date: 11/11 10:47:32
From: FDCCU@CUVMA
Subject: BOO BWR - PUN file from RSCS
Tag: FILE (4110) ORIGIN DBNUAMA1 RECK 11/11/87 6:05:41 E.S.T.
To: SY.FDC@CU20B
Reply-To: RECK%DBNUAMA1.BITNET@CUVMA.COLUMBIA.EDU
****** CC for you, Frank ******
By the way, I forgot: thanks very much for calling the admissions
people! I think my friend Christoph hasn't got anything yet, but of
course, ordinary mail is slow. Anyway, the delay has been accounted
for, and he is much calmer now.
From: RECK@DBNUAMA1.BITNET (Gisbert W.Selke)
To: PHIL@UIUCVMD (Phil Howard)
Date: 11 Nov 87
Re: BOO file problems (cf. last info-kermit digest)
No, I don't have the AMIGA Kermit, but:
I was doubting my sanity some time ago when I had serious problems with
MS-Kermit boo files, too. It turned out to be a local EBCDIC -> ASCII
conversion problem, and after some experimenting I found a way to get
my boo files transferred in a reliable way - the un-booed executables
do work.
The problem is mainly that the boo format uses all the characters from
ASCII-zero (ASCII 48) to ASCII-tilde (ASCII 126). Included in this set
are some characters for which no standard EBCDIC <-> ASCII conversion
rule exists; assuming that characters and digits are OK (they will be,
won't they?!?), the extra characters needed are:
colon ":"
semicolon ";"
less than "<"
equals "="
greater than ">"
question mark "?"
at-sign "@"
left square bracket "[" (at our place, EBCDIC hex 'AD')
backslash "\"
right square bracket "]" (at our place, EBCDIC hex 'BD')
caret, up-arrow "^" (in EBCDIC, usually negation sign)
underscore "_"
accent grave "`"
left curly brace "{"
vertical bar ":" (maybe "|" in some EBCDIC places)
right curly brace "}"
tilde, quiggle "~"
You should check if all these characters are transferred properly with
whatever procedure you use to get files to your Amiga. The ones that
caused trouble here were the up-arrow/negation-sign, the vertical bar
and the square brackets. So I used XEDIT to translate these particular
characters into inconspicuous sequences which got transferred properly;
I wrote the following XEDIT macro file to accomplish this:
SET LRECL 255
SET TRUNC 255
SET ARB OFF
SET HEX ON
TOP
* For transferring boo files to PC via IRMA board and IRMA software:
* translate characters which will not transfer properly otherwise:
:0 C /^/`not`/ * *
:0 C /|/`vba`/ * *
:0 C /X'AD'/`lbr`/ * *
:0 C /X'BD'/`rbr`/ * *
Remember to invoke XEDIT with a greater width, i.e.
XEDIT <file name> <file type> (width 255 noprof
This also makes sure you're not hampered by any profile which sets
trunc or lrecl to something inconvenient. Executing the above macro
file results in a file with greater line lengths: your file transfer
utility should be able to cope with that.
Also note that at some places, apparently ASCII left and right square
brackets are translated to EBCDIC "" (cent) and "|" (continuous
vertical bar), respectively; you might have to check that, although
I never encountered that with CUVMA files.
Well, I hope this at least gives you some clues, even if it isn't a
ready solution to your problem.
Happy kermitting,
\Gisbert
P.S.: I am enclosing a brief description of the boo format which
I prepared for a booing programme - for what it's worth.
C BOO FORMAT FILES
...
C
C IT IS NOT MEANT TO BE A TRANSFER PROTOCOL REPLACEMENT; IT
C JUST MAKES TRANSFER POSSIBLE ACROSS LINES (E.G., DATA NETWORKS)
C WHEN NO KERMITS ARE AVAILABLE OR ONE OF THEM CAN'T COPE WITH
C BINARY STUFF.
C
C BEWARE OF GREMLINS, THOUGH; ESPECIALLY EBCDIC <-> ASCII
C TRANSLATION MAY BE A PROBLEM FOR SOME OF THE CHARACTERS ...
C
C BASICALLY, 3 BYTES = 24 BITS ARE ENCODED INTO 4 CHARACTERS
C BY DIVIDING THEM INTO 6-BIT-PIECES AND THEN ADDING ASCII-ZERO
C TO MAKE THESE PIECES PRINTABLE. THE RESULT LIES IN THE RANGE
C ASCII-ZERO TO ASCII-SMALL-O. - IN ADDITION, NULL COMPRESSION
C TAKES PLACE; CONSECUTIVE NULL BYTES (WHICH OCCUR FREQUENTLY
C IN EXECUTABLE FILES, E.G.) ARE ENCODED WITH A TILDE LEAD-IN
C FOLLOWED BY THE NUMBER OF NULLS (UP TO 78), AGAIN RENDERED
C PRINTABLE BY ADDING ASCII-ZERO. THE RESULTING CHARACTER IS IN
C THE RANGE ASCII-ZERO (WELL, ASCII-TWO OR -THREE, REALLY) TO
C TILDE (ASCII CODE 126). - CHUNKS OF FOUR CHARACTERS BELONGING
C TOGETHER (RSP. TILDE AND NULL REPEAT COUNT) SHOULD NOT BE
C DIVIDED ACROSS LINES. A LINE HAS A MAXIMUM LENGTH OF 76
C CHARACTERS. - IN ADDITION, THE FIRST LINE OF THE FILE CONTAINS
C THE NAME OF THE ORIGINAL FILE (IF KNOWN - OTHERWISE A DUMMY NAME)
C AND NOTHING ELSE.
C