home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
ibm370
/
ibm370.txt
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
719KB
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Oct 29 08:45:40 1986
Flags: 000000000001
Mail-From: SY.FDC created at 29-Oct-86 08:45:36
Date: Wed 29 Oct 86 08:45:36-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Tuning length of long packets
To: PEPMNT@CFATA1, TUCBOB@TUCCVM, PEPAP@CFA1, RAF@NIHCU, TUCSEB@TUCC,
VVVCU@CUVMA.COLUMBIA.EDU, FDCCU@CUVMA.COLUMBIA.EDU, DEDOUREK@UNBMVS1,
GMW@PSUVM, UZ32112@BLIULG12, SYSBJAV@TCSVM, GUCJS@SEGUC21,
OC.AMS@CU20B.COLUMBIA.EDU, 26-377@HARVBUS1
In-Reply-To: Message from "(John F. Chandler) <PEPMNT@CFATA1>" of Tue 28 Oct 86 20:09:36-EST
Message-ID: <12250663704.155.SY.FDC@CU20B.COLUMBIA.EDU>
It's nice to keep the last packet in a retransmission buffer so you don't have
to recompute it each time. But if the packet simply cannot get through unless
it's shorter, then it makes good sense to try a new, shorter length. I'd
suggest something like this:
When computing the packet initially, save a pointer to some spot about halfway
through, where it can be legally broken (i.e. not in the middle of a quoted
sequence). If retransmission is necessary, insert the data from that point
onward to the beginning of a save-for-next-time buffer, recompute and insert
the new length and block check, and make a new halfway pointer. Repeat as
necessary (i.e. as long as the packet is NAK'd, or the previous packet is
ACK'd). Once the current packet is finally ACK'd, remember to fill subsequent
packets from the save-buffer till it's empty. (Alternatively, and perhaps
more simply, just back up the input file pointer and totally recompute
the whole packet for the new length).
It's a little hairy, but it may be necessary, especially in cases where the
user asks for packets longer than the transmission medium can handle. I'd
suggest the size be halved during backoff for rapid recovery, and then
gradually increased for each ACK. To prevent going through the same cycle
again when the maximum size is eventually exceeded, the program might want to
record the length of the longest successful packet, and make that the de facto
maximum length.
By the way, this technique should work just fine with "classic" synchronous,
stop-and-wait Kermit, but is totally inappropriate to sliding windows, in
which a whole list (of up to 31) packets must be maintained for retransmission.
- Frank
-------
From "John Voigt - Systems Group <SYSBJAV@TCSVM>" Wed Oct 29 13:22:56 1986
Flags: 000000000011
Return-Path: <SYSBJAV%TCSVM.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 29 Oct 86 13:22:51-EST
Received: from TCSVM(MAILER) by CUVMA (Mailer X1.23b) id 8081;
Wed, 29 Oct 86 12:00:41 EST
Received: by TCSVM (Mailer X1.23) id 5178; Wed, 29 Oct 86 09:55:22 CST
Date: Wed, 29 Oct 86 09:34:01 CST
From: John Voigt - Systems Group <SYSBJAV@TCSVM>
Subject: Re: Who's doing what
To: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>,
sy.christine@CU20B.COLUMBIA.EDU
>
>
>---------------------------Original message----------------------------
>Here's my list of people working on IBM mainframe Kermits, just so you all
>know who's who, and who's doing what. I also included at the bottom a
>couple notes about the wierd IBM systems -- if anybody knows more than I do
>& can correct any of it, please let me know. Same for the other entries.
>Anybody should feel free to contact anybody else to share ideas, code, etc.
>
>
>John Voigt
>Systems Group
>Tulane University Computer Center
>=N SYSBJAV@TCSVM.BITNET
>=D 19 Dec 85
>=S IBM 370 Series running MUSIC (McGill Univ System for Interactive Computing)
>=C Version 1.2 installed as of 19 Dec 85, further developments unknown
>
Frank: The above info is essentially correct. The version we have was ported
>From an old version developed by Indiana University. It was a conversion from
an early CMS version. We were looking into converting the latest CMS version
to add the new features that weren't included in the old CMS version. It has
come to my attention that you are in the process of trying to co-ordinate an
effort to modularize the IBM assembler versions and bring them all to the same
rev level. We will hold up on our effort until the common IBM code is complete
then we will add the necessary routines to make your version work with MUSIC.
Please keep me informed on progress toward unifying the IBM mainframe versions
and let me know if there is anything we can do to help.
----------
"Nine out of ten students who have tried UNIX go back to women."
----------
John Voigt
Coordinator of Electronic Campus Mail Systems
Systems Group - Computer Services Dept.
BITNET: SYSBJAV@TCSVM
ARPANET: SYSBJAV%TCSVM.BITNET@WISCVM.WISC.EDU
DEC2060: ZERO@DEC20R (now defunct)
DEC2050: JOHNV@ADM20R (soon to be defunct)
ATT: 504-865-5631
USPS: Room 102 Richardson Bldg
Tulane University
New Orleans LA 70118-5698
SHARE code: TUL
ICBM: 029N 58 090W 01
From "(John F. Chandler) <PEPMNT@CFATA1.BITNET>" Wed Oct 29 14:13:31 1986
Flags: 000000000011
Return-Path: <PEPMNT%CFATA1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 29 Oct 86 14:13:09-EST
Received: from CFATA1(PEPMNT) by CUVMA (Mailer X1.23b) id 8112;
Wed, 29 Oct 86 12:11:01 EST
Date: 1986 Oct 29 13:00 EDT
From: (John F. Chandler) <PEPMNT@CFATA1.BITNET>
To: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Tuning length of long packets
In-reply-to: SY.FDC@CU20B.COLUMBIA.EDU message of Wed 29 Oct 86 08:45:36-EST
Frank,
You have both PEPMNT@CFATA1 and PEPAP@CFA1 in the distribution, but mail
to the latter just gets forwarded to me here, so I would suggest sending
only to PEPMNT@CFATA1. As to the matter of packet-length tuning, I agree
that the halving you describe would be nice to have, but I think it would
take considerable effort to implement. The question remains, then, of
whether the quick-and-dirty tuning I proposed (keeping the last-attempted
packet through thick and thin) is worth installing. I've never had to
deal with a really noisy line for Kermiting, and I've never used long
packets, either, so I can't judge that.
John
From "(John F. Chandler) <PEPMNT@CFATA1.BITNET>" Wed Oct 29 14:13:31 1986
Flags: 000000000011
Return-Path: <PEPMNT%CFATA1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 29 Oct 86 14:13:09-EST
Received: from CFATA1(PEPMNT) by CUVMA (Mailer X1.23b) id 8112;
Wed, 29 Oct 86 12:11:01 EST
Date: 1986 Oct 29 13:00 EDT
From: (John F. Chandler) <PEPMNT@CFATA1.BITNET>
To: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Tuning length of long packets
In-reply-to: SY.FDC@CU20B.COLUMBIA.EDU message of Wed 29 Oct 86 08:45:36-EST
Frank,
You have both PEPMNT@CFATA1 and PEPAP@CFA1 in the distribution, but mail
to the latter just gets forwarded to me here, so I would suggest sending
only to PEPMNT@CFATA1. As to the matter of packet-length tuning, I agree
that the halving you describe would be nice to have, but I think it would
take considerable effort to implement. The question remains, then, of
whether the quick-and-dirty tuning I proposed (keeping the last-attempted
packet through thick and thin) is worth installing. I've never had to
deal with a really noisy line for Kermiting, and I've never used long
packets, either, so I can't judge that.
John
From "Roger Fajman <RAF@NIHCU>" Wed Oct 29 14:13:35 1986
Flags: 000000000001
Return-Path: <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 29 Oct 86 14:13:31-EST
Received: from NIHCU(MAILER) by CUVMA (Mailer X1.23b) id 8384;
Wed, 29 Oct 86 13:31:31 EST
To: "Bob Bolch" <TUCBOB@TUCCVM>,
"Steve Blankinship" <TUCSEB@TUCC>,
"John Chandler" <PEPMNT@CFATA1>,
"Frank da Cruz" <SY.FDC@CU20B.COLUMBIA.EDU>,
"John DeDourek" <DEDOUREK@UNBMVS1>,
"Vace Kundakci" <VVVCU@CUVMA>,
"George M. Weaver" <GMW@PSUVM>
From: "Roger Fajman" <RAF@NIHCU>
Date: Wed, 29 Oct 86 13:32:14 EST
Subject: Kermit
That method of adjusting the packet size sounds as reasonable to me
as anything that I have thought of.
I built an analytic model of Kermit and made graphs of throughput
vs. packet size under various assumptions of line speed, error rate,
and ACK delay time. I'll be glad to send a copy to anyone who gives
me their postal address.
Regarding a UNIT parameter: it would not be useful to us here, as
we set the UNIT name in the dynamic allocation exit. I really don't
know whether there might be a use for it in other installations.
The TSO ALLOCATE command supports a UNIT option, but most other
things don't.
Roger
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Thu Oct 30 09:08:26 1986
Flags: 000000000001
Mail-From: SY.FDC created at 30-Oct-86 09:08:23
Date: Thu 30 Oct 86 09:08:23-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Discussion list
To: RAF@NIHCU
In-Reply-To: Message from ""Roger Fajman" <RAF@NIHCU>" of Wed 29 Oct 86 19:56:16-EST
Message-ID: <12250929996.140.SY.FDC@CU20B.COLUMBIA.EDU>
Hmmm... I'm not sure I know who they all are. The UZ guy is the one from
Belgium. OC.AMS is Bill Hall, who wrote one of the MTS Kermits. 26-377 is
somebody that John Chandler started including in his mailings. I think the
GUCJS guy is the one in Sweden who's responsible for GUTS. - Frank
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Oct 31 09:22:35 1986
Flags: 000000000001
Mail-From: SY.FDC created at 31-Oct-86 09:22:23
Date: Fri 31 Oct 86 09:22:23-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Test message for IBM 370 Kermit folks
To: IBM-Kermit@CU20B.COLUMBIA.EDU
cc: sy.christine@CU20B.COLUMBIA.EDU
Message-ID: <12251194689.158.SY.FDC@CU20B.COLUMBIA.EDU>
I set up a mailing list at CU20B for this discussion. If you mail to
IBM-KERMIT@CU20B, it'll go to everybody (the list is not moderated).
Here's what the list looks like currently:
IBM-Kermit:
papa%USC-CSE.CSNET@CSNET-RELAY, ! Marco Papa, USC (CMS) !
OC.AMS@CU20B.COLUMBIA.EDU, ! Bill Hall, Bell Labs (MTS) !
SY.FDC@CU20B.COLUMBIA.EDU, ! Frank da Cruz, CU (Kermit) !
"Samuel_Lam%UBC.MAILNET"@MIT-MULTICS, ! Samuel Lam, U of BC (???) !
UZ32112%BLIULG12.BITNET@WISCVM.WISC.EDU, ! (don't remember who this is) !
CMSMAINT%BROWNVM.BITNET@WISCVM.WISC.EDU, ! Peter DiCamillo, Brown (CMS) !
PEPMNT%CFATA1.BITNET@WISCVM.WISC.EDU, ! John Chandler, Harvard (CMS) !
VVVCU%CUVMA.BITNET@WISCVM.WISC.EDU, ! Vace Kundakci, CU (CMS) !
26-377%HARVBUS1.BITNET@WISCVM.WISC.EDU, ! ???, Harvard (CMS?) !
RAF%NIHCU.BITNET@WISCVM.WISC.EDU, ! Roger Fajman, NIH (TSO) !
GMW%PSUVM.BITNET@WISCVM.WISC.EDU, ! George Weaver, Penn State (???) !
GUCJS%SEGUC21.BITNET@WISCVM.WISC.EDU, ! Jon Scott, Gothenburg U (GUTS) !
SYSBJAV%TCSVM.BITNET@WISCVM.WISC.EDU, ! John Voigt, Tulane (MUSIC) !
TUCBOB%TUCCVM.BITNET@WISCVM.WISC.EDU, ! Bob Bolch, Tulane (CMS) !
TUCSEB%TUCC.BITNET@WISCVM.WISC.EDU, ! Steve Blankinship, Tulane (CMS) !
DEDOUREK%UNBMVS1.BITNET@WISCVM.WISC.EDU, ! John Dedourek, U of NB (TSO?) !
KOVACHDG%UREGINA1.BITNET@WISCVM.WISC.EDU, ! Don Kovach, U of Regina (???) !
SYSRONR%UCHIMVS1.BITNET@WISCVM.WISC.EDU ! Ron Rusnak, U of Chicago (TSO) !
Note that routing is all through the Wisconsin gateway, which is currently
necessary for mailing lists (but CU20B and CUVMA might also be able to fill
this role soon).
The mail archive of the discussion so far has been put in KER:IBM370.TXT
on CU20B, and should find its way onto BITNET KERMSRV within a few days.
Holler if you want off, have corrections, additions, problems, or need
anything else.
- Frank
-------
From Samuel_Lam%UBC.MAILNET@MIT-MULTICS.ARPA Sat Nov 1 21:39:11 1986
Flags: 000000000011
Return-Path: <@MIT-MULTICS.ARPA:Samuel_Lam@UBC.MAILNET>
Received: from MIT-MULTICS.ARPA by CU20B.COLUMBIA.EDU with TCP; Sat 1 Nov 86 21:39:08-EST
Received: from UBC.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708733682139963@MIT-MULTICS.ARPA>; 01 Nov 1986 21:01:22 est
Date: Fri, 31 Oct 86 22:02:56 PST
From: Samuel_Lam%UBC.MAILNET@MIT-MULTICS.ARPA
To: SY.FDC@CU20B.COLUMBIA.EDU
Message-ID: <428232@UBC.MAILNET>
Subject: Re: Test message for IBM 370 Kermit folks
Frank, I have some changes to request already... (Don't things change
fast nowadays!)
Three things so far:
Please send to <"IBM-Kermit%UBC.Mailnet"@MIT-Multics> instead,
This is a local redistribution address we just set up.
The local contact is now Bruce Jolliffe (<"Bruce_Jolliffe@UBC...>).
He manages the local redistribution of this list now.
Our main operating system here is MTS (Michigan Terminal System),
but we have a little TSO as well.
Thanks very much.
...Sam
From Bruce_Jolliffe%UBC.MAILNET@MIT-MULTICS.ARPA Mon Nov 3 22:59:09 1986
Flags: 000000000011
Return-Path: <@MIT-MULTICS.ARPA:Bruce_Jolliffe@UBC.MAILNET>
Received: from MIT-MULTICS.ARPA by CU20B.COLUMBIA.EDU with TCP; Mon 3 Nov 86 22:59:03-EST
Received: from UBC.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2708911833943175@MIT-MULTICS.ARPA>; 03 Nov 1986 22:30:33 est
Date: Mon, 3 Nov 86 13:43:10 PST
From: Bruce_Jolliffe%UBC.MAILNET@MIT-MULTICS.ARPA
To: sy.fdc@cu20b.columbia.edu
Message-ID: <429544@UBC.MAILNET>
Subject: MTS Kermit and Your Book
Thanks for the prompt mailing of your new book. Also, I'm glad
the long lost MTS Kermit has been found. I wondered what had happened
to the beast. It is probably long out of date. We distribute
the program privately through our own channels to our sister
sites.
Sam has given me a copy of the discussions on the attempt at
consolidating the 370 versions. That is no easy task considering
the number of environments out there. For instance within the
MTS community there are three different network "front ends".
Which means MTS Kermit has to know what site it is running at.
Also our Kermit is written in a higher level systems language
that is a cross between C and Pascal. Still I will track the
discussions closely.
-- Bruce Jolliffe
From Bruce_Jolliffe%UBC.MAILNET@MIT-MULTICS.ARPA Wed Nov 5 15:29:25 1986
Flags: 000000000011
Return-Path: <@MIT-MULTICS.ARPA:Bruce_Jolliffe@UBC.MAILNET>
Received: from MIT-MULTICS.ARPA by CU20B.COLUMBIA.EDU with TCP; Wed 5 Nov 86 15:28:58-EST
Received: from UBC.MAILNET by MIT-MULTICS.ARPA with Mailnet id <2709058745132327@MIT-MULTICS.ARPA>; 05 Nov 1986 15:19:05 est
Date: Wed, 5 Nov 86 08:57:08 PST
From: Bruce_Jolliffe%UBC.MAILNET@MIT-MULTICS.ARPA
To: SY.FDC@CU20B.COLUMBIA.EDU
Message-ID: <431311@UBC.MAILNET>
Subject: Re: MTS Kermit and Your Book
When I started the Kermit project a couple of years ago I took
a look at the existing MTS Kermit implementations that you currently
distribute on the Kermit tape (Pascal and Assembler). I discovered
that they didn't work and were very minimal attempts. Neither of
those implementations were put into production.
Currently the PLUS version is in production at the University of
British Columbia, Simon Fraser University, University of Alberta,
Rensselaer Polytechnic Institute, and the University of Michigan.
There are some differences in the UM version from the base version
used elsewhere but we hope to re-incorporate those differences
into our base version. Richard Conto at UM was the chap who did
additional work to the UM version.
I think there would be some reluctance to using the assembler version
as it stands but if it could be sufficiently modularized so that operating
system and "front end" dependancies are isolated it could be considered.
We will be connecting directly to BITNET in the near future. RPI has
already started production of this service and we should be soon. I'll
let you know when we cut over.
Hope these answer your questions.
-- Bruce
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Nov 5 16:06:18 1986
Flags: 000000000001
Mail-From: SY.FDC created at 5-Nov-86 16:06:16
Date: Wed 5 Nov 86 16:06:16-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: MTS Kermit and Your Book
To: Bruce_Jolliffe%UBC.MAILNET@MIT-MULTICS.ARPA
In-Reply-To: <431311@UBC.MAILNET>
Message-ID: <12252578932.157.SY.FDC@CU20B.COLUMBIA.EDU>
The entire purpose of modularizing the new assembler version is to make
it easily adaptable to systems like MTS. I'd heartily recommend you jump
into the discussion. You might begin by sending a message to IBM-KERMIT@CU20B
describing your special requirements for MTS, the various front ends, etc.,
and inquire if the work that's been done so far meshes with these, and see
what comes back. Thanks! - Frank
-------
From "(John F. Chandler) <PEPMNT@CFATA1>" Mon Nov 10 15:34:20 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFATA1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 10 Nov 86 15:34:05-EST
Received: from CFATA1(PEPMNT) by CUVMA (Mailer X1.23b) id 0300;
Mon, 10 Nov 86 15:32:27 EST
Date: 1986 Nov 10 14:40 EST
From: (John F. Chandler) <PEPMNT@CFATA1>
To: <IBM-KERMIT@CU20B>
Subject: TSO version of Kermit
I haven't seen either of the new TSO Kermits, but I assume they are far
beyond the capabilities of the old ones now on KERMSRV. I am asuming
that they support the following syntax forms for datasets in user
commands:
'dsn' or 'dsn(memb)' or udsn or udsn(memb)
where dsn is a fully-qualified DSN and udsn omits the current prefix,
if any. It seems reasonable to convert all of those into an internal
form consisting of a 52-byte string made up of 44 bytes of DSN and 8
bytes of member name (or blank), i.e., just what is found in the JFCB.
1. Is there (or should there be) the option of specifying '*' for the
member name, possibly sending the whole PDS in the form of IEBUPDTE
input?
2. Is there (or should there be) wildcard matching in the DSN as well?
3. Is there an obvious way of extracting a 'name.type' from 'dsn(memb)',
e.g., name=memb, type=last level index of dsn?
4. If the user types an invalid DSN, say, in a RECEIVE command, should
Kermit (a) reject the command or (b) fix the name by
i. truncating indices to 8 characters, if necessary,
ii. changing the 1st character of each index to alpha/nat'l (say, @),
if necessary, and
iii. changing other characters to alphameric, if necessary?
5. On receiving a file header with 'name.type' such that either part of
the name is invalid as a cataloged DSN index, should Kermit follow
plan 4.b? To avoid the possibility of cataloging problems, how
about saving RECEIVE'd files as 'prefix.KERCV.name.type', where
KERCV could be an option (like the prefix)? The user would be
expected to have only 4-level DSN's in that part of the catalog.
In case of filename collision there could be parallel indices
KERCV01, KERCV02, etc., to try out in the search for unique filenames.
On another note: it has been suggested that a fullword be reserved in
the common variables section for version-dependent functions. Is there
a general need for such a reservation (i.e., in at least two different
operating systems), or should that be relegated to the version-dependent
macro FILES, which defines system-dependent constants and initialized
variables?
John
From "Roger Fajman <RAF@NIHCU>" Mon Nov 10 21:52:04 1986
Flags: 000000000001
Return-Path: <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 10 Nov 86 21:51:58-EST
Received: from NIHCU(MAILER) by CUVMA (Mailer X1.23b) id 0847;
Mon, 10 Nov 86 17:49:58 EST
To: ibm-kermit@cu20b.columbia.edu
From: "Roger Fajman" <RAF@NIHCU>
Date: Mon, 10 Nov 86 17:50:31 EST
> I haven't seen either of the new TSO Kermits, but I assume they are far
> beyond the capabilities of the old ones now on KERMSRV. I am asuming
> that they support the following syntax forms for datasets in user
> commands:
> 'dsn' or 'dsn(memb)' or udsn or udsn(memb)
> where dsn is a fully-qualified DSN and udsn omits the current prefix,
> if any. It seems reasonable to convert all of those into an internal
> form consisting of a 52-byte string made up of 44 bytes of DSN and 8
> bytes of member name (or blank), i.e., just what is found in the JFCB.
Yes, NIH TSO Kermit supports all of those forms.
> 1. Is there (or should there be) the option of specifying '*' for the
> member name, possibly sending the whole PDS in the form of IEBUPDTE
> input?
We don't support it now, but plan to in the future.
We will send each member as a separate file.
> 2. Is there (or should there be) wildcard matching in the DSN as well?
We support one wild in the data set name. It will match
periods, as well as other characters.
> 3. Is there an obvious way of extracting a 'name.type' from 'dsn(memb)',
> e.g., name=memb, type=last level index of dsn?
We use the member name as the file name, with no extension.
> 4. If the user types an invalid DSN, say, in a RECEIVE command, should
> Kermit (a) reject the command or (b) fix the name by
> i. truncating indices to 8 characters, if necessary,
> ii. changing the 1st character of each index to alpha/nat'l (say, @),
> if necessary, and
> iii. changing other characters to alphameric, if necessary?
In the case of RECEIVE, we issue a message and prompt for a correct
name. In the case, of GET, where it is not possible to prompt,
altering the name could be a useful thing to do, as long as it is
under control of a user-settable option.
I suggest something like the following:
(1) Change invalid characters to #.
(2) If the first character following a period is invalid,
insert a #.
(3) Truncate index levels that are longer than 8 characters.
> 5. On receiving a file header with 'name.type' such that either part of
> the name is invalid as a cataloged DSN index, should Kermit follow
> plan 4.b? To avoid the possibility of cataloging problems, how
> about saving RECEIVE'd files as 'prefix.KERCV.name.type', where
> KERCV could be an option (like the prefix)? The user would be
> expected to have only 4-level DSN's in that part of the catalog.
> In case of filename collision there could be parallel indices
> KERCV01, KERCV02, etc., to try out in the search for unique filenames.
Fix the name, if the user has so requested via a settable option.
Don't use KERCV. Cataloging problems should be treated as a
data set name collision.
> On another note: it has been suggested that a fullword be reserved in
> the common variables section for version-dependent functions. Is there
> a general need for such a reservation (i.e., in at least two different
> operating systems), or should that be relegated to the version-dependent
> macro FILES, which defines system-dependent constants and initialized
> variables?
I haven't studied your proposal enough to say.
> John
Roger
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Tue Nov 11 10:02:04 1986
Flags: 000000000001
Mail-From: SY.FDC created at 11-Nov-86 10:02:00
Date: Tue 11 Nov 86 10:02:00-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: TESTING
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Message-ID: <12254085483.64.SY.FDC@CU20B.COLUMBIA.EDU>
TESTING
-------
From BENNO@HROEUR1.BITNET Tue Nov 11 10:27:05 1986
Flags: 000000000001
Return-Path: <BENNO%HROEUR1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 11 Nov 86 10:27:00-EST
Received: from HROEUR1(BENNO) by CUVMA (Mailer X1.23b) id 2859;
Tue, 11 Nov 86 09:45:21 EST
Date: Tue, 11 Nov 86 15:38:35 EST
To: IBM-Kermit@CU20B.COLUMBIA.EDU
From: BENNO@HROEUR1.BITNET
Subject: Some questions (again)
(This is a repost; the previous message probably is lost somewhere)
Here's my reply to Frank's quesion.
I read in notes I received earlier that there has been a proposal
for a kernel. I would like to see that one too...
Did anyone of you look at the way KERMIT-4.x (UNIX) is done ??
I liked it, and it might be a good reference.
We might even think of coding the system-independent code in C,
translating this in assembler and adding the system-dependent
stuff later. Reasons to do it that way are:
- most off the system-independent stuff already has been written
in C, so the effort would be minimised;
- debugging will be easier;
- updates could be done together with people maintaining other
kermit-implementations.
Maybe this discussion has been held before, but I only just entered...
Ben Noordzij.
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Tue Nov 11 13:30:07 1986
Flags: 000000000001
Mail-From: SY.FDC created at 11-Nov-86 13:29:55
Date: Tue 11 Nov 86 13:29:55-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [FDCCU@CUVMA: YMUMMD MAIL - PUN file from RSCS]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12254123334.64.SY.FDC@CU20B.COLUMBIA.EDU>
More potential new TSO Kermits crawling out of the woodwork. I'll add him
to the list. John, you might want to forward him a copy of your proposed
portable 370 Kermit structure. - Frank
---------------
Return-Path: <FDCCU%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 11 Nov 86 12:43:09-EST
Received: by CUVMA (Mailer X1.23b) id 3665; Tue, 11 Nov 86 12:00:11 EST
Date: 11/11 11:45:12
From: FDCCU@CUVMA
Subject: YMUMMD MAIL - PUN file from RSCS
Tag: FILE (8154) ORIGIN UKACRL MAILER 11/11/86 10:33:41 E.S.T.
To: SY.FDC@CU20B
Reply-To: MAILER@UKACRL
Received: By UK.AC.RL.IB (MAILER) ; Tue, 11 Nov 86 15:33:41 GMT
Via: UK.AC.UMIST.CN.PA; 11 NOV 86 15:33:23 BST
From: Mike Glendinning <YMUMMD%UK.AC.UMIST.CENTRAL-SERVICES.PRIME-A@AC.UK>
To: FDCCU@CUVMA
Date: Tue, 11 Nov 86 13:48:08 GMT
Message-Id: <$RWJRDJXFBWWV at UMPA>
Subject: Re: Call for IBM mainframe Kermit developers.
In response to your request on Info-Kermit Digest volume 5, number 14,
we (at the University of Manchester) have been intending to implement
a variant of TSO Kermit under ROSCOE/ETSO. Obviously we would
be very interested to hear of any new developments in Kermit for
either TSO or CMS.
-- Mike Glendinning
University of Manchester Regional Computer Centre
England.
-------
From BENNO@HROEUR1.BITNET Tue Nov 11 23:56:04 1986
Flags: 000000000001
Return-Path: <BENNO%HROEUR1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 11 Nov 86 23:55:51-EST
Received: from HROEUR1(BENNO) by CUVMA (Mailer X1.23b) id 6362;
Tue, 11 Nov 86 23:54:26 EST
Date: Tue, 11 Nov 86 10:11:29 EST
To: IBM-Kermit@CU20B.COLUMBIA.EDU
From: BENNO@HROEUR1.BITNET
Subject: Some questions and a proposal .......
(This is a repost; the previous message probably is lost somewhere)
Here's my reply to Frank's quesion.
I read in notes I received earlier that there has been a proposal
for a kernel. I would like to see that one too...
Did anyone of you look at the way KERMIT-4.x (UNIX) is done ??
I liked it, and it might be a good reference.
We might even think of coding the system-independent code in C,
translating this in assembler and adding the system-dependent
stuff later. Reasons to do it that way are:
- most off the system-independent stuff already has been written
in C, so the effort would be minimised;
- debugging will be easier;
- updates could be done together with people maintaining other
kermit-implementations.
Maybe this discussion has been held before, but I only just entered...
Ben Noordzij.
From BENNO%HROEUR1.BITNET@WISCVM.WISC.EDU Wed Nov 12 04:32:52 1986
Flags: 000000000001
Return-Path: <BENNO%HROEUR1.BITNET@WISCVM.WISC.EDU>
Received: from WISCVM.WISC.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 12 Nov 86 04:32:43-EST
Received: from (BENNO)HROEUR1.BITNET by WISCVM.WISC.EDU on 11/11/86 at
11:21:24 CST
Date: Tue, 11 Nov 86 09:52:20 EST
To: IBM-Kermit@CU20B.ARPA
From: BENNO%HROEUR1.BITNET@WISCVM.WISC.EDU
Subject: Some questions .....
From: BENNO at HROEUR1
To: IBM-KERMIT at CU20B.COLUMBIA.EDU
Here's my reply to Frank's quesion.
I read in notes I received earlier that there has been a proposal
for a kernel. I would like to see that one too...
Did anyone of you look at the way KERMIT-4.x (UNIX) is done ??
I liked it, and it might be a good reference.
Ben Noordzij.
From "(John F. Chandler) <PEPMNT@CFATA1.BITNET>" Wed Nov 12 19:53:38 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFATA1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 12 Nov 86 19:53:32-EST
Received: from CFATA1(PEPMNT) by CUVMA (Mailer X1.23b) id 0809;
Wed, 12 Nov 86 19:52:10 EST
Date: 1986 Nov 12 14:21 EST
From: (John F. Chandler) <PEPMNT@CFATA1.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Re: Some questions (again)
In-reply-to: BENNO@HROEUR1.BITNET message of Tue, 11 Nov 86 15:38:35 EST
The notion of borrowing the existing 'system-independent' part of C-Kermit
is interesting, but fraught with problems. Since the distribution copy
would be in assembly language anyway, an update (even a very simple one)
would be a complicated process of sending the change to the maintainer
of the C-language source, applying the update there, re-translating to
assembler, making any overriding changes to the new assembler version to
make it runnable in a non-C environment, and finally sending out the
whole new source (unless the compiler can be persuaded not to make any
sweeping changes in register allocation or whatever in light of the
C-source change, in which case the new assembler source could be compared
with the old one and converted into an update). I, for one, do not use
C and do not know of any place around here with a C compiler for IBM 370.
From "(John F. Chandler) <PEPMNT@CFATA1>" Thu Nov 13 14:46:09 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFATA1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 13 Nov 86 14:42:27-EST
Received: from CFATA1(PEPMNT) by CUVMA (Mailer X1.23b) id 4160;
Thu, 13 Nov 86 14:40:24 EST
Date: 1986 Nov 13 11:54 EST
From: (John F. Chandler) <PEPMNT@CFATA1>
To: <IBM-KERMIT@CU20B>
Subject: Revised skeleton
Following Sam Lam's suggestion I will use the terms "specific" and "generic"
instead of "system-dependent" and "system-independent", since the latter
pair are so long and so similar. I have now tested all the parts of the
TSO-specific code that CMS will support (storage alocation, terminal I/O,
and disk open/close/read/write) and am more confident that the following
skeleton has stabilized. As before, I have included the common variables
and some of the constants as well as the imbedded entry-point descriptions
and generic-looking code in the specific subroutines. Unfamiliar op-codes
are Kermit macros, either generic (like PTEXT, which sets up string
pointers) or specific (like DMSFREE, which assigns free storage, or OPENF,
which opens/tests a file). The reentrancy is embodied in macros ENTER,
LOCALS, and EXIT (which are all generic). It is possible to have two or
more entry points in the same CSECT (using ENTER ALT), but the reasons for
joining entries in the specific code will, of course, depend on the operating
system. Also, in some operating systems complete reentrancy is neither
necessary nor convenient (witness variables *before* the LOCALS stmt in
the SVC interception code). I will now state as many of the hidden
assumptions built into this design as I can think of:
1. IBM mainframe I/O is record-oriented.
2. Free static storage can be assigned for the duration of execution.
3. A given character string can be passed (doctored, if need be) to the
operating system for execution as a command. This isn't absolutely
essential, except to enable the "SET SYSCMD ON" Kermit command.
4. Terminal output can be intercepted somehow and saved in a buffer.
5. Kermit at entry has R13->save area, R14->return adr, R15->Kermit.
Otherwise, the ENTER and RET macros are not generic.
6. A file specification will fit into a string of no more than 256 bytes.
7. The File Access Block (that's generic -- TSO-specific = DCB,
CMS-specific = FSCB, etc.) will fit into a relatively short area.
8. The file attributes of possible interest for opening a new file are
block size, logical record length, volume, unit, record format, and
allocation increment (in addition to the name and possibly the size
in Kbytes).
Here follows the skeleton:
---------
------ COMMON STORAGE -------
* Send prompt to Micro CCW 01255700
S1XOPL DC A(S1XON,S1ORDL+1) For sending prompt @SC86295 01256000
S1XON DC X'&S1CMD',AL1(SBA),X'5D7F',AL1(SBA),X'0005' @SC86295 01256300
S1ORDL EQU *-S1XON @SC86295 01256600
DC AL1(CR) @SC86295 01256900
XONCHAR DC AL1(XON) @SC86121 01269000
XLFCT DC A(KMAXF) Extended packet size base @SC86202 01308000
AKMIN DC A(KMIN) Packet min size @SC86295 01309000
AMAXWT DC A(MAXWT) Longest terminal write @SC86295 01309200
AMAXRT DC A(MAXRT) Longest terminal read @SC86295 01309400
F64KP DC A(((&MAXLR+15)/8)*8) Size of disk buffers @SC86295 01309600
F0 DC F'0' 01310000
F1 DC F'1' 01311000
F2 DC F'2' 01312000
F3 DC F'3' @SC86295 01312500
F5 DC F'5' 01313000
F8 DC F'8' 01314000
F12 DC F'12' 01315000
F32 DC F'32' 01318000
F64 DC F'64' 01319000
BLANK EQU F64+3 EBCDIC blank @SC86295 01319500
F DC F'15' 01320000
MOD64 DC F'63' 01321000
F256 DC F'256' 01325000
SPACE DC A(ABL) ASCII SPACE 01329000
LOBIT DC X'0000007F' 01333000
* Parameter defaults. Must map directly into DEFPARM etc. 01334000
KSYSTF , @SC86295 01335000
....
...
MAXBSZ DC F'&MAXBS' Max blksiz @SC86268 01397000
BUFSIZ DC Y(LPKT) Length of packet buffers @SC86190 01403000
* 01404000
* Constants for COMMON 01409000
LTORG 01410000
* Translation for conversion to hex notation @SC86156 01413000
TRHEX EQU *-240 @SC86156 01414000
DC C'0123456789ABCDEF' @SC86156 01415000
TITLE 'Variable storage for Kermit-370' 01480000
STORAG DSECT 01480040
* - - - Translate tables (user-settable or program-modified) 01480080
TRTBL DS CL256 For finding blanks @SC86295 01480120
ATOE DS CL256 For converting to EBCDIC @SC86295 01480160
ETOA DS CL256 For converting to ASCII @SC86295 01480200
UPCASE DS CL256 For upcasing EBCDIC @SC86295 01480240
OFF80 DS CL256 For removing x'80' bits @SC86295 01480280
* - - - Variables initialized to zeroes 01480320
SCANPTR DS 0D Len and address of parse buffer 01480360
LEN DS F 01480400
ADR DS F 01480440
SCANSV DS D Saved len and adr @SC86295 01480480
CMD DS CL256 Buffer @SC86121 01480520
CBUF DS A Address of CP response buffer @SC86121 01480560
DATL DS F Send packet size @SC86121 01480600
FDATE DS F Date of current file @SC86295 01480640
KBYTES DS F Size of current file @SC86158 01480680
FL1 DS X Use to test our flags @SC86121 01480720
FL2 DS X For local settings @SC86121 01480760
FL3 DS X More for local settings @SC86121 01480800
FL4 DS X More ... @SC86158 01480840
FL5 DS X More ... @SC86171 01480880
SEQ DS X Current pkt number @SC86135 01480920
RSN DS X Received pkt number @SC86135 01480960
RBUF DS A Addr of FSREAD buffer @SC86121 01481000
CLEN DS A Length of non-tokenized parm @SC86121 01481040
NSENT DS F Number of files sent @SC86121 01481080
TSENT DS F Pointer to sent files table @SC86121 01481120
IOERC DS F Error count to detect loops @SC86158 01481160
TXTPTR DS 2F Ptrs to start and end of text @SC86158 01481200
RBUFL DS F Record len (if recfm = V) @SC86121 01481240
RDWLEN DS F Record descriptor length @SC86151 01481280
SNDPKL DS F SNDPKT length for I/O @SC86295 01481320
RCVPKL DS F RCVPKT length after I/O @SC86295 01481360
APKT DS A Ptr to packet buffer @SC86190 01481400
ASPKT DS A Ptr to effective send packet @SC86190 01481440
AASPKT DS A Ptr to send packet @SC86190 01481480
ASDATA DS A Ptr to data to send @SC86190 01481520
ARPKT DS A Ptr to receive packet buffer @SC86190 01481560
ARDATA DS A Ptr to received data @SC86190 01481600
FILPTR DS A Ticket for FILNAM file I/O @SC86295 01481640
LOGPTR DS A Ticket for LOG file I/O @SC86295 01481680
TOUTOT DS 2F I*8 count of bytes sent @SC86295 01481720
TINTOT DS 2F I*8 count of bytes received @SC86295 01481760
DSKTOT DS 2F I*8 count of disk I/O bytes @SC86295 01481800
PAKCNT DS F Number of packets sent/received @SC86295 01481840
RTRCNT DS F Number of retries @SC86295 01481880
SECTOT DS F Duration of transfer (sec) @SC86295 01481920
LSTATS EQU *-TOUTOT Size of area to initialize @SC86295 01481960
PREFIX DS X,CL(FORMAXL) Prefix count and buffer @HF86223 01482000
SUFFIX DS X,CL(FORMAXL) Suffix count and buffer @HF86223 01482040
JFSPEC DS X Length of foreign filespec @SC86224 01482080
JFNAM DS CL47 Filespec @SC86224 01482120
FILNAM DS CL(LFID) SEND/REC filename @SC86295 01482160
DS 0F @SC86295 01482200
IFILE DS CL(LFID) Name of file(s) to send @SC86295 01482240
LIMTRY DS F Max packet retries 01482280
FREEDW DS F Size of aux. storage @SC86295 01482320
STKPTR DS F Current stack end @SC86295 01482360
STKLIM DS F End of stack storage @SC86295 01482400
EVCTR DS F Count of files opened @SC86295 01482440
EMSGP DS A Ptr to micro message @BS86090 01482480
EMSGL DS F Length of msg @BS86090 01482520
LEMSG EQU 64 Max msg length kept @SC86295 01482560
RBUFP DS F RBUF pointer 01482600
WBUFL DS F Data length in WBUF 01482640
MAXSIZ DS 2A(KDEF-16) Max pkt size sent 01482680
ORGR1 DS F Saved R1 at main entry @SC86295 01482720
* Plists for reading and writing in protocol mode 01482760
S1WRPL DS 2F Address, length of data to send @SC86295 01482800
S1RDPL DS A(0,LPKT+3) For reading data (max length) @SC86295 01482840
* 01482880
TYWRPL DS 2F Address, length of data to send @SC86295 01482920
TYRDPL DS A(0,LPKT) For reading data (max length) @SC86295 01482960
* 01483000
RIOC DS F Saved data length from prev read @SC86295 01483040
S1DATA DS XL(S1ORDL) Write or write/read orders @SC86295 01483080
WRRD EQU *-1 Zap this to 0 for just write @SC86295 01483120
* 01483160
PREV DS C Previous char decoded 01483200
* - - - Variables initialized via block MVC's 01483240
KSYSTF , @SC86295 01483280
* Specifications for LOG file @SC86295 01483320
LOGFDB DS 0F @SC86295 01483360
DS Y(5,LPKT+8) TRKAL, BLKSI @SC86295 01483400
LOGBUF DS A Buffer ptr @SC86295 01483440
DS A(LPKT) Buffer size @SC86295 01483480
DS C'V' RECFM @SC86295 01483520
LOGFLGS DS X'00' @SC86295 01483560
DS Y(LPKT) LRECL @SC86295 01483600
LOGVOL DS CL6' ' Default disk volume @SC86295 01483640
LOGUNT DS CL8'SYSDA' Default unit @SC86316 01483680
* Specifications for SEND/RECEIVE file @SC86295 01483720
FILFDB DS 0F @SC86295 01483760
TRKAL DS H'5' TRKAL @SC86295 01483800
BLKSI DS H'6233' BLKSI @SC86295 01483840
WBUF DS A,F Adr,length of FSWRITE buffer @SC86121 01483880
RFM DS C'V' Default recfm for disk write 01483920
FILFLGS DS X'00' @SC86295 01483960
LRECL DS H'80' Lrecl for disk write 01484000
VOLUME DS CL6' ' Default disk volume @SC86295 01484040
UNIT DS CL8'SYSDA' Default unit @SC86316 01484080
* Specifications for TAKE file (read-only) @SC86295 01484120
TAKFDB DS 0F @SC86295 01484160
DS H'0,0' TRKAL, BLKSI @SC86295 01484200
TAKBUF DS A Buffer ptr (CMD) @SC86295 01484240
DS F'256' Max buffer size @SC86295 01484280
DS C'V' RECFM @SC86295 01484320
DS X'00' @SC86295 01484360
* 01484400
MAXTRY DS F'5' Retry limit during transfer @SC86164 01484440
LCLDLY DS F'10' Time to wait before sending @SC86164 01484480
RPSIZ DS A(KMAX) Max receive size @SC86295 01484520
SPSIZ DS A(KDEF) Max send size @SC86295 01484560
MAXOUT DS F'&MAXLR' Max output buffer @SC86268 01484600
TYPFIL DS C'T' Type of file (T,B,V,D),see BINF @SC86151 01484640
* 01484680
DEFPARM DS AL1(KDEF+ABL,ABL,ABL,64,CR+ABL,A#,AN,A1,ABL,ABL) SC86149 01484720
DS AL1(ABL,ABL,ABL,ABL) Extended size defaults @TB86196 01484760
RCAPA DS X'0' Capabilities of micro @SC86149 01484800
SCAPA DS X'8' Capabilities I have (A-packets) @SC86149 01484840
REOL DS AL1(CR) EOL char I need (cr) 01484880
SEOL DS AL1(CR) EOL I'll send 01484920
RMARK DS AL1(SOH) Incoming pkt start char 01484960
SMARK DS AL1(SOH) Outbound pkt start char 01485000
RCTLQ DS AL1(A#) Micro's ctl-quote char 01485040
SCTLQ DS AL1(A#) Ctl-quote char we'll use 01485080
EBQC DS AL1(AAMP) Orig 8-bit quote char 01485120
RTIMO DS AL1(5) Time limit - micro to wait for us @SC86164 01485160
TIMOUT DS AL1(0) Timeout, if we can implement it @SC86164 01485200
BCTC DS AL1(1) User requested chksum length 01485240
RPTQC DS AL1(ATIL) Original repeat prefix 01485280
LDEFS EQU *-DEFS @SC86295 01485320
* - - - Initialized to zeroes 01485360
RPTQ DS X Repeat prefix 01485400
EBQ DS X 8-bit quoting char (off) 01485440
BCTU DS X Checksum length in use 01485480
BCTR DS X Other Kermit's chksum length 01485520
RPADN DS X Receive padding count 01485560
SPADN DS X Send pad count @SC86164 01485600
RPADC DS X Receive pad char 01485640
SPADC DS X Send pad char @SC86164 01485680
TMP DS X 01485720
TMPDW DS D Work double word 01485760
FSIZE DS F Record length @SC86203 01485800
FRECF DS C Record format flag @SC86151 01485840
STYPE DS C Type of packet sent @SC86295 01485880
RTYPE DS C Type of packet received @SC86295 01485920
ERRNUM DS X Error number @SC86156 01485960
OLDERR DS X Saved error number in loop @SC86171 01486000
TCTLQ DS X XECHO control character escape @SC86165 01486040
DS 0D @SC86295 01486080
STODWDS EQU (*-STORAG)/8 @SC86295 01486120
TITLE 'CWDSET/DSPACE Routines - set/show working directory' 02099000
* Set new 'working directory', i.e., filemode letter 02099200
* Entry: SCANPTR string has option 02099400
* Exit: R15=0 if ok, R15=1 if error or help needed. ERRNUM unchanged. 02099600
CWDSET ENTER @SC86164 02099800
NTOKN N=CWDERR,H=CWDERR @SC86164 02104000
....
...
B RTRN0 @SC86295 02112000
CWDERR PTEXT 'Must be valid ... 02113000
B RTRN1 @SC86295 02114000
* 02116000
* DSPACE Routine - display available disk space @SC86164 02116003
* 02116006
* Show space in 'working directory' or other minidisk 02116009
* Entry: SCANPTR string has option (none => working directory) 02116012
* Exit: R15=0 if ok, R15=1 if error or help needed. ERRNUM unchanged 02116015
DSPACE ENTER ALT @SC86164 02116018
....
...
LOCALS , @SC86295 02116039
EXIT , @SC86295 02116042
TITLE 'FSPEC Routine - extract filespec from scan string' 02116045
* 02116048
* Entry: R1->name field, R0=flags selecting operation (see below) 02116051
* For parse operations, SCANPTR defines the input string. 02116054
* For getting foreign or display filespec, R7->output buffer 02116057
* Exit: if not FFNEW, then R15=0 if ok, 1 if ?, 2 if bad. 02116060
* For R15=1 or 2 R3,R4 give message. ERRNUM may be leftover. 02116063
* 02116066
* Flags: Notes: 02116069
* Tasks: FFRCF FFSND FFGET FFNEW 02116072
* Parse RECV X set ROVR properly 02116075
* Parse SEND 1st X 02116078
* Parse SEND 2nd X X 02116081
* Parse GET 1st X X 02116084
* Parse GET 2nd X set ROVR properly 02116087
* Parse F-packet (FFHDR) X X X 02116090
* Parse for Generic(FFUTL) X X FFWLD: allow partial 02116093
* Parse TAKE 02116096
* 02116099
* Get unique name X R15: 0=>ok, 1=>bad 02116102
* Get foreign name (FFENC) X X R15->end of string 02116105
* Get display form (FFDSP) X X R15->end of string 02116108
* 02116111
FSPEC ENTER @SC86295 02116114
STC 0,FSPFLG @SC86295 02116117
LR 0,1 Copy ptr to filespec @SC86295 02116120
TM FSPFLG,FFNEW @SC86295 02116123
BO FSPWRN @SC86295 02116126
MVC FSPBAD(16),=C'Invalid filename' @SC86295 02116132
PTEXT FSPBAD,16 Standard msg form @SC86295 02116135
MVI ERRNUM,ERRFNE Assume bad file name @SC86158 02116138
....
...
B RTRN0 @SC86295 02116507
FSPMIS MVC FSPBAD,=C'Missing' @SC86295 02116510
FSPINV LA 15,2 @SC86295 02116513
B FSPPTRS @SC86295 02116516
* @SC86295 02116519
FSP2H PTEXT 'Enter foreign filespec' @SC86295 02116528
LA 15,1 @SC86295 02116531
FSPPTRS L 14,4(13) @SC86295 02116534
STM 3,4,32(14) Return msg ptrs @SC86295 02116537
FSPRET RET , @SC86295 02116540
* 02116543
* Non-parsing functions . . . 02116546
* 02116549
* Get unique filespec 02116552
FSPWRN LR 4,1 Save name ptr @SC86295 02116555
TM FSPFLG,FFENC @SC86295 02116558
BO FSPENC Encode name into buffer @SC86295 02116561
TM FSPFLG,FFDSP @SC86295 02116564
BO FSPDSP Copy name into buffer for display @SC86295 02116567
.... avoid collisions
... avoid collisions
FSPSTA OPENF T,(4),E=RTRN0 Does it exist already? @SC86135 02116588
....
...
B RTRN1 Failed @SC86295 02116603
* 02116606
* Encode name at (R1) into (R7) buffer (in ASCII), possibly with 02116609
* substitution from JFSPEC, but disable subsequend subst. 02116612
* Return updated ptr in R15 02116615
FSPENC LA 1,JFSPEC Complex string? @SC86224 02116618
....
...
FSPENR LR 15,7 Save ptr @SC86295 02116660
B FSPRET @SC86295 02116663
* 02116666
* Copy name at (R1) into (R7) buffer in display form 02116669
* Return updated ptr in R15 02116672
FSPDSP ... 02116675
B FSPENR @SC86295 02116687
LOCALS , @SC86295 02116828
FSPBAD DS C'Invalid',C' file' @SC86295 02116831
FSPBADX DS C'name' @SC86295 02116834
FSPPTR DS XL8 Saved scan ptrs @SC86295 02116837
FSPFLG DS X Filespec flags @SC86295 02116840
FSPEC EXIT @SC86295 02116843
TITLE 'SUPFNC Routine - various supervisor functions' @SC86158 02586000
SUPFNC ENTER @SC86295 02587000
* On entry, R1 = operation code, R0 = possible ptr @SC86158 02588000
* Exit: R15 set (0 => ok, <0 => illegal cmd, >0 => depends) 02589000
* ERRNUM set appropriately (R1=1,3,4) or unchanged (2,5-9) 02589500
* 1 -> Start typeout interception 02590000
* 2 -> Clean up afterwards and stop interception 02590500
* 3 -> Execute CMS command with or without interception 02591000
* If UCMD set, SCANPTR gives text, else R0->text,R6=len 02591500
* 4 -> Execute CP command with or without interception 02592000
* R0->text, R6=len 02592500
* 5 -> Stop interception if going 02593000
* 6 -> Retrieve original cmd parms into CBUF (R15=1 if null) 02593500
* 7 -> Test for stacked lines, return number in R15 02594000
* 8 -> Log off (doesn't return!) 02594500
* 9 -> Wait specified time 02595000
* 10-> Return clock time in R15 (centisec) 02595500
BCT 1,ICPFIN @SC86158 02597000
* Start interception, initialize ptrs @SC86158 02598000
MVI ERRNUM,ERRNOE OK @SC86158 02599000
LA 0,2048 Suitable offset @SC86158 02600000
A 0,WBUF Output buffer @SC86158 02601000
L 1,TSENT Limit @SC86158 02602000
LR 15,0 @SC86158 02603000
STM 15,0,TXTPTR Save @SC86158 02604000
STM 0,1,SVCOPTR @SC86158 02605000
SR 1,0 Get length @SC86158 02606000
L 15,=X'15000000' @SC86158 02607000
MVCL 0,14 Fill with NL (X'15') @SC86158 02608000
....
...
B RTRN0 @SC86295 02614500
* Clean up after interception @SC86295 02614800
ICPFIN BCT 1,ICPCMS @SC86158 02616000
L 5,SVCOPTR End of text @SC86158 02621000
ST 5,TXTPTR+4 Save @SC86158 02628000
B ICPRST1 Now restore interrupts @SC86295 02628500
* Restore SVC interrupt vector @SC86158 02629000
ICPRST BCT 1,SFCLIN @SC86295 02630000
ICPRST1 CLC ... 02630500
BNE RTRN0 OK @SC86295 02631000
....
...
B RTRN0 02633500
* EXECUTE COMMAND AT (R0), SAVE RETURN CODE. 02634000
ICPCMS BCT 1,ICPCP @SC86158 02636000
TM FL4,UCMD User CMS command? @SC86295 02637000
BZ ICPCMS0 No, already set up @SC86295 02637080
LM 0,1,SCANPTR @SC86295 02637160
LR 0,1 @SC86295 02637800
ICPCMS0 LR 3,0 @SC86295 02637880
....
...
LTR 6,15 Save return code @SC86295 02687600
BNM SFCRC @SC86295 02688200
ICPCMIL MVI ERRNUM,ERRSYS Illegal system command @SC86295 02691200
B RTRNM1 @SC86295 02691800
* Execute CP command at (R0) with text interception @SC86158 02699000
ICPCP BCT 1,ICPRST @SC86158 02700000
B ICPRC @SC86295 02722050
* 02722100
....
...
ICPRC C 6,F1 Illegal command? @SC86295 02722200
BE ICPCMIL Yes @SC86295 02722250
* Issue return code msg if needed @SC86295 02722300
SFCRC LTR 4,6 Check RC @SC86295 02722350
BZ SFCZRC RC=0 @SC86158 02722400
MVC CMD(2),=C'R(' Set up message @SC86209 02722450
LA 15,CMD+2 @SC86209 02722500
BAL 2,EDDEC Edit RC into msg @SC86295 02722550
MVI 0(15),C')' Format is R(rc) @SC86209 02722600
LA 0,1(15) @SC86268 02722650
LA 1,CMD Start of edited string @SC86209 02722700
SR 0,1 Length @SC86268 02722750
WTEXT 1,0 @SC86268 02722800
SFCZRC LR 15,6 @SC86295 02722850
MVI ERRNUM,ERRNOE No errors @SC86295 02722900
B RTRN @SC86295 02722950
* 02723000
SFCLIN BCT 1,SFCSTK @SC86295 02723050
* Retrieve original command line arguments, if any @SC86295 02723100
* Return code =0 if yes, =1 if no @SC86295 02723150
* Leave string in CBUF buffer (up to 256), length in CLEN @SC86295 02723200
L 6,ORGR1 Original R1 @SC86295 02723250
....
...
BE RTRN1 Go if nothing on cmd 02723500
L 3,CBUF A safe data area 02723550
....
...
S 3,CBUF Length = current pos - beginning 02724500
SFCCMDS C 3,F256 Is it too long? 02724550
BNH *+8 No, OK length 02724600
L 3,F256 Truncate past CMD length 02724650
ST 3,CLEN Save command length 02724700
B RTRN0 @SC86295 02724750
* 02724800
* Test for stacked commands @SC86295 02724850
* return code = number of stacked lines @SC86295 02724900
SFCSTK BCT 1,SFCKIL @SC86295 02724950
....
...
B RTRN @SC86295 02725100
* 02725150
* Log out @SC86295 02725200
SFCKIL BCT 1,SFCWT @SC86295 02725250
....
...
* 02725350
* Wait specified time in R0 (sec) 02725400
SFCWT BCT 1,SFCCLK @SC86295 02725450
....
...
B RTRN0 @SC86295 02725600
* 02725650
* Return time in centisec in R15 02725700
SFCCLK ... 02725750
B RTRN @SC86295 02726000
TITLE 'SVC interceptor, executed in system protect key' 02726050
....
...
ICPTGO LM 14,15,SVCOPTR Output ptrs @SC86158 02752300
SR 15,14 Length left @SC86158 02752600
LA 12,255 Limit @SC86158 02753000
CH 12,... Buffer length @SC86295 02754000
BNH *+8 Too big @SC86158 02755000
LH 12,... Ok, use it @SC86295 02756000
LTR 12,12 @SC86158 02757000
BNP ICPTRET @SC86283 02758000
CR 12,15 Enough room? @SC86283 02759000
BH ICPTRET No @SC86283 02760000
ICM 15,7,... Buffer address @SC86295 02761000
BCTR 12,0 Set up for mvc @SC86158 02763000
EX 12,SVCCOPY Move to WBUF @SC86158 02766000
LA 14,2(12,14) New end @SC86158 02767000
ST 14,SVCOPTR @SC86158 02768000
ICPTRET SR 15,15 Success @SC86283 02768100
....
...
* Storage for SVC interception @SC86158 02846000
SVCOPTR DS 2F Buffer output and end ptrs @SC86158 02851000
LOCALS , @SC86295 02854000
SUPFNC EXIT @SC86158 02855000
TITLE 'TERMIO Routine - Handle terminal I/O' 03970010
* R1 points to a pair of (adr,len) for read or write. If I/O is 03970020
* successfull, R15 returns transferred byte count (else returns -1). 03970030
* Command code is in R0: 03970040
* 1 => Open line for I/O 4 => Write packet 03970050
* 2 => Close line 5 => Read packet 03970060
* 3 => Reset line status after ( 6 => Write message ) not used 03970070
* environment changes 03970080
* 03970090
TERMIO ENTER 03970100
SR 15,15 OK @SC86295 03970110
BCT 0,TRMCLS @SC86295 03970120
* Open terminal line for protocol 03970130
B RTRN0 @SC86295 03970170
* Close terminal line after protocol transfer 03970180
TRMCLS BCT 0,TRMRSET @SC86295 03970190
B RTRN0 @SC86295 03970210
* (Re)set terminal characteristics to suit environment 03970220
TRMRSET ... 03970230
B RTRN0 @SC86295 03970320
* 03970330
* Perform I/O request 03970340
TRMRW ... 03970350
RET @SC86295 03970420
LOCALS , @SC86295 03970560
EXIT 03970570
TITLE 'SCRNIO Routine - Handle screen I/O via Series/1' 03971000
* R1 points to a pair of (adr,len) for read or write. If I/O is 03972000
* successfull, R15 returns transferred byte count (else returns -1). 03972100
* Command code is in R0: 03972200
* 1 => Open screen for I/O 4 => Write packet 03972300
* 2 => Close screen 5 => Read packet 03972400
* 3 => Reset screen status after 6 => Write message 03972500
* environment changes 03972600
* 03972700
SCRNIO ENTER 03975000
BCT 0,SCRCLS @SC86295 03975020
....
...
B RTRN0 @SC86295 03975180
SCRCLS BCT 0,SCRRSET @SC86295 03975200
....
...
B RTRN0 @SC86295 03975360
* (Re)set device characteristics to suit environment 03975380
SCRRSET BCT 0,SCRRW @SC86295 03975400
....
...
B RTRN0 03975420
* 03975440
* Perform I/O request 03975460
SCRRW ... 03975480
B RTRN 03975620
TITLE 'SETMSG Routine - controls CP breakin' 04110000
* Entry: R1 selects operation 04111000
* Exit: R15=0 if ok 04111500
* 1-> Analyze user environment, determine if suitable. 04112000
* Save quantities needed and condition line for entering commands. 04112500
* Perform any system-dependent initialization. 04113000
* 2-> Condition line for protocol transfers. 04113500
* 3-> Decondition line at end of transfer. 04114000
* 4-> System-dependent clean-up at exit. 04114500
SETMSG ENTER ALT @SC86295 04115600
BCT 1,STM2 Go if R1 not 1, so no init 04116000
....
...
B RTRN0 @SC86295 04132000
* 04133000
STM2 BCT 1,STM3 Go if R1 was not 2, so not off 04134000
....
...
B STMD 04139000
* 04140000
STM3 BCT 1,STM4 @SC86316 04141000
....
...
STMD ... 04143000
B RTRN0 04144000
* 04144300
STM4 B RTRN0 Special clean-up not needed @SC86316 04144600
LOCALS , @SC86295 04192260
SETMSG EXIT 04193000
TITLE 'DISKIO Routine - performs disk I/O functions' 04306000
* Function selected on entry by R0: 04306010
* 1=> open (in): R1->pattern FDB, R2->name. Returns R0->FAB, R1->FDB 04306020
* 2=> open (out): (same, but no complete FDB if new file) 04306030
* 3=> test name: R2->name. Returns R1->FDB if found (else R15=1) 04306040
* 4=> close file: R1->adr(FAB). 04306050
* 5=> set up search: R1->pattern name. 04306060
* 6=> return next file in list: Returns R1->FDB + sets up FILNAM 04306070
* 7=> close search (if any). 04306080
* 8=> test CWD string: R1->string. Returns R15=0 if ok, else =1. 04306090
* 9=> read: R1->FAB. Returns R15=12 if EOF, 0 if ok; R0=# data 04306100
* 10=> write: R1->FAB. Returns R15=0 if ok. 04306110
* 11=> test space: R1->adr(FAB), R2=est. Kbytes. Return R15=0 if ok. 04306120
* 12=> not used. Return R15=0 if ok. 04306130
* 13=> directory info on file: R1->name. Returns R15=0 if ok. 04306140
* 14=> delete file: R1->name. Returns R15=0 if ok. 04306150
* 15=> rename file: R1->name, R2->new name. Returns R15=0 if ok. 04306160
* 16=> copy file: R1->name, R2->new name. Returns R15=0 if ok. 04306170
DISKIO ENTER 04306180
USING FABD,3 @SC86295 04306190
SR 4,4 Signal no block assigned @SC86295 04306200
BCT 0,DSKOPNO @SC86295 04306210
* 04306220
* Open for input file whose name is at (R2), FDB at (R1) 04306230
BAL 9,DSKALC Get FAB @SC86295 04306240
....
...
B RTRN0 @SC86295 04306280
* 04306290
* Open for output file whose name is at (R2), FDB at (R1) 04306300
DSKOPNO BCT 0,DSKTEST @SC86295 04306310
BAL 9,DSKALC Get FAB @SC86295 04306320
....
...
B RTRN0 @SC86295 04306360
* 04306410
* Test for existence of file whose name is at (R2) 04306420
DSKTEST BCT 0,DSKCLOS @SC86295 04306430
....
...
* 04306470
* Close file whose ticket is at (R1), release block 04306480
DSKCLOS BCT 0,DSKNSET @SC86295 04306490
ICM 3,15,0(1) Get FAB ptr, if any @SC86295 04306500
BZ RTRN0 None, ignore @SC86295 04306510
XC 0(4,1),0(1) Yes, now clear ticket @SC86295 04306520
....
...
LA 0,FABDWDS @SC86295 04306540
DMSFRET DWORDS=(0),LOC=(1) @SC86295 04306550
B RTRN0 @SC86295 04306560
* 04306570
* Read from file whose ticket is at (R1) 04306580
DSKRED BCT 0,DSKWRT @SC86295 04306590
....
...
* End of file on input. Don't close it yet. @SC86295 04306630
DSKEOD LA 15,12 End return code @SC86295 04306640
B RTRN @SC86295 04306650
* 04306660
* Write to file whose ticket is at (R1) 04306670
DSKWRT BCT 0,DSKTSP @SC86316 04306680
....
...
B RTRN0 @SC86295 04306710
* 04306720
DSKXXX BCT 0,DSKUTL @SC86316 04306730
B RTRN0 @SC86316 04306740
* 04306750
* Disk utility for file(s) at (R1) and (R2) 04306760
DSKUTL LR 8,0 Save code-12 @SC86295 04306770
BCTR 0,0 Code-13: DIR,DEL,REN,COP @SC86295 04306780
SLA 0,3 @SC86295 04306790
LA 5,DSKCMDS @SC86295 04306800
AR 5,0 Ptr to command name @SC86295 04306810
....
...
B RTRN @SC86295 04306990
* 04307110
* Return on error, release useless block, if any 04307120
DSKER1 LTR 1,4 Any block assigned? @SC86295 04307130
BZ RTRN1 No @SC86295 04307140
LA 0,FABDWDS Yes, release it @SC86295 04307150
DMSFRET DWORDS=(0),LOC=(1) @SC86295 04307160
B RTRN1 Flag error @SC86295 04307170
* 04307180
DSKALC LR 5,1 Save FDB ptr @SC86295 04307190
LA 0,FABDWDS @SC86295 04307210
DMSFREE DWORDS=(0) @SC86295 04307220
LR 3,1 New block ptr @SC86295 04307230
LR 4,1 @SC86295 04307240
L 1,4(13) @SC86295 04307250
ST 3,20(1) Return R0 @SC86295 04307260
XC 0(8*FABDWDS,3),0(3) @SC86295 04307270
MVC FDBD(FDBCOP),0(5) Copy user's FDB @SC86295 04307280
....
...
BR 9 @SC86295 04307320
* 04307420
* Set up search through list of files, pattern at (R1) 04307430
DSKNSET BCT 0,DSKNXT @SC86295 04307440
NI DSKFL,255-CWDF Find files @SC86295 04307450
....
...
DSKNSX ... 04307470
B RTRN0 @SC86295 04307480
* 04307490
* Flush previous file pattern 04307500
DSKXSET BCT 0,DSKCWDF @SC86295 04307510
B DSKNSX @SC86295 04307520
* 04307530
* Check CWD string, return code in R15 04307540
DSKCWDF BCT 0,DSKRED @SC86295 04307550
OI DSKFL,CWDF Find disk @SC86295 04307560
....
...
B ... 04307590
* 04307600
* Check disk space for proposed file: name at (R1) 04307610
DSKTSP BCT 0,DSKXXX @SC86316 04307620
....
...
SRDA 0,10 Convert to Kbytes @SC86316 04307730
CR 1,2 @SC86316 04307740
BL RTRN1 No room @SC86316 04307750
B RTRN0 Ok @SC86316 04307760
* 04307770
* NXTFST Routine - searches the ADT and FST chains 04307780
DSKNXT BCT 0,DSKXSET @SC86295 04307790
....
...
EXIT 04543000
END KERMIT 04544000
From "(John F. Chandler) <PEPMNT@CFATA1>" Fri Nov 14 19:31:35 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFATA1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 14 Nov 86 19:31:31-EST
Received: from CFATA1(PEPMNT) by CUVMA (Mailer X1.23b) id 8877;
Fri, 14 Nov 86 19:32:12 EST
Date: 1986 Nov 14 19:14 EST
From: (John F. Chandler) <PEPMNT@CFATA1>
To: <IBM-KERMIT@CU20B>
Subject: New name
The Nov. version of the BITNET/NETNORTH/EARN routing tables has, for
the first time, the 'correct' name for my node, namely, CFAAMP. As
far as I can tell, nearly all of the network has installed the new
tables (with the exception of one site here at Harvard). I would
appreciate it if each of you would attempt to send me an interactive
message (*not* mail) at CFAAMP and note whether (and where) there are
any snags. If there is any snag other than at HARVSC3, I would
appreciate hearing about it (if your site has not yet installed the
new table, perhaps you can expedite the process). I can still be
reached at CFATA1. Thanks.
John
From <DEDOUREK@UNBMVS1> Mon Nov 17 16:37:12 1986
Flags: 000000000001
Return-Path: <DEDOUREK%UNBMVS1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 17 Nov 86 16:36:55-EST
Received: from UNBMVS1(MAILER) by CUVMA (Mailer X1.23b) id 4374;
Mon, 17 Nov 86 16:36:59 EST
Date: 17 Nov 86 17:24:03 AST
From: <DEDOUREK@UNBMVS1>
To: IBM-Kermit@CU20B.COLUMBIA.EDU
bcc:
Subject: EBCDIC to/from ASCII in IBM Kermits
Message-ID: <ID55241.D861117.T172403.DEDOUREK@UNBMVS1>
The following comments on EBCDIC to/from ASCII trnaslation in Kermit.
This is motivated by the fact that the "front end" at U.N.B. has some
"funny" translations, e.g. backslash (\) to cent sign ( ). (Hmm. I
wonder what that line will look like after going through various
gateways.) It appears that approximately the following happens when
my (ASCII) micro Kermit speaks with my (IBM) mainframe Kermit.
Micro to mainframe
I1. Micro Kermit sends ASCII
I2. IBM "front end" receives ASCII on line and converts to EBCDIC.
I3. Mainframe Kermit gets EBCDIC and converts to ASCII.
I4. Mainframe Kermit does protocol things, checks for errors, etc.
on the ASCII text.
I5. Mainframe Kermit converts to EBCDIC
I6. Text is stored in file (in EBCDIC; I am assuming text files).
Mainframe to Micro
O1. Mainframe Kermit accesses text file (which is EBCDIC).
O2. Mainframe Kermit converts to ASCII
O3. Mainframe Kermit does its protocol things, computes checksums, etc.
on the ASCII text.
O4. Mainframe Kermit translates to EBCDIC and sends
O5. IBM "front end" converts EBCDIC to ASCII and sends on line
O6. Micro Kermit receives ASCII
By IBM "front end" in the above, I refer to the collection of software
between the actual communication line, running in ASCII, and the Kermit
program, running under some terminal system. On our system, this
includes things like NTO, NCP, SNA, VTAM, TSO, ond other alpha-getti.
Steps I3, I5, O2 and O4 involve ASCII to/from EBCDIC conversions done by
the IBM Kermit. Step I3 converts EBCDIC to ASCII and must exactly
reverse the ASCII to EBCDIC translation done by the "front end" for the
protocol to work correctly. Similarly, step O4 converts the ASCII
packet to EBCDIC in preparation for the "front end" conversion of EBCDIC
to ASCII. Thus the conversions in steps I3 and O4 must be exact
inverses of the "front ends" translations. If the front end translation
is fixed, or can be set to a standard value, then these tables should be
hardwired on the Kermit to reflect those translations; alternately they
might be selectable from a small set which exactly reflects the set of
available "front ends;" and if possible, automatically selected by
sensing which front end table is in use.
Translations I5 and O2 are "user oriented" translations and should be
easily selectable by the user. There should be a standard set. The
most often used one would translate identical ASCII and EBCDIC. But
there are other versions. If I use my micro to prepare PL/1 source
text for the mainframe, I might want to define ASCII caret (sorry, not
on my EBCDIC keyboard) or ASCII tilda (~) to IBM "not sign" (^), and
reverse that translation on receipt.
This would imply that four translation tables are required, two each of
EBCDIC to ASCII and ASCII to EBCDIC. My initial examination of a few
IBM Kermits indicates the presence of only two such tables. This would
seem to limit me to only the identical "user" conversion which exactly
happens to reverse the "front end" translation. Have I missed
something?
John DeDourek
DEDOUREK@UNBMVS1.BITNET
From "(John F. Chandler) <PEPMNT@CFATA1.BITNET>" Mon Nov 17 19:23:11 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFATA1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 17 Nov 86 19:23:05-EST
Received: from CFATA1(PEPMNT) by CUVMA (Mailer X1.23b) id 4858;
Mon, 17 Nov 86 19:23:34 EST
Date: 1986 Nov 17 18:15 EST
From: (John F. Chandler) <PEPMNT@CFATA1.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Re: EBCDIC to/from ASCII in IBM Kermits
In-reply-to: DEDOUREK@UNBMVS1 message of 17 Nov 86 17:24:03 AST
It is quite true that a fully rigorous Kermit needs 4 translate tables
to deal with linemode front ends on IBM mainframes. However,
1. A really bizarre front-end translation table would render Kermit
impossible anyway (e.g., the input or output translation not even
invertible).
2. The front-end translation is the one the user is used to, so having
four tables would be pure "gravy".
3. Kermit-CMS allows the user to set/alter any entries in the ETOA and
ATOE tables, so the set of standard variants could be embodied in a
set of TAKE files. Moreover, the intallation-wide init. file would
set up the translations to match the front end. I fear there are
too many variants now (and in the future, too) to create any hardwired
set of standards.
JFC
From "Roger Fajman <RAF@NIHCU>" Mon Nov 17 21:51:28 1986
Flags: 000000000001
Return-Path: <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 17 Nov 86 21:51:11-EST
Received: from NIHCU(MAILER) by CUVMA (Mailer X1.23b) id 5134;
Mon, 17 Nov 86 21:51:39 EST
To: ibm-kermit@cu20b.columbia.edu
From: "Roger Fajman" <RAF@NIHCU>
Date: Mon, 17 Nov 86 21:36:12 EST
Subject: Translate tables
I think John Dedourek makes an excellent point about ASCII/EBCDIC
translation tables. The tables that are used to reverse the "front
end" translation must match the front end. The tables used to
translate data in files could vary from the others, if they are
settable by the user. User changes to translate tables should not
affect the tables used for the "front end" translations, or Kermit
will likely not work at all. These tables should be set by the
installation only.
Our TSO Kermit has only 2 tables, but it does not offer user settable
translate tables, so this is not a problem. So far, none of our
users has requested such a feature. The tables can be set by the
installation, of course.
I am not aware of any small set of standard "front end" tables. At
least under TSO there is considerable variation among installations,
as modification of the IBM tables was essential, as they did not even
support lower case.
Roger Fajman
From "Andre PIRARD <A-PIRARD@BLIULG12>" Tue Nov 18 12:51:05 1986
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 18 Nov 86 12:50:56-EST
Received: from BLIULG12(MAILER) by CUVMA (Mailer X1.23b) id 6736;
Tue, 18 Nov 86 11:24:23 EST
Received: by BLIULG12 (Mailer X1.23b) id 3333; Tue, 18 Nov 86 17:24:22 ULG
Date: Tue, 18 Nov 86 14:58:52 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: New name, translation & 7171 synch
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
As of to day, I have had my user id changed to something more humanly readable.
A-PIRARD replaces the former UZ32112 that I will increasingly overlook.
I can't help the international convention B(elgium) LI(ege) etc...
Please note for net distribution as well as personal correspondance (Frank).
On the subject of translation tables, we use the standard IBM VM ones.
We had some variations until we started micro files transfer and we realized
it was a no-return choice to make. Once files are stored, one must be able
to get them back even years later without trouble. Modifiable tables should
be useful only for foreign files.
I think the VM tables are fairly standard. They are the same as those used
by the Series/1 and 7171 and by the WISCVM gateway, both an important issue.
We aligned the TSO tables on that standard and all goes well...
Until one comes to national characters (lucky you!). They don't fit in the
ascii range of course. We have in fact several codings. The first one
(called French ISO ascii I think) defines replacements for seldom used ascii
characters (braces etc..) with our non overstriked characters, including
circumflex accent and what we call trema (replacing tilde). The latter
are involved in overstrikes (accent backspace letter) just the way one does
it on a typewriter. Needless to say that representation is just a joy to sort.
Then came IBM and its PC extended ascii and Apple with a different one.
Not bad, but rather unusual to transmit on seven bits lines.
On the IBM mainframe side, there are an awful variety of codes on printers,
terminals etc..., most of them like ISO ascii after standard translation.
But it looks like a new EBCDIC standard emerges which is called 'table 500'
and, like the extended ascii, uses additional codes suitable for all roman
characters based languages.
So why does IBM stick on seven bit transmission? I finally managed to have the
7171 and IBM PC talk our characters on seven bits lines, but I leave it for
you to guess how. I still don't know exactly how I am going to transfer them.
Up to now, the best thing to do with national characters was to avoid them
(using uppercase).
Lucky you.
On an easier subject, my present micro ftp programs (not using Kermit)
are specialized in communication through the 7171. They automatically
start the mainframe program when a user locally requests a file transfer.
I am converting them to the Kermit protocol for various reasons and intend
to keep the same automatic start procedure.
Now the hitch with having two programs to talk is that it is just the
opposite of the RECEIVE/SEND turnaround time (being too late).
In fact the local program has to know when all the screen management fuss
has come to an end and the other side is listening. Knowing that the
remote side is involved in a 7171 transparent write/read mechanism, the best
way to achieve this is to have it to send a priming character the local side
is waiting for. That character must of course not be used in any other
terminal control sequence (of the extendable varieties of ascii terminals
that can be used on the 7171).
The former CMS Kermit version used to send an XON at the right time but
it disappeared from the latest version. I thought it was intended for that
purpose and regreted I was wrong.
Knowing of the variety of terminal codes, it does not seem a good idea to
use a control code for that purpose. I think an ascii character from the
higher range would do best as they do not appear as cursor addresses
characters either.
I presently achieve this by having a test Kermit init file echo that
particular character, but I feel this risky beeing too fast anyway.
This is a point I'd like to have 7171 Kermits in common.
Another one is the possibility to have the local Kermit automatically
tell the mainframe of all the file characteristics (especially binary vs
text) in a uniform way, preferrably via the attributes packet, but
acceptedly via coded command supplement. But I think this suggestion
is evident due to the group ideology.
From "(John F. Chandler) <PEPMNT@CFATA1.BITNET>" Tue Nov 18 13:40:58 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFATA1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 18 Nov 86 13:40:49-EST
Received: from CFATA1(PEPMNT) by CUVMA (Mailer X1.23b) id 7309;
Tue, 18 Nov 86 13:37:51 EST
Date: 1986 Nov 18 13:27 EST
From: (John F. Chandler) <PEPMNT@CFATA1.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Re: New name, translation & 7171 synch
In-reply-to: A-PIRARD@BLIULG12 message of Tue, 18 Nov 86 14:58:52 ULG
Kermit-CMS still has traces of the former practice of sending an XON
as a server-mode prompt. The present practice of sending a CR seems
to work just fine, but I don't know the reason for the switch. Vace?
Grabbing file attributes from the Attribute packets seems like a great
idea, but we probably need a way to override them at the mainframe
Kermit -- this implies having two different levels of SET options.
Consequently, I have held off on implementing such a scheme although I
now have a provision for comparing the advertised file length with the
available disk space to decide whether an incoming file must be rejected.
Any ideas how to implement three priorities of file attribute?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Tue Nov 18 15:45:28 1986
Flags: 000000000001
Mail-From: SY.FDC created at 18-Nov-86 15:45:16
Date: Tue 18 Nov 86 15:45:16-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Another Test Message
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12255982983.11.SY.FDC@CU20B.COLUMBIA.EDU>
Please reply to me if you got this message. There seems to be so much
congestion at the WISCVM gateway that U of Wisconsin is threatening to
cut off the Relay function. If all of you can get this message, then we
can start using our own BITNET host as the mail relay. I'm using a
different method than last time, and I sure hope it works. - Frank
-------
From "Vace Kundakci <VVVCU@CUVMA>" Tue Nov 18 16:51:56 1986
Flags: 000000000001
Return-Path: <VVVCU%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 18 Nov 86 16:50:55-EST
Received: by CUVMA (Mailer X1.23b) id 7742; Tue, 18 Nov 86 15:27:23 EST
Date: Tue, 18 Nov 86 15:27 EST
From: Vace Kundakci <VVVCU@CUVMA>
To: IBM-KERMIT@CU20B
Subject: Re: New name, translation & 7171 synch
In-Reply-To: Your memo of 1986 Nov 18 13:27 EST
Xon is as good as any other character. The switch to RDTERM with
prompts forces us to put at least a one character prompt. CMS is
known to do bad things if the Prompt length is 0 in rdterm.
Secondly, just in case if the micro is waiting for an xon, it serves
better than a cr (but not much). So I vote for keeping it.
/Vace
------
From "Jonathan Scott <GUCJS%SEGUC21.BITNET@WISCVM.WISC.EDU>" Tue Nov 18 19:35:36 1986
Flags: 000000000001
Return-Path: <GUCJS%SEGUC21.BITNET@WISCVM.WISC.EDU>
Received: from WISCVM.WISC.EDU ([192.12.12.13]) by CU20B.COLUMBIA.EDU with TCP; Tue 18 Nov 86 19:35:21-EST
Received: from (GUCJS)SEGUC21.BITNET by WISCVM.WISC.EDU on 11/18/86 at
16:01:38 CST
Date: Tue, 18 Nov 86 21:57 -0100
From: Jonathan Scott <GUCJS%SEGUC21.BITNET@WISCVM.WISC.EDU>
Subject: Translation and 7171
To: <ibm-kermit@cu20b.columbia.edu>
Comment: To IBM-KERMIT@CU20B.COLUMBIA.EDU
It probably doesn't help the rest of you very much, but it appears that
by using the special facilities of our own time-sharing system we have
managed to avoid two problems to a large extent.
1. Translation. In our system, we have a generous selection of
terminal translate tables (each of which has a line of description)
to suit different ASCII conventions. Our GUTS KERMIT simply uses a
function in our system which translates data to or from 7-bit ASCII
using the current tables for the user. I wish the PC end of the
line was as simple.
2. 7171 support. We have an option in GUTS to switch to normal line by
line mode when connected through a 7171. It is turned on simply by
selecting an ASCII translate table name instead of an EBCDIC one.
Our system sends XON as usual at the end of each prompt in this
mode, and the code in our GUTS KERMIT does not know it is running
through the 7171.
The 7171 does have one horrible feature which I don't seem to be able to
get round: It is impossible to cancel or time out a transparent read,
so the mainframe end cannot time out. (To be more precise, the 7171
simply refuses to send anything more to the terminal until it gets some
input, even if the host gives up on the read and tries to write). Does
anyone happen to know of any solution to this, or is merely a "feature"
awaiting official documentation?
From "Andre PIRARD <A-PIRARD@BLIULG12>" Wed Nov 19 05:02:34 1986
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 19 Nov 86 05:02:23-EST
Received: from BLIULG12(MAILER) by CUVMA (Mailer X1.23b) id 0252;
Wed, 19 Nov 86 04:59:30 EST
Received: by BLIULG12 (Mailer X1.23b) id 3906; Wed, 19 Nov 86 10:56:43 ULG
Date: Wed, 19 Nov 1986 09:48:17 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Timing out IBM mainframes
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
I have in fact read several times that CMS Kermit was impossible to timeout.
I do not think so, but I'll only be theoretical.
3270 fullscreen I/O is usually done via a specialized DIAGNOSE 58.
When a diagnose 58 is issued, the net effect is to issue a SIO on behalf of
the requesting virtual machine which *does* receive control back before I/O end
The diagnose is usually followed by a TIO loop on the console address.
Successive TIO's for the same unit are noticed by CP which suspends the virtual
machine on the assumption the loop will go on until the I/O is complete.
So why not setup a timer interrupt whose execution would simply issue a HIO
to the console address? I presume any interrupt must be taken while in the
suspended state and the HIO will break the TIO loop. That's the "principles
of operations" theory and a nice thing about CP is that it strongly adheres
to probably the best manual IBM has ever written.
I have not done it because all my micros ftps time out (simply by loop count).
Has anyone tried? It seems too simple to have been missed.
Doing asynchronous I/O on the TSO side is possible too. Just start a subtask
to do the TGET. The main task is waiting on a pair of ECB's: one POSTed by
a timer exit setup by the main task and the other by the subtask getting
a satisfied TGET. If the timer expires, abend and restart the subtask. The
TGET will be canceled by MVS purging the subtask resources.
And while we are at it, having achieved asynchronous comm line I/O on both
systems, why not try to take advantage of it. Mainframes are reportedly
slow in response time to small packet size. It might help to overlap
line and disk I/O. It is acking incoming packets and requesting the next one
before writing to disk. It is reading the next packet from disk before getting
the previous ack.
I leave it to you to evaluate the performance increase, but I suspect it to
be worth the effort in TSO for the following reason. When a TGET is issued
in TSO, the task enters a long wait having the effect of swapping out the job
if all tasks are in long wait, which is the case if it is the only one.
It would not be the case with my double tasks scheme as long as the explicit
waits issued are short. This would keep the job resident. On the other hand,
beware of the job transaction not being reset and having it grow a single
transaction driving it in low priority RSM domains.
Hope this may help. Andre.
From "Vace Kundakci <VVVCU@CUVMA>" Wed Nov 19 09:12:16 1986
Flags: 000000000001
Return-Path: <VVVCU%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 19 Nov 86 09:12:08-EST
Received: by CUVMA (Mailer X1.23b) id 0461; Wed, 19 Nov 86 09:09:18 EST
Date: Wed, 19 Nov 86 09:09 EST
From: Vace Kundakci <VVVCU@CUVMA>
To: Andre PIRARD <A-PIRARD@BLIULG12>
CC: IBM-KERMIT@CU20B
Subject: Re: Timing out IBM mainframes; Andre PIRARD <A-PIRARD@BLIULG12>
In-Reply-To: Your memo of Wed, 19 Nov 1986 09:48:17 ULG
You're right. But tty mode operation in CMS cannot be timed out
which means that two logic paths are necessary, pulling them even
further apart.
/Vace
------
From "Andre PIRARD <A-PIRARD@BLIULG12>" Wed Nov 19 11:16:06 1986
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 19 Nov 86 11:15:30-EST
Received: from BLIULG12(MAILER) by CUVMA (Mailer X1.23b) id 0810;
Wed, 19 Nov 86 11:12:09 EST
Received: by BLIULG12 (Mailer X1.23b) id 4564; Wed, 19 Nov 86 17:12:58 ULG
Date: Wed, 19 Nov 86 17:02:23 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: 7171 synch
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Humble apologies for having missed the CR as a 7171 R/W prompt.
Thank you John for pointing out.
It does exactly what I need and is excluded from any terminal control
characters set.
So let us leave it that way and rather generalize the practice.
From "Roger Fajman <RAF@NIHCU>" Wed Nov 19 16:23:18 1986
Flags: 000000000001
Return-Path: <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 19 Nov 86 16:23:08-EST
Received: from NIHCU(MAILER) by CUVMA (Mailer X1.23b) id 1716;
Wed, 19 Nov 86 14:59:33 EST
To: IBM-Kermit@CU20B.COLUMBIA.EDU
From: "Roger Fajman" <RAF@NIHCU>
Date: Wed, 19 Nov 86 15:00:37 EST
Subject: Timeouts and overlap
The TGET-in-a-subtask method for timeout in TSO does work. That
is the method that we use. Under TSO, if you are using QSAM to
access the disk data set, overlapping of disk I/O and terminal
I/O is automatic. The access method handles the buffering.
From "(John F. Chandler) <PEPMNT@CFAAMP>" Fri Nov 21 17:22:08 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 21 Nov 86 17:22:02-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 9507;
Fri, 21 Nov 86 17:19:27 EST
Date: 1986 Nov 21 11:35 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
To: <IBM-KERMIT@CU20B>
Subject: Special characters
A recent note in the Kermit Digest pointed out a problem in TSO Kermit
that arises if the user has a printable character for the character-delete
function. This same problem arises in almost any system. CMS deals with
it by turning off line-edit functions during a protocol transfer, and TSO
Kermit can similarly save the user's values when it starts up and substitute
"safe" values during a transfer. I note that the special characters are
kept in both the UPT and PSCB, so presumably both would have to be modified
(and then restored after the transfer). In the generic "skeleton" I sent
out, the functions of saving, changing, and restoring the edit characters
would be performed under variants 1, 2, and 3, respectively, of SETMSG.
John
From "(John F. Chandler) <PEPMNT@CFAAMP>" Fri Nov 21 22:38:37 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 21 Nov 86 22:38:26-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 9896;
Fri, 21 Nov 86 22:35:41 EST
Date: 1986 Nov 21 21:55 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
To: <IBM-KERMIT@CU20B>
Subject: Brief macro documentation
Here is a description of the macros I use in the generic Kermit. The
ones of particular interest are the "specific" category -- each must
be implemented as part of a new system-specific version.
The quasi-generic macros generate purely generic code and are, I think,
invariant, but must be included with the specific ones because the CMS
version, at least, doesn't use them. The generic macros are also
included just for good measure. Any comments?
N.B. the DMSFREE and DMSFRET macros don't actually have to preserve R14
as far as my present code is concerned, but I put the restriction in
just in case.
John
----------------------------------------------------------------------
Notation: &1, &2, etc. refer to positional parameters. Keyword parms
are described by name. LA means adr suitable for LA instr, R means
register # in (), A means suitable for A-constant.
-------------------------- specific macros ----------------------------
*COPY RDTERM
&LABEL RDTERM &BUF,&PRBUFF=,&PRLGTH=
..* Read from the terminal, possible prompt
.* Read from the terminal, possible prompt
..* &1: read buffer (len=130) (LA), &PRBUFF= prompt buf. if any (LA/R),
.* &1: read buffer (len=130) (LA), &PRBUFF= prompt buf. if any (LA/R),
..* &PRLGTH= prompt length (LA/R)
.* &PRLGTH= prompt length (LA/R)
*COPY DMSFREE
&LABEL DMSFREE &DWORDS=(0),&ERR=
..* Obtain free storage block: len=8*(R0). Returns ptr in R1, but
.* Obtain free storage block: len=8*(R0). Returns ptr in R1, but
..* preserves registers 2-14
.* preserves registers 2-14
..* &DWORDS= length in doublewords should be in R0,
.* &DWORDS= length in doublewords should be in R0,
..* &ERR= branch if failure
.* &ERR= branch if failure
*COPY DMSFRET
&LABEL DMSFRET &DWORDS=(0),&LOC=(1),&ERR=
..* Return free storage block: len=8*(R0), adr=(R1). Preserves R2-14.
.* Return free storage block: len=8*(R0), adr=(R1). Preserves R2-14.
..* &DWORDS= length in doublewords should be in R0, &LOC= adr (in R1),
.* &DWORDS= length in doublewords should be in R0, &LOC= adr (in R1),
..* &ERR= branch if failure
.* &ERR= branch if failure
*COPY WTEXT 00164000
&LABEL WTEXT &ARG,&LEN 00167000
..* Display some text, e.g., WTEXT 'Hi there' or WTEXT 3,4 0016720
.* Display some text, e.g., WTEXT 'Hi there' or WTEXT 3,4 00167200
..* &1: 'text' or 0016740
.* &1: 'text' or 00167400
..* &1: reg->text, &2: reg=length of text or 0016760
.* &1: reg->text, &2: reg=length of text or 00167600
..* &1: adr of text (LA), &2: length of text (LA) 0016780
.* &1: adr of text (LA), &2: length of text (LA) 00167800
*COPY FDBD 00232000
FDBD 00232200
..* Map of File Descriptor Block 0023230
.* Map of File Descriptor Block 00232300
FABD DSECT , @SC86295 00232400
...
FDBD DS 0F Beginning of short descriptor @SC86295 00232900
FDBTRKAL DS H File track allocation increment @SC86295 00233000
FDBBLKSI DS H File block size @SC86295 00233100
FDBBUFF DS A Buffer ptr @SC86295 00233200
FDBBSIZ DS F Max record length @SC86295 00233300
FDBRCF DS C Record format @SC86295 00233400
FDBFLGS DS X Flags @SC86295 00233500
FDBACTV EQU X'80' File is already open @SC86295 00233600
FDBEPL EQU X'20' Extended form @SC86295 00233800
* APPN EQU X'10' DISP=MOD @SC86295 00233900
FDBLRC DS H File record length @SC86295 00234300
FDBVOL DS 0CL6 File volume label @SC86295 00234400
...
FDBCOP EQU *-FDBD Length to copy for OPEN @SC86295 00234500
FDBSIZE DS F File size in Kbytes @SC86295 00234600
...
FDBDATE DS F Creation date: packed yyyymmdd @SC86295 00235000
...
FDBINFO EQU *-FDBD Length of info returned @SC86295 00235200
... 00235300
FABDWDS EQU (*-FABD+7)/8 @SC86295 00235400
*COPY KSYSTF 00239030
KSYSTF 00239090
..* Define system-dependent globally-known constants and init. variables 0023912
.* Define system-dependent globally-known constants and init. variables 00239120
..* symb .DS + label &P.DEFS mark start of variables/init. values 0023915
.* symb .DS + label &P.DEFS mark start of variables/init. values 00239150
LCLC &P 00239180
PUSH PRINT 00239210
PRINT GEN 00239240
AIF ('&SYSECT' EQ 'STORAG').DS 00239270
&P SETC 'I' For initial values 00239300
... 00239330
..DS ANOP 0023957
.DS ANOP 00239570
&P.DEFS DS 0D 00239600
... 00239330
POP PRINT 00239780
*COPY SSYMS 00379000
SSYMS <-------------------CMS version 00379200
..* Set global symbols for conditional assembly 0037930
.* Set global symbols for conditional assembly 00379300
GBLC &KVRSN,&KSYS,&KDATE,&RTN,&TYPCMD,&S1CMD,&WDIR @SC86268 00379400
GBLA &MAXLR,&MAXBS @SC86268 00379500
&KSYS SETC 'CMS' System name @SC86268 00379600
MNOTE '*** Kermit-&KSYS release &KVRSN (&KDATE) ***' 00379700
&MAXLR SETA 65535 Max lrecl @SC86268 00379800
&MAXBS SETA 65535 Max blksize @SC86268 00379900
&S1CMD SETC '40' S/1 command prefix @SC86268 00380000
PUSH PRINT 00380100
PRINT GEN 00380200
MAXWT EQU 1760 Max WRTERM buffer @SC86268 00380300
MAXRT EQU 2030 Max RDTERM buffer @SC86268 00380400
LFID EQU 18 Max length of filespec @SC86268 00380500
&WDIR SETC 'DESTINATION' SET parameter for CWD @SC86295 00380600
&TYPCMD SETC 'TYPE' Host command for TYPE @SC86268 00380700
TYPMIN EQU 2 Min abbrv of system TYPE cmd or 2 @SC86268 00380800
POP PRINT 00380900
*COPY SYSMACS 00381100
SYSMACS <-------------------CMS version 00381300
..* Include system control block definition macros and list all macros 0038140
.* Include system control block definition macros and list all macros 00381400
MNOTE '---MACLIBs needed: DMSSP, CMSLIB, TSOMAC, OSMACRO' 00381500
MNOTE '---MACROs: ADT, DCH, DIAG, DMSEXS, DMSFREE, DMSFRET, DMSKEY,' 00381600
MNOTE '--- FSCB, FSREAD, FSTB, FSWRITE, FVS, GETFST, HNDINT,' 00381700
MNOTE '--- LINEDIT, NUCON, RDTERM, SAVE, STAX, WAITD, WAITT' 00381800
USING NUCON,0 00381900
NUCON , CMS Nucleus 00382000
FSTB , File Status Table 00382100
DCH , Data Control Hyperblock 00382200
ADT , Active Disk Table 00382300
FVS , File system storage @SC86268 00382400
----------omitted: specific macros not used in generic code -----------
----------------------- quasi-generic macros --------------------------
*COPY FSWRITE
&LABEL FSWRITE &FSCB=(1),&BUFFER=,&BSIZE=,&ERROR=
..* Write to a disk file (ticket ptr in R1)
.* Write to a disk file (ticket ptr in R1)
..* &BUFFER= data ptr (LA/R), &BSIZE= data length (LA/R) - if either is
.* &BUFFER= data ptr (LA/R), &BSIZE= data length (LA/R) - if either is
..* given, it replaces FDB value (see OPENF), &ERROR= branch if error
.* given, it replaces FDB value (see OPENF), &ERROR= branch if error
*COPY FSREAD
&LABEL FSREAD &FSCB=(1),&BUFFER=,&BSIZE=,&ERROR=,&CODE=9
..* Read from disk file (or write) (see FSWRITE)
.* Read from disk file (or write) (see FSWRITE)
-------------------------- generic macros -----------------------------
*COPY KW 00093000
&LABEL KW &KW,&ADDR,&MIN=1 00095000
..* Define a KW for the parser 0009530
.* Define a KW for the parser 00095300
..* &1: keyword, &2: address of handler (A), &MIN=length of min. abrv. 0009560
.* &1: keyword, &2: address of handler (A), &MIN=length of min. abrv. 00095600
*COPY SCAN 00104000
&LABEL SCAN &TABLE,&ERROR 00106000
..* Parse input using a KW table 0010630
.* Parse input using a KW table 00106300
..* &1: adr of relevant table (LA/R), &2: handler if no match (LA) 0010660
.* &1: adr of relevant table (LA/R), &2: handler if no match (LA) 00106600
*COPY HELP 00111000
&LABEL HELP &TABLE,&RETURN 00113000
..* Display acceptable keywords, then branch 0011330
.* Display acceptable keywords, then branch 00113300
..* &1: ptr to table (LA/R), &2: place to branch (LA) 0011360
.* &1: ptr to table (LA/R), &2: place to branch (LA) 00113600
*COPY NTOKN 00118000
&LABEL NTOKN &H=,&N= 00120000
..* Pick next token, optionally test for ? 0012030
.* Pick next token, optionally test for ? 00120300
..* &H= handler if '?' (LA), &N= handler if none (LA) 0012060
.* &H= handler if '?' (LA), &N= handler if none (LA) 00120600
*COPY FTOKN 00126090
&LABEL FTOKN &H=,&N= 00126270
..* Find start of next token, optionally test for ? 0012636
.* Find start of next token, optionally test for ? 00126360
..* &H= handler if '?' (LA), &N= handler if none (LA) 0012645
.* &H= handler if '?' (LA), &N= handler if none (LA) 00126450
*COPY PTEXT 00179000
&LABEL PTEXT &TEXT,&LEN,&AREG=3,&LREG=4 00182000
..* Set up 2 registers to point to some text and contain the length 0018220
.* Set up 2 registers to point to some text and contain the length 00182200
..* &1: 'text' or &AREG= reg for ptr, 0018240
.* &1: 'text' or &AREG= reg for ptr, 00182400
..* &1: adr of text (LA), &2: length of text (LA) &LREG= reg for len 0018260
.* &1: adr of text (LA), &2: length of text (LA) &LREG= reg for len 00182600
*COPY KCALL 00193000
&LABEL KCALL &NAME,&VALUE,&EXT,&E= 00196000
* Call a routine, fill R1 with a parm if any, and allow error branch 00196200
..* &1: routine name, &2: argument (LA/R) (opt), &3: EXT if non-Kermit, 0019640
.* &1: routine name, &2: argument (LA/R) (opt), &3: EXT if non-Kermit, 00196400
..* &E= branch if R15 NZ (LA) or (branch,cc) with cc=suffix of B instr 0019660
.* &E= branch if R15 NZ (LA) or (branch,cc) with cc=suffix of B instr 00196600
*COPY ADCON 00211000
ADCON 00211180
..* Define address constants for subroutine calls, etc. Takes a list. 0021127
.* Define address constants for subroutine calls, etc. Takes a list. 00211270
*COPY LREG 00211900
&LABEL LREG &R,&VAL @SC86295 00213000
..* Load register with parameter 0021310
.* Load register with parameter 00213100
..* &1: reg, &2: value (LA) or (reg) or omitted 0021320
.* &1: reg, &2: value (LA) or (reg) or omitted 00213200
*COPY OPENF 00214300
&LABEL OPENF &MODE,&NAME,&FDB,&FID,&E= 00214500
..* Open file for input or output or test existence 0021460
.* Open file for input or output or test existence 00214600
..* &1: I|O|T, &2: file name (LA/R), &3: pattern FDB (LA/R), 0021470
.* &1: I|O|T, &2: file name (LA/R), &3: pattern FDB (LA/R), 00214700
..* &4: file ticket (LA) (opt), &E= error branch (see KCALL) 0021480
.* &4: file ticket (LA) (opt), &E= error branch (see KCALL) 00214800
*COPY CLOSF 00217000
&LABEL CLOSF &FID,&E= 00222000
..* Call DISKIO to close a file 0022260
.* Call DISKIO to close a file 00222600
..* &1: file ticket (LA) (opt), &E= error branch (see KCALL) 0022320
.* &1: file ticket (LA) (opt), &E= error branch (see KCALL) 00223200
*COPY ERASF 00229000
&LABEL ERASF &NAME,&E= 00229200
..* Call DISKIO to erase a file 0022930
.* Call DISKIO to erase a file 00229300
..* &1: file name (LA/R), &E= error branch (see KCALL) 0022940
.* &1: file name (LA/R), &E= error branch (see KCALL) 00229400
*COPY NXTFSET 00229800
&LABEL NXTFSET &NAME,&TYPE,&E= 00230000
..* Call DISKIO to set up search for files 0023010
.* Call DISKIO to set up search for files 00230100
..* &1: file name (LA/R), &2: CWD if checking validity for CWD, 0023020
.* &1: file name (LA/R), &2: CWD if checking validity for CWD, 00230200
..* &E= error branch (see KCALL) 0023030
.* &E= error branch (see KCALL) 00230300
*COPY NXTF 00231200
&LABEL NXTF &E= 00231400
..* Call DISKIO to get next file name in FILNAM 0023150
.* Call DISKIO to get next file name in FILNAM 00231500
..* &E= error branch (see KCALL) 0023160
.* &E= error branch (see KCALL) 00231600
*COPY RET 00253000
&LABEL RET &TYPE 00256000
..* Generate return from subroutines. 0025690
.* Generate return from subroutines. 00256900
..* &1: MAIN if return from Kermit main code 0025780
.* &1: MAIN if return from Kermit main code 00257800
*COPY ENTER 00269000
&LABEL ENTER &TYPE @SC86295 00271000
..* Establish routine entry code 0027180
.* Establish routine entry code 00271800
..* &1: ALT if 2ndary entry 0027260
.* &1: ALT if 2ndary entry 00272600
*COPY EXIT 00301000
EXIT 00303000
..* Assembler stuff for end of routine and end of local temporaries 0030400
.* Assembler stuff for end of routine and end of local temporaries 00304000
*COPY LOCALS 00306400
LOCALS 00307200
..* Define storage for save area. Follow with temporaries 0030760
.* Define storage for save area. Follow with temporaries 00307600
*COPY ASCSYM 00311000
ASCSYM &LIST 00314000
..* Define symbols (of form 'Ax') for ASCII upper-case & digits 0031450
.* Define symbols (of form 'Ax') for ASCII upper-case & digits 00314500
*COPY NOTQR 00336000
&LABEL NOTQR &BRANCH @SC86120 00338000
..* Test for an Ascii char range of 33-62 and 96-126 0033830
.* Test for an Ascii char range of 33-62 and 96-126 00338300
..* &1: branch if out of range (LA) 0033860
.* &1: branch if out of range (LA) 00338600
*COPY UNCHR 00342000
&LABEL UNCHR ®,&DATA,&TO 00344000
..* UnChr: Subtract an ASCII space. Set cc=M if too small. 0034430
.* UnChr: Subtract an ASCII space. Set cc=M if too small. 00344300
..* &1: reg for value, &2: source (LA) if not &1, &3: dest (LA) (opt) 0034460
.* &1: reg for value, &2: source (LA) if not &1, &3: dest (LA) (opt) 00344600
*COPY TOCHR 00347000
&LABEL TOCHR ®,&DATA,&TO 00349000
..* ToChr: Add an ASCII space 0034930
.* ToChr: Add an ASCII space 00349300
..* &1: reg for value, &2: source (LA) if not &1, &3: dest (LA) (opt) 0034960
.* &1: reg for value, &2: source (LA) if not &1, &3: dest (LA) (opt) 00349600
*COPY CTL 00352000
&LABEL CTL ®,&DATA,&TO 00355000
..* CTL: Reverse bit 6 to make a ctl char printable and vice versa 0035530
.* CTL: Reverse bit 6 to make a ctl char printable and vice versa 00355300
..* &1: reg for value, &2: source (LA) if not &1, &3: dest (LA) (opt) 0035560
.* &1: reg for value, &2: source (LA) if not &1, &3: dest (LA) (opt) 00355600
*COPY CCHAR 00358000
&LABEL CCHAR ®,&DATA,&TO,&OP,&VALUE 00360000
..* CCHAR: Used by CTL/UNCHR/TOCHR to add/subtract number 0036020
.* CCHAR: Used by CTL/UNCHR/TOCHR to add/subtract number 00360200
..* &1: reg for value, &2: source (LA) if not &1, &3: dest (LA) (opt), 0036040
.* &1: reg for value, &2: source (LA) if not &1, &3: dest (LA) (opt), 00360400
..* &4: opcode for change, &5: operand 0036060
.* &4: opcode for change, &5: operand 00360600
*COPY MSGDF 00370000
MSGDF &NM,&TEXT 00372000
..* Define error message table entry and pointer 0037230
.* Define error message table entry and pointer 00372300
..* &1: 3-letter error code, &2: 'text of message' 0037260
.* &1: 3-letter error code, &2: 'text of message' 00372600
From "(John F. Chandler) <PEPMNT@CFAAMP>" Wed Nov 26 14:20:19 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 26 Nov 86 14:20:04-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 4424;
Wed, 26 Nov 86 13:40:34 EST
Date: 1986 Nov 26 12:04 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
To: <IBM-KERMIT@CU20B>
Subject: Structure of Generic Kermit
The generic Kermit-370 will need to be made up of pieces, unlike the
present-day specific versions. The following is a nomenclature I have
devised and a possible scheme of division, enumerating all the pieces
that would go into the CMS-specific version.
+----------- Prefix
| +--------- System code: 0=>generic (hence, I370); C=>CMS; T=>TSO;
| | G=>GUTS; M=>MTS; I=>MUSIC (short for IMU);
| | W=>WYLBUR; etc.
| | +------- Component name (1st two letters are unique, but 3rd makes
| | | it more readable)
---|---
I370DOC.ASM - Short description + history of program (generic)
I370MAC.ASM - Generic macros
I37CMAC.ASM - Specific macros
I370DEF.ASM - Global equates (generic)
I370COM.ASM - Common code + constants and variables (generic)
I370CMD.ASM - User interface (generic, but replaceable)
I370PRO.ASM - Generic protocol implementation
I37CUTL.ASM - Specific code
The TSO-specific version would be almost the same:
I370DOC.ASM
I37TDOC.ASM - History of TSO version
I370MAC.ASM
I37TMAC.ASM - TSO-specific macros
I370DEF.ASM
I370COM.ASM
I370CMD.ASM
I370PRO.ASM
I37TUTL.ASM - TSO-specific code
>From what I gather, the WYLBUR-specific version would be a bit different:
I370DOC.ASM
I37WDOC.ASM - History of WYLBUR version
I370MAC.ASM
I37WMAC.ASM - WYLBUR-specific macros
I370DEF.ASM
I370COM.ASM
I37WCMD.ASM - WYLBUR-specific version of user interface
I370PRO.ASM
I37WUTL.ASM - WYLBUR-specific code
Does anyone see any infelicities in this arrangement? Perhaps the DEF
and COM sections could be fused, but that's a small detail. Somewhat
more important is the question of how to make sure all the pieces get
put together properly for assembly (as outlined, the code is still a
single assembly for each version -- there could also be auxilliary
subroutines in separate assemblies). One idea I had was to interleave
cards of the form "*COPY <name>" among the macro definitions and then
give instructions on using an editor as needed to convert the original
sources into input for the appropriate utility program for creating a
macro library. Such a library would contain not just the macros, but
also the various pieces I370COM, etc. There would then be a skeleton
system-specific source consisting of nothing but COPY instructions to
assure correct assembly.
1. Are there any systems where such a library couldn't be easily
made and used? For example, if a system (A) has macros that
match the names of Kermit macros or COPY names and (B) can't
be instructed to search the Kermit library ahead of the default
library, this scheme breaks down.
2. Can anyone think of a better way to organize things? Should
we consider adding a system-specific command procedure to paste
the pieces together automatically?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Nov 26 15:17:16 1986
Flags: 000000000001
Mail-From: SY.FDC created at 26-Nov-86 15:16:50
Date: Wed 26 Nov 86 15:16:49-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Structure of Generic Kermit
To: IBM-Kermit@CU20B.COLUMBIA.EDU
In-Reply-To: Message from "(John F. Chandler) <PEPMNT@CFAAMP>" of Wed 26 Nov 86 14:20:21-EST
Message-ID: <12258074956.19.SY.FDC@CU20B.COLUMBIA.EDU>
The file names look just fine. A minor consideration in the 6.3 paradigm,
however, is that SOME systems, when encountering a name of the form 7.3
(like your names) will truncate them to 7.2, rather than 6.3 (RT-11 is such
a system). Thus, you have to ensure uniqueness both ways. It would be better
if you really made them 6.3. I know it's hard... Just dropping the "7" would
do the job (or maybe the "3", so we could reserve "4", "6", and "8" for
System 34,36,38... Except there's already an I8 somewhere, oh well...
Another possibility is to gather all the files for a particular version
together into a single file, with textual markers separating each file-within-
the-file. Then you could call the big files with more sensible names:
I37TSO.ASM, I37CMS.ASM, I37GUT.ASM, I37MUS.ASM, I37ALL.ASM, ... This is
better for distribution anyway.
- Frank
-------
From <DEDOUREK@UNBMVS1> Thu Nov 27 15:02:23 1986
Flags: 000000000001
Return-Path: <DEDOUREK%UNBMVS1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 27 Nov 86 15:02:19-EST
Received: from UNBMVS1(MAILER) by CUVMA (Mailer X1.23b) id 7429;
Thu, 27 Nov 86 15:02:53 EST
Date: 27 Nov 86 15:51:36 AST
From: <DEDOUREK@UNBMVS1>
To: IBM-Kermit@cu20b.columbia.edu
bcc:
Subject: Standard convention for text files to IBM TSO
Message-ID: <ID56833.D861127.T155136.DEDOUREK@UNBMVS1>
Some programs on the IBM PC (e.g. the Turbo Pascal editor) appear quite
willing to create text files in which the last line is not terminated by
the usual CR LF pair. Since the format of text files "on the wire" in
the Kermit protocol is defined essentially to be the IBM PC format,
text files can appear in this form. (Indeed, IBM PC Kermit, v 2.28 does
send these files without the final CR LF pair.)
IBM TSO Kermit must translate from the Kermit canonical text file
representation to the IBM text file representation, namely fixed or
variable records in standard OS record formats. IBM TSO Kermit, version
1.0, fails to store the characters of the final line when not followed
by the CR LF pair. Instead, these characters are attached to the
beginning of the first line of the next file transferred, if any.
Should there be a standard behaviour for Kermits which must translate
the canonical Kermit text record format to a local host representation
when the final CR LF is omitted? Or should the Kermit protocol place
the blame on the sending Kermit for failing to append an extra CR LF?
John DeDourek
DEDOUREK@UNBMVS1.BITNET
From "(John F. Chandler) <PEPMNT@CFAAMP>" Fri Nov 28 21:14:44 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 28 Nov 86 21:14:39-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 9159;
Fri, 28 Nov 86 20:35:11 EST
Date: 1986 Nov 28 20:24 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
To: <IBM-KERMIT@CU20B>
Subject: More on macros
Here's another system-specific macro:
FDBPAT &N
..* Define system-dependent part of output FDB patterns
.* Define system-dependent part of output FDB patterns
..* &1: variable-name prefix (or null if defining init. values)
.* &1: variable-name prefix (or null if defining init. values)
LCLC &V,&U @SC86316
AIF ('&N' EQ '').ALC @SC86316
&V SETC 'VOL' @SC86316
&U SETC 'UNT' @SC86316
..ALC ANOP @SC86316
.ALC ANOP @SC86316
....
...
MEND
The CMS version does nothing (as above). The TSO version inserts values
for volume and unit as follows:
-----------------------------------------------------
&N.&V DC CL6' ' No volume specified
&N.&U DC CL8'SYSDA' Default unit
-----------------------------------------------------
Other systems would define whatever is appropriate, i.e., any quantities
needed for opening an output file (other than record format, record
length, block size, assorted flags, file identifier, and allocation
increment).
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Mon Dec 1 08:40:16 1986
Flags: 000000000001
Mail-From: SY.FDC created at 1-Dec-86 08:40:08
Date: Mon 1 Dec 86 08:40:07-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Standard convention for text files to IBM TSO
To: DEDOUREK@UNBMVS1, IBM-Kermit@CU20B.COLUMBIA.EDU
cc: jrd@USU
In-Reply-To: <ID56833.D861127.T155136.DEDOUREK@UNBMVS1>
Message-ID: <12259313459.150.SY.FDC@CU20B.COLUMBIA.EDU>
MS-DOS Kermit presently makes absolutely no distinction between text and
binary files because DOS's text file format happens to correspond precisely
to Kermit's 'canonic form' for text files. Therefore data conversions are
never necessary (except the business about ^Z's at the end). Changing DOS
Kermit to add a CRLF at the end of an outbound file that does not end in a
CRLF would open the whole text-vs-binary can of worms. I think the benefits
of leaving that particular can closed outweigh the benefits of CRLF insertion.
In particular, when there is no distinction between text and binary files,
then you can mix the two types in wildcard groups, which makes DOS-to-DOS
transfers very painless. - Frank
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Mon Dec 1 08:51:33 1986
Flags: 000000000001
Mail-From: SY.FDC created at 1-Dec-86 08:51:22
Date: Mon 1 Dec 86 08:51:22-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [The Mailer Daemon <Mailer@CU20B.COLUMBIA.EDU>: Message of 26-Nov-86 15:16:50]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12259315505.150.SY.FDC@CU20B.COLUMBIA.EDU>
Let's try this again...
---------------
Date: Sat 29 Nov 86 15:31:03-EST
From: The Mailer Daemon <Mailer@CU20B.COLUMBIA.EDU>
To: SY.FDC@CU20B.COLUMBIA.EDU
Subject: Message of 26-Nov-86 15:16:50
Message undeliverable and dequeued after 3 days:
A-PIRARD%BLIULG12.BITNET@WISCVM.WISC.EDU: Cannot connect to host
CMSMAINT%BROWNVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
PEPMNT%CFATA1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
VVVCU%CUVMA.BITNET@WISCVM.WISC.EDU: Cannot connect to host
26-377%HARVBUS1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
BENNO%HROEUR1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
RAF%NIHCU.BITNET@WISCVM.WISC.EDU: Cannot connect to host
GMW%PSUVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
GUCJS%SEGUC21.BITNET@WISCVM.WISC.EDU: Cannot connect to host
OPRBMVC%TCSVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
SYSBJAV%TCSVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
TUCBOB%TUCCVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
TUCSEB%TUCC.BITNET@WISCVM.WISC.EDU: Cannot connect to host
YMUMMD%UK.AC.UMIST.CENTRAL-SERVICES.PRIME-A%UKACRL.BITNET@WISCVM.WISC.EDU: Cannot connect to host
DEDOUREK%UNBMVS1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
KOVACHDG%UREGINA1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
SYSRONR%UCHIMVS1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
------------
Date: Wed 26 Nov 86 15:16:49-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Structure of Generic Kermit
To: IBM-Kermit@CU20B.COLUMBIA.EDU
In-Reply-To: Message from "(John F. Chandler) <PEPMNT@CFAAMP>" of Wed 26 Nov 86 14:20:21-EST
Message-ID: <12258074956.19.SY.FDC@CU20B.COLUMBIA.EDU>
The file names look just fine. A minor consideration in the 6.3 paradigm,
however, is that SOME systems, when encountering a name of the form 7.3
(like your names) will truncate them to 7.2, rather than 6.3 (RT-11 is such
a system). Thus, you have to ensure uniqueness both ways. It would be better
if you really made them 6.3. I know it's hard... Just dropping the "7" would
do the job (or maybe the "3", so we could reserve "4", "6", and "8" for
System 34,36,38... Except there's already an I8 somewhere, oh well...
Another possibility is to gather all the files for a particular version
together into a single file, with textual markers separating each file-within-
the-file. Then you could call the big files with more sensible names:
I37TSO.ASM, I37CMS.ASM, I37GUT.ASM, I37MUS.ASM, I37ALL.ASM, ... This is
better for distribution anyway.
- Frank
-------
-------
-------
From <DEDOUREK@UNBMVS1> Mon Dec 1 17:26:16 1986
Flags: 000000000001
Return-Path: <DEDOUREK%UNBMVS1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 1 Dec 86 17:25:32-EST
Received: from UNBMVS1(MAILER) by CUVMA (Mailer X1.23b) id 3636;
Mon, 01 Dec 86 16:40:46 EST
Date: 01 Dec 86 15:29:57 AST
From: <DEDOUREK@UNBMVS1>
To: sy.fdc@cu20b.columbia.edu,
ibm-kermit@cu20b.columbia.edu
cc: jrd@usu
bcc:
In-Reply-To: <12259313459.150.sy.fdc@cu20b.columbia.edu>
Subject: Behaviour of IBM TSO Kermit with no CR LF after last line
Message-ID: <ID57164.D861201.T152957.DEDOUREK@UNBMVS1>
Frank:
Actually, I agree that MS/DOS Kermit should NOT be changed to
distinguish between "text" and "binary" mode. That possibility was
mentioned in my note mainly to get people to consider the ramifications
of that solution. The MS-DOS text file format should remain the
canonical format of a text file "on the wire."
The real problem is that some Kermit implementors (me, in
particular!) did not realize that this canonical format included
the possibility of the CR LF not being present following the last
line. I suspect (but don't know) that this is the source of the
peculiar behaviour (moving the last line to the beginning of the next
file) of the IBM TSO Kermit which is used here.
John DeDourek
From <DEDOUREK@UNBMVS1> Wed Dec 3 10:02:21 1986
Flags: 000000000001
Return-Path: <DEDOUREK%UNBMVS1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 3 Dec 86 10:02:15-EST
Received: from UNBMVS1(MAILER) by CUVMA (Mailer X1.23b) id 9549;
Wed, 03 Dec 86 10:03:47 EST
Date: 03 Dec 86 10:50:14 AST
From: <DEDOUREK@UNBMVS1>
To: ibm-kermit@cu20b.columbia.edu
Subject: test
Message-ID: <ID57333.D861203.T105014.DEDOUREK@UNBMVS1>
Test of ibm-kermit to bitnet.
ibm-kermit has been unsuccessful in passing my messages to recipients
on bitnet.
DeDourek@unbmvs1.bitnet
From "Roger Fajman <RAF@NIHCU>" Fri Dec 5 23:42:09 1986
Flags: 000000000001
Return-Path: <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 5 Dec 86 23:42:04-EST
Received: from NIHCU(MAILER) by CUVMA (Mailer X1.23b) id 9114;
Fri, 05 Dec 86 23:43:34 EST
To: IBM-Kermit@CU20B.COLUMBIA.EDU
From: "Roger Fajman" <RAF@NIHCU>
Date: Fri, 05 Dec 86 23:36:16 EST
Subject: NIH TSO Kermit
I would like to announce the availability of the NIH TSO Kermit
Version 1.0. The following summarizes its capabilities:
NIH TSO Kermit Capabilities At a Glance:
Local operation: No
Remote operation: Yes
Transfers text files: Yes
Transfers binary files: Yes
Wildcard send: Yes
XX/XY interruption: Yes
Filename collision avoidance: No
Timeouts: Yes
8th-bit prefixing: Yes
Repeat character compression: Yes
Alternate block check types: Yes
Communication settings: No
Transmit BREAK: No
IBM mainframe communication: Yes
Transaction logging: No
Session logging: No
Debug logging: Yes
Raw transmit: No
Login scripts: No
Act as server: Yes
Talk to server: No
Advanced commands for servers: No
Local file management: Yes
Command/init files: Yes
Handle file attributes: No
I am sending a tape to Frank da Cruz at Columbia so that NIH TSO
Kermit can be included on the regular Columbia distribution tapes.
When the files are available on KERMSRV, ask for TSNKER.TXT to see
the installation instructions. There are 8 required files, plus 13
more if you want the source.
NIH TSO Kermit may also be obtained directly from NIH by sending a
letter of request and a tape to the following address:
Joseph D. Naughton
Chief, Computer Center
National Institutes of Health
Building 12, Room 2244
Bethesda, MD 20892
There is no charge.
The NIH version of TSO Kermit is an extensive modification and
rewrite of the University of Chicago TSO Kermit, which in turn was
based on an early CMS Kermit developed at Columbia University. The
external design was done by Roger Fajman and Dale Wright. The
internal design and programming was done by Dale Wright.
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Tue Dec 9 08:46:29 1986
Flags: 000000000001
Mail-From: SY.FDC created at 9-Dec-86 08:46:24
Date: Tue 9 Dec 86 08:46:23-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Local mode operation for IBM Kermit?
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12261411752.21.SY.FDC@CU20B.COLUMBIA.EDU>
Here's a query and my response. Any reactions?
------------------------------
Date: 8 Dec 86 20:42 EDT
From: (robert hendricks) <HENDRICKS@NYU-ACF1.ARPA>
Subject: KERMIT Support of C-80 Terminal Concentrator
I am a student at NYU and am working as a systems programmer supporting a
VM R3 system on a 4361. In addition to using the 4361, the researchers
here also use a VM system at NASA to which they communicate over a leased
line controlled by a Commtex C-80 terminal concentrator. We have a desire
to use the leased line to transfer files between a PC connected to the 4361
and the VM system at NASA.
Do you know whether anyone is working on a version of KERMIT which would
recognize the special features of the C-80 to allow this? From what I know
of it, which is very little, the C-80 behaves similarly to the Yale IUP
software in a 7171 or Series 1.
I would gladly volunteer to help develop and test this enhancement to
KERMIT unless has already been done. What I'm searching for at present is
just some guidance on how I might get started and where to go to get help.
-------
Date: Tue 9 Dec 86 08:43:14-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: KERMIT Support of C-80 Terminal Concentrator
You will have two problems: first, dealing with the C-80, and second,
getting a version of VM/CMS Kermit that provides "local mode" or "dialout"
operation. For the C-80, there might be very little work involved if it
really works like the Series/1, 7171, or other front end that supports or
emulates the Yale IUP, since CMS Kermit already does that. For local mode
operation (in which the copy of Kermit running on your VM "operator
console" connects to the other system over a second, assigned TTY device),
you or someone would have to write code to do this. I'll forward your
message to the IBM mainframe Kermit people and see what they say. - Frank
-------
-------
From "(John F. Chandler) <PEPMNT@CFAAMP>" Tue Dec 9 14:54:50 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 9 Dec 86 14:54:22-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 8096;
Tue, 09 Dec 86 14:52:34 EST
Date: 1986 Dec 9 14:30 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
To: <IBM-KERMIT@CU20B>
Subject: Update to macro specs
One small addition to the specification for the RDTERM macro (note the
length read should be returned in R0):
*COPY RDTERM
&LABEL RDTERM &BUF,&PRBUFF=,&PRLGTH=
..* Read from the terminal, possible prompt. Get length read in R0.
.* Read from the terminal, possible prompt. Get length read in R0.
..* &1: read buffer (len=130) (LA), &PRBUFF= prompt buf. if any (LA/R),
.* &1: read buffer (len=130) (LA), &PRBUFF= prompt buf. if any (LA/R),
..* &PRLGTH= prompt length (LA/R)
.* &PRLGTH= prompt length (LA/R)
From "Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU>" Wed Dec 10 21:52:09 1986
Flags: 000000000001
Mail-From: SY.KEN created at 10-Dec-86 21:52:03
Date: Wed 10 Dec 86 21:52:03-EST
From: Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU>
Subject: Just a test
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <12261816922.172.SY.KEN@CU20B.COLUMBIA.EDU>
Testing to see how far, and in what directions, this mail will go. /Ken
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Thu Dec 11 15:32:38 1986
Flags: 000000000001
Mail-From: SY.FDC created at 11-Dec-86 15:32:27
Date: Thu 11 Dec 86 15:32:24-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [(robert hendricks) <HENDRICKS@NYU-ACF1.ARPA>: RE: KERMIT Support of C-80 Terminal Concentrator]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12262009953.158.SY.FDC@CU20B.COLUMBIA.EDU>
IBM-Kermit folks, meet Robert Hendricks of the NYU Academic Computing Facility,
who will be looking at adding support for a new protocol converter to CMS
Kermit (and, presumably, to the new portable 370 Kermit). If anybody wants to
speak up about the best way to support multiple kinds of protocol converters in
portable 370 Kermit, now's a good time. It goes without saying, I hope, that
any protocol converter we want to support must be capable of having the host
put it into and take it out of transparent mode, so it's just a question of
allowing multiple ways to do this. - Frank
---------------
Date: 11 Dec 86 14:16 EDT
From: (robert hendricks) <HENDRICKS@NYU-ACF1.ARPA>
To: <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: RE: KERMIT Support of C-80 Terminal Concentrator
Thank you for your quick reply. I realized that I already have a version of
the source, 3.1, July 1986. So I can start looking it over to see what would
be involved in allowing KERMIT to recognize the special traits of a C-80.
I didn't mean to suggest that I needed to communicate CMS/KERMIT-CMS/KERMIT
or to add dialout capability. I would appreciate knowing whether anyone
else is working on support for the C-80 in a serious manner.
-------
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Dec 12 09:22:46 1986
Flags: 000000000001
Mail-From: SY.FDC created at 12-Dec-86 09:22:31
Date: Fri 12 Dec 86 09:22:31-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [The Mailer Daemon <Mailer@CU20B.COLUMBIA.EDU>: Message of 9-Dec-86 08:46:24]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12262204760.160.SY.FDC@CU20B.COLUMBIA.EDU>
It looks like the WISCVM gateway is shut... I'm trying this directly
>From CU20B out to BITNET (thru CUVMA) in hopes that things have been
fixed up a bit since last time. Apologies to those of you who may already
have received it. Also, I just received Roger Fajman's TSO Kermit tape,
and will be putting it in the distribution next week. - Frank
---------------
Date: Fri 12 Dec 86 08:59:05-EST
From: The Mailer Daemon <Mailer@CU20B.COLUMBIA.EDU>
To: SY.FDC@CU20B.COLUMBIA.EDU
Subject: Message of 9-Dec-86 08:46:24
Message undeliverable and dequeued after 3 days:
A-PIRARD%BLIULG12.BITNET@WISCVM.WISC.EDU: Cannot connect to host
CMSMAINT%BROWNVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
PEPMNT%CFATA1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
VVVCU%CUVMA.BITNET@WISCVM.WISC.EDU: Cannot connect to host
26-377%HARVBUS1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
BENNO%HROEUR1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
RAF%NIHCU.BITNET@WISCVM.WISC.EDU: Cannot connect to host
GMW%PSUVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
GUCJS%SEGUC21.BITNET@WISCVM.WISC.EDU: Cannot connect to host
OPRBMVC%TCSVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
SYSBJAV%TCSVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
TUCBOB%TUCCVM.BITNET@WISCVM.WISC.EDU: Cannot connect to host
TUCSEB%TUCC.BITNET@WISCVM.WISC.EDU: Cannot connect to host
YMUMMD%UK.AC.UMIST.CENTRAL-SERVICES.PRIME-A%UKACRL.BITNET@WISCVM.WISC.EDU: Cannot connect to host
DEDOUREK%UNBMVS1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
KOVACHDG%UREGINA1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
SYSRONR%UCHIMVS1.BITNET@WISCVM.WISC.EDU: Cannot connect to host
------------
Date: Tue 9 Dec 86 08:46:23-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Local mode operation for IBM Kermit?
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12261411752.21.SY.FDC@CU20B.COLUMBIA.EDU>
Here's a query and my response. Any reactions?
------------------------------
Date: 8 Dec 86 20:42 EDT
From: (robert hendricks) <HENDRICKS@NYU-ACF1.ARPA>
Subject: KERMIT Support of C-80 Terminal Concentrator
I am a student at NYU and am working as a systems programmer supporting a
VM R3 system on a 4361. In addition to using the 4361, the researchers
here also use a VM system at NASA to which they communicate over a leased
line controlled by a Commtex C-80 terminal concentrator. We have a desire
to use the leased line to transfer files between a PC connected to the 4361
and the VM system at NASA.
Do you know whether anyone is working on a version of KERMIT which would
recognize the special features of the C-80 to allow this? From what I know
of it, which is very little, the C-80 behaves similarly to the Yale IUP
software in a 7171 or Series 1.
I would gladly volunteer to help develop and test this enhancement to
KERMIT unless has already been done. What I'm searching for at present is
just some guidance on how I might get started and where to go to get help.
-------
Date: Tue 9 Dec 86 08:43:14-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: KERMIT Support of C-80 Terminal Concentrator
You will have two problems: first, dealing with the C-80, and second,
getting a version of VM/CMS Kermit that provides "local mode" or "dialout"
operation. For the C-80, there might be very little work involved if it
really works like the Series/1, 7171, or other front end that supports or
emulates the Yale IUP, since CMS Kermit already does that. For local mode
operation (in which the copy of Kermit running on your VM "operator
console" connects to the other system over a second, assigned TTY device),
you or someone would have to write code to do this. I'll forward your
message to the IBM mainframe Kermit people and see what they say. - Frank
-------
-------
-------
-------
From "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" Tue Dec 16 21:07:04 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMB.COLUMBIA.EDU>
Received: from CUVMB.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 16 Dec 86 21:06:55-EST
Received: from CUVMA(MAILER) by CUVMB (Mailer X1.23b) id 1100;
Tue, 16 Dec 86 21:05:31 EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 1038;
Tue, 16 Dec 86 21:05:39 EST
Date: 1986 Dec 16 21:06 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Kermit retry options
There have been some requests for the ability to set the initial retry
limit (for CMS, the initial exchange has a built-in retry limit of 16,
but subsequent exchanges are subject to a variable limit). Does anyone
know of any standard nomenclature for distinguishing the two cases? I
toyed with the idea of simply setting the initial limit to 3 times the
normal limit, but that wouldn't satisfy everybody. How does this sound:
SET RETRY INIT <n> for the initial exchange
SET RETRY CONT <n> | SET RETRY <n> for subsequent packets
The alternate form for subsequent packets would maintain compatibility
with the present CMS version. Any comments?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Dec 17 08:29:22 1986
Flags: 000000000001
Mail-From: SY.FDC created at 17-Dec-86 08:29:16
Date: Wed 17 Dec 86 08:29:16-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Kermit retry options
To: PEPMNT@CFAAMP, IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Message from "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" of Tue 16 Dec 86 21:07:06-EST
Message-ID: <12263505785.141.SY.FDC@CU20B.COLUMBIA.EDU>
Most Kermit programs use SET RETRY {INITIAL, PACKETS} <n>. - Frank
-------
From "Vace Kundakci <VVVCU@CUVMA>" Wed Dec 17 10:59:28 1986
Flags: 000000000001
Return-Path: <VVVCU%CUVMA.BITNET@CUVMB.COLUMBIA.EDU>
Received: from CUVMB.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 17 Dec 86 10:59:11-EST
Received: from CUVMA(MAILER) by CUVMB (Mailer X1.23b) id 1400;
Wed, 17 Dec 86 10:10:17 EST
Received: by CUVMA (Mailer X1.23b) id 4865; Wed, 17 Dec 86 10:10:24 EST
Date: Wed, 17 Dec 86 10:10 EST
From: Vace Kundakci <VVVCU@CUVMA>
To: John F. Chandler <PEPMNT@CFAAMP.BITNET>
CC: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Re: Kermit retry options; (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
In-Reply-To: Your memo of 1986 Dec 16 21:06 EST
Kermit manual defines those commands as
SET RETRY INITIAL n
SET RETRY PACKETS n
/Vace
------
From "Andre PIRARD <A-PIRARD@BLIULG12>" Wed Dec 17 13:41:00 1986
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMB.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 17 Dec 86 13:40:44-EST
Received: from BLIULG12(MAILER) by CUVMA (Mailer X1.23b) id 3462;
Mon, 15 Dec 86 11:36:33 EST
Received: by BLIULG12 (Mailer X1.23b) id 7839; Mon, 15 Dec 86 17:01:21 ULG
Date: Mon, 15 Dec 86 16:40:52 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: TSO server Kermit quest
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
One of our application programmers wishes to setup a easy data transfer
procedure for "end users". It should send a batch of files to TSO over a
DCS line and be as automated as possible.
The (assembler) Kermit we run has no server mode, which is a must in this case.
The only other official Kermit offering has server mode, but requires Pascal
which we don't have.
I've seen mentions of other TSO Kermits in this list.
So I guess it is the best place to ask.
Would anyone be willing to send me a copy not too hard to install?
We have PL/I and Fortran mostly.
Merry Christmas and happy New Year to all.
Andre PIRARD
SEGI - Universite de Liege
15, av. des Tilleuls
B4000 LIEGE (Belgique)
+32 (41) 520180(449)
Bitnet: A-PIRARD%BLIULG12
Arpanet: A-PIRARD%BLIULG12.BITNET@WISCVM.WISC.EDU
From "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" Mon Dec 22 16:10:42 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMB.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 22 Dec 86 16:10:32-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 5563;
Mon, 22 Dec 86 12:03:15 EST
Date: 1986 Dec 22 12:02 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
To: <INFO-KERMIT-REQUEST@CU20B.COLUMBIA.EDU>, <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Digest V.5 #18
On closer examination, I see that the Kermit Digest I just got is not the
expected #18, but rather #19. That means I never got #18, and a quick
check with the nearest other BITNET subscriber reveals that he missed out
on #18 as well. Did all BITNET subscribers miss #18? If so, a special
re-issue might be in order.
From "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" Tue Dec 30 17:04:56 1986
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMB.COLUMBIA.EDU>
Received: from CUVMB.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 30 Dec 86 17:04:47-EST
Received: from CUVMA(MAILER) by CUVMB (Mailer X1.23b) id 1505;
Tue, 30 Dec 86 17:06:46 EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 7139;
Tue, 30 Dec 86 17:04:42 EST
Date: 1986 Dec 30 15:58 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: System-specific SET parameters
The necessity of providing different SET parameters in different versions
of Kermit-370 seems to require 3 more system-specific macros to define
the variable portion of the SET/SHOW parameter tables and the corresponding
handlers for SET and for SHOW. There might be a need for another 3 to
take care of file attributes, since the parameter tables are arranged
heirarchically. I would like to conduct a survey of systems and file
attributes to fill out the following table of relevant attributes:
---------------------------------------------------------------------
S y s t e m
Attrib
CMS GUTS MTS MUSIC TSO VSPC WYLBUR
BLKSIZE x
LRECL x x
RECFM (1) x x
SPACE (2) x
TYPE (3) x x
UNIT x
VOLUME x
---------------------------------------------------------------------
Notes:
(1) CMS requires F and V; TSO also allows U.
(2) Disk space allocation increment, in tracks.
(3) Data type: Text, Binary, V-binary, D-binary (the latter two being
undelimited varying-length records with length prefixes).
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Dec 31 09:59:19 1986
Flags: 000000000001
Mail-From: SY.FDC created at 31-Dec-86 09:59:09
Date: Wed 31 Dec 86 09:59:08-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [Pat Macdonald <pam%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET>: MVS/TSO, VM/CMS, UTS Kermit]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12267192161.290.SY.FDC@CU20B.COLUMBIA.EDU>
(I told him that long packets have already been defined and implemented,
and invited her/him to join the Info-Kermit and IBM-Kermit discussion groups.)
---------------
Date: 27 Dec 86 23:56 +0600
From: Pat Macdonald <pam%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET>
To: SY.FDC@CU20B.COLUMBIA.EDU
Subject: MVS/TSO, VM/CMS, UTS Kermit
I have developed a version of Kermit for IBM 370 architecture. My original
objective was to support packet sizes > 96 bytes. My design has produced a
program which will run on either MVS or UTS (and almost certainly VM but I
am unable to test this).
The initial objective is achieved by adding an additional header byte to each
packet after the send-init parameters have been exchanged. The toal length of
a packet is the given by:
total-length = byte[1] + N * byte[4]
where N is agreed to via the send-init parameters.
The second benefit derives from the following two C macros:
#define ATOE(x) (' '==0x20?(x):atoe[(x)])
#define ETOA(x) (' '==0x20?(x):etoa[(x)])
where atoe and etoa are appropriate ASCII / EBCDIC translation tables.
If this is of interewst, I can provide greator detail including source which
is approximately 1100+ lines of C.
-------
From "Pat Macdonald <pam%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET>" Wed Dec 31 22:48:33 1986
Flags: 000000000001
Return-Path: <pam%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET>
Received: from RELAY.CS.NET by CU20B.COLUMBIA.EDU with TCP; Wed 31 Dec 86 22:48:30-EST
Received: from ubc by csnet-relay.csnet id ac12460; 31 Dec 86 22:50 EST
Received: by ubc.csnet id AA03287; Wed, 31 Dec 86 17:12:33 pst
Date: 1 Jan 87 1:13 +0600
From: Pat Macdonald <pam%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET>
To: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
In-Reply-To: <12267191643.290.SY.FDC@CU20B.COLUMBIA.EDU>
Message-Id: <71*pam@cc.uofm.cdn>
Subject: Re: MVS/TSO, VM/CMS, UTS Kermit
I am on the Kermit mailing list and was aware of work being done on extended
packet lengths. My primary reason for mentioning my version of Kermit to you
was because of its portability accross MVS and UTS (and probably VM).
The particular version I am using is written in C, but I have a predecessor
written in assembler.
From <DEDOUREK@UNBMVS1> Tue Jan 6 13:18:29 1987
Flags: 000000000001
Return-Path: <DEDOUREK%UNBMVS1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 6 Jan 87 13:18:20-EST
Received: from UNBMVS1(MAILER) by CUVMA (Mailer X1.23b) id 0489;
Tue, 06 Jan 87 13:14:58 EST
Date: 06 Jan 87 14:07:17 AST
From: <DEDOUREK@UNBMVS1>
To: IBM-Kermit@CU20B.COLUMBIA.EDU
bcc:
Subject: File attributes for VSPC
Message-ID: <ID60048.D870106.T140717.DEDOUREK@UNBMVS1>
As requested, the following indicates the attributes of files in the
VSPC time sharing system under MVS. We have not reached a conclusion
as to how these should be specified and are open to suggestions.
John DeDourek
dedourek@unbmvs1.bitnet
---------------------------------------------------------------------
S y s t e m
Attrib
" CMS GUTS MTS MUSIC TSO VSPC (4) WYLBUR
BLKSIZE x
LRECL x x
RECFM (1) x x
SPACE (2) x x
TYPE (3) (5) x x x
UNIT x
VOLUME x
CONTENT (6) x
PROTECTION (7) x
STATUS (8) x
---------------------------------------------------------------------
Notes:
(1) CMS requires F and V; TSO also allows U.
(2) Disk space allocation increment, in tracks.
(3) Data type: Text, Binary, V-binary, D-binary (the latter two being
undelimited varying-length records with length prefixes).
(4) VSPC provides its own complete file system; this file system
appears to MVS as three VSAM files.
(5) Valid file types under VSPC are: SEQUENTIAL, DIRECT, SEQUENTIAL
UNDEFINED, DIRECT UNDEFINED, and OBJECT. It is unlikely that
kermit will be implemented to write OBJECT type files. Except for
object files, all files are composed of variable length lines with
up to 4058 characters per line. EBCDIC is normal. Each line has a
5 digit line number. Line numbers must be in ascending order. A
direct file requires that the numbers be consecutive (increment of
one), starting at one.
(6) Valid VSPC content types are: DATA, CLIST, and one per foreground
language processor, e.g. BASIC, FORTRAN, PASCAL; the types valid
at an installation exactly correspond to the foreground processors
installed at that installation.
(7) VSPC allows PROTECTION to be any combination of READ or NOREAD,
combined with WRITE or NOWRITE combined with PASSWORD or NOPASSWORD.
If password is specified, then the standard VSPC conventions are
that password must be supplied in the form PASSWORD(password) or
else by appending /password to the file name, or else the system will
prompt for the password at the terminal.
(8) VSPC STATUS is SHARE or NOSHARE indicating whether users other than
the owner have access. This interacts with the PROTECTION in saveral
ways; perhaps these should be combined.
PROTECTION/ Access allowed to Access allowed to
STATUS the file owner others
READ WRITE NOSHARE read write execute none
READ NOWRITE NOSHARE read execute "
NOREAD WRITE NOSHARE read write execute "
NOREAD NOWRITE NOSHARE read execute "
READ WRITE SHARE read write execute read execute
READ NOWRITE SHARE read execute read execute
NOREAD WRITE SHARE read write execute execute
NOREAD NOWRITE SHARE read execute execute
where "execute" on a source program means compile (compiler
indicated by content) followed by execute of object.
If PASSWORD is indicated, then any access requires that the
password be supplied.
(?) VSPC in several respects can be considered "strange"
From "(John F. Chandler) <PEPMNT@CFAAMP>" Tue Jan 6 13:47:52 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMB.COLUMBIA.EDU>
Received: from CUVMB.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 6 Jan 87 13:47:41-EST
Received: from CFAAMP(PEPMNT) by CUVMB (Mailer X1.23b) id 2517;
Mon, 05 Jan 87 21:40:08 EST
Date: 1987 Jan 5 18:58 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
To: <IBM-KERMIT@CU20B>
Subject: VTAM - 7171 - Series/1 - Long packets
It is dismally true that IBM's program product VTAM causes problems for
CMS Kermit trying to receive long packets through a 7171 (and presumably
through any Series/1-like protocol emulator). The question is: is VTAM
available with operating systems other than CMS and TSO? On a related
topic: under what circumstances will a transparent-mode read to a 7171
return a zero-length data string (ditto for Yale ASCII package)?
From "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" Tue Jan 6 15:37:10 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 6 Jan 87 15:36:45-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 1124;
Tue, 06 Jan 87 15:33:21 EST
Date: 1987 Jan 6 15:31 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: S/1 wait after 'Greetings'
According to comments in CMS Kermit, S/1 support was originally added
by Bob Shields. Thus, he is probably the one who instituted the 1-sec
delay after entering transparent mode. Does anyone know where he can
be found? It has been suggested that said delay is not needed, but he
must have had some reason for putting it in.
From "Vace Kundakci <VVVCU@CUVMA>" Wed Jan 7 09:50:42 1987
Flags: 000000000001
Return-Path: <VVVCU%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 7 Jan 87 09:50:29-EST
Received: by CUVMA (Mailer X1.23b) id 3357; Wed, 07 Jan 87 09:47:06 EST
Date: Wed, 7 Jan 87 09:47 EST
From: Vace Kundakci <VVVCU@CUVMA>
To: John F. Chandler <PEPMNT@CFAAMP.BITNET>
CC: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Re: S/1 wait after 'Greetings'; (John F. Chandler) <PEPMNT@CFAAMP.BIT
In-Reply-To: Your memo of 1987 Jan 6 15:31 EST
I put that delay in. Without it, the greeting lines come out
somewhat garbled, specifically, the cursor stays at random places,
and not at the beginning of the 3rd line, after the two lines of the
greeting.
The problem only happened entering server mode and receive, because
send does a sleep anyway.
/Vace
------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Jan 7 15:55:04 1987
Flags: 000000000001
Mail-From: SY.FDC created at 7-Jan-87 15:54:54
Date: Wed 7 Jan 87 15:54:54-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: 3708 Support
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12269091937.28.SY.FDC@CU20B.COLUMBIA.EDU>
I got the following query about using Kermit through the 3708. Is my response
relatively accurate? Does anybody have anything to add? The whole issue of
supporting multiple kinds of non-Series/1-compatible protocol converters
should probably be considered when designing any kind of portable IBM 370
Kermit. - Frank
-----
Date: 06 January 87 14:43 EST
From: ENKJ@CORNELLC
Subject: 3708 PROTOCOL
To: INFO-KERMIT@CU20B.COLUMBIA.EDU
OUR INSTALLATION RECENTLY INSTALLED KERMIT UNDER VM/CMS. WE HAVE SOME NATIVE
TWX LINES (SUPPORTED BY IBM'S BTAM) AND THESE WORK VERY WELL WITH KERMIT.
HOWEVER, WE ARE CONVERTING OUR REMOTE LINES TO USE AN IBM 3708 PROTOCOL
CONVERTER. THIS IS SUPPORTED UNDER VTAM AND ALLOWS FULL SCREEN PROTOCOL
CONVERSION AS WELL AS NTO-LIKE (TWX) LINE MODE FUNCTION. WE HAVE NOT BEEN
ABLE TO GET KERMIT WORKING IN EITHER MODE USING THE 3708.
THE 3708 IS LOCALLY ATTACHED TO A 3705 AND THE END-USERS DIAL IN WITH
300/1200/2400 BAUD MODEMS. ACCORDING TO IBM PERSONNEL, THE 3708 SUPPORTS
FILE TRANSFER AS LONG AS IT CONFORMS TO SOME GENERAL RULES. WE HAVE LOOKED
INTO THIS EXTENSIVELY, BUT HAVE NOT FOUND ANY OBVIOUS PROBLEMS. WE ARE ABLE
TO GET INTO KERMIT SUCCESSFULLY AT BOTH ENDS AND ISSUE ALL NECESSARY SET
COMMANDS. WE ARE ABLE TO INITIATE A SEND FROM THE MAINFRAME END. WHEN WE
TYPE THE RECEIVE COMMAND AT THE PC END, WE GET THE FULL SCREEN BUT IT NEVER
SHOWS ANY DATA BEING TRANSMITTED. A VTAM LINE TRACE SHOWS WHAT LOOKS LIKE
CONTROL INFORMATION BEING SENT FROM THE MAINFRAME END. CAN YOU GIVE US ANY
HELP IN THIS AREA? WE CAN PROVIDE TRACE INFORMATION IF NECESSARY.
THANK YOU.
LINDA POPPLETON
------------------------------
Date: Wed 7 Jan 87 15:45:54-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: [ENKJ@CORNELLC: 3708 PROTOCOL]
To: SY.CHRISTINE@CU20B.COLUMBIA.EDU, ENKJ@CORNELLC
I haven't heard what the magic formula is for getting Kermit to work through
the 3708. In fact, I don't expect CMS Kermit to work through the 3708 because
the 3708 is not compatible with the Series/1, 7171, or 4994, which are the
only protocol converters that CMS Kermit knows about. The reason CMS Kermit
has to know about the protocol converter is so that it can issue the correct
command to put it in transparent mode, so that packets can get through it
unmodified. Unfortunately, I don't think there's any way for CMS Kermit to
sense what kind of protocol converter is employed -- it just knows that it's
communicating with a 3278 or whatever and ASSUMES that there's a Series/1
compatible protocol converter in the middle. To add support for any other
protocol converters, you would probably have to add SET commands to CMS Kermit,
like "set protocol-converter 3708", "set protocol-converter micom", etc.,
and then add the appropriate code to take the thing into and back out of
transparent mode. As to why you can't use Kermit through the 3708 in linemode,
I haven't a clue. Normally, CMS Kermit in linemode works in typical IBM
half duplex manner, sending a packet that terminates with a carriage return,
and then an XON (Ctrl-Q) to grant permission to the PC to send. I don't know
if that's what the 3708 does. An easy way to check all this is to use
IBM PC Kermit with SET DEBUG ON in connect mode as a kind of line monitor.
Finally, in all the above, I've assumed you've set all the appropriate
parameters (parity, handshake, etc) on the PC end, and that you realize the
parameters will be different for linemode and 3270-style connections. I'll
send your query out to some of the IBM mainframe Kermit experts to see if
they have any experience or hints about the 3708. - Frank
-------
-------
From "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" Tue Jan 20 15:49:08 1987
Flags: 000000000011
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 20 Jan 87 15:48:56-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 5941;
Tue, 20 Jan 87 15:48:34 EST
Date: 1987 Jan 20 15:00 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Non-standard features
Traditionally, CMS and TSO Kermits have set file attributes by commands
of the form SET LRECL 999 rather than SET FILE LRECL 999 (the standard).
I have preserved compatibility as much as possible by honoring both
forms in SET commands (but not in SHOW), specifically, LRECL, RECFM, and
FILE-TYPE. Can anyone think of reasons why retaining the old forms would
be harmful in the generic Kermit-370? Clearly, if it is just a question
of purity vs. compatibility, then the latter wins out, but if some other
consideration argues against the old forms, then the time to drop them is
now. Speaking of file attributes, there has still been no response to my
file attribute questionnaire for GUTS, MTS, or WYLBUR -- anybody care to
fill in the blanks?
Meanwhile, I offer the following scenario for assembling Kermit from the
various pieces making up the Kermit-370 source:
a) All the pieces have *COPY cards imbedded appropriately (the macros
already have them -- each macro is preceded by a card of the form
*COPY macro-name
to improve legibility).
b) The builder concatenates all the pieces in any order, changes the
*COPY cards into the appropriate member-separators, and runs the
result through a PDS generator.
c) The "real" source for Kermit is a small skeleton which consists of,
say, comments and COPY instructions (which refer to members of the
macro+source library).
Does this sound too elaborate? I know it is feasible (and easily
automated) for both CMS and TSO -- how about other systems?
John
From "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" Tue Jan 27 02:57:20 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 27 Jan 87 02:56:40-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 6147;
Mon, 26 Jan 87 20:07:07 EST
Date: 1987 Jan 23 15:46 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Mixed-case filespecs?
I have recently considered the possibility of preserving the case of
commands typed at Kermit-370. Despite the tedium of selectively
upcasing pieces according to context, there is the advantage of
allowing the QUOTE character to be set to a lower-case character
and of (X)ECHOing mixed-case strings. The question is: should the
optional foreign filespec be automatically upcased on a SEND command?
This is really two questions: are there systems that would really
like to be fed mixed- or lower-case filespecs, and are there systems
that would really object to being fed lower-case filespecs (coupled
with Kermits that wouldn't take care of such details)?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Tue Jan 27 09:17:08 1987
Flags: 000000000001
Mail-From: SY.FDC created at 27-Jan-87 09:16:39
Date: Tue 27 Jan 87 09:16:39-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Mixed-case filespecs?
To: PEPMNT@CFAAMP, IBM-Kermit@CU20B.COLUMBIA.EDU
In-Reply-To: Message from "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" of Tue 27 Jan 87 02:57:24-EST
Message-ID: <12274262315.289.SY.FDC@CU20B.COLUMBIA.EDU>
The rule has always been "don't mess with the format (including case) of a
foreign filespec". Unix is the prime example of a system in which case is
significant in filespecs. We've got to assume there are others. It's true
that most Kermits will try to deal with filenames in F or R packets being in
the wrong case, but they usually only do this in a dumb way ("can't find the
file? let's try upper/lowercasing it and look again") that doesn't account
for mixed case filenames (e.g. the famous Unix "Makefile"). - Frank
-------
From "Vace Kundakci <VVVCU@CUVMA>" Tue Jan 27 10:46:41 1987
Flags: 000000000001
Return-Path: <VVVCU%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 27 Jan 87 10:46:29-EST
Received: by CUVMA (Mailer X1.23b) id 8129; Tue, 27 Jan 87 10:43:05 EST
Date: Tue, 27 Jan 87 10:43 EST
From: Vace Kundakci <VVVCU@CUVMA>
To: John F. Chandler <PEPMNT@CFAAMP.BITNET>
CC: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Re: Mixed-case filespecs?; (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
In-Reply-To: Your memo of 1987 Jan 23 15:46 EST
I think only the owner of the filesystem can decide on the case of a
file name. Therefore, yes, kermit-370 should keep foreign file name
in it original (typed) case, and translate all local filenames to
upper case (i.e. upon "receive" command).
/Vace
------
From "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" Tue Feb 3 16:23:52 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 3 Feb 87 16:23:39-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 5547;
Tue, 03 Feb 87 16:20:06 EST
Date: 1987 Feb 3 16:04 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Old address vanishing ...
Please note: my old address (pepmnt@cfata1) has been usable for the last
several months despite the new name of our BITNET node (cfaamp), but it
will soon become unusable. In fact, the name CFATA1 is being assigned
to a different computer. Please be sure to use only the new address
>From now on.
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Feb 6 09:42:47 1987
Flags: 000000000001
Mail-From: SY.FDC created at 6-Feb-87 09:42:38
Date: Fri 6 Feb 87 09:42:38-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [Andre PIRARD <A-PIRARD@BLIULG12>: MacKermit CMS TAKE file]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12276888486.38.SY.FDC@CU20B.COLUMBIA.EDU>
This might be of some interest. What's this new EBCDIC character set? - Frank
---------------
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 6 Feb 87 03:51:32-EST
Received: from BLIULG12(MAILER) by CUVMA (Mailer X1.23b) id 7999;
Fri, 06 Feb 87 03:48:12 EST
Received: by BLIULG12 (Mailer X1.23b) id 5055; Fri, 06 Feb 87 09:48:15 ULG
Date: Fri, 06 Feb 87 09:22:45 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: MacKermit CMS TAKE file
To: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Frank,
I told you some time ago of national characters and an emerging IBM EBCDIC
set called "table 500" to support them. I've composed an according conversion
table to be TAKEn on CMS KERMIT for use with MacKermit.
Pittifully, it's only useful in file transfer mode.
I see no way in terminal mode (on the 7171) that would not involve screen
codes translation on the Mac.
By the way, there is still the problem of the "OPTION dot" key that is
nowhere to find on our national keyboards. We have : (colon) where you have
. (dot) and our dot is the shifted key to the right of your M (which is our
(dot) and our dot is the shifted key to the right of your M (which is our
",?" (isn't that easy?)). Neither OPTION : nor . (which needs the shift key)
nor others yield the interrupt. Do you have a hint? Or wouldn't there be
a more "international" choice to be chosen in a future version?
Here goes my file for anyone it can help:
* CMS KERMIT TAKE file to convert Apple Macintosh extended ascii
* international characters to their EBCDIC IBM table 500 equivalent.
* use: TAKE KERMAC
* within CMS KERMIT connected to a Mac before file transfer.
* Andre Pirard
* Service General d'Informatique
* Universite de Liege
* Belgique
*
SET ATOE 128 099
SET ATOE 129 103
SET ATOE 130 104
SET ATOE 131 113
SET ATOE 132 105
SET ATOE 133 236
SET ATOE 134 252
SET ATOE 135 069
SET ATOE 136 068
SET ATOE 137 066
SET ATOE 138 066
SET ATOE 139 070
SET ATOE 140 071
SET ATOE 141 072
SET ATOE 142 081
SET ATOE 143 084
SET ATOE 144 082
SET ATOE 145 083
SET ATOE 146 085
SET ATOE 147 088
SET ATOE 148 086
SET ATOE 149 087
SET ATOE 150 073
SET ATOE 151 206
SET ATOE 152 205
SET ATOE 153 203
SET ATOE 154 204
SET ATOE 156 222
SET ATOE 157 221
SET ATOE 158 219
SET ATOE 159 220
SET ATOE 161 144
SET ATOE 162 176
SET ATOE 163 177
SET ATOE 167 089
SET ATOE 174 158
SET ATOE 180 178
SET ATOE 190 156
SET ETOA 099 128
SET ETOA 103 129
SET ETOA 104 130
SET ETOA 113 131
SET ETOA 105 132
SET ETOA 236 133
SET ETOA 252 134
SET ETOA 069 135
SET ETOA 068 136
SET ETOA 066 137
SET ETOA 066 138
SET ETOA 070 139
SET ETOA 071 140
SET ETOA 072 141
SET ETOA 081 142
SET ETOA 084 143
SET ETOA 082 144
SET ETOA 083 145
SET ETOA 085 146
SET ETOA 088 147
SET ETOA 086 148
SET ETOA 087 149
SET ETOA 073 150
SET ETOA 206 151
SET ETOA 205 152
SET ETOA 203 153
SET ETOA 204 154
SET ETOA 222 156
SET ETOA 221 157
SET ETOA 219 158
SET ETOA 220 159
SET ETOA 144 161
SET ETOA 176 162
SET ETOA 177 163
SET ETOA 089 167
SET ETOA 158 174
SET ETOA 178 180
SET ETOA 156 190
-------
From "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" Fri Feb 13 19:32:36 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 13 Feb 87 19:32:27-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 1773;
Wed, 11 Feb 87 18:43:44 EST
Date: 1987 Feb 11 18:05 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
To: <IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Generic update program
I have devised a file-update program along the lines of CMS UPDATE (i.e.,
it goes by line numbers in cols 73-80 or 76-80 of 80-byte records and
uses input control cards with the characteristic "./" syntax). The
program, however, is generic 370, and it uses a subset of the macro
library for Kermit-370 as well as part of the disk I/O routine from
Kermit. I can't really say that it's a substitute for CMS UPDATE, since
it doesn't take advantage of all the same optimization tricks, but it
could be tuned up to the same extant as Kermit disk I/O. The important
point is that it is GENERIC, and its syntax is less cumbersome than that
of, for example, IEBUPDTE (an OS program with about the same capabilities
for updating). At present, GUPI (Generic Update Program for IBM 370)
exists for CMS only, but the MTS version is in the works, and the TSO
version could be available soon. I propose that the generic Kermit-370
be maintained between major releases by means of some such generic
update program, so that updates alone can be published, thereby saving
network distribution load and also placing all the different versions
of Kermit-370 on an equal footing with regard to upgrading the shared
code. Does anyone have a favorite update syntax to recommend? Bear
in mind that this generic updating scheme must also be accompanied
by a reasonable generic method of generating update control files in
the first place. CMS is blessed with an editor that generates them
automatically (in the sense that one can edit a file in "update" mode
and only the changes are saved/accumulated), but a truly generic
approach might require a file comparison program that generates an
update file given from the original and altered source files. I have
two different programs of that kind, one in FORTRAN, and one in
CMS-specific assembly language.
John
From <DEDOUREK@UNBMVS1> Thu Mar 19 08:03:50 1987
Flags: 000000000001
Return-Path: <DEDOUREK%UNBMVS1.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 19 Mar 87 08:03:43-EST
Received: from UNBMVS1(MAILER) by CUVMA (Mailer X1.23b) id 3081;
Thu, 19 Mar 87 08:04:18 EST
Date: 19 Mar 87 09:00:14 AST
From: <DEDOUREK@UNBMVS1>
To: info-kermit@cu20b.columbia.edu,
ibm-kermit@cu20b.columbia.edu,
kermit@unbmvs1.bitnet,
dgm@unbmvs1.netnorth
Subject: Re: Re: SET ETOA/ATOE in CMS KERMIT
bcc:
Keywords CMS Kermit MVS IBM
Message-ID: <ID67637.D870319.T090014.DEDOUREK@UNBMVS1>
The question of what translation to use between EBCDIC and ASCII can
be influenced by the purpose of the file transfer, and the
reasonableness of the "local standards for 7-bit-ASCII-to-EBCDIC
conversion." Let us consider three applications, and my comments on
them.
1. Mainframe used to back up text files on my micro.
I don't care how the text comes out in EBCDIC, as long as
when I Kermit it back to my micro it comes out the same.
Usually no problem, except maybe for files which don't end
with a new-line, since they come back with one added, but
that's not usually important. If it were, the "SET FILE
BINARY" or its equivalent in whatever Kermit will solve the
problem.
2. Micro used to locally edit and maybe test C programs for the
mainframe.
The mainframe C is based on the standard so uses most of the
"EBCDIC equivalents of ASCII," that is we want things like
curly braces ({}), square brackets ([]), backslash (\), double
("), exclamation point (').
A "good" conversion standard should take care of
this. Problems arise with square brackets [], because they are
not well supported in EBCDIC; as an example I am typing this on
an IBM 3278 terminal, fortunately with APL support, so I can
type [, but it's a FIVE KEY SEQUENCE to get that character.
Also, with : or |, which are the two different vertical bars in
EBCDIC, one with a break and one without. Also with curly
braces, they seem to appear at various different places in the
EBCDIC table, and are created with different codes by the various
terminals; we have several "3278 equivalent" terminals which
use different codes for {}. Also with caret, which I
can't type because it isn't in EBCDIC. Obviously, the key
question is: "Does Kermit translate to the codes recognized by
the C compiler on the mainframe?" This carries over to other
"ASCII type" software on the mainframe.
The problem is that everyone on the
mainframe with an IBM terminal (3278 type) wants the software
to agree with THEIR terminal, and everyone who uses Kermit
or an ASCII terminal wants the 7171 to agree with what THEIR
software needs.
3. Micro used to edit files for the mainframe software; typical
case is to create a PL/1 program to run on the mainframe.
Here we have a piece of software (the PL/1 compiler) written
to EBCDIC standards. EBCDIC has some important characters not
present in ASCII: the "not" symbol (^); the cent sign ( ); both
vertical bars (| and :). Now it is necessary that some
"unimportant" ASCII characters be translated into the needed
EBCDIC to please the mainframe software. The comments at the
end of 2 apply similarly.
My original comment to IBM-Kermit@CU20B.COLUMBIA.EDU on user selection
of translate tables in IBM Kermit for tso was prompted when
I assigned some students to write C programs using Lattice C under MVS.
About halfway through the month, the terminals in the general terminal
room here were moved from the 3705 to the 7171 protocol converter. The
backslash key "\" on the ASCII terminals now produced EBCDIC cent sign
" " but displayed as backslash "\" much to the consternation of the
students learning C. A complaint to the U.N.B. computing center
elicited the response that the cent sign was an important character, and
therefore IBM (or someone) wrote the 7171 protocol converter software to
work that way, and beside, they were hoping to install the TSO Kermit
which worked with the 7171, so they couldn't change it. (Yes, I know
better, but...)
John DeDourek
Professor of Computer Science
School of Computer Science
University of New Brunswick
P.O. Box 4400
Fredericton, New Brunswick, CANADA E3B 5A3
(506) 453-4566
Electronic mail:
DEDOUREK -- University of New Brunswick Mercury System
DEDOUREK@UNBMVS1.BITNET -- BITNET/NETNORTH
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Thu Mar 19 12:02:15 1987
Flags: 000000000001
Mail-From: SY.FDC created at 19-Mar-87 12:02:06
Date: Thu 19 Mar 87 12:02:06-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Kermit with VCNA?
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12287661779.32.SY.FDC@CU20B.COLUMBIA.EDU>
Do any of you know anything about VCNA? Can you comment on the following
exchange and maybe help out this person? Thanks! - Frank
------------------------------
Date: 17 March 87 14:21 EST
From: JOWY@CORNELLC
Subject: KERMIT THROUGH IBM'S VCNA
To: FDC@CU20B.COLUMBIA.EDU
WE HAVE RECENTLY INSTALLED THE CMS VERSION OF KERMIT (3.1) ON OUR IBM MAINFRAME
AND WE ARE ACCESSING CMS THROUGH VCNA. SO FAR, WE HAVE BEEN UNABLE TO EVEN
INITIATE A FILE TRANSFER. WHEN ATTEMPTING TO UPLOAD FROM A PC, WE GET A
MESSAGE FROM KERMIT SAYING IT WAS UNABLE TO RECEIVE AN ACKNOWLEDGEMENT FROM THE
HOST. WHEN ATTEMPTING TO DOWNLOAD TO A PC, WE GET A MESSAGE SAYING IT WAS
UNABLE TO RECEIVE AN INITIATE. AN EXAMINATION OF THE VTAM TRACE RECORDS SHOW
THERE IS A CARRIAGE RETURN AND LINE FEED ON THE FRONT OF EVERY PACKET THE
HOST IS TRYING TO SEND. WE THINK THAT VCNA IS SOMEHOW DOING THIS TO US.
SINCE CARRIAGE RETURN IS THE END-OF-LINE CHARACTER, THE LINE TURNS AROUND
BEFORE THE PACKET IS RECEIVED SO IT APPEARS THE PACKET IS IGNORED. DO YOU
KNOW ANYTHING ABOUT ANY PROBLEMS USING KERMIT WITH VCNA OR DO YOU KNOW OF
ANYONE WHO IS ACTUALLY DOING IT?
THIS IS THE SAME PROBLEM WE HAVE INQUIRED ABOUT BEFORE UNDER ENKJ@CORNELLC.
AT THAT TIME, WE THOUGHT OUR 3708 MIGHT BE A PROBLEM. WE HAVE TRIED
CHANGING THE START-OF-PACKET CHARACTER AND THIS DID NOT WORK.
THANKS. LINDA POPPLETON
------------------------------
Date: Tue, 17 Mar 87 16:13 EST
From: Vace Kundakci <VVVCU@CUVMA>
Subject: VCNA
VCNA is the old way of implementing VTAM under VM. VM creates
virtual terminal sessions and passes data back and forth to a VS1
system running VTAM (which is also in charge of the real terminals).
I really do not know if Kermit should work under that setup. My
insticts say they should if the terminals are non-SNA but would not
if they are SNA. And, 3708 is an SNA box. As far as I know non-SNA
terminal controllers like the 7171 work under VTAM fine.
/Vace
------------------------------
Date: 19 March 87 10:51 EST
From: JOWY@CORNELLC
Subject: KERMIT UNDER SNA PROTOCOL
In the copy of the letter you sent me from Vace Kundakci concerning running
Kermit under VCNA through a 3708, he said that non-SNA should work but that
SNA would not. Is it a definite and known thing that Kermit will not work
under SNA? Do you think this is something simple that can be gotten around,
or do you think we should forget the whole idea of using Kermit? We have
a bunch of projects hanging waiting for me to get Kermit working, but if
Kermit was never meant to work under SNA, then I guess I had better start
looking at other file transfer programs. Of course, IBM would like us to use
their file transfer program, but for financial reasons Kermit would be a better
option for us. Is there any way to find out if anyone else has been successful
in getting Kermit to work under SNA?
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Thu Mar 19 12:43:31 1987
Flags: 000000000001
Mail-From: SY.FDC created at 19-Mar-87 12:43:24
Date: Thu 19 Mar 87 12:43:24-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Kermit with VCNA?
To: JOWY@CORNELLC
cc: IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Message from "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" of Thu 19 Mar 87 12:32:43-EST
Message-ID: <12287669299.32.SY.FDC@CU20B.COLUMBIA.EDU>
Linda, Did you have all the parameters set appropriately on the PC? It isn't
clear (to me at least) from your message whether your connection to CMS is
linemode or full-screen. I assume it must be linemode because CMS Kermit
doesn't know how to deal with full-screen terminals except through Series/1
style front ends. So, did you give the "DO IBM" command on your PC? If so,
do the parameters defined in the "IBM" macro agree with the ones your system
uses? Maybe the problem just has something to do with parity or line
turnaround. Make sure the parities agree. If your system uses LF instead
of XON for line turnaround, you'll have to "SET HANDSHAKE LF" after giving
the "DO IBM" command. Try that and see if it works... - Frank
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Mar 27 12:26:49 1987
Flags: 000000000001
Mail-From: SY.FDC created at 27-Mar-87 12:26:46
Date: Fri 27 Mar 87 12:26:46-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Another volunteer
To: pepmnt@CFAAMP
cc: vvvcu@CUVMA.COLUMBIA.EDU
Message-ID: <12289763422.73.SY.FDC@CU20B.COLUMBIA.EDU>
Thomas Kern at US Dept of Energy (BOBLITT@VTVM1.BITNET), 301-353-2211, is
interested in adding transaction files to CMS Kermit, and a "subcom" (REXX)
interface to TAKE files. Could you call him or send mail and coordinate this?
Thanks! - Frank
-------
From "Andre PIRARD <A-PIRARD@BLIULG12>" Tue Mar 31 12:32:21 1987
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 31 Mar 87 12:31:47-EST
Received: from BLIULG12(MAILER) by CUVMA (Mailer X1.23b) id 4812;
Tue, 31 Mar 87 12:30:55 EST
Received: by BLIULG12 (Mailer X1.23b) id 3483; Tue, 31 Mar 87 13:38:41 ULG
Date: Tue, 31 Mar 1987 13:36:22 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Re: More on ASCII/EBCDIC translation
To: "John F. Chandler" <PEPMNT@CFAAMP.BITNET>,
"Kai U. Leppamaki" <LK-KLE@FINHUT>
cc: Columbia University Center for Computing Activities
<INFO-KERMIT@CU20B.COLUMBIA.EDU>,
IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Your message of 1987 Mar 17 14:26 EST
John, Kai,
All you said are perfectly correct. But I don't agree with John that character
translation is not Kermit's concern. It must bear sitting on Big Blue shoulders
In summary, EBCDIC/ASCII translation tables are necessary for IBM Kermit
to revert the IBM mainframe physical layer translation, so that the original
received data be worked on for data-link layer packet validation/disassembly.
I'd call that reversal tables. They are *normally* 7-bit tables.
After packet analysis, Kermit may need translate the now 8-bit data to EBCDIC,
what is finally the actual code conversion. Let us distinguish them first for
sake of clarity, and call these actual tables. They *must* be 8-bit tables.
And the other way round for sending.
The same tables are presently used.
The question is: should they be different and how?
SET ATOE/ETOA were originally meant to be a maintenance facility. That of
adapting Kermit reversal tables to the IBM system tables without reassembly.
For that purpose, they would only appear in the SYSTEM KERMINI or such
and are irrelevant to the final user.
But character codes being what you know, that commands got to be used to
control what I called above the actual code conversion.
The present practical situation is that various TAKE files have been written
to fill various needs, either private or public.
So, my opinion is that there is a real need for actual conversion control and
that this usage should be devoted to the SET ATOE/ETOA and documented as such.
Inventing a new command for it would simply cause too many files to be changed.
The change in command scope only involves a single change per installation.
If a new command were to be defined, it would apply to the new reversal tables.
But is it that command really needed? There are so many already.
Kermit could be distributed in object (HEX) code format with standard tables.
Linking it with new tables is really no problem to someone who has been able
to modify the system tables in the first place, and to no one anyway, is it?
IBM system tables (reversal) look fairly stable. Failing that, a small
replacement set could do the trick.
Actual conversion tables could be from IBM mainframe multilingual EBCDIC
"best standard" to, say, well established IBM PC extended ASCII.
What is "best standard" can only be told by IBM. They should be consulted
for official plans. But US IBM representatives probably won't know.
So I can add my two cents of information. IBM Belgium people are very active
about character codes, because we have three national languages (sic!),
and because we house the EEC (European Economic Community) HQs in Brussels.
This is support for English, French, Dutch, German, Spanish, Italian, Danish,
Norwegian and Portuguese. Finnish and Swedish are added, although not in EEC.
They have a 3274 RPQ 7L0577 that uses an "EBCDIC Multi-lingual code page 500",
presently a subset. (Note to non IBMers: hardware mod to *the* IBM terminal).
The interest is not in the RPQ itself, but that this character code was
selected after international consultations and that it conforms to the
ISO 8859/1 standard (Group 1 for latin based alphabets). At least IBM France is
said to adopt that code very soon. There is support for several printers.
P.S. For the suggested new SET usage, a requirement is that after modification,
the original actual table can be easily returned to (e. g. SET ATOE without
parameter) without exiting Kermit, so that successive modifications be not
cumulative.
From "(John F. Chandler) <PEPMNT@CFAAMP.BITNET>" Tue Mar 31 14:07:57 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 31 Mar 87 14:07:36-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 5325;
Tue, 31 Mar 87 14:06:40 EST
Date: 1987 Mar 31 13:39 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
*To: Andre PIRARD <A-PIRARD@BLIULG12>, (Kai U. Leppamaki) <LK-KLE@FINHUT>
To: Columbia University Center for Computing Activities
<INFO-KERMIT@CU20B.COLUMBIA.EDU>,
<IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Re: More on ASCII/EBCDIC translation
In-reply-to: A-PIRARD@BLIULG12 message of Tue, 31 Mar 1987 13:36:22 ULG
I may be wrong, but I believe there is a further level of complication
in the translation business. It's not just that the mapping from ASCII
to graphic may vary from "terminal" to "terminal", and that the mapping
>From ASCII to EBCDIC (for TTY lines) may vary from site to site, but also
that two different A-E mappings might exist for the same site: one for
direct TTY lines and one for VTAM. If that is the case, then the original
function of SET ATOE/ETOA remains necessary at the user level.
From FDCCU@CUVMA Tue Mar 31 18:01:07 1987
Flags: 000000000011
Return-Path: <FDCCU%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 31 Mar 87 18:01:02-EST
Received: by CUVMA (Mailer X1.23b) id 6506; Tue, 31 Mar 87 18:00:11 EST
Date: 03/31 17:20:04
From: FDCCU@CUVMA
Subject: BOBLITT NOTE - PUN file from RSCS
Tag: FILE (5709) ORIGIN VTVM1 BOBLITT 3/31/87 12:19:07 E.S.T.
To: SY.FDC@CU20B
Reply-To: BOBLITT@VTVM1
Date: 31 March 1987, 17:13:50 EST
From: Thomas Kern (301)353-2211 BOBLITT at VTVM1
To: Frank Da Cruz FDCCU at CUVMA
Subj: IBM-Kermit discussion group
The Department of Energy currently runs VM/HPO 4.2 and MVS/SP 1.3.5.
We have Kermit installed on both systems. Future systems include VM/XA
and MVS/XA. All asynch access will be thru 7171 protocal convertors
controlled by VTAM on the host side.
Now how do I participate in the discussion group?
Do I send CMS notes to a single site or to a mailing list?
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Apr 1 08:40:14 1987
Flags: 000000000001
Mail-From: SY.FDC created at 1-Apr-87 08:40:06
Date: Wed 1 Apr 87 08:40:06-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [Andre PIRARD <A-PIRARD@BLIULG12>: Re: More on ASCII/EBCDIC translation]
To: ibm-kermit@CU20B.COLUMBIA.EDU
Message-ID: <12291032879.267.SY.FDC@CU20B.COLUMBIA.EDU>
Any comments, before entering this latest round into the Info-Kermit digest?
---------------
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 31 Mar 87 12:31:47-EST
Received: from BLIULG12(MAILER) by CUVMA (Mailer X1.23b) id 4812;
Tue, 31 Mar 87 12:30:55 EST
Received: by BLIULG12 (Mailer X1.23b) id 3483; Tue, 31 Mar 87 13:38:41 ULG
Date: Tue, 31 Mar 1987 13:36:22 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Re: More on ASCII/EBCDIC translation
To: "John F. Chandler" <PEPMNT@CFAAMP.BITNET>,
"Kai U. Leppamaki" <LK-KLE@FINHUT>
cc: Columbia University Center for Computing Activities
<INFO-KERMIT@CU20B.COLUMBIA.EDU>,
IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Your message of 1987 Mar 17 14:26 EST
John, Kai,
All you said are perfectly correct. But I don't agree with John that character
translation is not Kermit's concern. It must bear sitting on Big Blue shoulders
In summary, EBCDIC/ASCII translation tables are necessary for IBM Kermit
to revert the IBM mainframe physical layer translation, so that the original
received data be worked on for data-link layer packet validation/disassembly.
I'd call that reversal tables. They are *normally* 7-bit tables.
After packet analysis, Kermit may need translate the now 8-bit data to EBCDIC,
what is finally the actual code conversion. Let us distinguish them first for
sake of clarity, and call these actual tables. They *must* be 8-bit tables.
And the other way round for sending.
The same tables are presently used.
The question is: should they be different and how?
SET ATOE/ETOA were originally meant to be a maintenance facility. That of
adapting Kermit reversal tables to the IBM system tables without reassembly.
For that purpose, they would only appear in the SYSTEM KERMINI or such
and are irrelevant to the final user.
But character codes being what you know, that commands got to be used to
control what I called above the actual code conversion.
The present practical situation is that various TAKE files have been written
to fill various needs, either private or public.
So, my opinion is that there is a real need for actual conversion control and
that this usage should be devoted to the SET ATOE/ETOA and documented as such.
Inventing a new command for it would simply cause too many files to be changed.
The change in command scope only involves a single change per installation.
If a new command were to be defined, it would apply to the new reversal tables.
But is it that command really needed? There are so many already.
Kermit could be distributed in object (HEX) code format with standard tables.
Linking it with new tables is really no problem to someone who has been able
to modify the system tables in the first place, and to no one anyway, is it?
IBM system tables (reversal) look fairly stable. Failing that, a small
replacement set could do the trick.
Actual conversion tables could be from IBM mainframe multilingual EBCDIC
"best standard" to, say, well established IBM PC extended ASCII.
What is "best standard" can only be told by IBM. They should be consulted
for official plans. But US IBM representatives probably won't know.
So I can add my two cents of information. IBM Belgium people are very active
about character codes, because we have three national languages (sic!),
and because we house the EEC (European Economic Community) HQs in Brussels.
This is support for English, French, Dutch, German, Spanish, Italian, Danish,
Norwegian and Portuguese. Finnish and Swedish are added, although not in EEC.
They have a 3274 RPQ 7L0577 that uses an "EBCDIC Multi-lingual code page 500",
presently a subset. (Note to non IBMers: hardware mod to *the* IBM terminal).
The interest is not in the RPQ itself, but that this character code was
selected after international consultations and that it conforms to the
ISO 8859/1 standard (Group 1 for latin based alphabets). At least IBM France is
said to adopt that code very soon. There is support for several printers.
P.S. For the suggested new SET usage, a requirement is that after modification,
the original actual table can be easily returned to (e. g. SET ATOE without
parameter) without exiting Kermit, so that successive modifications be not
cumulative.
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Apr 1 08:40:47 1987
Flags: 000000000001
Mail-From: SY.FDC created at 1-Apr-87 08:40:38
Date: Wed 1 Apr 87 08:40:37-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [(John F. Chandler) <PEPMNT@CFAAMP.BITNET>: Re: More on ASCII/EBCDIC translation]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12291032974.267.SY.FDC@CU20B.COLUMBIA.EDU>
more...
---------------
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 31 Mar 87 14:07:36-EST
Received: from CFAAMP(PEPMNT) by CUVMA (Mailer X1.23b) id 5325;
Tue, 31 Mar 87 14:06:40 EST
Date: 1987 Mar 31 13:39 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
*To: Andre PIRARD <A-PIRARD@BLIULG12>, (Kai U. Leppamaki) <LK-KLE@FINHUT>
To: Columbia University Center for Computing Activities
<INFO-KERMIT@CU20B.COLUMBIA.EDU>,
<IBM-KERMIT@CU20B.COLUMBIA.EDU>
Subject: Re: More on ASCII/EBCDIC translation
In-reply-to: A-PIRARD@BLIULG12 message of Tue, 31 Mar 1987 13:36:22 ULG
I may be wrong, but I believe there is a further level of complication
in the translation business. It's not just that the mapping from ASCII
to graphic may vary from "terminal" to "terminal", and that the mapping
>From ASCII to EBCDIC (for TTY lines) may vary from site to site, but also
that two different A-E mappings might exist for the same site: one for
direct TTY lines and one for VTAM. If that is the case, then the original
function of SET ATOE/ETOA remains necessary at the user level.
-------
From "Andre PIRARD <A-PIRARD@BLIULG12>" Thu Apr 2 08:47:16 1987
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 2 Apr 87 08:47:10-EST
Received: from BLIULG12(MAILER) by CUVMA (Mailer X1.23b) id 2320;
Thu, 02 Apr 87 08:46:36 EST
Received: by BLIULG12 (Mailer X1.23b) id 7338; Thu, 02 Apr 87 11:52:55 ULG
Date: Thu, 02 Apr 87 10:58:56 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Re: More on ASCII/EBCDIC translation
To: "John F. Chandler" <PEPMNT@CFAAMP>
cc: Columbia University Center for Computing Activities
<INFO-KERMIT@CU20B.COLUMBIA.EDU>,
IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Your message of 1987 Mar 31 13:39 EST
>I may be wrong, but I believe there is a further level of complication
>in the translation business. It's not just that the mapping from ASCII
>to graphic may vary from "terminal" to "terminal", and that the mapping
>from ASCII to EBCDIC (for TTY lines) may vary from site to site, but also
>that two different A-E mappings might exist for the same site: one for
>direct TTY lines and one for VTAM. If that is the case, then the original
>function of SET ATOE/ETOA remains necessary at the user level.
John,
No, you're right. Within the same site, it should make sense to use the same
translation tables, whatever the path. But it is not to be taken for granted.
And there *is* yet another situation, that of a user accessing site1 to do a
remote logon on site2. He could use site1 system tables and site2 Kermit
reversal tables. Although not very TTY-feasible now, it must be considered.
So, even if Kermit reversal tables are customized, overriding should be
allowed. But I still strongly feel it must be with *the new* command.
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Apr 23 22:18:40 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 23 Apr 87 21:18:31-EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 7453; Thu, 23 Apr 87 21:16:23 EST
Date: 1987 Apr 23 20:22 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Two kinds of EBCDIC-ASCII translation
Message-id: <PEPMNT.870423.202239.A0@CFAAMP.BITNET>
It strikes me that a reasonable compromise can make nearly everyone
happy. To sum up the arguments:
1. For Series/1-type interfaces the issue is moot.
2. For TTY-type interfaces there are two kinds of translation presently
served by a single pair of tables -- (a) counteracting the interface
translation and (b) converting between the external, possibly 8-bit,
"ASCII" standard and the internal EBCDIC.
3. If the 7-bit part of the external "ASCII" character set were always
mapped to the same internal EBCDIC characters, a single pair of
tables would do the trick. However, the "national" characters
violate that condition.
4. While adding another pair of tables doesn't fix all the files that
have already been stored on disk with the wrong "national" character
set, it can certainly help prevent that problem in the future (and
isn't hard to implement anyway).
5. While function (a) usually shouldn't need any modification by a
Kermit user, there's a very real possibility that more than one kind
of terminal translation will exist at a single site, so both sets
of tables must be user-settable.
6. There are too many variants on translation to allow Kermit to have
multiple sets pre-stored and callable by name -- it really is easy
enough to write a TAKE file to allow that kind of standardization.
7. While it would be convenient to have one command alter, say, both
ATOE and ETOA at the same time (since they're supposed to be
inverses), there's no guarantee that the terminal translation tables
themselves are inverses, so are more-or-less stuck with independent
SET commands for all the tables.
I propose the following new commands for Kermit-370:
SET TTABLE (ON|OFF) Default: OFF. If OFF, then use the original tables
(ATOE and ETOA) both for counteracting the terminal translation on
TTY lines and for translating between disk files and packets. If
ON, then use the new tables (TATOE and TETOA) for the terminal
un-translation.
SET (TATOE|TETOA) 'n' 'm' Just like the old (SET|TDUMP) (ETOA|ATOE),
TDUMP (TATOE|TETOA) except that they apply to the new tables.
Initially, the old and new tables would be identical, but user or TAKE
commands would alter them separately. The default value of TTABLE means
that no one is forced to change old TAKE files that worked with previous
official releases of CMS Kermit. I propose also to modify the syntax of
all four SET (T)(E|A)TO(A|E) commands so that ommitting the offset and
value ('n' 'm') is not an ERROR, but rather resets the corresponding
table to its initial contents (before SYSTEM KERMINI). I welcome any
comments on this design.
John
From "Vace Kundakci <VVVCU@CUVMA>" Fri Apr 24 11:22:27 1987
Flags: 000000000001
Return-Path: <VVVCU%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 24 Apr 87 10:22:12-EST
Received: by CUVMA (Mailer X1.24) id 8819; Fri, 24 Apr 87 10:20:11 EST
Date: Fri, 24 Apr 87 10:20 EST
From: Vace Kundakci <VVVCU@CUVMA>
To: PEPMNT@CFAAMP.BITNET (John F. Chandler)
CC: IBM-KERMIT@CU20B
Subject: Re: Two kinds of EBCDIC-ASCII translation; (John F. Chandler) PEPMNT@
In-Reply-To: Your memo of 1987 Apr 23 20:22 EDT
I agree with your analysis... On more command you may want to
consider is one which dumps the current translate table which has
been modified by the user onto a disk using set commands (or maybe
those entries which differ from the static table entries). This way
a user can take a snapshot of what the current table is in case he
needs to reload it in the future.
/Vace
------
From "Andre PIRARD <A-PIRARD@BLIULG12>" Mon Apr 27 20:03:38 1987
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 27 Apr 87 18:03:30-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 7448; Mon, 27 Apr 87 18:01:46 EST
Received: by BLIULG12 (Mailer X1.23b) id 2768; Mon, 27 Apr 87 15:01:36 ULG
Date: Mon, 27 Apr 87 14:27:30 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Re: Two kinds of EBCDIC-ASCII translation
To: "John F. Chandler" <PEPMNT@CFAAMP.BITNET>,
IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Your message of 1987 Apr 23 20:22 EDT
I find the proposition technically perfect, thank you John.
But it is adding to the complexity of Kermit options rarely understood
by the average user. Frankly speaking, I would have preferred TTABLE ON
always, because this makes SET ATOE/ETOA a harmless user command.
However, this can be defaulted to if the set TTABLE ON is coded in the
SYSTEM KERMINI file, what should be recommended in the documentation
when there is no other good (compatibility) reason not to do so.
Wouldn't it be useful in this respect to have the documentation file split
in two parts, one for general users, the other for the system programmer
and the occasional user with specific needs?
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Apr 27 22:26:53 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 27 Apr 87 20:26:46-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 7827; Mon, 27 Apr 87 20:24:55 EST
Date: 1987 Apr 27 20:24 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: Two kinds of EBCDIC-ASCII translation
In-reply-to: A-PIRARD@BLIULG12 message of Mon, 27 Apr 87 14:27:30 ULG
Message-id: <PEPMNT.870427.202417.A0@CFAAMP.BITNET>
As I see it, there isn't much impelling the casual user to try issuing
SET ATOE commands at random. Therefore, the main factor in deciding
the default value of TTABLE should be conservatism: make the program
work the same way it did last week if at all possible. If last week's
behavior was unacceptable (and this is a site-dependent judgement), then
the default can be changed in the SYSTEM KERMINI file.
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed May 20 14:57:33 1987
Flags: 000000000001
Mail-From: SY.FDC created at 20-May-87 12:57:22
Date: Wed 20 May 87 12:57:22-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: 3708 support
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12303913846.32.SY.FDC@CU20B.COLUMBIA.EDU>
I got a version of old TSO-Kermit (v 1, the Chicago version), modified to
support the 3708. I hope that one of you will grab it and incorporate the
code into your version(s), and that it will find its way into the portable
370 Kermit. Watch Info-Kermit for the announcement, then grab it off BITNET.
(It's already on CU20B in KER:TS3*.* in case you have Arpanet or CCnet
access). Somebody please call the guy (his name's in the TS3KER.MSG file,
along with phone #) and let him know what's up, so he doesn't start doing
something some of you are also doing (or have done). - Frank
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed May 20 18:20:51 1987
Flags: 000000000001
Mail-From: SY.FDC created at 20-May-87 16:19:48
Date: Wed 20 May 87 16:19:48-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: 3708 Support
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12303950699.32.SY.FDC@CU20B.COLUMBIA.EDU>
At John Chandler's request, here are the lines from the 3708-supporting
Kermit that were changed from the Chicago 1.0 version:
Changed lines from TSOKER.ASM:
STH R0,TERMTYPE save as terminal type scs-gsm
* BNZ BADDEV YES, THEN REFUSE USER scs-gsm TSO01650
BE OVWOK OK to overwrite scs-gsm TSO03150
SPACE , scs-gsm
WRTERM 'Data Set will not be overwritten.' scs-gsm
B PROMPT scs-gsm
SPACE , scs-gsm
OVWOK DS 0H OK TO OVERWRITE scs-gsm
WRTERM 'Data Set will be overwritten.' scs-gsm
BZ MAKDCBX Ok, merge in dcb atrributes scs-gsm TSO03230
SPACE , scs-gsm TSO03230
BINCVRT R1,WRKBUFF+31,DBLWRK scs-gsm TSO03230
TPUT WRKBUFF,38 scs-gsm TSO03230
B PROMPT GO BACK FOR MORE scs-gsm
SPACE , scs-gsm
SPACE , scs-gsm TSO03230
LR R2,R1 save return code scs-gsm TSO03230
WRTERM 'Unable to send file.' scs-gsm TSO03230
CH R2,=AL2(1) data set not found? scs-gsm TSO03230
BNE SNDALCE1 no, other error. scs-gsm TSO03230
SPACE , scs-gsm TSO03230
MVC WRKBUFF(8),=C'Dataset ' scs-gsm TSO03230
MVC WRKBUFF+8(44),DSNAME scs-gsm TSO03230
MVC WRKBUFF+52(16),=CL16' was not found.' scs-gsm TSO03230
TPUT WRKBUFF,68 scs-gsm TSO03230
B PROMPT GO BACK FOR MORE scs-gsm
SPACE , scs-gsm TSO03230
SNDALCE1 DS 0H scs-gsm TSO03230
BINCVRT R2,WRKBUFF+31,DBLWRK scs-gsm TSO03230
TPUT WRKBUFF,38 scs-gsm TSO03230
B PROMPT GO BACK FOR MORE scs-gsm
SPACE , scs-gsm
SPACE , scs-gsm
MVC WRKBUFF(2),=H'26' scs-gsm TSO16600
XC WRKBUFF+2(2),WRKBUFF+2 scs-gsm TSO16610
PUT DEBUG,WRKBUFF scs-gsm TSO16630
LA R1,4(,R6) ADJUST LENGTH scs-gsm TSO16640
STH R1,WRKBUFF SET RDW scs-gsm TSO16650
EX R6,DBGMVC1 MOVE IN DATA scs-gsm TSO16660
PUT DEBUG,WRKBUFF scs-gsm TSO16670
SPNODEB DS 0H scs-gsm TSO16680
TR SNDPKT(130),ATOE SEND IN EBCDIC scs-gsm TSO16570
TM DEBUG+(DCBOFLGS-IHADCB),DCBOFOPN DEBUG?scs-gsm TSO16580
BZ SPNODEBA scs-gsm TSO16590
SPACE , scs-gsm
MVC WRKBUFF(2),=H'27' scs-gsm TSO16600
XC WRKBUFF+2(2),WRKBUFF+2 scs-gsm TSO16610
SPNODEBA DS 0H scs-gsm TSO16680
OC TERMTYPE,TERMTYPE Check terminal type. scs-gsm
BNZ SP3270 Must be a 3270. scs-gsm
SPACE , scs-gsm
* scs-gsm
* Write packet to tty device. scs-gsm
* scs-gsm
TPUT SNDPKT,(R6),CONTROL,WAIT,NOHOLD,BREAKIN scs-gsm TSO16680
B SPCKRET Go check return code. scs-gsm
SPACE , scs-gsm
* scs-gsm
* Write Packet to 3270 Device. scs-gsm
* scs-gsm
SP3270 DS 0H Check return code scs-gsm
TPUT SNDPKT,(R6),FULLSCR,WAIT,NOHOLD,BREAKIN scs-gsm TSO16680
SPACE , scs-gsm
SPCKRET DS 0H Check return code scs-gsm
MVC WRKBUFF+4(22),=CL22'TGET REC PACKET EBCDIC' scs-gsm TSO17100
PUT DEBUG,WRKBUFF scs-gsm TSO17110
STH R8,WRKBUFF SET RDW scs-gsm TSO17120
EX R8,DBGMVC2 MOVE IN DATA scs-gsm TSO17130
PUT DEBUG,WRKBUFF scs-gsm TSO17140
RDNODEB DS 0H scs-gsm TSO17150
TR RECPKT(130),ETOA scs-gsm TSO17150
TM DEBUG+(DCBOFLGS-IHADCB),DCBOFOPN OPEN? scs-gsm TSO17050
BZ RDNODEBA scs-gsm TSO17060
MVC WRKBUFF(2),=H'25' scs-gsm TSO17080
XC WRKBUFF+2(2),WRKBUFF+2 scs-gsm TSO17090
MVC WRKBUFF+4(21),=CL21'TGET REC PACKET ASCII' scs-gsm TSO17100
PUT DEBUG,WRKBUFF scs-gsm TSO17110
STH R8,WRKBUFF SET RDW scs-gsm TSO17120
EX R8,DBGMVC2 MOVE IN DATA scs-gsm TSO17130
PUT DEBUG,WRKBUFF scs-gsm TSO17140
RDNODEBA DS 0H scs-gsm TSO17150
TERMTYPE DS H Terminal type 0 = tty scs-gsm
This is not really a differences file -- I just included the lines that have
the guy's initials on them, assuming the line numbers will do the rest.
Anyhow, here's the guy's message:
From: Geoffrey S. Mendelson May 1987
SUNGARD Central Computer Facility
401 North Broad Street, Suite 600
Philadelphia, PA 19108
Phone 215-351-1300
Enclosed is a copy of a modifed Kermit TSO. It has been changed to:
1. Work through an IBM 3708.
2. Add error messages that were missing.
It has been tested using MVS/XA and TSO/E.
Where I changed the code, except at the translate tables, I added 'scs-gsm' in
the comments field of each line. The translate tables are completely new and
were generated mostly by machine using TSO, CMS and a PC.
This version was built on the TSO version 1 and uses all the same
documentation, installation procedures, etc. I have not included them on the
tape.
In the near future I hope to add binary file transfer and some of the features
of the CMS version 3.
If you have any questions, please call me at 215-351-1395.
-------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Wed May 20 21:46:55 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 20 May 87 19:46:49-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 9473; Wed, 20 May 87 19:44:58 EDT
Date: 1987 May 20 19:12 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: 3708 support
Message-id: <PEPMNT.870520.191212.A0@CFAAMP.BITNET>
I can't really tell for sure, but the "differences" file seems to
indicate that the 3708 front end is more-or-less indistinguishable
>From a Series/1 but is operationally quite different -- in particular,
it appears that the 3708 performs ASCII/EBCDIC translation just like
a 3705 and doesn't really have a transparent mode. Does anybody know
if this is true?
John
From "Andre PIRARD <A-PIRARD@BLIULG12>" Mon May 25 05:50:35 1987
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 25 May 87 03:50:29-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 9874; Mon, 25 May 87 03:48:52 EDT
Received: by BLIULG12 (Mailer X1.23b) id 2552; Mon, 25 May 87 09:48:55 ULG
Date: Mon, 25 May 1987 08:48:09 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: CMS Kermit and the 7171
To: IBM-KERMIT@CU20B.COLUMBIA.EDU,
Protocol Converter list <IBM7171@DEARN>
cc: Kai U Leppamaki <LK-KLE@FINHUT>
I am currently converting a file transfer programs suite to Kermit protocol.
We will use it primarily for communication between micros and mainframe thru
7171's and we want strong and easy performance in that particular environment.
I've just undertaken tests under noisy line conditions and I have analysed
the behaviour of the (our) 7171. Amazing!
Test conditions: file upload at 300 bauds with an acoustic coupler to provoke
transmission errors, so I can tap on the handset.
Observation: during 7171 transparent write/read, read phase (the micro is
sending a packet), I tap once. The transmission error causes the 7171 to
terminate read phase and gives the incomplete packet to the host Kermit.
The host Kermit nacks the packet and the 7171 reenters a second transparent
write/read. The micro is still sending the rest of the interrupted packet which
the 7171 takes as a new one. Moreover, the 7171 entering read phase during
already ongoing transmission often (but not always) causes it to immediately
sense another transmission error which repeats the process. The net result
is that a micro originating packet can be sliced into as many packets as the
host response time allows. The tap on the hanset is often followed by
a two-way continuous transmission (mostly favoured at 300 bauds).
For that reason, I used (and continue) to have the micro purge its input buffer
just before it sends an end-of-packet character. But...
1) We could admittedly do without that 7171 oddity (the manual GA37-0021-0 says
'...all the characters received during the read [phase] (including erroneous
characters and the terminating character) will be presented to the host').
2) The CMS Kermit retry count defaults to 5 and limits to 31 (*why?*). That
can be too easily used up under the above conditions. No wonder some people
reported difficulties in file transfers with the 7171.
Do others observe this? Anybody has an idea for a cure?
I'd be *most* interested in comments and am willing to summerize to the net.
From POSTMAST@CUVMA Tue May 26 10:42:17 1987
Flags: 000000000001
Return-Path: <POSTMAST%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 26 May 87 08:42:09-EDT
Received: by CUVMA (Mailer X1.24) id 1226; Tue, 26 May 87 08:40:31 EDT
Date: Tue, 26 May 87 08:40 EDT
From: POSTMAST@CUVMA
To: IBM-KERMIT@CU20B
Subject: Re: Undelivered mail; Network Mailer <MAILER@HARVBUS1>
Comments: Forwarding the following to you...
Received: by CUVMA (Mailer X1.24) id 9890; Mon, 25 May 87 03:53:03 EDT
Received: from HARVBUS1(MAILER) by CUVMA (Mailer X1.24) id 9889;
Mon, 25 May 87 03:53:02 EDT
Received: by HARVBUS1 (Mailer X1.23b) id 3347; Mon, 25 May 87 03:52:45 EST
Date: Mon, 25 May 87 03:52:44 EST
From: Network Mailer <MAILER@HARVBUS1>
Subject: Undelivered mail
To: MAILER@CUVMA
ReSent-Date: Mon, 25 May 87 03:53:02 EDT
ReSent-From: Network Mailer <MAILER@CUVMA>
ReSent-To: POSTMAST@CUVMA
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
Validity check failed.
--------------------RETURNED MAIL FILE--------------------
Received: from CUVMA(MAILER) by HARVBUS1 (Mailer X1.23b) id 3346;
Mon, 25 May 87 03:52:44 EST
Received: from CUVMA.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 9878; Mon, 25 May 87 03:50:04 EDT
Received: from CU20B.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU on 05/25/87 at 03:50:03
EDT
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 25 May 87
03:50:29-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 9874; Mon, 25 May 87 03:48:52 EDT
Received: by BLIULG12 (Mailer X1.23b) id 2552; Mon, 25 May 87 09:48:55 ULG
Date: Mon, 25 May 1987 08:48:09 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: CMS Kermit and the 7171
To: IBM-KERMIT@CU20B.COLUMBIA.EDU,
Protocol Converter list <IBM7171@DEARN>
cc: Kai U Leppamaki <LK-KLE@FINHUT>
I am currently converting a file transfer programs suite to Kermit protocol.
We will use it primarily for communication between micros and mainframe thru
7171's and we want strong and easy performance in that particular environment.
I've just undertaken tests under noisy line conditions and I have analysed
the behaviour of the (our) 7171. Amazing!
Test conditions: file upload at 300 bauds with an acoustic coupler to provoke
transmission errors, so I can tap on the handset.
Observation: during 7171 transparent write/read, read phase (the micro is
sending a packet), I tap once. The transmission error causes the 7171 to
terminate read phase and gives the incomplete packet to the host Kermit.
The host Kermit nacks the packet and the 7171 reenters a second transparent
write/read. The micro is still sending the rest of the interrupted packet which
the 7171 takes as a new one. Moreover, the 7171 entering read phase during
already ongoing transmission often (but not always) causes it to immediately
sense another transmission error which repeats the process. The net result
is that a micro originating packet can be sliced into as many packets as the
host response time allows. The tap on the hanset is often followed by
a two-way continuous transmission (mostly favoured at 300 bauds).
For that reason, I used (and continue) to have the micro purge its input buffer
just before it sends an end-of-packet character. But...
1) We could admittedly do without that 7171 oddity (the manual GA37-0021-0 says
'...all the characters received during the read [phase] (including erroneous
characters and the terminating character) will be presented to the host').
2) The CMS Kermit retry count defaults to 5 and limits to 31 (*why?*). That
can be too easily used up under the above conditions. No wonder some people
reported difficulties in file transfers with the 7171.
Do others observe this? Anybody has an idea for a cure?
I'd be *most* interested in comments and am willing to summerize to the net.
------ End of forwarded mail by POSTMAST@CUVMA.
From POSTMAST@CUVMA Tue May 26 13:47:48 1987
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 26 May 87 11:46:18-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 1583; Tue, 26 May 87 10:24:08 EDT
Received: by BLIULG12 (Mailer X1.23b) id 1319; Tue, 26 May 87 16:22:23 ULG
Resent-Date: Tue, 26 May 87 16:17:52 ULG
Resent-From: Andre PIRARD <A-PIRARD@BLIULG12>
Resent-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Received: from CU20B.COLUMBIA.EDU by wiscvm.wisc.edu ; Tue, 26 May 87 07:41:28
CDT
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 26 May 87
08:42:09-EDT
Received: by CUVMA (Mailer X1.24) id 1226; Tue, 26 May 87 08:40:31 EDT
Date: Tue, 26 May 87 08:40 EDT
From: POSTMAST@CUVMA
To: IBM-KERMIT@CU20B
Subject: Re: Undelivered mail; Network Mailer <MAILER@HARVBUS1>
Comments: Forwarding the following to you...
I am forwarding back my mail so you be aware of the problem.
Still for inclusion in IBM-KERMIT.
----------------------------Original message----------------------------
Received: by CUVMA (Mailer X1.24) id 9890; Mon, 25 May 87 03:53:03 EDT
Received: from HARVBUS1(MAILER) by CUVMA (Mailer X1.24) id 9889;
Mon, 25 May 87 03:53:02 EDT
Received: by HARVBUS1 (Mailer X1.23b) id 3347; Mon, 25 May 87 03:52:45 EST
Date: Mon, 25 May 87 03:52:44 EST
From: Network Mailer <MAILER@HARVBUS1>
Subject: Undelivered mail
To: MAILER@CUVMA
ReSent-Date: Mon, 25 May 87 03:53:02 EDT
ReSent-From: Network Mailer <MAILER@CUVMA>
ReSent-To: POSTMAST@CUVMA
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
Validity check failed.
--------------------RETURNED MAIL FILE--------------------
Received: from CUVMA(MAILER) by HARVBUS1 (Mailer X1.23b) id 3346;
Mon, 25 May 87 03:52:44 EST
Received: from CUVMA.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 9878; Mon, 25 May 87 03:50:04 EDT
Received: from CU20B.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU on 05/25/87 at 03:50:03
EDT
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 25 May 87
03:50:29-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 9874; Mon, 25 May 87 03:48:52 EDT
Received: by BLIULG12 (Mailer X1.23b) id 2552; Mon, 25 May 87 09:48:55 ULG
Date: Mon, 25 May 1987 08:48:09 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: CMS Kermit and the 7171
To: IBM-KERMIT@CU20B.COLUMBIA.EDU,
Protocol Converter list <IBM7171@DEARN>
cc: Kai U Leppamaki <LK-KLE@FINHUT>
I am currently converting a file transfer programs suite to Kermit protocol.
We will use it primarily for communication between micros and mainframe thru
7171's and we want strong and easy performance in that particular environment.
I've just undertaken tests under noisy line conditions and I have analysed
the behaviour of the (our) 7171. Amazing!
Test conditions: file upload at 300 bauds with an acoustic coupler to provoke
transmission errors, so I can tap on the handset.
Observation: during 7171 transparent write/read, read phase (the micro is
sending a packet), I tap once. The transmission error causes the 7171 to
terminate read phase and gives the incomplete packet to the host Kermit.
The host Kermit nacks the packet and the 7171 reenters a second transparent
write/read. The micro is still sending the rest of the interrupted packet which
the 7171 takes as a new one. Moreover, the 7171 entering read phase during
already ongoing transmission often (but not always) causes it to immediately
sense another transmission error which repeats the process. The net result
is that a micro originating packet can be sliced into as many packets as the
host response time allows. The tap on the hanset is often followed by
a two-way continuous transmission (mostly favoured at 300 bauds).
For that reason, I used (and continue) to have the micro purge its input buffer
just before it sends an end-of-packet character. But...
1) We could admittedly do without that 7171 oddity (the manual GA37-0021-0 says
'...all the characters received during the read [phase] (including erroneous
characters and the terminating character) will be presented to the host').
2) The CMS Kermit retry count defaults to 5 and limits to 31 (*why?*). That
can be too easily used up under the above conditions. No wonder some people
reported difficulties in file transfers with the 7171.
Do others observe this? Anybody has an idea for a cure?
I'd be *most* interested in comments and am willing to summerize to the net.
------ End of forwarded mail by POSTMAST@CUVMA.
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Thu Jun 4 15:07:24 1987
Flags: 000000000001
Mail-From: SY.FDC created at 4-Jun-87 13:07:13
Date: Thu 4 Jun 87 13:07:13-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Kermit can work through non-IBM protocol converters!
To: IBM-Kermit@CU20B.COLUMBIA.EDU
cc: sy.christine@CU20B.COLUMBIA.EDU
Message-ID: <12307847800.152.SY.FDC@CU20B.COLUMBIA.EDU>
I just got a call from Mark Hripko of TRW in Redondo Beach, CA. He says he
has found that if you issue the SNA command to go into graphics mode to
almost any kind of protocol converter (Datastream, Micom, IBM 3708 or 3710,
etc etc), that it becomes sufficiently transparent to transfer Kermit packets
through. He's added code to the old TSOS1 Kermit to do this. He'd like
any of you who are working on "portable Kermit" or TSO Kermit to contact him,
and he'll tell you how to do it. I can't tell you how many calls I've had
>From people with wierd protocol converters who needed to be able to use
Kermit and had to tell them it was impossible. Now it turns out that it may
have been possible all along! Could somebody please call him and report back
to IBM-Kermit if this is as good as it sounds? Thanks! - Frank
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Jun 12 14:56:39 1987
Flags: 000000000001
Mail-From: SY.FDC created at 12-Jun-87 12:56:35
Date: Fri 12 Jun 87 12:56:35-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Another operating system for Portable Kermit
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12309943015.22.SY.FDC@CU20B.COLUMBIA.EDU>
I understand that recent versions of VM/CMS Kermit do not run under
VM/370 (the old, free version of VM), but that the original version 1.0
did. Maybe Portable Kermit should include support for VM/370 as well as
VM/SP. - Frank
-------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Jun 12 16:29:25 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 12 Jun 87 14:29:18-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 5663; Fri, 12 Jun 87 14:27:53 EDT
Date: 1987 Jun 12 13:43 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: (Frank da Cruz) SY.FDC@CU20B.COLUMBIA.EDU,
IBM-Kermit@CU20B.COLUMBIA.EDU
Subject: Re: Another operating system for Portable Kermit
In-reply-to: SY.FDC@CU20B.COLUMBIA.EDU message of Fri 12 Jun 87 12:56:35-EDT
Message-id: <PEPMNT.870612.134356.A0@CFAAMP.BITNET>
>I understand that recent versions of VM/CMS Kermit do not run under
>VM/370 (the old, free version of VM), but that the original version 1.0
>did.
Certainly Kermit-370 could have a version that would run under VM/370
(if it still exists -- does anybody still use it???). The implementation
would, of course, have to be done with the cooperation of people who use
the system.
On another topic: I have spoken to Mark Hripko of TRW, and he seems quite
sure that any kind of Kermit for a 370 can be made to run through a 3708
or any of a host of other protocol converters. It should be relatively
simple to add that capability to the generic Kermit-370. Unfortunately,
Kermit itself can't tell the difference between a 3708 and a Series/1,
so I propose the following new command to give the user the option of
specifying the type of front end.
SET TERMINAL ( TTY | SERIES1 | GRAPH )
Kermit would start out as 'TTY' or 'SERIES1' depending on the kind of
terminal. Does anyone have any better ideas for this command?
John
From "Andre PIRARD <A-PIRARD@BLIULG12>" Wed Jun 17 06:39:30 1987
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 17 Jun 87 04:39:26-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 6767; Wed, 17 Jun 87 04:38:21 EDT
Received: by BLIULG12 (Mailer X1.24) id 2072; Wed, 17 Jun 87 10:27:48 ULG
Date: Wed, 17 Jun 1987 10:05:31 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Re: Kermit writer pain
To: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>,
"John F. Chandler" <PEPMNT@CFAAMP.BITNET>,
IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Your message of Fri 12 Jun 87 08:50:35-EDT
Frank wrote me:
>...
>However, when the remote Kermit is a server that is set up to use the default
>1 character block check, there is a mechanism to let the receiver specify a
>higher order block check. If at the local Kermit you type SET BLOCK 3 and
>then GET FOO.BAR, the I packet performs what amounts to a SET BLOCK 3 at
>the server end, so that when it prepares to send FOO.BAR, it specifies a
>type 3 block check in its own S-packet.
>...
I had realized that, but well, I've just come to testing block checks
negociation and I'm afraid CMS Kermit 3.1 does not...
Here is a trace resulting from a GET my program issues to CMSKERM.
Note the first two packets are just part of an automatic CMSKERM invokation,
to make sure I talk to Kermit. I left them in for completeness sake.
Finally, it does not bother me too much, I'm going to put SET BL 3 in the file
I TAKE, of course. But I think I ought to point it out, because that's using
check 1 when the user thinks he's using 3.
R:# N3
S:9 EInvalid server command;
R:- I~ @-#&3 ('
S:- Y~% @-#&3 (<
R:, RTEST.TEST-
S:- S~% @-#&1~(S
R:- Y~ @-#&3 (7
S:,!FTEST.TEST"
R:#!Y?
S:6"A!%00001."I1"!A/#AMJ)
R:#"Y@
S:U#DBJEWIKTADCHLSV G#M#J=
R:##YA
S:#$ZC
R:#$YB
S:#%B,
R:#%YC
R:$ GF4
S:# Y>
R:# N3
For comparison, the SEND goes:
S:9 EInvalid server command;
R:- S~ @-#&3 (1
S:- Y~% @-#&3 (<
R:.!FTEST.TEST +K
S:%!Y,\I
R:W"DBJEWIKTADCHLSV G#M#J#\U
S:%"Y.5!
R:%#Z,X"
S:%#Y/R9
R:%$B!_#
S:%$Y+&1
R:$ GF4
S:# Y>
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Jun 18 13:22:23 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 18 Jun 87 11:22:18-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 0961; Thu, 18 Jun 87 10:41:03 EDT
Date: 1987 Jun 18 09:58 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: Kermit writer pain
Message-id: <PEPMNT.870618.095821.A0@CFAAMP.BITNET>
The problem of CMS Kermit server forgetting parameters set in an I-packet
can be solved (I think) by the following update to version 3.1 (or any
later one):
---------------------------------------------
SC87169 - Fix Server forgetting I-packet info
---------------------------------------------
/ R 03372000 $ 3372000 200 06/18/87 10:06:07
TM FL2,SRV Possible I-packet exchange? @SC87169
BZ RPSCLR Not in Server mode @SC87169
TM FL3,PXCH Any exchange since last SET? @SC87169
BO RPARBAK Yes, keep latest settings @SC87169
RPSCLR MVC BCTR,BCTC Use what user set @SC87169
---------------------------------------------
I haven't followed all the ramifications of this update, but I think it
is just the thing.
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Thu Jun 18 17:26:48 1987
Flags: 000000000001
Mail-From: SY.FDC created at 18-Jun-87 15:26:41
Date: Thu 18 Jun 87 15:26:41-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Another IBM mainframe system
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12311543204.153.SY.FDC@CU20B.COLUMBIA.EDU>
Somebody called and wanted to know if we had a Kermit for MVS/ROSCOE.
They don't have TSO. Does anybody know if TSO Kermit would work under
ROSCOE? (I don't even know if I'm spelling it right...) Thanks! - Frank
-------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Jun 19 23:28:33 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 19 Jun 87 21:28:29-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 7836; Fri, 19 Jun 87 21:27:32 EDT
Date: 1987 Jun 19 21:20 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: SET SERIES1
Message-id: <PEPMNT.870619.212037.A0@CFAAMP.BITNET>
In light of the probably imminent addition of 3708 support I am adding
a command SET TERMINAL (TTY | SERIES1 | GRAPHICS). The question is:
is there any reason to retain the SET SERIES1 (ON | OFF) command, which
is logically replaced by the new command? Admittedly, compatibility is
usually nice to preserve, but how important is that consideration in
this situation? (The command is used, as far as I can tell, only by
Kermit developers for testing S/1 code).
John
From "Vace Kundakci <VVVCU@CUVMA>" Tue Jun 23 15:48:09 1987
Flags: 000000000001
Return-Path: <VVVCU%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 23 Jun 87 13:47:56-EDT
Received: by CUVMA (Mailer X1.24) id 6577; Tue, 23 Jun 87 13:47:39 EDT
Date: Tue, 23 Jun 87 13:47 EDT
From: Vace Kundakci <VVVCU@CUVMA>
To: PEPMNT@CFAAMP.BITNET (John F. Chandler)
CC: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: SET SERIES1; (John F. Chandler) PEPMNT@CFAAMP.BITNET
In-Reply-To: Your memo of 1987 Jun 19 21:20 EDT
Considering the S1/TTY test is done automatically when Kermit is
invoked, this command is pretty useless anyway. I vote for not
retaining set Series1 on/off command.
/Vace
------
From "Andre PIRARD <A-PIRARD@BLIULG12>" Tue Jun 23 18:45:29 1987
Flags: 000000000001
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 23 Jun 87 16:45:11-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 7884; Tue, 23 Jun 87 16:44:34 EDT
Received: by BLIULG12 (Mailer X1.24) id 0750; Mon, 22 Jun 87 11:02:55 ULG
Date: Mon, 22 Jun 1987 10:46:40 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: SET SERIES1
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
John,
I agree with you the SET TERMINAL ... won't probably hurt anyone.
The strongest compatibility issue is when commands are coded in private
TAKE files or worse, as part of distributed programs that issue CMS
(hopefully 3270) commands from within a micro. But there is apparently no
reason for the micro to interfere the host own business.
But while on the subject, it might be easy (John, decide) to implement what
I feel a useful (others, vote) feature used to supplement from a TAKE file
the program behaviour based on the terminal type. That is a command like:
IF keyword THEN other-command
that could be used like:
IF terminal-type THEN SET SEND PACKET-SIZE as-appropriate (max 1900 for S/1)
IF SERIES1 THEN SET RETRIES according-to-the-7171-problem-you-know
etc... What do you all think of the idea?
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Mon Jun 29 19:13:56 1987
Flags: 000000000001
Mail-From: SY.FDC created at 29-Jun-87 17:13:48
Date: Mon 29 Jun 87 17:13:48-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [ENKJ@CORNELLC: 3708 support]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12314446288.26.SY.FDC@CU20B.COLUMBIA.EDU>
...
---------------
Return-Path: <ENKJ%CORNELLC.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 29 Jun 87 13:23:42-EDT
Received: from CORNELLC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 6991; Mon, 29 Jun 87 13:23:25 EDT
Received: by CORNELLC (Mailer X1.23b) id 3535; Mon, 29 Jun 87 13:20:33 EDT
Date: 29 June 87 13:20 EDT
From: ENKJ@CORNELLC
Subject: 3708 support
To: FDC@CU20B.COLUMBIA.EDU
We have successfully implemented KERMIT on VM system with VCNA and the
IBM 3708 protocol converter using ENVELOPING mode. If you are interested
on the procedure for making this configuration work I will be glad to send
you the process we went through. Just send me your mailing address and I
will be glad to send you the steps. I would like to thank you for all of
your help we sincerely appreciate KERMIT.
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Thu Jul 2 13:23:36 1987
Flags: 000000000001
Mail-From: SY.FDC created at 2-Jul-87 11:23:32
Date: Thu 2 Jul 87 11:23:31-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [JOWY@CORNELLC: Using KERMIT with an IBM 3708 and VCNA]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12315168954.28.SY.FDC@CU20B.COLUMBIA.EDU>
How to adapt the 3708 to Kermit...
---------------
Return-Path: <JOWY%CORNELLC.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 2 Jul 87 11:18:58-EDT
Received: from CORNELLC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 6836; Thu, 02 Jul 87 10:38:44 EDT
Received: by CORNELLC (Mailer X1.23b) id 5238; Thu, 02 Jul 87 10:31:55 EDT
Date: 02 July 87 10:31 EDT
From: JOWY@CORNELLC
Subject: Using KERMIT with an IBM 3708 and VCNA
To: FDC@CU20B.COLUMBIA.EDU
Several months I wrote you a couple of different letters trying to
find out about restrictions with using KERMIT on an IBM system with a 3708 and
the VCNA program product. Although no one was able to help with my particular
situation, I thought you might be interested in knowing that we finally got
KERMIT working on our system. (without any change in the KERMIT program)
*
Using protocol enveloping mode on the 3708, you must go through 7 separate
steps to get things working. Briefly, they are as follows: 1) Apply IBM APAR
DY30352 to bypass VCNA translation tables. 2) Apply IBM APAR II01192 to
increase the length of a 'line' for a TWX-type terminal to 80 bytes instead of
72 bytes. 3) Set the packet length on both sides of KERMIT to 80 bytes.
4) Change DTIPDODR source code for VCNA to skip the addition of a 'CRLF'
on the front of any line beginning with 02 (CNTRL B). 5) Require that both
sides of the link use 02 (CNTRL B) as the start-of-packet character. This is
because the 3708 interprets the normal start-of-packet character (CNTRL A) as
an attention signal. 6) Use the alternate translate table provided on the
3708, which allows for more accurate transmission of some control characters.
*
I don't know if anyone else will ever need to use KERMIT on this type of
system, but if they do, this info should help. Also, if anyone has any
questions on this, they are welcome to contact me: Linda Poppleton,
JOWY@CORNELLC. My phone number is 607-255-7925.
-------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Jul 6 15:27:53 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 6 Jul 87 13:27:51-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 3636; Mon, 06 Jul 87 13:27:52 EDT
Date: 1987 Jul 6 12:27 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Comments: To: JOWY@CORNELLC
To: (Frank da Cruz) SY.FDC@CU20B.COLUMBIA.EDU
Subject: Re: [JOWY@CORNELLC: |Using KERMIT with an IBM 3708 and VCNA]
In-reply-to: SY.FDC@CU20B.COLUMBIA.EDU message of Thu 2 Jul 87 11:23:31-EDT
Message-id: <PEPMNT.870706.122700.A0@CFAAMP.BITNET>
> I thought you might be interested in knowing that we finally got
> KERMIT working on our system. (without any change in the KERMIT program)
The message doesn't say which version of Kermit -- was it Kermit-CMS 3.1
or some other?
> 1) Apply IBM APAR DY30352 to bypass VCNA translation tables.
I take it this fix doesn't hurt other applications.
> 2) Apply IBM APAR II01192 to increase the length of a 'line' for a
> TWX-type terminal to 80 bytes instead of 72 bytes.
This sounds like a good idea anyway. Still, 96 bytes would be even
better.
> 4) Change DTIPDODR source code for VCNA to skip the addition of a 'CRLF'
> on the front of any line beginning with 02 (CNTRL B).
Is this really necessary? Is it because the Kermit at the other end
thinks the CRLF marks the end of a bad packet? I guess this means that
padding is out of the question through the 3708.
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Tue Jul 21 11:52:32 1987
Flags: 000000000001
Mail-From: SY.FDC created at 21-Jul-87 09:52:26
Date: Tue 21 Jul 87 09:52:25-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: VM/SP 5.0 Kermit problem
To: pepmnt@CFAAMP
cc: vvvcu@CUVMA.COLUMBIA.EDU
Message-ID: <12320133106.176.SY.FDC@CU20B.COLUMBIA.EDU>
Got a letter from somebody saying that VM/SP 5.0 causes problems for 2.01
of CMS Kermit; don't know if this applies to the current long-packet
version. To quote:
The basic problem was in a hard-coded macro expansion for the RDTERM macro.
One of the parameters in that expansion utilizes an undocumented feature of
CMS, that is the ability to read from the console and bypass all translate
tables. Release 4 and prior assumed that the input buffer was 130 bytes
long. Release 5 of CMS assumes that the input buffer is 255 bytes long, and
pads data to the right with blanks.
The change is the increase the size of RECPKT to 255:
RECPKT DS CL255
Again, this may or may not affect 3.1, just passing it along... - Frank
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Jul 31 23:38:43 1987
Flags: 000000000001
Mail-From: SY.FDC created at 31-Jul-87 21:38:39
Date: Fri 31 Jul 87 21:38:39-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [Todd Booth <todd@CS.UCLA.EDU>: CMS Kermit 3.1 7171?]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12322883112.174.SY.FDC@CU20B.COLUMBIA.EDU>
Anybody know this?
---------------
Return-Path: <todd@CS.UCLA.EDU>
Received: from ATHENA.CS.UCLA.EDU ([128.97.2.15]) by CU20B.COLUMBIA.EDU with TCP; Fri 31 Jul 87 19:39:49-EDT
Date: Fri, 31 Jul 87 16:34:10 PDT
From: Todd Booth <todd@CS.UCLA.EDU>
To: Submission for Kermit <kermit@cu20b.columbia.edu>
Subject: CMS Kermit 3.1 7171?
Message-ID: <870731.233410z.05449.todd@ATHENA.CS.UCLA.EDU>
Is there code in *any* Kermit to reset the 7171, once it is hung due to
parity or line errors? We've gened the 7171s to ignore parity errors on
input which solves the parity erorrs, but we'd like to check parity for
data entry users. This also doesn't address the framing errors, which
will also lock the port until a reset is received (from the PC side - to
bad).
--todd booth / ucla data comm
-------
From "Scott Galloway <sgallowa%xls-plexus01>@amc-hq" Sun Aug 2 15:37:28 1987
Flags: 000000000001
Return-Path: <sgallowa@xls-plexus01>
Received: from amc-hq.arpa by CU20B.COLUMBIA.EDU with TCP; Thu 30 Jul 87 13:27:00-EDT
Received: from amc1 by AMC-HQ.ARPA id ac28074; 30 Jul 87 13:18 EDT
Received: from xls-plexus01 by AMC1.AMC1.AMC id ab16655; 30 Jul 87 13:05 EDT
Date: 30 Jul 87 12:18:41-EDT (Thu)
From: Scott Galloway <sgallowa%xls-plexus01>@amc-hq
To: IBM-Kermit at Cu20b
cc: sgallowa at Xls-Plexus01, pbremer at Xls-Plexus01
Subject: IBM Kermit maillist
I am interested in receiving information from your IBM-Kermit info exchange.
We currently use Kermit-TSO from the University of Chicago, but are looking
at any and all other avenues involving Kermit on our IBM 43xx mainframes.
Please, if possible, add my e-mail address to your list.
Thanks!
Scott D. Galloway arpanet: sgallowa@amc-hq
USAMC - LSSA comm ph: (717) 267-9191
Op Sys Br, AMXLS-LCS
Letterkenny Army Depot
Chambersburg, PA. 17201
From "Scott Galloway <sgallowa%xls-plexus01>@amc-hq" Sun Aug 2 15:37:28 1987
Flags: 000000000001
Received: from amc-hq.arpa by CU20B.COLUMBIA.EDU with TCP; Thu 30 Jul 87 11:17:21-EDT
Received: from amc1 by AMC-HQ.ARPA id aa26338; 30 Jul 87 11:10 EDT
Received: from xls-plexus01 by AMC1.AMC1.AMC id a010729; 30 Jul 87 10:57 EDT
Date: 30 Jul 87 10:51:47-EDT (Thu)
From: Scott Galloway <sgallowa%xls-plexus01>@amc-hq
To: Roger Fajman <IBM-Kermit@cu20b>
cc: sgallowa at Xls-Plexus01, pbremer at Xls-Plexus01
Subject: TSO Kermit
Mr. Roger Fajman,
In a message addressed to IBM-Kermit@cu20b, dated 05 Dec 86, you announce
the availability of NIH TSO Kermit Version 1.0. Here at LSSA, we currently
use the University of Chicago version with extended packets (1000 bytes).
We have an immediate need for binary file transfer to our IBM 43xx
mainframes, and also the ability for large extended packets. In the message
you indicate the ability of binary file transfer but no mention of the
extended packets. Is this the current status of NIH Kermit capabilities?
If available, can you still acquire NIH TSO Kermit for no charge by sending
you a tape to this address? ...does this include entire source code?
Joseph D. Naughton
Chief, Computer Center
National Institutes of Health
Building 12, Room 2244
Bethesda, MD 20892
Thanks in advance!!
Scott D. Galloway arpanet: sgallowa@amc-hq
U.S. Army Materiel Command comm ph: (717) 267-9191
Logistic Systems Support Activity
Letterkenny Army Depot
Chambersburg, PA. 17201
-------
From "Andre PIRARD <A-PIRARD@BLIULG12>" Wed Aug 5 06:29:08 1987
Flags: 000000000000
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 5 Aug 87 04:29:03-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 2470; Wed, 05 Aug 87 04:28:45 EDT
Received: by BLIULG12 (Mailer X1.24) id 2547; Tue, 04 Aug 87 17:36:37 ULG
Date: Tue, 04 Aug 87 16:45:03 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Re: CMS Kermit 3.1 7171?
To: Todd Booth <todd@CS.UCLA.EDU>,
IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Your message of Fri, 31 Jul 87 16:34:10 PDT
>Is there code in *any* Kermit to reset the 7171, once it is hung due to
>parity or line errors? ...
>--todd booth / ucla data comm
Too funny. I am just converting to the Kermit protocol a suite of programs
that used... something called the ucla protocol. I have modified a ucla
CMS program to run through the 7171. And the micro side takes care of what
you say.
Now I've generalized the procedure in the Kermit environment. There is a
user definable "message" that contains a line recovery string (the native
module contains no messages, they come from a file read the first time it
is used, then the user asks the program to save itself to a new executable
file). The string is better in the messages file than in a menu parameter.
The recovery string is sent on the comm line everytime an ill formed packet
is received or a timeout occurs. *Every* Kermit should have that feature.
For the 7171, the recovery string contains:
^R : 7171 transmission error reset
^X : 7171 typeahead purge
^Q : break XON/XOFF interlock.
^B : defined locally to clear the screen on all terminal types.
The latter deserves some explanation. Spurious non-transparent host screen
output may occasionally show up, despite every host Kermit effort to avoid it.
The host Kermit must recover the situation, but cannot do so should a
screenful be written. Hence the micro clearing it.
So yes and no. There *is* one, but it's still in development phase and I
further don't know yet what status it will stamped by our management: PD,
small fee or nope. They're afraid of after-release troubles.
But I sure recommend the feature. It has provided reliable service for years
over disgustingly noisy lines.
From "Scott Galloway <sgallowa%xls-plexus01>@amc-hq" Wed Aug 5 12:53:36 1987
Flags: 000000000000
Return-Path: <sgallowa@xls-plexus01>
Received: from amc-hq.arpa by CU20B.COLUMBIA.EDU with TCP; Wed 5 Aug 87 10:53:19-EDT
Received: from amc1 by AMC-HQ.ARPA id aa17402; 5 Aug 87 10:19 EDT
Received: from xls-plexus01 by AMC1.AMC1.AMC id ab11506; 5 Aug 87 9:59 EDT
Date: 5 Aug 87 8:07:25-EDT (Wed)
From: Scott Galloway <sgallowa%xls-plexus01>@amc-hq
To: Roger Fajman <IBM-Kermit@cu20b>
cc: pbremer at Xls-Plexus01, sgallowa at Xls-Plexus01
Subject: [Scott Galloway: TSO Kermit]
I am resending this request for assistance in fear that the one I sent out
last week "disappeared" in transit... please ignore if a response has been
sent to me in last 24 hours.
Thank-you.
Scott Galloway
----- Forwarded message # 1:
Date: 30 Jul 87 10:51:47-EDT (Thu)
From: Scott Galloway <sgallowa@xls-plexus01>
To: Roger Fajman <IBM-Kermit@cu20b>
cc: sgallowa at Xls-Plexus01, pbremer at Xls-Plexus01
Subject: TSO Kermit
Mr. Roger Fajman,
In a message addressed to IBM-Kermit@cu20b, dated 05 Dec 86, you announce
the availability of NIH TSO Kermit Version 1.0. Here at LSSA, we currently
use the University of Chicago version with extended packets (1000 bytes).
We have an immediate need for binary file transfer to our IBM 43xx
mainframes, and also the ability for large extended packets. In the message
you indicate the ability of binary file transfer but no mention of the
extended packets. Is this the current status of NIH Kermit capabilities?
If available, can you still acquire NIH TSO Kermit for no charge by sending
you a tape to this address? ...does this include entire source code?
Joseph D. Naughton
Chief, Computer Center
National Institutes of Health
Building 12, Room 2244
Bethesda, MD 20892
Thanks in advance!!
Scott D. Galloway arpanet: sgallowa@amc-hq
U.S. Army Materiel Command comm ph: (717) 267-9191
Logistic Systems Support Activity
Letterkenny Army Depot
Chambersburg, PA. 17201
----- End of forwarded messages
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Wed Aug 5 15:44:05 1987
Flags: 000000000000
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 5 Aug 87 13:43:59-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 3862; Wed, 05 Aug 87 13:43:41 EDT
Date: 1987 Aug 5 13:30 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Comments: To: (Andre PIRARD) A-PIRARD@BLIULG12
Comments: To: (Todd Booth) todd@CS.UCLA.EDU
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: CMS Kermit 3.1 7171?
In-reply-to: A-PIRARD@BLIULG12 message of Tue, 04 Aug 87 16:45:03 ULG
Message-id: <PEPMNT.870805.133051.A0@CFAAMP.BITNET>
Your reset mechanism sounds useful, but it appears to me to require the
active cooperation (if not sole responsibility) of the micro. Hence, we
need to propose the idea to the Kermit community as a whole. Even if
Liege wants to hold onto your particular implementation, we might be
able to generalize the notion for auto-reset.
John
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Aug 10 18:08:49 1987
Flags: 000000000000
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 10 Aug 87 16:08:42-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.24) with
BSMTP id 0201; Mon, 10 Aug 87 16:08:20 EDT
Date: 1987 Aug 10 13:05 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Comments: To: (Andre PIRARD) A-PIRARD@BLIULG12
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: CMS 3.2 x-binary
In-reply-to: A-PIRARD@BLIULG12 message of Mon, 10 Aug 1987 10:06:28 ULG
Message-id: <PEPMNT.870810.130550.A0@CFAAMP.BITNET>
> I noticed that v-binary downloads F files
> just as binary does. That makes the user bound to specify not only the file
> RECFM F, but also the LRECL when he uploads F files.
> It would be easier if he had concern of neither RECFM nor LRECL.
> Do you see any any other straightforward way to transport CMS files, DISK DUMP
> excepted?
As a matter of fact, there is a way for transporting files for eventual
reconstruction on a system like the original one. The method is called
archiving. Kermit-CMS is halfway there -- it generates attribute info
that could be saved away by the micro Kermit and passed along with the
file to the target host. What is missing is a well-thought-out scheme
for deciding precedence among the possible sources of attribute info.
We must remember that "most" micro Kermits do not support file archiving,
so the mainframe must continue to assume that the usual source of
attributes will be the user, via SET commands. I haven't thought it all
out myself, but perhaps Kermit-370 could merge any attributes received
via A-packets and then restore the defaults.
John
From "Andre PIRARD <A-PIRARD@BLIULG12>" Wed Aug 12 06:32:38 1987
Flags: 000000000000
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 12 Aug 87 04:32:32-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.24) with BSMTP
id 5807; Wed, 12 Aug 87 04:32:16 EDT
Received: by BLIULG12 (Mailer X1.24) id 7788; Wed, 12 Aug 87 10:30:09 ULG
Date: Wed, 12 Aug 87 09:57:00 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Re: CMS 3.2 x-binary
To: "John F. Chandler" <PEPMNT@CFAAMP.BITNET>
cc: IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Your message of 1987 Aug 10 13:05 EDT
>As a matter of fact, there is a way for transporting files for eventual
>reconstruction on a system like the original one. The method is called
>archiving. ...
Yes, but as you say, everyone has to deal with attributes packets, keep them
somewhere and send them back. It is a long way until they all do so.
If we agree an archive file is of no use on the archiver other than
resending as is for reconstructing, why not think of the archivee
including the attributes in the data itself, just where the archiver would
think of putting them? As with CMS, the data format itself may have to be
adapted for reconstruction anyway (also think of the Mac forks...).
If the CMS V-BINARY or like were to segment fixed length files, the only
missing information would be RECFM, LRECL and timestamp to do so.
From "Scott Galloway <sgallowa%xls-plexus01>@amc-hq" Wed Aug 12 17:05:54 1987
Flags: 000000000000
Return-Path: <sgallowa@xls-plexus01>
Received: from amc-hq.arpa by CU20B.COLUMBIA.EDU with TCP; Wed 12 Aug 87 15:05:30-EDT
Received: from amc1 by AMC-HQ.ARPA id ae00155; 12 Aug 87 9:53 EDT
Received: from xls-plexus01 by AMC1.AMC1.AMC id a017175; 12 Aug 87 8:26 EDT
Date: 12 Aug 87 8:24:04-EDT (Wed)
From: Scott Galloway <sgallowa%xls-plexus01>@amc-hq
To: JOHN F. CHANDLER <IBM-Kermit@cu20b>
cc: sgallowa at Xls-Plexus01, pbremer at Xls-Plexus01
Subject: TSO KERMIT - Help!
PLEASE FORWARD THIS MESSAGE TO JOHN F. CHANDLER:
I have been trying for the past 8 days to send a message to pepmnt@cfaamp.
This continually brings back failed mail. I have tried the following
addresses:
pepmnt.cfaamp@wiscvm
pepmnt@cfaamp
pepmnt.cfaamp.bitnet@wiscvm
I do not claim expertise in the electronic mail system we use, especially
since our gateway is located 75 miles south in AMC-HQ in Washington, D.C.
I have reported this problem to our local mail administrator, but this week
she is on vacation. This is why I chose to use the IBM-Kermit maillist to
try to forward this message.
Any help from anyone on this matter will be greatly appreciated.
Scott D. Galloway
HERE IS THE MESSAGE TO JOHN F. CHANDLER <pepmnt@cfaamp> :
John,
I only received partial source code of your latest TSO Kermit, and I
received some parts two or three times. Please resend all source again.
Either try again by electronic mail or if that doesn't get it here... we
might try postal mail.
Thanks!
Scott D. Galloway arpa: sgallowa@amc-hq
USAMC-LSSA (Attn: AMXLS-LCS)
Letterkenny Army Depot
Chambersburg, PA. 17201
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Sat Aug 22 13:40:38 1987
Flags: 000000000001
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Sat 22 Aug 87 11:40:32-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 1614; Sat, 22 Aug 87 11:41:17 EDT
Date: 1987 Aug 21 17:41 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: SET TERMINAL command
Message-id: <PEPMNT.870821.174141.A0@CFAAMP.BITNET>
I noticed in the latest Kermit digest that SET TERMINAL has been
implemented in a C Kermit. When I proposed that Kermit-370 use a
command,
SET TERMINAL TTY|SERIES1|GRAPHICS,
I figured there would be no conflict of terminology. Actually, as I
think about it, a better term would be CONTROLLER or FRONT-END, since
the kind of terminal/micro doesn't really enter into this distinction.
Meanwhile, it turns out that the new code (labelled "GRAPHICS") turns
out not to work for 3708's, but only for similar SNA devices from other
vendors. Still, IBM has started thinking about adopting changes to the
3708 to make the convention work. Moreover, there is the recent success
at Cornell in getting an unmodified Kermit-CMS to work through a 3708
with a bit of system tinkering. In light of all this, are there any
opinions on the best terminology: TERMINAL vs. CONTROLLER vs. FRONT-END
vs. other suggestions? As for the option names (TTY, SERIES1, GRAPHICS),
now is also the time to settle on the best choices there, too. The only
constraint I would put on those is that the first letter of each must be
a unique abbreviation. Any suggestions before this gets frozen in?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Thu Sep 3 13:53:50 1987
Flags: 000000000000
Mail-From: SY.FDC created at 3-Sep-87 11:53:40
Date: Thu 3 Sep 87 11:53:40-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [POSTMAST@CUVMA: Re:]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12331689514.173.SY.FDC@CU20B.COLUMBIA.EDU>
I don't know if this message ever made it through to the IBM-Kermit list,
if so, apologies...
---------------
Date: Mon, 25 May 1987 08:48:09 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: CMS Kermit and the 7171
To: IBM-KERMIT@CU20B.COLUMBIA.EDU,
Protocol Converter list <IBM7171@DEARN>
cc: Kai U Leppamaki <LK-KLE@FINHUT>
I am currently converting a file transfer programs suite to Kermit protocol.
We will use it primarily for communication between micros and mainframe thru
7171's and we want strong and easy performance in that particular environment.
I've just undertaken tests under noisy line conditions and I have analysed
the behaviour of the (our) 7171. Amazing!
Test conditions: file upload at 300 bauds with an acoustic coupler to provoke
transmission errors, so I can tap on the handset.
Observation: during 7171 transparent write/read, read phase (the micro is
sending a packet), I tap once. The transmission error causes the 7171 to
terminate read phase and gives the incomplete packet to the host Kermit.
The host Kermit nacks the packet and the 7171 reenters a second transparent
write/read. The micro is still sending the rest of the interrupted packet which
the 7171 takes as a new one. Moreover, the 7171 entering read phase during
already ongoing transmission often (but not always) causes it to immediately
sense another transmission error which repeats the process. The net result
is that a micro originating packet can be sliced into as many packets as the
host response time allows. The tap on the hanset is often followed by
a two-way continuous transmission (mostly favoured at 300 bauds).
For that reason, I used (and continue) to have the micro purge its input buffer
just before it sends an end-of-packet character. But...
1) We could admittedly do without that 7171 oddity (the manual GA37-0021-0 says
'...all the characters received during the read [phase] (including erroneous
characters and the terminating character) will be presented to the host').
2) The CMS Kermit retry count defaults to 5 and limits to 31 (*why?*). That
can be too easily used up under the above conditions. No wonder some people
reported difficulties in file transfers with the 7171.
Do others observe this? Anybody has an idea for a cure?
I'd be *most* interested in comments and am willing to summerize to the net.
------ End of forwarded mail by POSTMAST@CUVMA.
------ End of forwarded mail by POSTMAST@CUVMA.
-------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Sep 11 03:18:56 1987
Flags: 000000000000
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 11 Sep 87 01:18:47-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 1468; Fri, 11 Sep 87 01:19:32 EDT
Date: 1987 Sep 10 19:51 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: EBCDIC-to-ASCII translation
Message-id: <PEPMNT.870910.195118.A0@CFAAMP.BITNET>
I find in the Yale S1TRANS package some EBCDIC codes that are given
ASCII equivalents where Kermit-CMS would put nulls. Can anybody comment
on the utility of these equivalents or on the advisability of adopting
them? Obviously, these represent redundant mappings into ASCII.
EBCDIC -> ASCII
04 (PF) 14 (DC4)
15 (NL) 0A (LF)
34 (PN) 12 (DC2)
35 (RS) 13 (DC3)
71 ???? 7E "~"
I can see how X'15' (New Line) might be better translated as a Line Feed
than as a Null, and I have seen at least one file originally from an
ASCII system where the "~" characters had been translated into X'71',
but the other mappings don't seem to make much sense. Comments?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Sep 16 19:32:18 1987
Flags: 000000000000
Mail-From: SY.FDC created at 16-Sep-87 17:32:09
Date: Wed 16 Sep 87 17:32:09-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: ["DAVID DRAKE" <drake@paxrv-nes.arpa>: STILL WORKING ON THE PROB]
To: ibm-kermit@CU20B.COLUMBIA.EDU
Message-ID: <12335159006.151.SY.FDC@CU20B.COLUMBIA.EDU>
Has anyone tried running Kermit from a PC to VM/CMS over a Telnet connection?
Any ideas? - Frank
---------------
Return-Path: <drake@paxrv-nes.arpa>
Received: from paxrv-nes.arpa by CU20B.COLUMBIA.EDU with TCP; Wed 16 Sep 87 16:21:39-EDT
Date: 16 Sep 87 15:46:00 EDT
From: "DAVID DRAKE" <drake@paxrv-nes.arpa>
Subject: STILL WORKING ON THE PROB
To: "sy.fdc" <sy.fdc@cu20b.columbia.edu>
cc: drake
Reply-To: "DAVID DRAKE" <drake@paxrv-nes.arpa>
PREVIOUS MESSAGE ATTACHED FOR REFERENCE
> 15 Sept 1987
>
> I am trying to transfer files between MS-DOS Kermit V 2.29B
> (2/19/87) and IBM VM-CMS Kermit V3.1 (8/27/87) without
> sucess. Both versions of KERMIT were installed as received
> from Columbia University. I am using a TELNET connection
> with TCP/IP. The SEND, RECEIVE, and GET commands are
> received by VM and an acknowledgement is returned, but
> never received by the PC. When in SERVER mode, the FINISH
> command is acknowledged successfully back to the PC. Why
> would this command work when all others fail?
>
FRANK,
Thanx for your quick response, however, to no avail as yet. I have a
few more tid bits for your perusal.
Parity does not seem to be the problem .... when I set it to none or odd
I get my problem. When I set it to even ... the commands thru the
TELNET get garble as it seems since status shows an invalid command.
I've tried setting the packet size to 35 and then to 20 with no
changes. This I thought could be the problem but in many combinations
between PC and VM sizes, I show no difference.
With the debug, I see a HEX 11 before the SOH on the FINISH acknowledge-
ment from VM. The other acknowledgements do not have the HEX 11. I have
FLOW=XON/XOFF and HANDSHAKE=NONE, and have tried the combinations of
FLOW=NONE and HANDSHAKE=XON and XOFF.
Thanx in advance,
Dave Drake
P.S. Does the author of the VM package mind questions ???
------
-------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Sep 17 22:08:38 1987
Flags: 000000000000
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 17 Sep 87 20:08:08-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 3811; Thu, 17 Sep 87 12:02:11 EDT
Date: 1987 Sep 16 19:06 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Long packets
Message-id: <PEPMNT.870916.190659.A0@CFAAMP.BITNET>
Has anyone tried sending or receiving packets longer than 1000 bytes
using Kermit-CMS? If so, how long and on what hardware? The current
version has buffers big enough for 1920 (apparently, the limit imposed
by VTAM). Are there any tighter limits? With the present state of the
art, what are the limits imposed by IBM 7171, Series/1, 4994, etc.?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Sep 18 11:34:11 1987
Flags: 000000000000
Mail-From: SY.FDC created at 18-Sep-87 09:34:06
Date: Fri 18 Sep 87 09:34:06-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: ["Michael J. MacDonald" <MIKEMAC@UNB>: Yet another version of ts2 kermit]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12335596266.160.SY.FDC@CU20B.COLUMBIA.EDU>
In case you're interested... Asked him to first check with Fritz Buetikofer,
the original author. This would be the first TSO Kermit that works with both
linemode and Series/1-style connections. - Frank
---------------
Return-Path: <MIKEMAC%UNB.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 18 Sep 87 08:45:54-EDT
Received: from UNB by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id 8340;
Fri, 18 Sep 87 08:48:01 EDT
Received: by UNBMVS1 (Mailer 1.31) id 3665; 18 Sep 87 09:47:13 ADT
Date: 18 Sep 87 09:47:24 ADT
To: SY.FDC@CU20B.COLUMBIA.EDU
Subject: Yet another version of ts2 kermit
From: "Michael J. MacDonald" <MIKEMAC@UNB>
Message-ID: <ID7698.D870918.T094724.MIKEMAC@UNB>
I have modified ts2 kermit so that it works through the ibm3705 and
the ibm7171 in transparent mode. If your interested I will package it
into a reasonable form and send it to you.
Michael MacDonald
Software Specialist, School of Computer Science
University of New Brunswick
Po. Box 4400
Fredericton, New Brunswick
CANADA E3B 5A3
(506) 453-4566
Netnorth/BITNET: MIKEMAC @ UNBMVS1
-------
From "Andre PIRARD <A-PIRARD@BLIULG12>" Mon Sep 21 13:18:21 1987
Flags: 000000000000
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 21 Sep 87 11:18:11-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 7716; Mon, 21 Sep 87 11:16:03 EDT
Received: by BLIULG12 (Mailer X1.24) id 4772; Mon, 21 Sep 87 17:14:21 ULG
Date: Mon, 21 Sep 87 17:10:43 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Kermit and the IBM 7171
To: Columbia University Center for Computing Activities
<INFO-KERMIT@CU20B.COLUMBIA.EDU>,
IBM-KERMIT@CU20B.COLUMBIA.EDU
I once wrote a communication/ftp program that we have been using on
the S/1 and 7171 for several years without much problem. For
several reasons too long to explain here, we decided to convert
it to the Kermit protocol. It now works beautifully with another
micro Kermit or in IBM 370 TTY mode, but the 7171 is such that it
causes nasty problems. I'll explain them mainly on the 370 list,
but I think some facts I learned from experience with my former
program can be of general interest to 7171 users.
1) The S/1 style protocol converters run in two modes: terminal
emulation and transparent mode. File transfer uses transparent
mode. In this mode, the host (370) outputs data (write phase),
then switches to read phase to get the reply. The 7171 always
uses interrupt driven RS232 I/O to a 340 bytes input buffer (the
S/1 uses a smaller buffer, but uses DMA in transparent mode).
This means that when using packet sizes larger than 340 bytes,
XON/XOFF pacing protocol MUST be used. It implies that the micro
Kermit use it, but also that it be not disabled on the 7171 side.
Failing that, I/O that once looked OK on a lightly loaded 7171
may suddenly go wrong when the load increases. And I have seen
what go wrong means: a buffer overflow may cause complete
deadlock of the communication port and need a DTR drop to recover it.
2) Considering that it is best to always use (or at least allow)
XON/XOFF in file transfer raises another problem. The 7171 will
receive XON/XOFF as pacing during write phase, but not during read
phase. Moreover, XOFF is defaulted as a end-of-input character.
It may happen that timing problems cause an XOFF sent by the
external device during write phase to effectively arrive during
read phase and end it with null input. For this reason, allowing
XON/XOFF as pacing must be paired with disabling XOFF as an end-
of-packet character. That is the system programmer setting bit
X'1000' at DC00:0008 in the 7171 NVRAM.
3) The 7171 may end an inbound packet prematurely on certain
types of transmission errors I could not determine. This process
looks like auto-catalytic. Once started, chances are high the
host is assaulted by an awful lot of short packets it NACKs. It
seems the reason is turning the line to read phase in the middle
of a character the external device trustfully sends. Because a
single error is multiplied, the 370 Kermit retry count should be
set as high as possible. On the other side, the external device
(micro) must expect a flood of NACKs in response to a single
packet. It is therefore essential to purge the input buffer as
late as possible, I do it just before sending the end-of-packet
character.
Question: does any Kermit reply before the eop? If yes, it would
be better to purge before sending the checksum.
4) There is no provision in the 7171 to recover from a lost XON,
nor in the 370 to timeout. To avoid deadlock, the micro must
implement its own recovery. At least XON should be sent to the
7171 after a timeout. I also send "clear screen" to allow the
host to recover from loosing fullscreen mode as well as
"transmission error reset" and "purge input buffer". The last two
may be unnecessary, but are harmless anyway.
5) The maximum packet size is 1920, a screensize buffer. Better
use 1900 to allow for some extraneous characters. Around 950 is
a good choice as little performance gain is (usually) observed
beyond and because it eases faster resynchronization when two
packets stick together.
I think these facts (and maybe others, welcome) will help to run
file transfer with the 7171 much more reliably.
Now that's not all. There are problems with VTAM and the fact
that being a half duplex device in file transfer mode, the 7171
would normally call for handshaking. But I'll continue these,
resorting to 370 Kermit internals, on the appropriate list.
This gives but an faint idea of the mess 370 Kermit people have
to deal with. Believe me how thankful one has to be for their
patience and work against a beast said to be working as designed!
From "Andre PIRARD <A-PIRARD@BLIULG12>" Tue Sep 22 13:36:33 1987
Flags: 000000000000
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 22 Sep 87 11:36:22-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 2196; Tue, 22 Sep 87 11:34:16 EDT
Received: by BLIULG12 (Mailer X1.24) id 1211; Tue, 22 Sep 87 17:33:17 ULG
Date: Tue, 22 Sep 87 17:25:04 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: More on the 7171
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
cc: Fernand Benedet <UZ33100@BLIULG12>
This is the continuation of my previous note about the 7171.
I have been testing my Kermit protocol program with CMS Kermit
3.1 and 3.2 beta test. With both I discovered synchronization
problems. Under timing conditions other than lightning fast host
response time caused by system load or network connection via
VTAM or PASSTHRU, many packets received by the 7171 are beheaded.
I analyzed traces and had a look at the source code. It appears
that the problem can be described as follows.
The 7171 is a half duplex device (I am speaking of file transfer
transparent mode). It cannot receive data before the time
transparent write/read phase switches to read. But the switching
time between last byte sent and first byte accepted is short
enough to suit any partner turnaround time. At least it is
predictable. This means that if a protocol is strictly doing
alternating write/read both sides, the external device (micro)
can send a packet as soon as having received one. This was the
case with my former protocol and the reason for little problems
with it.
It appears that 3.2 beta, as opposed to 3.1, may use separate I/O
requests for write (or prompts?) and read, probably to get around
the VTAM problem. This implies that the time the 7171 is ready to
accept data now depends on such factors as host load and network
path length. And this is the cause for my packets being
truncated. The problem does not show on direct link to a lightly
loaded host or maybe other protocol converters. It can be hidden
by a longer response time of a particular client.
But there is another problem with both 3.1 and 3.2. The Kermit
protocol is such that there are times when a packet is not a
reply to another. In those cases, CMS Kermit has nothing to write
before reading. Specific examples:
1) When a client has received a file or data, ACKs the B packet
and is about to transmit another server request mode.
2) Same when it detects an error and sends and error packet.
3) The first packet sent by the client.
These problems do not show when a server is being driven manually
because human response time exceeds hardware turnaround. But when
the client is automated and transmits requests in a row, the
problem is real.
The CMS Kermit documentation states that HANDSHAKE OFF and FLOW-
CONTROL XON/XOFF should be used with the 7171. In fact, there are
carriage returns and XONs sent after packets and as read prompts.
I tried to use them to solve my synchronization problems. But the
logic got intricate, gave different results with each version and
I did not feel comfortable using undocumented particulars that do
not strictly adhere to the Kermit protocol and are subject to
change without notice. Furthemore, XON is not always usable as
explained below.
So here is my proposition (and the reason for posting list wide).
Because the 7171 is a half duplex device, Kermit should use a
reliable documented handshake character in addition to the end-
of-packet character. This handshake character will be sent when
and only when the 370 Kermit issues a write/read, as the very
last data byte of the write/read request output. This drastically
solves synchronization problems as a whole.
As I explained in my note to Info-Kermit, XON/XOFF is essential
during file transfers of packets longer than some 340 bytes.
This rules out XON as handshake. Which to choose, whether hard
coded or optional and in a parameter are moot issues I leave for
debate. But it should be different from any character used by
terminal mode for screen control, so that an automated client can
issue a terminal mode command to start host Kermit and discard
resulting screen update until it meets the handshake character.
Escape is obviously rejected, maybe just another carriage-return?
I take the occasion to add some topics on losely related problems
concerning robustness.
- Digging out mail, I found a question from John asking when a
read could produce null data length. In addition to the VTAM
buffer overflow and retry, we just discovered from having VTAM
traced by a colleague that VTAM reacts to any 7171 attention by
doing a read-modified. The 7171 generates an attention at the
conclusion of any transparent I/O, be it write or write/read.
Thus, after bare write, VTAM has null input ready for what they
call a receive operation. Vague rumor alledges that a succeeding
send (the converse of receive) cancels pending input. But it
better be checked out because unsollicited input is just what a
protocol needs to run out of synch.
- Given this, wouldn't Kermit be better off confining to
write/read exclusively? This makes sure even null input is
the result of the other side talking. Thus null input would be
treated as corrupted packet and go through normal protocol
recovery, in addition to nontransparent VTAM recovery. The 3.2
new behaviour of nacking a bad packet while in server idle mode
is most welcome and to be generalized throughout. The former
error packet was indeed misleading to an automated client.
Last, many thanks again to all having been involved in CMS Kermit
and John particularly. I wish this note will help.
This note however transmitted via CMS Kermit 3.1.
Andre PIRARD
SEGI - Universite de Liege
15, av. des Tilleuls
B-4000 LIEGE (Belgique)
+32 (41) 520180(449)
Bitnet: A-PIRARD@BLIULG12
Arpanet: A-PIRARD%BLIULG12.BITNET@WISCVM.WISC.EDU
From "Andre PIRARD <A-PIRARD@BLIULG12>" Fri Sep 25 05:54:13 1987
Flags: 000000000000
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 25 Sep 87 03:54:08-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 3239; Fri, 25 Sep 87 03:51:59 EDT
Received: by BLIULG12 (Mailer X1.24) id 0479; Fri, 25 Sep 87 09:51:37 ULG
Date: Fri, 25 Sep 87 09:37:25 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Lost messages
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Due to recent RSCS problems and lost spool, my conversation with IBM-Kermit
has been disrupted, so:
- Has my "More about the 7171" note been received?
- Please resend me any correspondence about it, whether private or list wide.
Please excuse the inconvenience.
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Sep 25 16:32:33 1987
Flags: 000000000000
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 25 Sep 87 14:32:17-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 5953; Fri, 25 Sep 87 14:30:06 EDT
Date: 1987 Sep 25 14:03 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: 7171 turn-around
Message-id: <PEPMNT.870925.140353.A0@CFAAMP.BITNET>
Maybe this is demanding a lot of the micro, but I think XON could be used
as a handshake, even while XON/XOFF is used by the 7171 for flow control.
When the micro is being driven by a human, there is no need for any
handshake, except for the problem with VTAM, which may entail some
resending. As it is now, the mainframe Kermit sends an XON at the end
of every packet (through a 7171, that is) to prompt the micro, but it
could easily withhold that XON when issuing a plain Write instead of a
Write/Read. Then the next (unsynchronized) Read could be prompted with
a CR XON, instead of the plain CR now used. There shouldn't be much of
a problem distinguishing between the XON handshake character (which comes
as the last character during a Write operation) and any XON that reverses
a preceding XOFF (which comes only during a Read operation). Am I
missing something?
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Oct 1 18:56:03 1987
Flags: 000000000000
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 1 Oct 87 16:55:48-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 5073; Thu, 01 Oct 87 14:38:33 EDT
Date: 1987 Sep 30 15:49 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Suggested changes in 7171 handling...
Message-id: <PEPMNT.870930.154916.A0@CFAAMP.BITNET>
> From: Andre PIRARD <A-PIRARD@BLIULG12>
> > I think XON could be
> >used as a handshake, even while XON/XOFF is used by the 7171 for flow
> >control. As it is now, the mainframe Kermit sends an XON at the end
> >of every packet (through a 7171, that is) to prompt the micro, but it
> >could easily withhold that XON when issuing a plain Write instead of a
> >Write/Read. Then the next (unsynchronized) Read could be prompted with
> >a CR XON, instead of the plain CR now used.
> My mod works almost as you said. It replaces the XON at the end
> of the packet by CR which is sent only if the read is not
> separate [i.e., is part of a write/read].
>
> As I said, the micro and 7171 normally do and must use
> XON/XOFF pacing. This means that any XON sent by the 7171 is
> filtered out by the physical layer. The micro Kermit datalink
> layer does *NOT* see it and therefore cannot use it for HANDSHAKE
> purpose. And even if an XON/XOFF deviation were devised, it still
> would not work through intermediate links like data switchers
> that use XON/XOFF too and would hide the XON's anyway. So, another
> character must be used.
It would probably be best to have the handshake be a unique character,
but there is already a CR (presumably) as the end-of-packet. For the
most part, I would expect the micro to ignore the "EOP", if any, so it
would require complicated extra logic to wait for a 2nd EOP. What
other characters suggest themselves???
> Now the question is: will this handshake work with any Kermit
> (without modifications that is)? I have had a look at some
> Kermits we have here. Some do provide for CR (MS, MAC), others
> don't (Apple, CP/M et al) and only know SET IBM ON which uses
> XON. For others, if any, providing choice but no CR, the
> particular character used could be in a 370KERM parameter.
It would be simple enough to add a SET HANDSHAKE command to Kermit-370,
but what should be the default???
> But previous experience shows that the XON formerly sent after
> end-of-packet character is usually short enough an additional
> delay to let the 7171 correctly switch from write to read before
> the micro does output. This is a matter of [empirical] fact however and
> highly dependent on line speed as well as micro and 7171
> turnaround time. I read a note from GILBERT@YALEVMX stating that
> 6ms are needed for a Series/1. Very tight timing indeed.
> So, if timing conditions prove to allow it, the micro may still
> do without handshaking if the protocol is not automated and
> separate reads correspond to human turnaround. The handshaking is
> however the recommended practice.
XON has at least two advantages:
1. It prompts the micro in case XON/XOFF pacing is in effect and the
real XON got lost.
2. It allows the documentation to say, "always set IBM ON when talking
to Kermit-370"
From "Andre PIRARD <A-PIRARD@BLIULG12>" Fri Oct 2 10:13:25 1987
Flags: 000000000000
Return-Path: <A-PIRARD%BLIULG12.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 2 Oct 87 08:13:17-EDT
Received: from BLIULG12.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 7938; Fri, 02 Oct 87 08:11:06 EDT
Received: by BLIULG12 (Mailer X1.24) id 7789; Fri, 02 Oct 87 13:10:22 ULG
Date: Fri, 02 Oct 87 10:46:08 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: 370 Kermit and handshake with protocol converters
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
A recent discussion between John Chandler and myself leads to a question.
It can be summarized briefly as follows.
- Using 370 Kermit through a Series/1 style protocol converter does, not
always but often, require that XON/XOFF pacing be used. Whether because of
terminal mode requirements or because of hardware requirements during file
transfer (e. g. 7171 and long packets).
- 370 Kermit uses transparent I/O to achieve file transfer, usually
write/read, but occasionally standalone read (in fact forced by hardware
to effectively be write/read with at least one output byte). While there
*seems* the external device (micro) always provides sufficient time to the
converter to switch from write to read state after having received a packet
(first case), the response to a read (second case) is unsynchronized.
It does not show with one off transactions, when manually driven, because
human response time makes up for the hardware turnaround requirements.
But with automated transactions, be it by TAKE files or a program,
chances are high that a packet sent by the micro be systematically missed
when it is not the reply to one sent by the host.
- Handshaking is therefore needed.
- CMS Kermit 3.1 happens to add an XON at the end of a packet and to send CR
as the forced output before standalone read. This is unusable as is but can
be turned to be.
- The question is: what single character should be used?
Could there be consent about a hard-coded value? Or should a command allow
to change it? What should then be the default?
- XON is associated with IBM. Some Kermits only provide for SET IBM ON. But
XON is unusable under XON/XOFF protocol. XOFF is even worse.
CR is to be ruled out as being the end-of-packet, conflicting when the micro
does not use it up.
We're left with the usually proposed LF, BELL or ESC.
I like neither BELL nor ESC, because they appear too often in terminal mode
screen controls and could interfere when the micro automatically starts the
host Kermit, or when, despite every effort to avoid it, the host system
manages to exit transparent mode (another story).
- I guess this note would be gibberish to most Kermit users. The choice must
lead to easy instructions to reliable Kermit operation.
-XON is for SET-IBM-ON-only Kermits. It implies that XON/XOFF be turned off
*both* on host and local, countrarily to terminal mode practice. This prevents
reliable transfer of packets longer than 300 bytes on the 7171. Changing the
HANDSHAKE on the host is just an addition to an already long list.
-LF is the only thing with FLOW- ON to be set locally, when feasible.
-careless ignorance of these details will only add to the already bad fame of
Kermit on the 7171, "stopping in the middle of the transfer".
- So my personal vote is LF.
- I think this kind of choice deserves list-wide discussion for total agreement
Thanks in advance. Andre.
From "Vace Kundakci <VVVCU@CUVMA>" Fri Oct 2 14:00:45 1987
Flags: 000000000000
Return-Path: <VVVCU%CUVMA.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 2 Oct 87 12:00:37-EDT
Received: by CUVMA (Mailer X1.25) id 9157; Fri, 02 Oct 87 11:58:15 EDT
Date: Fri, 2 Oct 87 11:58 EDT
From: Vace Kundakci <VVVCU@CUVMA>
To: Andre PIRARD <A-PIRARD@BLIULG12>
CC: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: 370 Kermit and handshake with protocol converters; Andre PIRARD <A-
In-Reply-To: Your memo of Fri, 02 Oct 87 10:46:08 ULG
Historically SET IBM ON was instituted due to the fact that
CMS-Kermit prior to 3.0 did WRTERM followed by RDTERM (without a
prompt). This allowed possibly infinite time between sending the
packet and issuing a rdterm. Secondly, RDTERM without prompt in
linemode puts up (vanilla VM) a dot-xon prompt. That is the only
reason SET IBM ON feature was instated, and the reason for selecting
XON. The events in the above scenario are:
SIO write (packet)
(wait some long time depending how CP wants to dispatch you)
SIO write (dot-xon) chained to read.
In the new linemode scenario, with RDTERM with prompts, SET IBM is
absolutely unnecessary! Here's the new scenario:
SIO write (packet) chained to read.
If there's any possibility that micro will send data before the host
is ready in the first scenario with SET IBM ON, that same reason will
apply to the second with or without SET IBM ON.
Therefore, SET IBM ON is unnecessary for linemode in CMS-Kermit >3.0.
In the ASCI-3270 mode, this is less of a problem. Therefore, let's
not use SET IBM ON any more for CMS Kermit. Am I missing somthing?
/Vace
------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Oct 2 16:42:31 1987
Flags: 000000000000
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 2 Oct 87 14:42:20-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 0288; Fri, 02 Oct 87 14:40:12 EDT
Date: 1987 Oct 2 13:52 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: 370 Kermit and handshake with protocol converters; Andre PIRARD <A-
In-reply-to: VVVCU@CUVMA message of Fri, 2 Oct 87 11:58 EDT
Message-id: <PEPMNT.871002.135218.A0@CFAAMP.BITNET>
> Historically SET IBM ON was instituted due to the fact that
> CMS-Kermit prior to 3.0 did WRTERM followed by RDTERM (without a
> prompt).
>
> In the new linemode scenario, with RDTERM with prompts, SET IBM is
> absolutely unnecessary! Here's the new scenario:
> SIO write (packet) chained to read.
1) I abandoned the new scenario because there's no way to tell VM to
bypass output translation on the prompt string (but it IS possible
for WRTERM). Very recently, I figured out a relatively clean way
of suppressing both input and output translation during transfers,
but I haven't gotten around to re-instating the RDTERM-with-prompt.
2) The business of waiting for an XON is not just CMS -- can one set
up a similar chained linemode write/read for other 370 systems?
3) I've never tried setting IBM off with, say, CMS Kermit 3.1 -- does
that really work (at all line speeds, etc.)?
> If there's any possibility that micro will send data before the host
> is ready in the first scenario with SET IBM ON, that same reason will
> apply to the second with or without SET IBM ON.
Andre's point is that there are situations when CMS Kermit can't use
the new scenario, e.g., when looking for the next command in server
mode after handling a GET request. An automated file-transfer program
running in a PC can easily feed the next command before VM (or a 7171)
is ready, unless there is some kind of handshake.
Following up on the handshake details: Andre's suggestion of LF for the
special character has merit, but might it not be best to leave the
default as XON? I think compatibility should always be a major concern
when introducing new features (unless the previous behavior was clearly
unacceptable). Since there are micro-Kermits that expect XON, it seems
advisable to place the burden of selecting LF on those who *really*
need it.
Another point: in issuing a short prompt over the 7171, should the
mainframe be limited to one character? Or should it send an EOL plus
a handshake? The latter has the advantage of being more like CMS
Kermit 3.1, which sends a CR (not always, but usually, the EOL).
John
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Oct 19 21:27:27 1987
Flags: 000000000000
Return-Path: <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 19 Oct 87 19:27:22-EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 3464; Mon, 19 Oct 87 13:11:59 EDT
Date: 1987 Oct 19 12:47 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: New names
Message-id: <PEPMNT.871019.124757.A0@CFAAMP.BITNET>
Here's a question of taste: for the upcoming release of Kermit-370 we
need a new file-name prefix. I have been tentatively using a three-byte
prefix with one character to indicate the system and three more to
specify the file, but the "official" maximum length for names is 6
characters, so something needs to be done. The suffixes could be
shortened to two bytes without losing uniqueness, but they would
certainly be less mnemonic. The three-byte "I37" seemed felicitous, in
that a code of "0" could denote generic modules with the resulting
"I370", but that feature gets lost if the prefix is shortened to two
bytes. Similarly, a two-byte prefix of "IB" allows the felicitous code
of "M" for generic stuff, but leaves no reasonable code for MTS-specific
modules (if they ever get created). Here are some possibilities I see:
----------- generic ---------- --- specific ---
1. I370DO, I370DE, I370CO, I370MA, etc. + I37CMA or I37TMA, etc.
2. IBM0DO, IBM0DE, IBM0CO, IBM0MA, etc. + IBMCMA or IBMTMA, etc.
3. IK0DOC, IK0DEF, IK0COM, IK0MAC, etc. + IKCMAC or IKTMAC, etc.
4. IBDOC0, IBDEF0, IBCOM0, IBMAC0, etc. + IBMACC or IBMACT, etc.
Any preferences, suggestions?
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Oct 22 21:52:32 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 22 Oct 87 19:52:25-EDT
Received: from CUVMA.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU ; Thu, 22 Oct 87 19:52:37 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 8498; Thu, 22 Oct 87 19:52:35 EDT
Date: 1987 Oct 22 19:32 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Nomenclature
Message-id: <PEPMNT.871022.193239.A0@CFAAMP.BITNET>
Ok, here are the results: 2 votes for 2-byte prefixes, N abstentions.
Therefore, I suggest the following scheme: prefix is IK, followed by
one character indicating the system (0=>generic, C=>CMS, T=>TSO, S=>CICS,
M=>MTS, I=>MUSIC, W=>WYLBUR, G=>GUTS, V=>VSPC...), followed by 3-letter
file name. The files for CMS would then be:
IK0CMD.ASM Assembler source for command handler
IK0COM.ASM Assembler source for global code
IK0DEF.ASM Assembler source for parameter definitions
IK0DOC.ASM Assembler source with brief history
IK0KER.DOC Kermit User Guide chapter for Kermit-370, plain text
IK0KER.MSS Scribe source for IK0KER.DOC
IK0MAC.ASM Assembler source for generic Kermit macros
IK0MAI.ASM Assembler source for storage initialization
IK0PRO.ASM Assembler source for generic routines
IKCBOO.ASM Assembler source for Kermit bootstrap program
IKCKER.ANN Text of Kermit-CMS 4.0 Announcement
IKCKER.BWR A "beware" file, listing known bugs and problems
IKCKER.DOC Kermit User Guide chapter for CMS, plain text
IKCKER.HLP Kermit-CMS help file, CMS HELP (Script) format
IKCKER.INS Kermit-CMS installation instructions (this file)
IKCKER.MSS Scribe source for IKCKER.DOC
IKCKER.UPD Updates for CMS-specific part of source
IKCMAC.ASM Assembler source for CMS-specific macros
IKCUTL.ASM Assembler source for CMS-specific routines
I suppose there would also be a CMSKERM.MSG containing a pointer to the
IKC and IK0 prefixes. TSO would be essentially the same (with IKC->IKT),
but with an additional IKTDYN.ASM. Any comments or suggestions?
John
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Sat Oct 24 00:16:09 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 23 Oct 87 22:16:02-EDT
Received: from CUVMA.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU ; Fri, 23 Oct 87 22:16:24 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 2836; Fri, 23 Oct 87 22:16:23 EDT
Date: 1987 Oct 23 22:04 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Handshake default
Message-id: <PEPMNT.871023.220445.A0@CFAAMP.BITNET>
On second thought, I believe it would be best to let the default for
HANDSHAKE in Kermit-370 to be 0 (none). This seems to fit both CMS and
TSO operation -- in CMS, no handshake is truly necessary because the
the writes and reads are chained for both Series/1 and TTY lines, and
in TSO, the needed handshake is supplied by the system anyway. This
might disconcert CMS Kermit users, who always SET IBM ON in their
micros, but they can always put SET HANDSHAKE 17 into the KERMINI file!
Any reactions?
John
From DEDOUREK%UNB.BITNET@CUVMA.COLUMBIA.EDU Sat Oct 24 00:45:34 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:DEDOUREK@UNB.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 23 Oct 87 22:45:24-EDT
Received: from CUVMA.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU ; Fri, 23 Oct 87 22:45:42 EDT
Received: from UNB by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id 2886;
Fri, 23 Oct 87 22:45:40 EDT
Date: 23 Oct 87 23:44:10 ADT
To: "Joe Doupnik" <JRD@USU.BITNET>
cc: "Kermit" <INFO-KERMIT@CU20B.COLUMBIA.EDU>,
"IBM-Kermit" <IBM-KERMIT@CU20b.COLUMBIA.EDU>,
"Stephen Mitchell" <9036985@UNB.BITNET>,
"Peter Jacobs" <JACOBS@UNB.BITNET>
Subject: Kermit-MS 2.29 (A?) B and C break VSPC Kermit
Keywords: MS-DOS VSPC Kermit
X-Ack-To: "John DeDourek" <DEDOUREK@UNB.BITNET>
From: DEDOUREK%UNB.BITNET@CUVMA.COLUMBIA.EDU
Message-ID: <ID3199.D871023.T234410.DEDOUREK@UNB>
First, the background to the problem.
VSPC (Virtual Storage Personal Computing) is a time sharing
system running under IBM's MVS operating system on IBM/370
class computers. It has been in use at UNB for many years and
is the principal terminal service provided by the University's
Computing Center. IBM has announced that it will discontinue
support for this system, and it will likely be phased out here
in the next one to two years. However, during that time, it was
desired to make Kermit available to UNB's user community.
VSPC runs processing programs (e.g. compilers, interpretters,
mail system) as follows. Each processing program is divided
into a read-only, shared code segment, and a readwrite data segment,
one per user, called the workspace. Workspaces for many users
share the same virtual address space. Virtual memory
fragmentation is controlled by moving a workspace within the
virtual address space when necessary. This may occur at any
service request (e.g. terminal read, terminal write) by the
processing program to VSPC. Any program which stores actual virtual
addresses of data (e.g. pointers) will break whenever the data
area is relocated. Obviously, most programs must be specially
written for VSPC. A graduate student (Stephen Mitchell) recently
completed a minimal Kermit implementation for VSPC.
Although he is currently cleaning up some problems, this Kermit
works reasonably well. He debugged it using Kermit-MS, version
2.29. It has also been successfully tested with Kermit-MS, version
2.28. However, recent testing with Kermit-MS, version 2-29B and
version 2-29C have failed. (Unfortunately, a 2-29A Kermit is
not currently available for testing.)
A description of the failure is as follows. The various
debugging options of Kermit-MS were used to analyze the
initiation of a file transfer from VSPC Kermit to Kermit-MS.
The exchange proceeds as follows.
IMPORTANT: because the "hat" which is normally used to indicate
control characters has no universal translation with
a particular EBCDIC character in the various mailers
through which this message might pass, and I am on
an EBCDIC machine, I will use * to designate control
characters in the following; e.g. *M is "return".
-- after starting both Kermits, and while being "connected" to
the mainframe, "talking" to VSPC Kermit, the user types
send test*M
-- VSPC Kermit responds with
*Jescape back to local system, give RECEIVE command*M
-- after a twenty second delay, VSPC Kermit sends its "init"
packet as
*J*A) S~( @-#U*M*G*Q
-- Kermit 2.29B and C "nak" this packet, VSPC Kermit responds
to the "nak" by retransmitting the "init" packet as above,
and this sequence repeats to the retry threshold, at which
time the transfer is abandoned.
Kermit-MS is set to
Baud rate 2400
Parity even
Local echo on
No flow control used
Handshake used: *Q
Send start-of-packet char: *A
Send packet size: 94
Receive start-of-packet char: *A
/vm DEDOUREK
/NC
/TO dedourek
ok
From DEDOUREK%UNB.BITNET@CUVMA.COLUMBIA.EDU Sat Oct 24 01:54:19 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:DEDOUREK@UNB.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 23 Oct 87 23:54:10-EDT
Received: from CUVMA.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU ; Fri, 23 Oct 87 23:54:30 EDT
Received: from UNB by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id 2951;
Fri, 23 Oct 87 23:54:29 EDT
Date: 24 Oct 87 00:54:22 ADT
To: "Joe Doupnik" <JRD@USU.BITNET>
cc: "Kermit" <INFO-KERMIT@CU20B.COLUMBIA.EDU>,
"IBM-Kermit" <IBM-KERMIT@CU20b.COLUMBIA.EDU>,
"Stephen Mitchell" <9036985@UNB.BITNET>,
"Peter Jacobs" <JACOBS@UNB.BITNET>
Subject: Re: Kermit-MS 2.29 (A?) B and C break VSPC Kermit
Keywords: MS-DOS VSPC Kermit
X-Ack-To: "John DeDourek" <DEDOUREK@UNB.BITNET>
From: DEDOUREK%UNB.BITNET@CUVMA.COLUMBIA.EDU
Message-ID: <ID3212.D871024.T005422.DEDOUREK@UNB>
Further testing of Kermit-MS 2.29C with VSPC shows the following:
Setting Kermit-MS to "no handshaking" with "debug on" leads to
successful transfers. However "no handshaking" with "debug off"
leads to many retrys, and usually exceeding the retry limit.
I conclude that:
--- One of the Kermit-MS versions subsequent to 2.29 changed the
handling of the handshaking such that extraneous characters
between the end of line indicator and the handshake character
(the bell for VSPC) cause the packet not to be accepted.
--- VSPC does not chain its read request to its write request,
so that with debugging off, Kermit-MS usually returns its
packet too soon. Debugging on, due to displaying packets
on the screen, slows transmission down just enough to allow
successful transmission, at least on a lightly loaded machine.
(This being written at 12:40 a.m.)
Since only VSPC service requests, not regular MVS requests, are
available to VSPC processors, we don't have any avenues to change
those features. Any suggestions would be appreciated.
John DeDourek
Professor of Computer Science
School of Computer Science
University of New Brunswick
P.O. Box 4400
Fredericton, New Brunswick, CANADA E3B 5A3
(506) 453-4566
/vm DEDOUREK
/NC
/TO 9036985
/SU I was surprised
/AC dedourek
Stephen:
I understand why you put each record in a new packet when sending
>From VSPC to the PC. Both the assembler and Pascal TSO Kermits
put one record per packet. Certainly the Kermit protocol manual
indicates that records should be packed up. But since neither
of the TSO Kermits do that, it is less serious that your VSPC
Kermit doesn't either. Is it easy or hard to make that change?
John DeDourek
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Oct 28 08:47:58 1987
Flags: 000000000000
Mail-From: SY.FDC created at 28-Oct-87 08:47:50
Date: Wed 28 Oct 87 08:47:50-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [(John F. Chandler) PEPMNT@CFAAMP.BITNET: IBM-Kermit list]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12346084526.36.SY.FDC@CU20B.COLUMBIA.EDU>
Date: 1987 Oct 27 23:10 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: (Frank da Cruz) SY.FDC@CU20B.COLUMBIA.EDU
Subject: IBM-Kermit list
Frank,
Since there's no way for the members of the IBM-Kermit list (on BITNET
anyway) to query the list server for the names of all the members, it
strikes me as a good idea for you to send out the list to all the members.
The last time you did that was a long time ago, and I gather that a fair
number of changes have occurred in the meantime. By the way, you might
be interested to know that some recent change in the mail transfer
software between CUVMA and CU20B has made my messages to the list come
out on BITNET looking entirely like mail from me, rather than partly
like mail from PEPMNT@CUVMA.
John
OK folks, here's the current list. Let me know of any changes you want.
If I ever get 5 free minutes, I might try to convert this to a LISTSERV
list, so you can query it, subscribe & unsubscribe yourself, etc. - Frank
IBM-Kermit:
*PK:<KERMIT-5>IBM370.TXT, ! Mail archive !
papa%USC-CSE.CSNET@RELAY.CS.NET, ! Marco Papa, USC (CMS) !
tank%apc3b2.UUCP@RELAY.CS.NET, ! Jon A. Tankersley (CMS) !
OC.AMS@CU20B.COLUMBIA.EDU, ! Bill Hall, Bell Labs (MTS) !
SY.FDC@CU20B.COLUMBIA.EDU, ! Frank da Cruz, CU (Kermit) !
"IBM-Kermit%UBC.Mailnet"@MIT-MULTICS.ARPA, ! Bruce Jolliffe, U of BC (MTS) !
HENDRICKS@NYU-ACF1.ARPA, ! Robert Hendricks, NYU (CMS/C-80) !
A-PIRARD%BLIULG11.BITNET@WISCVM.WISC.EDU, ! Andre Pirard, U of Liege (CMS) !
CMSMAINT%BROWNVM.BITNET@WISCVM.WISC.EDU, ! Peter DiCamillo, Brown (CMS) !
PEPMNT@CFAAMP, ! John Chandler, Harvard (CMS) !
VVVCU@CUVMA, ! Vace Kundakci, CU (CMS) !
26-377%HARVBUS1.BITNET@WISCVM.WISC.EDU, ! Clark Frazier, Harv.B.Sch. (CMS) !
BENNO%HROEUR1.BITNET@WISCVM.WISC.EDU, ! Benno Noordzij, U Rottrdam (MUSIC) !
FNRICK%LSUVM.BITNET@WISCVM.WISC.EDU, ! Rick Royston, LSU (CMS,TSO 327x) !
RAF@NIHCU, ! Roger Fajman, NIH (TSO) !
! GMW@PSUVM, George Weaver, Penn St. (INTERACT) removed at his request Jun 87 !
GUCJS@SEGUC21, ! Jon Scott, Gothenburg U (GUTS) !
OPRBMVC%TCSVM.BITNET@WISCVM.WISC.EDU, ! Manole Calamari, Tulane (MUSIC) !
SYSBJAV%TCSVM.BITNET@WISCVM.WISC.EDU, ! John Voigt, Tulane (MUSIC) !
TUCBOB%TUCCVM.BITNET@WISCVM.WISC.EDU, ! Bob Bolch, Triangle Univ (CMS) !
TUCSEB%TUCC.BITNET@WISCVM.WISC.EDU, ! Steve Blankinship, TU (TSO) !
YMUMMD%UK.AC.UMIST.CENTRAL-SERVICES.PRIME-A%UKACRL.BITNET@WISCVM.WISC.EDU,
! Mike Glendinning, U of Manchester !
! (TSO/ROSCOE/ETSO) !
DEDOUREK@UNBMVS1, ! John Dedourek, U of NB (VSPC) !
KOVACHDG%UREGINA1.BITNET@WISCVM.WISC.EDU, ! Don Kovach, U of Regina (???) !
SYSRONR%UCHIMVS1.BITNET@WISCVM.WISC.EDU, ! Ron Rusnak, U of Chicago (TSO) !
BOBLITT%VTVM1.BITNET@WISCVM.WISC.EDU ! Thomas Kern, VPI (VM/HPO,MVS/SP/VTAM) !
(end)
-------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Nov 2 15:55:51 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 2 Nov 87 15:55:43-EST
Received: from CUVMA.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU ; Mon, 02 Nov 87 15:49:23 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 7956; Mon, 02 Nov 87 15:49:21 EST
Date: 1987 Nov 2 15:44 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: SET LINE
Message-id: <PEPMNT.871102.154459.A0@CFAAMP.BITNET>
What is a reasonable limit on the length of the argument string for the
SET LINE command? Under VM/CMS, I think the natural implementation would
entail assigning LINE to a virtual device, i.e., only three characters.
I believe MTS Kermit has some kind of device name that could be assigned,
but it isn't clear how long the name could reasonably be. Any ideas for
other systems?
John
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Nov 5 23:29:29 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 5 Nov 87 23:29:01-EST
Received: from CUVMA.COLUMBIA.EDU by CUVMA.COLUMBIA.EDU ; Thu, 05 Nov 87 22:53:53 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 2798; Thu, 05 Nov 87 22:53:51 EST
Date: 1987 Nov 5 22:48 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Kermit update history
Message-id: <PEPMNT.871105.224830.A0@CFAAMP.BITNET>
The following is an update history partly pieced together from the
comments at the beginning of CMS Kermit. Some details are missing
and others may be wrong. Let me know if you have any corrections
or additions (this will be part of the Kermit-370 distribution).
John
---------
Kermit updates: labels matching columns 65-71 of the source, with
brief descriptions of the changes made. Changes up to Kermit-CMS
3.0 (never released) were not so labeled. Includes all variants
of Kermit-370.
------------------------------------------------------------
Column 65: institution
B-UC Berkeley, C-U of Chicago, H-Harvard, K-Kentucky, L-Liege, N-NIH,
S-Smithsonian AO, T-Triangle U CC, 0-Columbia, 1-Brown
Column 66: author/originator
?S: Bob Shields
BS: Greg Small
CR: Ron Rusnak
HF: Clark Frazier
KE: Dave Elbon
LP: Andre Pirard
NW: Dale White
SC: John Chandler
TB: Bob Bolch
TS: Steve Blankinship
0K: Vace Kundakci
0T: Daphne Tzoar
1D: Peter DiCamillo
Columns 66-71: date in form YYDDD
------------------------------------------------------ From CMS 2.0
Description
------- -----------------------------------------------------------
0T83Sep - 8-bit quoting to allow binary file transfer.
0T83Sep - Don't restrict disk lrecl to 256.
0T84Aug - Pack as much data into a packet as possible.
0T84Aug - Use common routines SPAR and RPAR for init packets.
0T84Sep - Add repeat count prefixing.
0T84Sep - Add support for two char checksum and three char CRC.
0T84Oct - Add SET/SHOW DEBUG mode.
?S85Feb - Add support for Series/1 front end.
0T85Mar - Add basic server support. Consolidate send-error-packet code.
0T85Mar - If debugging is on, log packets in a file.
0T85Mar - Read SYSTEM KERMINI and (USERID) KERMINI at start. TAKE.
0T85Mar - Implement skip file or file group when receiving.
0T85Apr - Add a SHOW ALL command.
0T85Apr - Add SET WARNING ON/OFF in case file name collisions.
?S85Apr - Bypass user translate tables for SPACK,RPACK.
0T85Apr - Add SET ETOA, SET ATOE and TDUMP.
0T85Apr - Encode outgoing filename, decode incoming one.
------------------------------------------------------ From CMS 2.01
Description
------- -----------------------------------------------------------
0K85 - If virtual console is not a TTY, assume 3270.
0K85 - Add a SLEEP command after server/receive mode greetings.
1D85 - Fix Logout hanging in Series1 mode.
KR85 - Hand-code HNDINT to allow non-009 console.
0K85 - Add SET EOF ON/OFF command to truncate file at ^Z.
0K85 - Add SET TABS-EXPAND ON/OFF command to expand tabs in TEXT.
BS85 - Do not change MAXOUT if not BINARY.
BS85 - Blk-3 chksum calculation begins at pkt len field.
BS85 - Initial setting of status: no file tranfer yet.
1D85 - Use max packet size of 60 for 7171.
0K85 - SHOW command defaults to SHOW ALL
------------------------------------------------------ From CMS 2.02
Description
------- -----------------------------------------------------------
0K86 - Almost a full rewrite.
------------------------------------------------------ From CMS 3.0
Label Description
------- -----------------------------------------------------------
BS86001 - Assorted ideas from Berkeley
TS86001 - TUCC Kermit-TSO
BS86090 - Augmented status print (Berkeley idea)
TS86100 - Add definable tab columns
SC86115 - Replace symbols w/ self-def terms
SC86119 - Fix bugs in 3.0
SC86120 - Revise SPAR/RPAR + parameter SET/SHOW
SC86121 - Rearrange COMMON: separate constants from variables
SC86125 - Add DROP indicator if aborting transfer
SC86133 - Replace SET/SHOW
SC86135 - Change error-exit mechanism in macros
SC86141 - Modify ENTER/RET to allow alternates
SC86148 - Replace SETMSG code
SC86149 - Add A-packets
HF86150 - Add transparent type and echo
SC86151 - Add V-binary file-type
SC86152 - Add SPARSET/RPARSET
SC86153 - Revise RPACK loop
SC86154 - Add padding
SC86155 - Add commands to foreign server
SC86156 - Systematize error codes + reporting same
HF86157 - Add return code from Kermit
SC86158 - Revise packet-recognition stuff
SC86159 - Watch for S/1 errors
SC86163 - Streamline ENCODE
SC86164 - Add SET DELAY + SET RETRY
SC86165 - Fix up transparent type/echo stuff
SC86171 - Add SET ECHO
SC86184 - Add short S/1 greeting
SC86190 - Move buffers out of COMMON
SC86191 - Skip padding for non-protocol stuff
TB86196 - Add long packets
SC86202 - Preliminaries for long packets
SC86203 - Add APPEND option
SC86204 - Assign names XECHO/XTYPE
SC86205 - Add limits from RDTERM/WRTERM
SC86206 - Add SET TEST
SC86209 - Replace LINEDIT by internal calls
TB86218 - Tune long packets for TTY line
SC86222 - Search R/O extensions
HF86223 - Add foreign filespec
SC86223 - Fix up foreign filespec
SC86224 - Tokenizing, foreign filenames, SET/SHOW, search R/O ext.
SC86225 - SET INCOMPLETE KEEP | DISCARD
SC86227 - Columnar SHOW
HF86232 - Fix up foreign filespec
HF86233 - Synchronize S/1 screen
SC86239 - Assorted changes
------------------------------------------------------ From CMS 3.1
Label Description - generic unless noted otherwise
------- -----------------------------------------------------------
SC86262 - Reorganize macros, add D-binary file-type
SC86265 - Fix bug in SET ATOE/ETOA
SC86268 - Prepare for generic version
SC86273 - Improve SET
SC86276 - Get around S/1 I/O errors
SC86283 - Add type-out snagging
SC86295 - Create generic version + CMS code
SC86299 - Disk I/O for generic TSO version (TSO)
SC86301 - Reorganize SIO
SC86316 - Reorganize generic Kermit
CR86321 - Skip setting LINEDIT+LINESIZE if S/1 (idea from TSOS1)
NW86330 - NIH Kermit-TSO (TSO)
SC86345 - Reorganize generic Kermit
SC86355 - Reorganize generic Kermit
SC87007 - Tune up a bit
SC87008 - Add 8-bit quote setting
TB87009 - Revised VTAM fix
SC87012 - More generic stuff
SC87015 - Make disk stuff more like NIH (TSO)
SC87020 - Implement type-out interception (TSO)
SC87034 - Allow lower case stuff
SC87117 - Implement new translation tables TATOE/TETOA + CMS EXEC SUBCOM
SC87166 - Change to SET TERMINAL, consolidate SET and SHOW code
SC87169 - Fix Server forgetting I-packet info
SC87201 - Avoid problems with INPUT/OUTPUT translations (CMS)
SC87253 - Margins for SEND, no extra XON, fix ext.plist, HOST, no delay.
SC87268 - TERMINAL -> CONTROLLER, truncation count, SET PROMPT
LP87272 - Make debug log record extra chars (except padding)
SC87274 - Add SET HANDSHAKE
SC87275 - Reinstate chained Write/Read for TTY lines (CMS)
SC87281 - Keep terminal buffers within 1 page each, fix translation
SC87286 - Log AID from S/1 reads, clean up DMSFRET, clean RIOLOG
SC87295 - Add control for CP TERM SCROLL (CMS)
SC87300 - Allow for error setting up comm line, deflt HNDSH = 0
From "Scott Galloway <sgallowa%xls-plexus01@amc-hq.arpa>" Fri Nov 6 14:15:51 1987
Flags: 000000000000
Return-Path: <sgallowa@xls-plexus01>
Received: from amc-hq.arpa by CU20B.COLUMBIA.EDU with TCP; Fri 6 Nov 87 14:15:11-EST
Received: from amc1 by AMC-HQ.ARPA id ah00167; 6 Nov 87 13:01 EST
Received: from xls-plexus01 by AMC1.AMC1.AMC id ac10321; 6 Nov 87 12:39 EST
Date: 6 Nov 87 12:32:10-EST (Fri)
From: Scott Galloway <sgallowa%xls-plexus01@amc-hq.arpa>
To: John Chandler <IBM-Kermit@cu20b>
cc: pbremer at Xls-Plexus01, sgallowa at Xls-Plexus01
Subject: Re: Status of TSO Kermit
PLEASE PASS THIS MESSAGE TO: JOHN CHANDLER
Subject: Status of TSO Kermit
John,
I am taking the IBM-Kermit route again because I am still having problems
sending mail directly to you... sorry for delays in getting a status to
you... here it is:
We are very dormant and nearly "dead" here...
I have yet to receive what I believe to be your entire source. I sent
a message to you on 26 Aug 87 indicating what I had received... below
is the message which was sent. I do admit to putting the investigation
into getting your code here and running, into "slow" mode, but until we get
all source code, other priorities have put this Kermit into the back seat.
We would be willing to send you a 9-trk tape to be returned to us with
your Kermit-TSO source code AND with installation instructions.
We are are still VERY interested in reviewing your code for possible use.
Please respond as soon as possible.
Thanks!
Scott
> Received: from amc1 by AMC-HQ.ARPA id aa02761; 26 Aug 87 13:55 EDT
> Received: from xls-plexus01 by AMC1.AMC1.AMC id a004948; 26 Aug 87 13:52 EDT
> Date: 26 Aug 87 13:37:35-EDT (Wed)
> From: Scott Galloway <sgallowa%xls-plexus01@amc-hq>
> To: pepmnt.cfaamp.bitnet at Wiscvm
> cc: sgallowa at Xls-Plexus01
> Subject: Re: Missing mail
>
> John,
>
> Thanks for assistance on the mail. I was on vacation last week and this is
> the first chance I've had to respond to you.
>
> I received five (5) source mail messages. Here is a list of the id sequence
> numbers for what I received in the order I received them: (knowing they are
> out of order)
>
> (1) 01086000 - 02097230
> (2) 00001400 - 00007570
> (3) 02599000 - 03888500
> (4) 02599000 - 04544000
> (5) 03158000 - 04544000
>
> I have not examined all lines... but I did find "broken parts" of the mail
> heading in some areas of the code... this makes me doubt the integrity.
>
> Here are the message id's I have received since the source code:
> <PEPMNT.870731.154707.A0@CFAAMP.BITNET> "Distortions of sources due to MAILER"
> <PEPMNT.870731.171029.A0@CFAAMP.BITNET> "Code updates"
> <PEPMNT.870730.183736.A0@CFAAMP.BITNET> "Kermit-370 TSO version"
> <PEPMNT.870805.111809.A0@CFAAMP.BITNET> "Another subroutine ..."
> <PEPMNT.870811.015104.A0@CFAAMP.BITNET> "Progress?"
> <PEPMNT.870814.162106.A0@CFAAMP.BITNET>
>
> I am not positive, but I think I have received all your follow up messages.
>
> Thats all... any assistance in "filling in the blanks" is appreciated.
> Thanks again!
>
> Scott
>
----- End of forwarded messages
----- End of forwarded messages
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Nov 12 18:50:10 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 12 Nov 87 18:50:02-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 12 Nov 87 18:44:04 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 9894; Thu, 12 Nov 87 18:44:00 EST
Date: 1987 Nov 12 14:42 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: TSO type-out interception
Message-id: <PEPMNT.871112.144232.A0@CFAAMP.BITNET>
The problem of how to intercept terminal output from a program attached
by TSO Kermit could probably be solved (with a great deal of effort) by
SVC screening. A less "high-powered" method (but one involving about
as much coding) would use the STACK user service to redirect PUTLINE
output to a disk file and then read it back. My TSO manuals are rather
old, so I can hope that there have been some new developments --
specifically, is there a new option on the STACK function to allow the
user to supply a DCB (possibly already OPEN'd) instead of a DDNAME for
the output redirection? If that were possible, and if the DCB were
presented as already opened using MOVE-mode PUT to a RECFM U dataset, the
"PUT" routine could neatly intercept the traffic without ever going to
disk! Is that too much to hope for?
John
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Nov 20 00:37:05 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 20 Nov 87 00:36:59-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 20 Nov 87 00:34:44 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 4749; Fri, 20 Nov 87 00:34:43 EST
Date: 1987 Nov 20 00:27 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: 3708 support
Message-id: <PEPMNT.871120.002751.A0@CFAAMP.BITNET>
Has anyone heard of a site where TS3KER actually works, other than
(presumably) the place where it was developed? I am including the
method of 3708 support from TS3KER in the generic Kermit, but I
wonder if it will actually do any good. Does anyone know of a site
with 3708's?
John
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Dec 7 14:13:01 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 7 Dec 87 14:12:43-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 07 Dec 87 14:11:42 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 3497; Mon, 07 Dec 87 14:11:38 EST
Date: 1987 Dec 7 13:30 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Handshake default for CMS Kermit
Message-id: <PEPMNT.871207.133011.A0@CFAAMP.BITNET>
On October 24 I sent a message to this list seeking opinions on what the
default should be for the handshake character sent by Kermit-CMS. At the
time, I had just changed my mind from a position favoring XON (i.e., the
status quo) to one favoring none at all (easier to explain in the Kermit
documentation and the "most efficient" choice). Seeing no response in
favor of the status quo, I went ahead and made the change. About the same
time, I also tightened up the code that sticks a HANDSHAKE character on
the end of an outgoing packet so that the HANDSHAKE is sent only when
a reply is really expected. It turns out that there is a bug in some
or all recent versions of MS-Kermit such that the HANDSHAKE character
is treated as the REAL end-of-packet (ignoring the EOL, I guess). In
light of that fact, Frank da Cruz has voted to reinstate the old XON
default in CMS Kermit (and in the generic TSO Kermit in SERIES1 mode,
for that matter) and to insert a spurious HANDSHAKE after certain
"final" packets, such as the ACK to a FIN or BYE command. From the
rationale behind creating the SET HANDSHAKE facility in the first place,
it is clear that such a spurious HANDSHAKE can't be tolerated *except*
in those two places, but I think in all other situations the mainframe
would soon be sending out a HANDSHAKE anyway. Before making any more
changes, I would like to hear any opinions there might be:
1. Does anyone prefer the default to be no handshake on technical
grounds (and why)?
2. Are there any thought on the topic of spurious handshakes? Bear
in mind that Kermit-CMS 3.1 sends them all the time.
John
From "Vace Kundakci <VVVCU@CUVMA>" Mon Dec 7 16:05:55 1987
Flags: 000000000000
Return-Path: <VVVCU@CUVMA.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 7 Dec 87 16:05:30-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 07 Dec 87 16:04:56 EST
Received: by CUVMA (Mailer X1.25) id 4523; Mon, 07 Dec 87 16:04:47 EST
Date: Mon, 7 Dec 87 16:04 EST
From: Vace Kundakci <VVVCU@CUVMA>
To: PEPMNT@CFAAMP.BITNET (John F. Chandler)
CC: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: Handshake default for CMS Kermit; (John F. Chandler) PEPMNT@CFAAM
In-Reply-To: Your msg of : 1987 Dec 7 13:30 EST
1. Handshake default should be as it has been, XON.
2. Set IBM command should be announced as useless.
3. People should be encouraged to run CMS linemode Kermit
without handshake.
4. The upcoming release should warn when kermit-cms is started
that the default is handshake xon and encourage users to change
it, and reminding them to not set handshake on the pc. And a
subsequent release should change the default to handshake none
and warn users that it is the default. and finally, a subsequent
release should default to no handshake and not warn about it.
/Vace
------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Dec 7 17:50:34 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 7 Dec 87 17:50:21-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 07 Dec 87 17:50:05 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 5086; Mon, 07 Dec 87 17:50:04 EST
Date: 1987 Dec 7 17:44 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: TSO handshake
Message-id: <PEPMNT.871207.174443.A0@CFAAMP.BITNET>
I have always been under the impression that TSO offers no means of
changing the prompt sequence for TTY-type terminals (XOFF . DEL XON,
or something like that). The recent business about XON's raises the
question again: is there any way to change or suppress the usual
prompt string in TSO?
John
From "Vace Kundakci <VVVCU@CUVMA>" Thu Dec 10 16:25:43 1987
Flags: 000000000000
Return-Path: <VVVCU@CUVMA.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 10 Dec 87 16:25:31-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 10 Dec 87 16:25:33 EST
Received: by CUVMA (Mailer X1.25) id 8987; Thu, 10 Dec 87 16:25:31 EST
Date: Thu, 10 Dec 87 16:25 EST
From: Vace Kundakci <VVVCU@CUVMA>
To: John Chandler <PEPMNT@CFAAMP>
CC: ibm-kermit@cu20b
Subject: Kermit test
Your new kermit works fine in linemode and 7171 modes with our
without handshake...
Here are some stats sending a very large file from cms to pc in
server mode.
connection handshake packet size transfer (disk bytes)
---------- --------- ----------- ---------------------
linemode xon 1000 617/sec
linemode none 1000 614/sec
7171 none 1000 669/sec
7171 none 80 527/sec
By the way all of the above tests had 0 errors, 9600 baud, and the
file I was transfering was a large CMS TEXT file (object deck) and I
was not using the binary mode.
/Vace
------
From DEDOUREK%UNB.BITNET@CUVMA.COLUMBIA.EDU Thu Dec 10 18:01:27 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:DEDOUREK@UNB.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 10 Dec 87 18:01:18-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 10 Dec 87 18:01:27 EST
Received: from UNB by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id 9405;
Thu, 10 Dec 87 18:01:24 EST
Date: 10 Dec 87 13:11:32 AST
To: ibm-kermit@cu20b.columbia.edu,
9036985@UNB,
mikemac@UNB,
jrd@usu.bitnet
Subject: handshaking in Kermit
From: DEDOUREK%UNB.BITNET@CUVMA.COLUMBIA.EDU
Message-ID: <ID4732.D871210.T131132.DEDOUREK@UNB>
Having just gone through quite a bit of agony about handshaking,
including having run afoul of the changes in MS-Kermit, I will
state some opinions. However, please understand I am not in
the "expert systems programmer" class.
I am running on an MVS machine with 2 time sharing systems in place:
TSO and VSPC (a IBM product which is being discontinued). We
needed a simple Kermit to ease the transition from VSPC to its
follow on. A MScCS student implemented such a Kermit, now in the
testing stage.
My understanding of handshaking is that it is applicable to a half-
duplex system (mostly,IBM mainframes), or a to a full-duplex system
without typeahead (don't know of any). In such systems, a relatively
fast machine (e.g. a PC) might start sending characters before
the receiving machine was able to start accepting characters. Such
characters are discarded. If they are the front of a Kermit packet,
the packet is, in essence, lost, resulting in an expensive (performance
wise) retransmission.
The handshake is intended to be issued by the receiving system (say
the IBM mainframe) immediately prior to when it is able to receive.
There may be a considerable gap between the mainframe sending a
packet, and issuing a read for one, since the user's program loses
control to one of the other 200 programs running for other users.
With no typeahead, the mainframe discards characters until the
user's program, Kermit in this case, actually issues a read request
to the timesharing system involved (VSPC, TSO, ...).
There are various methods for issuing a handshake. VSPC does it
automatically whenever a read is issued; the user has no control;
the handshake is two characters long: XON BELL. I can't speak
for TSO, but having observed it with MS-Kermit's debug option
on, it appears to issue one whenever it completes a write or
requests a read, at least on our system. Do I understand from
the discussion that CMS does not issue the handshake and it is
left to Kermit itself to issue the handshake?
It would seem to me, that a local Kermit which has its handshaking
character enabled, because it is talking to an IBM mainframe, or
some such, should accept and process a packet as soon as the
end of packet (CR) character is received. However, when it prepares
to send a packet, it should delay until receipt of the handshake.
I realize that there are significant problems in this naive view,
having to do with flushing buffers to avoid spurious characters etc.
However, as a user of a real IBM mainframe, under other than the
most popular operating system (CMS) I am concerned that the
handshaking features are being transformed from their real purpose
into a CMS specific feature.
John DeDourek
DEDOUREK@UNBMVS1.BITNET
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Dec 10 18:54:57 1987
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 10 Dec 87 18:54:49-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 10 Dec 87 18:54:58 EST
Received: from CFAAMP.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
9619; Thu, 10 Dec 87 18:54:57 EST
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer X1.25) with
BSMTP id 4268; Thu, 10 Dec 87 18:52:19 EST
Date: 1987 Dec 10 18:14 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: DEDOUREK@UNB.BITNET, ibm-kermit@cu20b.columbia.edu, 9036985@UNB.BITNET,
MIKEMAC@UNB.BITNET, JRD@USU.BITNET
Subject: Re: handshaking in Kermit
In-reply-to: DEDOUREK%UNB.BITNET@CUVMA.COLUMBIA.EDU message of 10 Dec 87
13:11:32 AST
Message-id: <PEPMNT.871210.181420.A0@CFAAMP.BITNET>
The main response is: fear not.
No, the user in CMS is *not* required to take care of handshaking, but
yes, Kermit-CMS takes over that function because CMS offers the chance
of scheduling a terminal READ *immediately* after the previous WRITE.
To that extent, in fact, handshaking is not needed at all for CMS Kermit.
The same freedom exists in any session conducted through a Series/1,
7171 or 4994 protocol emulator. Therefore, the issue of handshaking is
at least relevant, if not necessarily very interesting, to nearly all
IBM mainframe users. Still, the CMS model will not be imposed on the
soon-to-be-released Kermit-370 across the board. In other words, the
decision of who does the handshaking (if any) is system-specific. For
example, in the TSO version (not yet complete) there is an implicit
assumption that the operating system will issue a handshake when it is
ready to read the next packet (in linemode), and Kermit declines to get
involved, but the handshake parameter remains available for users who
operate in SERIES1 mode.
As for the behavior of MSKermit (and possibly others), I don't see any
reason for treating the handshake character, if any, as the end of the
previous packet instead of the trigger for the next. Still, I'm
willing to deal with facts, and there's no real harm in sending an extra
handshake after a transmission is nominally complete if that will make
all these existing Kermits happy (at least, I can't think of any real
harm). In short, all versions of Kermit-370 will make sure that at
least one handshake gets sent out sometime after every packet (unless
the user says not to) and that no handshake will be sent before its time.
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Mon Dec 28 15:27:53 1987
Flags: 000000000000
Mail-From: SY.FDC created at 28-Dec-87 15:27:48
Date: Mon 28 Dec 87 15:27:48-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [jimbys%CITIAGO.BITNET@CUVMA.COLUMBIA.EDU (James V. Bys): Kermit on 9370 using ASCII Subsystem]
To: ibm-kermit@CU20B.COLUMBIA.EDU
Message-ID: <12362148121.25.SY.FDC@CU20B.COLUMBIA.EDU>
Anybody have any ideas??? Please reply directly to James, with cc to me
in case there turns out to be a quick fix (in which case we'll publish it
in the digest). - Frank
---------------
Return-Path: <@CUVMA.COLUMBIA.EDU:jimbys@CitIago.Bitnet>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 28 Dec 87 15:07:40-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 28 Dec 87 14:59:36 EST
Received: from CitIago.Bitnet by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 4987; Mon, 28 Dec 87 14:59:34 EST
Date: Mon, 28 Dec 87 11:20:39 PST
From: jimbys%CITIAGO.BITNET@CUVMA.COLUMBIA.EDU (James V. Bys)
Message-Id: <871228112039.02f@Iago.Caltech.Edu>
Subject: Kermit on 9370 using ASCII Subsystem
To: sy.fdc@cu20b.columbia.edu
The following question for info-kermit has been submitted to the following
three addresses in order:
INFO-KERMIT@CU20B.COLUMBIA.EDU
INFO-KERMIT-REQUEST@CU20B.COLUMBIA.EDU
SY.FDC@CU20B.COLUMBIA.EDU
Our mailer has not reported that either of the first two submissions was
returned, but the article has not successfully been submitted either.
If you have now received the following article please respond to
JIMBYS@IAGO.CALTECH.EDU. Also please submit the following question
to the info-kermit newsgroup. Thanks!
------------------------------------------------------------------------------
We have been running CMS Kermit 3.1 on an IBM 4381 with a 7171 interface
successfully. We recently received an IBM 9375 with an ASCII Subsystem.
This IBM supported subsystem acts similarly to the 7171.
Kermit compiles and starts successfully on the 9375. When Kermit is
put in server mode, the FIRST file transfer occurs successfully. After
this transfer, the terminal attached to the ASCII Subsystem is completely
hung. None of the local reset characters have any effect. Needless to
say, no further communication by the local Kermit with the 9375 occurs.
The CMS installation instructions state:
"When CMS Kermit is to be used with a 7171, make sure the 7171 is set
up with its 'keyboard lock delay' parameter set to 0. Otherwise, the
'terminal' will hang whenever CMS Kermit clears the screen..."
This symptom sounds similar to the one mentioned above using the
ASCII Subsystem. There, however, is no mention that we could find of
a "keyboard lock delay" parameter in manual SA33-1564 "ASCII Subsystem
Customization and Programmer's Guide".
Could anyone that has successfully installed Kermit through an ASCII
Subsystem please comment?
James V. Bys
California Institute of Technology
Internet address: JIMBYS@iago.caltech.edu
Bitnet address: JIMBYS@CITIAGO
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Jan 6 11:52:55 1988
Flags: 000000000000
Mail-From: SY.FDC created at 6-Jan-88 11:52:46
Date: Wed 6 Jan 88 11:52:45-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Test message
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12364468271.13.SY.FDC@CU20B.COLUMBIA.EDU>
I moved the BITNET subscribers to IBM-Kermit to a LISTSERV list because
of the trouble with BITNET gateways disappearing, etc. You should still
send mail to IBM-Kermit@CU20B to get to all the subscribers. Mail to
IBM-KERM@CUVMA will only reach the BITNET subscribers. - Frank
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Thu Jan 7 14:17:29 1988
Flags: 000000000000
Mail-From: SY.FDC created at 7-Jan-88 14:17:24
Date: Thu 7 Jan 88 14:17:24-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [Doug Baldwin <KGDJB%ASUACAD.BITNET@CUVMA.COLUMBIA.EDU>: Is Kermit available on MVS/WYLBUR]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12364756745.13.SY.FDC@CU20B.COLUMBIA.EDU>
Was any progress ever make on the Wylbur front? I remember Roger said they
were planning to add this to NIH TSO Kermit. Any hope for Portable 370
Kermit? From the tone of this message, these folks might be willing to act
as a development site... - Frank
---------------
Return-Path: <@CUVMA.COLUMBIA.EDU:KGDJB@ASUACAD.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 7 Jan 88 11:33:24-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 07 Jan 88 11:30:04 EST
Received: from ASUACAD.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 9625; Thu, 07 Jan 88 11:30:01 EST
Received: by ASUACAD (Mailer X1.25) id 2566; Thu, 07 Jan 88 09:30:05 MST
Date: Thu, 7 Jan 1988 09:28:03 MST
From: Doug Baldwin <KGDJB%ASUACAD.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Is Kermit available on MVS/WYLBUR
To: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Dear Frank,
Here at Arizona State University, we are running Online Business Systems'
(OBS) WYLBUR under MVS on an IBM 3090. WYLBUR is accessed in full-screen
mode via an IBM 7171 protocol converter, and in line-mode via an IBM 3705
front end. We also have similar access for CMS running under VM, and
use Kermit-CMS successfully with that.
Do you know if it is possible to run Kermit on WYLBUR? We have
assumed that it couldn't be done because this was a batch-oriented
system. Is it possible to at least come up with the barebones SEND and
RECEIVE commands with Kermit protocol using I/O routines that
bypass WYLBUR I/O, and can operate through the 7171? At one time,
OBS said they might possibly write something with the proper
motivation ($$$$), but they push their own file transfer program
called EXCELINK.
We would like to user Kermit on all our systems, but WYLBUR has always
been a thorn in our side for file transfers. If you know of any Kermit
versions already written for WYLBUR, or have some suggestions, please pass
them along. Thank you for your help.
Doug Baldwin
Computing Services
Arizona State University
-------
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Thu Jan 7 18:00:08 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 7 Jan 88 18:00:04-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 07 Jan 88 17:59:03 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
1715; Thu, 07 Jan 88 17:58:58 EST
To: SY.FDC@CU20B.COLUMBIA.EDU, IBM-KERMIT@CU20B.COLUMBIA.EDU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Thu, 07 Jan 88 17:59:54 EST
Subject: Re: [Doug Baldwin
<KGDJB%ASUACAD.BITNET@CUVMA.COLUMBIA.EDU>: Is
> Was any progress ever make on the Wylbur front? I remember Roger said they
> were planning to add this to NIH TSO Kermit. Any hope for Portable 370
> Kermit? From the tone of this message, these folks might be willing to act
> as a development site... - Frank
We are just getting ready to actually start implementing Kermit in
NIH WYLBUR. We don't plan to use the generic 370 Kermit, for
reasons that I outlined a long time ago. Instead, we will be
extracting a Kermit protocol module from NIH TSO Kermit and using
that in NIH WYLBUR with a separate command interpreter. The
protocol module might be useful with OBS WYLBUR, but I doubt that
our command interpreter would be.
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Jan 7 19:32:32 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 7 Jan 88 19:32:29-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 07 Jan 88 19:31:38 EST
Received: from CFAAMP.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
1855; Thu, 07 Jan 88 19:31:36 EST
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer X1.25) with
BSMTP id 0892; Thu, 07 Jan 88 19:28:27 EST
Date: Thu, 1988 Jan 7 19:08 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU, KGDJB@ASUACAD.BITNET
Subject: Re: [Doug Baldwin <KGDJB%ASUACAD.BITNET@CUVMA.COLUMBIA.EDU>: Is Kermit
available on MVS/WYLBUR]
In-reply-to: SY.FDC@CU20B.COLUMBIA.EDU message of Thu 7 Jan 88 14:17:24-EST
Message-id: <PEPMNT.880107.190801.B0@CFAAMP.BITNET>
> From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
>
> Was any progress ever make on the Wylbur front? I remember Roger said they
> were planning to add this to NIH TSO Kermit. Any hope for Portable 370
> Kermit? From the tone of this message, these folks might be willing to act
> as a development site... - Frank
> From: Doug Baldwin <KGDJB%ASUACAD.BITNET@CUVMA.COLUMBIA.EDU>
>
> Do you know if it is possible to run Kermit on WYLBUR? We have
> assumed that it couldn't be done because this was a batch-oriented
> system.
I thought WYLBUR was intrinsically interactive -- does this just mean
that ASU has MVS but not TSO?
> Kermit protocol using I/O routines that
> bypass WYLBUR I/O, and can operate through the 7171?
If WYLBUR can talk to the terminals, I'm sure Kermit running under
WYLBUR can do the same.
I have no idea how similar the OBS WYLBUR is to the NIH WYLBUR, but
Roger Fajman at NIH has been looking into Kermit for WYLBUR there. My
own feeling is that WYLBUR need not settle for a barebones Kermit, since
Kermit-370 could be ported to a WYLBUR environment. Kermit-370 is best
suited to running with lots of virtual memory, so the simplest way to
graft Kermit onto WYLBUR is to institute a KERMIT mode (in which all the
buffers and other read/write memory are allocated) so that Kermit won't
add a significant amount to the storage needed for each user. However,
Roger believes that WYLBUR should be modeless, and I don't know enough
about WYLBUR to design the needed interface.
John
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Wed Jan 20 16:57:25 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 20 Jan 88 16:57:21-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 20 Jan 88 16:55:02 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 4454; Wed, 20 Jan 88 16:55:00 EST
Date: Wed, 1988 Jan 20 16:06 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Post-4.0 revisions
Message-id: <PEPMNT.880120.160601.B0@CFAAMP.BITNET>
It has been suggested that Kermit-CMS scan the file header packet for
three tokens, not just two. I had originally avoided the third token,
if any, because it (1) might be just something extra tacked on by the
micro Kermit and (2) might imply an invalid disk mode, thereby causing
the transfer to fail. The orthodox answers to those objections are (1)
the canonical form is 'name.type', so any third token is intentional,
and (2) yes, but the transfer fails right away, and the same problem
would occur if the default destination turned out to be a read-only
disk anyway. One advantage of checking for a third token is that a
mode number other than '1' could be specified. Can anybody think of any
other arguments for or against this change? By the way, the change is
simplicity itself: remove lines 05172000 and 05173000.
Another change that has come up is trimming any trailing blanks off the
command lines read from TAKE files, particularly RECFM=F. This is, of
course, applicable to all flavors of Kermit-370, not just CMS. Given
that, under some circumstances, trailing blanks are already removed from
lines entered at a terminal, it seems unlikely that there could be any
real value in preserving trailing blanks, but there's always that chance.
Any thoughts?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Wed Jan 20 17:35:40 1988
Flags: 000000000000
Mail-From: SY.FDC created at 20-Jan-88 17:35:38
Date: Wed 20 Jan 88 17:35:37-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Post-4.0 revisions
To: PEPMNT@CFAAMP, IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: <PEPMNT.880120.160601.B0@CFAAMP.BITNET>
Message-ID: <12368200703.29.SY.FDC@CU20B.COLUMBIA.EDU>
I think Kermit-CMS should believe the entire file header. The other
Kermit program does not parse or validate in any way the remote filespec
in SEND or GET commands for just that reason, but puts whatever the user
typed into the F packet, e.g. "foo bar a2". - Frank
-------
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Jan 22 12:00:47 1988
Flags: 000000000000
Mail-From: SY.FDC created at 22-Jan-88 12:00:38
Date: Fri 22 Jan 88 12:00:38-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: [Hans Morten Kind <kind%rose.uib.uninett@TOR.nta.no>: CMS KERMIT]
To: IBM-Kermit@CU20B.COLUMBIA.EDU
Message-ID: <12368664008.33.SY.FDC@CU20B.COLUMBIA.EDU>
Has anyone ever seen anything like this?
---------------
Date: 22 Jan 88 13:33 +0800
From: Hans Morten Kind <kind%rose.uib.uninett@TOR.nta.no>
To: <sy.fdc@cuvma.columbia.edu>
Subject: CMS KERMIT
I have experienced a problem running CMS KERMIT 4.0 and also 2.01
Our environment:
IBM4381 : CMS/SP release 5
IBM7171 : Support utility ver 1.03
Sending parties:
PC's connected over LAN running MS-KERMIT's
Direct line to KERMIT VMS running on a microVAX
The error occurs when CMS KERMIT is the receiving part:
it suddenly goes dead
In the log file we can see him receiving D-packets and sending Y-packets.
At random place in the transfer a receiving packet is not
ended; there is no CR and the packet is not full (94 bytes).
The sending KERMIT will retry sending the packet, but
CMS-KERMIT does not answer at all. This is observed at
the sending side and by a line-monitor. The last packet
(an E-packet) is not answered either. None of these packets
are viewed in the log-file: the last one beeing the abnormal
terminated packet. Escaping back to CMS-KERMIT, nothing
happens. It is still in a 'transparent read' and recognizes
no input than CNTRL-G. After 6-7 such 'master-resets' CMS KERMIT
says 'Invalid packet', meaning all the received CNTRL-G's.
In the line-monitor we can see that the packet sent is OK.
Different Kermits have been tested against CMS-KERMIT:
they all experience the same problem.
It seems that the error is more likely to occur for
a large file than for small ones.
The hang happens at different places in the file.
I have tried the following with no success:
- disable pacing for the terminal-type beeing used
- disable pacing in transparent r/w: DC00:0008 10
- assemble Kermit with the transparent command:
115d7f110000
meaning only transparent write, NOT read
Although there is not seen any XON/XOFF characters in the
line monitor.
Is this a common problem or are there any solutions?
Hans Morten Kind
reply to arpa-gwy: kind%rose.uib.uninett@tor.nta.no
or to earn : edphk@nobergen
-------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Jan 22 16:43:07 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 22 Jan 88 16:42:59-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 22 Jan 88 16:40:39 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 5928; Fri, 22 Jan 88 16:40:38 EST
Date: Fri, 1988 Jan 22 15:30 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Comments: To: EDPHK@NOBERGEN
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: [Hans Morten Kind <kind%rose.uib.uninett@TOR.nta.no>: CMS KERMIT]
In-reply-to: SY.FDC@CU20B.COLUMBIA.EDU message of Fri 22 Jan 88 12:00:38-EST
Message-id: <PEPMNT.880122.153008.B0@CFAAMP.BITNET>
> In the log file we can see him receiving D-packets and sending Y-packets.
> At random place in the transfer a receiving packet is not
> ended; there is no CR and the packet is not full (94 bytes).
Does the AID in the log agree with the apparent length of the buffer
(as shown in the log)? Does the AID indicate any kind of abnormal
transmission? Note that 4.0 is more helpful than 2.01.
> None of these packets
> are viewed in the log-file: the last one beeing the abnormal
> terminated packet.
Does the log show anything being sent from CMS in response to the
abnormal packet, e.g., a repeat of the previous Y-packet?
> After 6-7 such 'master-resets' CMS KERMIT
> says 'Invalid packet', meaning all the received CNTRL-G's.
>
> I have tried the following with no success:
> - assemble Kermit with the transparent command:
> 115d7f110000
> meaning only transparent write, NOT read
This probably has no effect, since Kermit-CMS changes the command back
and forth at need -- you would need to catch all references to WRRD.
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Jan 25 17:09:41 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 25 Jan 88 17:09:36-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 25 Jan 88 17:07:48 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 7514; Mon, 25 Jan 88 17:07:47 EST
Date: Mon, 1988 Jan 25 16:37 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Kermit features
Message-id: <PEPMNT.880125.163740.B0@CFAAMP.BITNET>
Traditionally, CMS Kermit and TSO Kermit have behaved differently about
the WARN parameter. When WARN is ON, CMS non-interactively changes the
filespec of any received file (if necessary) to be unique, but TSO
prompts the user for permission to overwrite in case of a filespec
collision. The latter behavior must actually be restricted so that the
interaction takes place only in regard to a filespec explicitly typed
by the user, so I pose the following question. Is it worthwhile to
provide the interactive prompting at all, given that the preferred mode
of operation nowadays is SERVER mode? Along the same lines, how much
of an advantage would it be to provide 'END' in TSO Kermit as a synonym
for 'EXIT' or 'QUIT'?
John
From "(John F. Chandler) PEPMNT@CFAAMP" Tue Jan 26 14:34:06 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 26 Jan 88 14:33:49-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 26 Jan 88 14:31:44 EST
Received: from HARVARDA.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 2136; Tue, 26 Jan 88 14:31:42 EST
Received: from CFAAMP(PEPMNT) by HARVARDA (Mailer X1.23b) id 9836;
Tue, 26 Jan 88 14:32:08 EST
Date: Tue, 1988 Jan 26 14:09 EST
From: (John F. Chandler) PEPMNT@CFAAMP
To: IBM-Kermit@CU20B.COLUMBIA.EDU,
(Denis Delaroca) delaroca@oac.ucla.edu,
(Scott Galloway) sgallowa%xls-plexus01@amc-hq.ARPA,
(Jack Schudel) $$$CBFI@NERVM,
(Charlie Turner) CHARLIE@UMVMA, (Richard J Waite) C0@DDAESA10,
(Michael J. MacDonald) MIKEMAC@UNB, (Michael Califf) CALIFFM@BAYLOR,
(Stephen Y. Odo) T004320@UHCCMVS, GILLES@UOFMCC
Subject: The BYE command
Message-id: <PEPMNT.880126.140922.B0@CFAAMP.BITNET>
It seems that Kermit-TSO, in server mode responding to a BYE command,
doesn't manage to log off immediately. What seems to happen, instead,
is this: Kermit returns to interactive mode, but the TSO session remains
active until Kermit exits. Does anyone know if that is standard
procedure for TSO? Or is there just something wrong with the way Kermit
is attaching the subtask to execute the LOGOFF command? Thanks.
John
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Tue Jan 26 16:51:29 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 26 Jan 88 16:51:10-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 26 Jan 88 16:49:05 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
3348; Tue, 26 Jan 88 16:49:02 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
cc: DAD@NIHCU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Tue, 26 Jan 88 16:50:07 EST
Subject: Re: Kermit features
> Traditionally, CMS Kermit and TSO Kermit have behaved differently about
> the WARN parameter. When WARN is ON, CMS non-interactively changes the
> filespec of any received file (if necessary) to be unique, but TSO
> prompts the user for permission to overwrite in case of a filespec
> collision. The latter behavior must actually be restricted so that the
> interaction takes place only in regard to a filespec explicitly typed
> by the user, so I pose the following question. Is it worthwhile to
> provide the interactive prompting at all, given that the preferred mode
> of operation nowadays is SERVER mode? Along the same lines, how much
> of an advantage would it be to provide 'END' in TSO Kermit as a synonym
> for 'EXIT' or 'QUIT'?
> John
Our latest (as yet unreleased) TSO Kermit does the following when an
uploaded data set name already exists:
File name collison handling on:
Server: pick a new name for the uploaded file
Receive: same
File name collision handling off:
Server: abort the transfer
Receive: prompt for a new name
We do provide END as a synonym for QUIT. END is the standard
subcommand in TSO for exiting from an application.
From "Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>" Tue Jan 26 18:00:53 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:TUCSEB@TUCC.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 26 Jan 88 18:00:47-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 26 Jan 88 17:58:50 EST
Received: from TUCC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
3866; Tue, 26 Jan 88 17:58:46 EST
Date: Tue, 26 Jan 88 17:59 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: The BYE command
My understanding of this is that the LOGOFF command justs sets a
bit saying that a logoff has been done. When all commands, etc.
have completed the session is logged off. Therefore, KERMIT must
exit back to the TMP before the logoff will be done. The KERMIT
that we wrote here at TUCC for MVS TSO honors the BYE command and
it attaches a subtask to execute the TSO LOGOFF command and then
it exits. The TSO session ends as soon as Kermit-TSO returns to
the TMP.
Steve Blankinship
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Tue Jan 26 18:06:57 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 26 Jan 88 18:06:51-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 26 Jan 88 18:04:47 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
3934; Tue, 26 Jan 88 18:04:42 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
cc: DAD@NIHCU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Tue, 26 Jan 88 17:45:36 EST
Subject: Re: The BYE command
> It seems that Kermit-TSO, in server mode responding to a BYE command,
> doesn't manage to log off immediately. What seems to happen, instead,
> is this: Kermit returns to interactive mode, but the TSO session remains
> active until Kermit exits. Does anyone know if that is standard
> procedure for TSO? Or is there just something wrong with the way Kermit
> is attaching the subtask to execute the LOGOFF command? Thanks.
> John
See my response to your question on IBM-MAIN:
> > I recently found unexpected behavior in an attempt to terminate a TSO
> > session from within an application program (Kermit, in case you're
> > interested). The program attached a subtask with a command buffer of
> > 'LOGOFF DISCONNECT', the subtask completed successfully (so it said), but
> > the TSO session was still going and remained so until the main program
> > exited. At that point, the session logged out immediately. Is this the
> > the standard result in TSO? Should I have placed the name 'LOGOFF' in
> > the ECTPCMD field instead of ECTSCMD? Any suggestions will be welcome.
>
> Yep, that's the way it works. In NIH TSO Kermit we issue the LOGOFF
> command and then exit. This works fine unless TSO Kermit was
> invoked as a subcommand of another TSO command. The only other
> solution that I can think of is to issue a STEP ABEND. I'm not sure
> if that would have bad side effects. I don't think it makes any
> difference what you put into ECTxCMD.
By the way, you should be a bit more specific as to which version of
Kermit for TSO you are speaking of.
From "(John F. Chandler) PEPJFC@CFAAMP.BITNET" Thu Jan 28 16:17:49 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPJFC@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 28 Jan 88 16:17:45-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 28 Jan 88 16:14:48 EST
Received: from CFAAMP.BITNET (PEPJFC) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 6439; Thu, 28 Jan 88 16:14:44 EST
Date: Thu, 1988 Jan 28 16:11 EST
From: (John F. Chandler) PEPJFC@CFAAMP.BITNET
To: ibm-kermit@cu20b.columbia.edu
Subject: The END subcommand
Message-id: <PEPJFC.880128.161141.B0@CFAAMP.BITNET>
I already asked this question, but with a different slant. TSO people
seem to feel that END is a natural synonym for EXIT/QUIT, so I guess
TSO Kermit, at least, should have it. The question is, then, should
END also be allowed as a QUIT synonym in all IBM mainframe Kermits (for
example, CMS), or just in TSO? More particularly, are there any systems
where the END subcommand should be reserved for some other function?
John
From "Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>" Mon Feb 1 10:16:04 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 1 Feb 88 10:15:55-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 01 Feb 88 10:12:58 EST
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
8245; Mon, 01 Feb 88 10:12:57 EST
Received: by BLIULG11 (Mailer X1.25) id 1651; Mon, 01 Feb 88 16:13:22 +0100
Date: Mon, 01 Feb 88 15:49:48 +0100
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: ISO8859, ANSI X3.4 and X3.26
To: Protocol Converter list <IBM7171@DEARN>,
IBM-KERMIT@CU20B.COLUMBIA.EDU,
Columbia University Center for Computing Activities
<INFO-KERMIT@CU20B.COLUMBIA.EDU>
Before taking this problem to IBM, I'd like to have a closer idea of:
1) Who is using or knows sites using X3.26, or do most sites use it
as opposed to my observations?
I. e. being on BITNET (no gateway), do you *not* see "![]|" as per the
character list below on most terminals at your site or after local
conversion to ASCII?
2) Is my list of problems complete?
3) Would your site be willing to change from X3.4 to X3.26 (or conversely).
4) Any other comment?
Read on...
IBM has introduced hardware supporting an extended EBCDIC
definition called "code page 500" conforming to the ISO 8859/1.
This extended EBCDIC is alleged to be the final solution to
multilingual character sets support. It conforms to ANSI X3.26
(1980) of which it is a superset, whereas it appears that the
most commonly used convention is ANSI X3.4 (1977).
Practical experience with international networking and using
character set dependent programs (such as compilers or binary
data encoding) shows that this discrepancy in only 4 codes can be
a real nightmare to the user (see a list below).
The question arises whether people without much need for
international character sets (mostly US users, but also IBM
itself) can be expected to undertake such a radical change soon
or even at all? Else, if it would not be wise to make things easy
and conform the multilingual codes to common international usage
before it is too late?
Specific list of X3.4 usage examples:
- IBM systems tradition itself. Only VM/SP 5 starts to consider
X3.26 with CP TERMINAL ASCIITBL VM2. But X3.4 remains the
default.
- hardware: e. g. most printers, 7171 protocol converters family.
- compilers: REXX, PL/I, Waterloo Pascal etc...
- most networks gateways converting between ASCII and EBCDIC.
- consequently, an impressive amount of EBCDIC data stored
everywhere.
- most file transfer programs.
- many other programs performing computation based on ASCII
codes:
- programs driving ASCII equipment through transparent
interfaces (e. g. 7171: TPRINT ...).
- 370 programs encoding or decoding binary data based on
EBCDIC equivalents of ASCII codes numerical values.
- ... ?
- ASCII format tape drivers.
- ... ?
The difference is particularly acute when characters codes
are used not for their graphics but for their numerical values.
In this case, the user is left without any clue why his
computation does not yield the expected results or, even if he
guesses, what conversion he must apply to achieve it correctly.
ASCII graphic ANSI 3.4 ANSI 3.26
(common use) (table 500)
21 Exclamation mark 5A 4F
5B left bracket AD 4A
5D right bracket BD 5A
7C vertical bar 4F 6A
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Feb 11 18:22:18 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 11 Feb 88 18:22:15-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 11 Feb 88 18:21:22 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 5493; Thu, 11 Feb 88 18:21:19 EST
Date: 1988 Feb 11 17:49 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Human-initiated commands to stop protocol mode
Message-id: <PEPMNT.880211.174903.B0@CFAAMP.BITNET>
It is often suggested that there be a command for the convenience of the
naive user whose micro Kermit drops out and leaves him talking straight
to the mainframe Kermit in protocol mode. Among the suggestions made by
CMS types were 'HT' and 'HX' (on the theory that naive users would be
likely to try one of those eventually). Other possibilities include
'FINISH' (actually implemented in NIH Kermit, I think) and 'STOP', the
former being intended to get Kermit out of server mode. In the default
case, with the retry limit set to 15, all it takes to stop a transfer
is a succession of 16 carriage returns, but getting out of server mode
is a little more difficult (the user would have to know how to restart
the micro Kermit or how to type '^A$ GF4'). The with this 'easy exit'
is that the mainframe Kermit has to be able to distinguish between a
possibly garbled packet (say, missing the ^A, but containing the word
'stop' in the data) and an intentional STOP command from a naive user
(say, coming through a line that usually sticks a few extra characters
on the beginning of each packet). I wouldn't want to have to try to
find a valid packet in the received byte stream before backing off and
looking for a possible 'easy exit' signal, but does anyone have a
better idea? Also, can anyone make a case for distinguishing among
different types of exit signals (e.g., 'FINISH' vs. 'STOP'), instead
of just doing whatever has to be done to get out of protocol mode as
soon as possible?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Feb 12 09:24:41 1988
Flags: 000000000000
Mail-From: SY.FDC created at 12-Feb-88 09:24:37
Date: Fri 12 Feb 88 09:24:37-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Human-initiated commands to stop protocol mode
To: PEPMNT@CFAAMP, IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: <PEPMNT.880211.174903.B0@CFAAMP.BITNET>
Message-ID: <12374140631.139.SY.FDC@CU20B.COLUMBIA.EDU>
What many other Kermits do, including DEC-20 and Unix Kermit, is look
for two Control-C's in succession. You'll never see these in protocol
mode, and they're relatively unlikely as noise, and they're fairly
intuitive to users of DEC computers, MS-DOS, CP/M, etc. - Frank
-------
From "Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>" Fri Feb 12 09:54:04 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:TUCSEB@TUCC.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 12 Feb 88 09:53:51-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 12 Feb 88 09:52:44 EST
Received: from TUCC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
7142; Fri, 12 Feb 88 09:52:43 EST
Date: Fri, 12 Feb 88 09:54 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: Re: Human-initiated commands to stop protocol mode
From "Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>" Fri Feb 12 10:13:03 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:TUCSEB@TUCC.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 12 Feb 88 10:12:43-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 12 Feb 88 10:11:21 EST
Received: from TUCC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
7292; Fri, 12 Feb 88 10:11:20 EST
Date: Fri, 12 Feb 88 10:10 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: Human-initiated commands to stop protocol mode
What I am about to do to alleviate the user "hung" in server mode case
is to use the attention key to send a series of successive breaks.
In TSO it is the usual procedure in other TSO commands to bang
on the attention key when you are in a hung condition. These
break signals would have to be successive within a certain time frame.
This would constitute a situation that would hopefully not occur in
a normal file transfer case.
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Fri Feb 12 13:15:11 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 12 Feb 88 13:14:57-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 12 Feb 88 13:13:46 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
8074; Fri, 12 Feb 88 13:13:43 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
cc: DAD@NIHCU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Fri, 12 Feb 88 13:10:28 EST
Subject: Re: Human-initiated commands to stop protocol mode
We have both FINISH and STOP in NIH TSO Kermit because FINISH is the
command to get out of server mode. It seems confusing to tell users
to use FINISH to abort a non-server mode transfer.
I believe (Dale can verify) that we require FINISH and STOP to be
the only thing in the line, to avoid the problem of them occuring in
the middle of a garbled packet.
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Fri Feb 12 13:56:58 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 12 Feb 88 13:55:33-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 12 Feb 88 13:54:08 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
8233; Fri, 12 Feb 88 13:54:07 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
cc: DAD@NIHCU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Fri, 12 Feb 88 13:33:46 EST
Subject: Re: Human-initiated commands to stop protocol mode
> What many other Kermits do, including DEC-20 and Unix Kermit, is look
> for two Control-C's in succession. You'll never see these in protocol
> mode, and they're relatively unlikely as noise, and they're fairly
> intuitive to users of DEC computers, MS-DOS, CP/M, etc. - Frank
> -------
Not very intutive to users of IBM mainframes, however.
Or to most users of IBM PCs who are not also DEC users, I think.
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Fri Feb 12 13:57:19 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 12 Feb 88 13:55:36-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 12 Feb 88 13:54:17 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
8242; Fri, 12 Feb 88 13:54:16 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
cc: DAD@NIHCU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Fri, 12 Feb 88 13:37:42 EST
Subject: Re: Human-initiated commands to stop protocol mode
> What I am about to do to alleviate the user "hung" in server mode case
> is to use the attention key to send a series of successive breaks.
> In TSO it is the usual procedure in other TSO commands to bang
> on the attention key when you are in a hung condition. These
> break signals would have to be successive within a certain time frame.
> This would constitute a situation that would hopefully not occur in
> a normal file transfer case.
Will this work through a protocol converter?
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Feb 18 15:40:00 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 18 Feb 88 15:39:47-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 18 Feb 88 15:38:51 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 2215; Thu, 18 Feb 88 15:38:50 EST
Date: 1988 Feb 18 15:29 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Canonical filespec for PDS members
Message-id: <PEPMNT.880218.152948.B0@CFAAMP.BITNET>
In my present implementation, the file header for a PDS member being
downloaded from Kermit-TSO contains just the member name. However,
it might make sense to tack on the last qualifier of the PDS name
(on the theory that it is probably the type of file). Does anyone
have strong feelings one way or the other? The present scheme is a
bit easier to implement (that's why I did it, in fact), but the
alternative isn't that much more work. To illustrate:
SEND KERMIT.ASM(IK0MAC)
now comes out with a file header of IK0MAC, but would be changed to
produce IK0MAC.ASM. On the other hand,
SEND 'SYS1.MACLIB(SAVE)'
now comes out with a file header of SAVE, but would be changed to
produce SAVE.MACLIB.
John
From "Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>" Fri Feb 19 06:49:40 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 19 Feb 88 06:49:37-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 19 Feb 88 06:48:46 EST
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
8159; Fri, 19 Feb 88 06:48:43 EST
Received: by BLIULG11 (Mailer X1.25) id 7643; Fri, 19 Feb 88 12:44:35 +0100
Date: Fri, 19 Feb 88 12:13:36 +0100
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: Canonical filespec for PDS members
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Message of 1988 Feb 18 15:29 EST from <PEPMNT@CFAAMP>
No definite feeling either way from a very casual TSO user.
But the improved canonical form seems the most natural and handy.
Most of the software extracting TSO PDS or CMS libs do that actually.
It often yields files with the right type to be directly usable.
An intermediate Kermit system storing 8-bytes filetypes will then comply.
But by no means a critical point however.
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Fri Feb 19 12:52:53 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 19 Feb 88 12:52:42-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 19 Feb 88 12:51:43 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
0743; Fri, 19 Feb 88 12:47:53 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Fri, 19 Feb 88 12:44:24 EST
Subject: Re: Canonical filespec for PDS members
We just use the member name in NIH TSO Kermit. It's a matter of
preferance, I guess. We have lots of PDSs that aren't named the TSO
way. Also, I think just using the member name is easier to explain
to users.
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Feb 19 17:22:36 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 19 Feb 88 17:22:33-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 19 Feb 88 17:21:43 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 2650; Fri, 19 Feb 88 17:21:39 EST
Date: Fri, 1988 Feb 19 17:15 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Trailing blanks
Message-id: <PEPMNT.880219.171549.B0@CFAAMP.BITNET>
It has been suggested that Kermit-370 should NOT trim off trailing
blanks from records when the record format is varying-length. That
could be made an option, but it might be simplest just to make the
change. After all, using XEDIT in CMS, you never have ANY trailing
blanks with RECFM V. I still think trailing blanks in a text file
are akin to the vermiform appendix, but maybe it isn't Kermit's
place to do the excision. Does anybody have any thoughts on the
subject?
John
From "Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>" Fri Feb 19 17:32:37 1988
Flags: 000000000000
Mail-From: SY.FDC created at 19-Feb-88 17:32:34
Date: Fri 19 Feb 88 17:32:34-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Trailing blanks
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: <PEPMNT.880219.171549.B0@CFAAMP.BITNET>
Message-ID: <12376064466.162.SY.FDC@CU20B.COLUMBIA.EDU>
There may be text files in which trailing blanks are significant. One
example is UUENCODEd files. Another might be ASCII-ized spreadsheets.
- Frank
-------
From Bruce_Jolliffe@mtsg.ubc.ca Wed Mar 2 12:17:00 1988
Flags: 000000000000
Return-Path: <@um.cc.umich.edu:Bruce_Jolliffe@mtsg.ubc.ca>
Received: from umix.cc.umich.edu by CU20B.COLUMBIA.EDU with TCP; Wed 2 Mar 88 12:16:53-EST
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA15027; Wed, 2 Mar 88 12:21:52 EST
Received: from mtsg.ubc.ca by um.cc.umich.edu via MTS-Net; Wed, 2 Mar 88 12:14:23 EST
Date: Wed, 2 Mar 88 09:13:36 PST
From: Bruce_Jolliffe@mtsg.ubc.ca
To: IBM-Kermit@cu20b.columbia.edu
Message-Id: <935393@mtsg.ubc.ca>
Subject: TSO Kermit
What is the current status on TSO Kermit, especially a version that
can handle the 7171. My files show that John was still awaiting
complete sources in November. Has there been any change since?
Any information to bring me up to date would be appreciated.
-- Bruce Jolliffe
Bruce_Jolliffe@mtsg.ubc.ca
or
USERBDJ@MTSG.BITNET
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Wed Mar 2 16:34:04 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 2 Mar 88 16:33:58-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 02 Mar 88 16:33:17 EST
Received: from CFAAMP.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
1932; Wed, 02 Mar 88 16:33:16 EST
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer X1.25) with
BSMTP id 8058; Wed, 02 Mar 88 16:06:34 EST
Date: Wed, 1988 Mar 2 15:51 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU, Bruce_Jolliffe@mtsg.ubc.ca
Subject: Re: TSO Kermit
In-reply-to: Bruce_Jolliffe@mtsg.ubc.ca message of Wed, 2 Mar 88 09:13:36 PST
Message-id: <PEPMNT.880302.155157.B0@CFAAMP.BITNET>
Kermit-TSO 4.0 is very nearly ready. It has been tested out on 7171's,
and I hope to have confirmation that it still works on 3705's any day
now. The only sticking point is interception of terminal output in
server mode, which is (to me, inexplicably) failing. I have several
volunteers who have tried out the present code with reasonable success,
so I suppose I could release a beta-test version pending resolution of
the interception problem. The complication is this: people will need
to apply updates to the composite source, both in the generic and
TSO-specific parts, so I will need to make GUPI available. I could
issue the source, but it might make sense just to put the object on
KERMSRV in binary, or maybe it's time to settle on a BOO/UNBOO format
for IBM-370-type machines.
Questions:
1. Is there any point in releasing a beta-test version through
Columbia (given that it really is still in a state of flux)?
2. What's the best way of distributing GUPI?
John
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Mar 3 18:12:57 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 3 Mar 88 18:12:53-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 03 Mar 88 18:12:01 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 1017; Thu, 03 Mar 88 18:12:00 EST
Date: 1988 Mar 3 17:51 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Mail
Message-id: <PEPMNT.880303.175136.B0@CFAAMP.BITNET>
We apparently had a connectivity crisis here for the last day, and I
fear that some mail may have been lost. If anyone sent me any mail on
the 1st or 2nd of March and hasn't received a reply, then I would
recommend sending it again. Meanwhile, I'd like to raise another
question about PDS's. Suppose the user has set the "working
directory" in Kermit-TSO to be a PDS -- what should Kermit do with a
canonical filename.type filespec that comes in with an upload? My
present algorithm simply truncates the string to 8 characters and then
converts any illegal characters (such as possibly the dot) to "#" in
order to make a legal member name, but it seems to me that it might
be better to truncate the name at the first dot (if any). Any
comments?
John
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Thu Mar 3 21:23:00 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 3 Mar 88 21:22:50-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 03 Mar 88 21:22:05 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
1863; Thu, 03 Mar 88 21:22:03 EST
To: Bruce_Jolliffe@mtsg.ubc.ca
cc: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Thu, 03 Mar 88 21:14:55 EST
Subject: Re: TSO Kermit
> What is the current status on TSO Kermit, especially a version that
> can handle the 7171. My files show that John was still awaiting
> complete sources in November. Has there been any change since?
We have been working with the University of Wisconsin
to get 7171 support into NIH TSO Kermit. We don't have
a 7171, so they are testing it.
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Sat Mar 5 15:33:22 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Sat 5 Mar 88 15:33:15-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Sat, 05 Mar 88 15:32:31 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
1460; Sat, 05 Mar 88 15:32:30 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
cc: DAD@NIHCU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Sat, 05 Mar 88 15:30:20 EST
Subject: Re: Mail
> We apparently had a connectivity crisis here for the last day, and I
> fear that some mail may have been lost. If anyone sent me any mail on
> the 1st or 2nd of March and hasn't received a reply, then I would
> recommend sending it again. Meanwhile, I'd like to raise another
> question about PDS's. Suppose the user has set the "working
> directory" in Kermit-TSO to be a PDS -- what should Kermit do with a
> canonical filename.type filespec that comes in with an upload? My
> present algorithm simply truncates the string to 8 characters and then
> converts any illegal characters (such as possibly the dot) to "#" in
> order to make a legal member name, but it seems to me that it might
> be better to truncate the name at the first dot (if any). Any
> comments?
> John
I believe that NIH TSO Kermit truncates at the dot.
It makes sense to me to do it that way.
From "Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>" Mon Mar 14 03:18:26 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 14 Mar 88 03:18:18-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 14 Mar 88 03:17:59 EST
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
7381; Mon, 14 Mar 88 03:17:58 EST
Received: by BLIULG11 (Mailer X1.25) id 7697; Mon, 14 Mar 88 09:15:55 +0100
Date: Mon, 14 Mar 1988 08:45:21 +0100
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: ASCII, ISO and which EBCDIC?
To: Info-IBMPC Digest c/o Gregory Hicks COMFLEACTS
<HICKS@WALKER-EMH.ARPA>,
IBM-KERMIT@CU20B.COLUMBIA.EDU,
Protocol Converter list <IBM7171@DEARN>,
LINKFAIL@FRULM11,
Columbia University Center for Computing Activities
<INFO-KERMIT@CU20B.COLUMBIA.EDU>
We, ASCII or EBCDIC network users must pay particular attention to character
codes standards, now extending to international. Even sites not interested in
in international characters will sooner or later hit the problem because,
albeit the situation is straight in the ASCII world with an ISO standard,
it is far from that for EBCDIC users faced to a choice of several codes whose
differences lies on a few codes, strangely enough not international.
The subject is discussed on a mailing list set up by Edwin Hart. Joining with:
TELL LISTSERV AT JHUVM SUB ISO8859 user-name
Or sending a note on BITNET to: LISTSERV AT JHUVM
Containing: SUB ISO8859 user-name
can help the community agree on a viable single code or at least help each
site in finding its most appropriate one and save everybody's time and money.
I'll soon post a summary of the problem to that list.
Please forward this note to anybody interested.
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Tue Mar 15 08:43:55 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 15 Mar 88 08:43:47-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 15 Mar 88 08:43:32 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 3664; Tue, 15 Mar 88 08:43:30 EST
Date: 1988 Mar 14 23:41 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Non-standard EBCDIC mappings
Message-id: <PEPMNT.880314.234157.B0@CFAAMP.BITNET>
>From various sources, I have gathered the following EBCDIC-to-ASCII
mappings, and I wonder if anyone can comment on them. These are
EBCDIC characters that "normally" are undefined, but are used as
extra versions of existing characters, for one reason or another.
If there are no objections, I propose to put them into the default
ETOA table someday, so please look at them carefully. Remember,
no ASCII character will get translated into one of these -- they are
just alternates. While we're at it, are there any other candidates
for semi-standard alternates?
-------------------------------------------------------------------
EBCDIC --> ASCII
hex name hex name
04 PF 14 DC4
15 NL 0A LF
34 PN 12 DC2
35 RS 13 DC3
62 2D hyphen
71 7E tilde
BE 5E caret
-------------------------------------------------------------------
John
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Tue Mar 15 12:25:19 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 15 Mar 88 12:25:08-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 15 Mar 88 12:11:58 EST
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
4788; Tue, 15 Mar 88 12:11:55 EST
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Tue, 15 Mar 88 12:11:25 EST
Subject: Re: Non-standard EBCDIC mappings
> From various sources, I have gathered the following EBCDIC-to-ASCII
> mappings, and I wonder if anyone can comment on them. These are
> EBCDIC characters that "normally" are undefined, but are used as
> extra versions of existing characters, for one reason or another.
> If there are no objections, I propose to put them into the default
> ETOA table someday, so please look at them carefully. Remember,
> no ASCII character will get translated into one of these -- they are
> just alternates. While we're at it, are there any other candidates
> for semi-standard alternates?
> -------------------------------------------------------------------
> EBCDIC --> ASCII
> hex name hex name
> 04 PF 14 DC4
> 15 NL 0A LF
> 34 PN 12 DC2
> 35 RS 13 DC3
> 62 2D hyphen
> 71 7E tilde
> BE 5E caret
> -------------------------------------------------------------------
> John
It's hard to comment without knowing the rest of the table, but
what about curly braces? There are two sets of commonly used
codes for them: C0/D0 (the 3270 codes) and 8B/9B (the TN codes).
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Tue Mar 15 15:37:33 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 15 Mar 88 15:37:28-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 15 Mar 88 15:48:09 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 6026; Tue, 15 Mar 88 15:48:07 EST
Date: Tue, 1988 Mar 15 14:49 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: EBCDIC characters again
Message-id: <PEPMNT.880315.144900.B0@CFAAMP.BITNET>
Roger Fajman pointed out that the whole ETOA table is needed for the
context, so, for those whoe don't have a copy of KERMIT-370, here is
the present version. Note that there are already some alternates in
the table, namely backslash, curly braces, and vertical stroke.
-------------------------------
ETOA DC X'00,01,02,03,00,09,00,7F,00,00,00,0B,0C,0D,0E,0F'
DC X'10,11,12,13,00,00,08,00,18,19,00,00,1C,1D,1E,1F'
DC X'00,00,00,00,00,0A,17,1B,00,00,00,00,00,05,06,07'
DC X'00,00,16,00,00,00,00,04,00,00,00,00,14,15,00,1A'
DC X'20,00,00,00,00,00,00,00,00,00,5C,2E,3C,28,2B,7C'
DC X'26,00,00,00,00,00,00,00,00,00,21,24,2A,29,3B,5E'
DC X'2D,2F,00,00,00,00,00,00,00,00,7C,2C,25,5F,3E,3F'
DC X'00,00,00,00,00,00,00,00,00,60,3A,23,40,27,3D,22'
DC X'00,61,62,63,64,65,66,67,68,69,00,7B,00,00,00,00'
DC X'00,6A,6B,6C,6D,6E,6F,70,71,72,00,7D,00,00,00,00'
DC X'00,7E,73,74,75,76,77,78,79,7A,00,00,00,5B,00,00'
DC X'00,00,00,00,00,00,00,00,00,00,00,00,00,5D,00,00'
DC X'7B,41,42,43,44,45,46,47,48,49,00,00,00,00,00,00'
DC X'7D,4A,4B,4C,4D,4E,4F,50,51,52,00,00,00,00,00,00'
DC X'5C,00,53,54,55,56,57,58,59,5A,00,00,00,00,00,00'
DC X'30,31,32,33,34,35,36,37,38,39,7C,00,00,00,00,00'
From "Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>" Thu Mar 17 08:14:09 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 17 Mar 88 08:14:00-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 17 Mar 88 08:09:09 EST
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
4297; Thu, 17 Mar 88 08:09:08 EST
Received: by BLIULG11 (Mailer X1.25) id 8197; Thu, 17 Mar 88 14:08:35 +0100
Date: Thu, 17 Mar 88 13:18:05 +0100
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: How send a VAX binary file on BITNET
To: Protocol Converter list <IBM7171@DEARN>,
TRANS-L@FINHUTC,
IBM-KERMIT@CU20B.COLUMBIA.EDU
Someone from our university is working abroad where they have a VAX connected
to EARN alias BITNET. He wishes to send files from his IBMPC to the IBMPC
of his colleague at our IBM VM/SP EARN site.
Character codes conversion being what you know, I recommended binary transfer,
the trouble-free ever-working method when the two ends are file compatible.
Text mode had failed miserably actually.
He sent his file to the VAX with Kermit. Using "No-mapping" he says.
He used MAIL/FILE/BINARY/CLASS=N ... to send it from VAX onto EARN.
I used binary mode download from the VM/SP RECEIVEd CMS file to the IBMPC.
The CMS file contained ASCII actually, but it was 80-characters fixed-length
records, each made of a line, padded with EBCDIC spaces (ASCII @),
of the original file that happened to be text.
I was expecting his n-bytes PC file to be split into arbitrarily sized
EARN records to be glued together on IBM world exit, as natural for
binary transfers.
His VAX command did not do that apparently.
Or was the fault on his VAX Kermit?
He'd be grateful for the explanation.
And I would like to know at least that of the VAX.
Thanks.
From "Stephen L. Arnold <ARNOLD%WISCPSL.BITNET@CUVMA.COLUMBIA.EDU>" Fri Mar 18 11:01:35 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 18 Mar 88 11:01:18-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 18 Mar 88 11:01:23 EST
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
9867; Fri, 18 Mar 88 11:01:19 EST
Received: by BLIULG11 (Mailer X1.25) id 7043; Fri, 18 Mar 88 16:57:40 +0100
Resent-Date: Fri, 18 Mar 88 16:39:27 +0100
Resent-From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Resent-To: Protocol Converter list <IBM7171@DEARN>,
TRANS-L@FINHUTC,
IBM-KERMIT@CU20B.COLUMBIA.EDU
Date: Thu, 17 Mar 88 12:45 CST
From: Stephen L. Arnold <ARNOLD%WISCPSL.BITNET@CUVMA.COLUMBIA.EDU>
Subject: RE: How send a VAX binary file on BITNET
To: A-PIRARD@BLIULG11
Original_To: Jnet%"A-PIRARD@BLIULG11",ARNOLD
I am ashamed of what I said. But I was only quoting what I had been told...
In fact the file sender used SEND, not MAIL, but also /PUNCH, "just to..."
I am forwarding Stephen's kind reply because several people on the nets asked
me to. BTW UUENCODE sometimes is just as risky as text.
No final word on the way back JNET RECEIVE, but it must be as simple as way to.
----------------------------Original message----------------------------
> He sent his file to the VAX with Kermit. Using "No-mapping" he says.
> He used MAIL/FILE/BINARY/CLASS=N ... to send it from VAX onto EARN.
> I used binary mode download from the VM/SP RECEIVEd CMS file to the IBMPC.
> The CMS file contained ASCII actually, but it was 80-characters fixed-length
> records, each made of a line, padded with EBCDIC spaces (ASCII @),
> of the original file that happened to be text.
You may want to try
$ SEND/FILE/BINARY/CLASS=N/NETDATA ...
--------
Hope this helps.
Regards,
Steve Arnold
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Mar 18 20:28:34 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 18 Mar 88 20:28:25-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 18 Mar 88 20:28:34 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 2716; Fri, 18 Mar 88 20:28:33 EST
Date: Fri, 1988 Mar 18 19:41 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Easy escape from protocol mode
Message-id: <PEPMNT.880318.194154.B0@CFAAMP.BITNET>
As I mentioned earlier, I have been working up a scheme whereby a user
could type a "magic" command at the mainframe to make Kermit-370 get
out of protocol mode regardless of what it is doing at the moment.
As I said before, this feature has been suggested often, and the
proposed syntax always makes obvious sense to the suggester, but most
ideas are not quite generic. The only idea I've seen that is both
generic and easily implemented is the following:
1. If Kermit-370 receives a "packet" that either has no SOH or has an
invalid checksum (or is too short), an extra test is performed
before generating the "INVALID PACKET" condition.
2. If the "packet" begins with a SOH, we fall through.
3. If the "packet" ends with the EOL character, we chop off the EOL.
4. The "packet" is translated to upper-case EBCDIC.
5. If the "packet" begins with anything but "S", we chop off the first
character -- this sounds weird, but I have evidence that at least
some front ends of the GRAPHICS class stick an extra byte on the
beginning of every packet. Until I can learn how to suppress that,
there is a certain ambiguity on where packets begin.
6. If the "packet" now consists of exactly "STOP", we jump into the
"escape from protocol" mode.
Point 5 is obviously a weakness in the filter, but this procedure
seems pretty safe to me even so. If and when there is a way of
knowing when to chop off the first character, then I think it becomes
very tight, indeed. Let me quickly review some of the other ideas
before asking for comments.
a. Use ^C^C.
Seems obvious to a DEC user, but not to IBM. Moreover, there
would have to be a carriage return anyway before the mainframe
would see it, so it wouldn't be all that obvious to DEC users.
Besides, if the user has set the padding character to ^C for
some reason, you couldn't even say that the string won't occur
naturally.
b. Use "BREAK".
Many popular modems can't transmit a break. Also, a 7171 won't
pass a break through to Kermit anyway.
c. Use HT.
Seems obvious to a CMS user, but not to anybody else.
d. Prompt the user for confirmation.
Sounds like a good idea, but it is a pain to implement. Also, it
only addresses the potential of accidental triggering.
e. Use FINISH.
This might actually be better, but I wonder if it might be
confusing to have this be the same as a server mode command.
By the way, this new feature has actually been implemented and tested,
and it is installed in the test release of Kermit-TSO 4.0 available
right now from Columbia. It is, however, undocumented, so there can
be no qualms about tinkering with it.
John
From "Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>" Wed Mar 23 05:06:53 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 05:06:36-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 23 Mar 88 05:06:42 EDT
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
2089; Wed, 23 Mar 88 05:06:40 EDT
Received: by BLIULG11 (Mailer X1.25) id 6083; Wed, 23 Mar 88 11:03:41 +0100
Date: Wed, 23 Mar 88 11:00:18 +0100
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: ASCII/ISO/which EBCDIC? summary
To: ISO8859@JHUVM,
Protocol Converter list <IBM7171@DEARN>,
Columbia University Center for Computing Activities
<INFO-KERMIT@CU20B.COLUMBIA.EDU>,
IBM-KERMIT@CU20B.COLUMBIA.EDU
Some time ago, I raised a discussion on several mailing lists
about data communication and ASCII/ISO/EBCDIC character codes. I
now realize my wording was very loose. Since then, I have had
contacts with both kind people on the nets and a very
knowledgeable IBM representative. I feel responsible to restate
the problem correctly to avoid confusion and reflect the
information, as I promised to some. I'll try to be as short as
feasible. Please join the Edwin Hart's list ISO8859 at JHUVM for
discussing details on codes etc...
We, ASCII or EBCDIC network users must pay particular attention
to character codes standards, now extending to international.
Even sites not interested in international characters will sooner
or later hit the problem because, albeit the situation is well
defined in the ASCII world with an (often overlooked) ISO
standard, it is far from that for EBCDIC users faced to a choice
among several new "codes pages" whose differences lie on
the positions of a few characters, strangely enough not the
extended ones. The era of data communication raises an urgent
need for a single character codes standard.
BITNET apparently had found one. It is now silently tossed up by
these new codes sets. We had been proposed "table 500" (below)
without warning. And it turns out that our IBM representatives
ignored the de-facto coherence of BITNET.
The ISO have produced a considerable work in defining the
graphics necessary for each country and assigned them codes. For
latin based alphabets, this yielded the ISO 8859/1 = ANSI
X3.134.2 = ECMA 94, which is wisely a superset of ISO 646 = ANSI
X3.4, the well known ASCII.
ISO 8859/1 assigns character graphics to the A0-FF codes range.
The range 80-9F is unassigned and can be used for special
purposes in 8-bit storage and transmission. But it is kept free
in order to not interfere with control codes 00-1F during 7-bit
transmission in compatibility with the ISO 2022, alternating
between the two sets with the SI/SO control codes.
Nobody questions the value of ISO and everything so far looks
ideal to avoid a new Babel for the largest part of the world.
IBM, in conforming EBCDIC to ISO, at least strongly claims that
any EBCDIC extension shall contain exactly the ISO characters
set, in order to make a revertible translation always possible,
but allows variations in which particular code is assigned to an
ISO character. This idea is also the origin of the IBM PC code
page 850 ASCII extension and of the IBM mainframes multiple
CECP's (country extended code pages) EBCDIC extensions.
Why multiple? because:
- Compatibility with previous codes rules IBM evolution, e. g.
code page 850 contains the ISO characters, but most of the former
cp 437 stay in place (missing ones expel graphic characters).
- The eighty-some-characters restricted former EBCDIC did not
contain all the X3.4 ASCII characters and conversely. (see IBM
publication GX20-1850, the yellow book, pp 9-12 second column,
let's call it simply "EBCDIC" and the third column "TN-chain").
- Some of those EBCDIC codes not in ASCII are vital for
programming or using IBM systems and had to be produced from
ASCII terminals.
- ASCII/EBCDIC translation tables were built to accommodate these
needs instead of mapping equivalent characters, varied over time
and systems, and are different from those used in file transfers.
- Habits, software and data built up to a huge amount.
- ISO now defines the missing EBCDIC characters.
- It is finally embarrassing to define a single extended EBCDIC
and the proposed extensions tend to match the terminal tables
rather than the more stable file transfer ones.
Never mind, says IBM. As long as a particular EBCDIC extension
conforms to ISO, GDDM will take care of that. And we're off on
the grounds that any conforming extension will do. These
extensions are called "Code Pages XXXXX" (cpXXX for short). The
most prominent offerings are cp500 and cp037, more of them below,
but others exist in order to best fit existing installation use.
GDDM is an IBM product that will interface with the operating
system, the I/O devices and the application programs in order to
(for our concern) convert one particular code page to another.
They say GDDM will use cp500 internally as the code page to and
>From which conversion will be made.
I simply don't believe in (that function of) GDDM because it can
only be effective when everything will have been converted to
that interface. Networking is a crying example. What could GDDM
do to a file (they're supposed to be code-tagged) received from a
network site that does not use it? My opinion is that we have to
settle on a single code NOW because the sooner the better, at
least for networking, but also the recommended one. Which one?
Practically, that making the most people happy certainly. And
BITNET users are numerous. Other reasons favour the present code:
- It must be compatible with former EBCDIC.
- The compatibility with the former ASCII/EBCDIC translation is
vital, because it often gets involved in conversions whose result
is used as data critical for computation rather than "good
looking" humanly readable text.
BTW, I think that storing ASCII data on BITNET servers is best
done in "binary" format (ASCII files streams split into "records"
of arbitrary length, best 128). So bad for docs direct EBCDIC-
wise readability.
cp500 is simply not compatible with the former EBCDIC: it carries
on a strange habit of using exclamation marks for what a compiler
understands as a vertical bar and such things. I am told it is
recommended to European because GDDM uses it internally (???) and
on the ground of previous codes compatibility, but it does not
preserve their accented letters :-)
cp037 is EBCDIC compatible and recommended to US and Canadian.
Both are not compatible with what I believe is the prominent
ASCII/EBCDIC translation, that of the 7171, VM, Kermit, BITNET
gateways, ASCII tapes conversion etc... and, as I am told by IBM,
the 3708 and 3275.
- cp037 puts brackets at BA and BB and cp500 puts them at 4A and
5A whereas traditional conversion from ASCII is to the positions
in the TN chain AD and BD.
- cp500 additionally deviates, because of its EBCDIC
discrepancies, for ASCII "exclamation mark" and "vertical bar".
- the ASCII "circumflex" uniformly translated to EBCDIC "not
sign" 5F. There was no circumflex in EBCDIC, but its new ISO-
based definition threatens the former conversion.
- whereas the ASCII backslash is often used to give the cent
sign in terminal mode, file transfers keep the EBCDIC backslash.
cp037 and cp500 differ in only 7 characters.
VM/SP 5 uses two TTY conversions: TERMINAL ASCIITBL VM1 or VM2.
VM1, the default, is "traditional" (037 with TN chain brackets)
and matches no code page. VM2 corresponds to cp500, but the
brochure GC24-5328 explains that by using the 037 graphics. To
add to the confusion the explanation refers to ANSI X3.4 and
X3.26 respectively.
My experience shows that BITNET is working perfectly as it
stands. Are we going to let a chance messing up all that?
And it looks like defining another code page would not be hard to
get from IBM and that there is "nothing defined yet as
communication standard". I think that we should strongly consider
requiring another code page that matches BITNET and that it
become the standard.
In summary:
Adopting CP037 with brackets at AD BD is easy. What I find more
serious is the "ASCII circumflex" to "EBCDIC not" conversion that
makes no theoretical sense now both characters are defined in the
other set, but is is presently used as such in many character
encoded stored binary files.
I close this discussion on these lists, it now belongs to the
list ISO8859.
From "Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>" Wed Mar 23 06:36:48 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 06:36:37-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 23 Mar 88 06:36:37 EDT
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
2224; Wed, 23 Mar 88 06:36:36 EDT
Received: by BLIULG11 (Mailer X1.25) id 7865; Wed, 23 Mar 88 12:35:32 +0100
Date: Wed, 23 Mar 88 12:21:37 +0100
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: Non-standard EBCDIC mappings
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Message of 1988 Mar 14 23:41 EST from <PEPMNT@CFAAMP>
Had the situation been well defined, I would have suggested implementing
the full ISO character set translation in the optional 8-bit table.
But with various EBCDIC versions and pure ISO itself being rarely used, even
on the IBM PC, I think the best is to wait and see.
The present IBM Kermit translation table is probably what everyone silently
wishes as "the" standard EBCDIC. Let us keep from encouraging exotic ones
and leave the door open for compatible extension.
From Bruce_Jolliffe@mtsg.ubc.ca Wed Mar 23 15:05:12 1988
Flags: 000000000000
Return-Path: <@um.cc.umich.edu:Bruce_Jolliffe@mtsg.ubc.ca>
Received: from umix.cc.umich.edu by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 15:04:53-EST
Received: by umix.cc.umich.edu (5.54/umix-2.0)
id AA20587; Wed, 23 Mar 88 15:08:57 EST
Received: from MTSG.UBC.CA by um.cc.umich.edu via MTS-Net; Wed, 23 Mar 88 14:54:46 EST
Date: Wed, 23 Mar 88 11:53:14 PST
From: Bruce_Jolliffe@mtsg.ubc.ca
To: IBM-Kermit@cu20b.Columbia.edu, info-kermit@cu20b.Columbia.edu,
iso8859%jhuvm@umix.cc.umich.edu, ibm7171%dearn@umix.cc.umich.edu
Message-Id: <972890@mtsg.ubc.ca>
Subject: ISO (ASCII) to EBCDIC Standards
As one of several MTS sites that have recently adopted an ISO 8859 -
Code Page 37 translation table I found your note on the adoption
standard ASCII-EBCDIC tables interesting. We mapped each ISO graphic
to its corresponding EBCDIC graphic. Thus we mapped the EBCDIC
logical not (5F) into the ISO logical not (AC). Similarily we mapped
the ISO circumflex into the EBCDIC circumflex (B0) and the ISO tilde
(7F) into the EBCDIC tilde (A1).
As you might guess the two thorniest issues over the IBM Code Page 37
was the square brackets and the logical not. As previously noted, in
another message, the square brackets in Code Page 37 are moved from
their traditional TN positions of AD and BD to BA and BB respectively.
The second issue concerned the logical not. At most of the MTS sites
we had traditionally mapped EBCDIC logical nots into tildes. After
much debate we decided it made no sense to do cross graphics mapping
and decided to go with a graphic to graphic mapping.
Many of the MTS sites provide general access to their IBM mainframes
exclusively through ASCII terminals. Thus many applications that
used the logical not as an input character had to be changed to accept
the EBCDIC tilde (we had previously mapped EBCDIC logical nots to
ASCII tildes).
Prior to the conversion there was a lot apprehension about changing to
the newer standard and we prepared for the worse. Now the conversion
has been done, and we can look back the conversion was more of a nuisance
rather than a major hassle. Granted it was not free, but with a
reasonable amount of preparation and saturation publicity the conversion
can be relatively painless.
The installations that have made this change include the University
of Michigan, Renssellaer Polytechnic Institute, University of
British Columbia, Simon Fraser University, University of Newcastle,
Durham University, and Wayne State University. The University of
Alberta, the other remaining major MTS site, is due to convert this
summer.
Bruce Jolliffe
Computing Centre
University of British Columbia
Bruce_Jolliffe@mtsg.ubc.ca
or
USERBDJ@UBCMTSG.BITNET
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Wed Mar 23 15:47:48 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 15:47:40-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 23 Mar 88 15:47:54 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 3033; Wed, 23 Mar 88 15:47:52 EDT
Date: Wed, 1988 Mar 23 15:42 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: New "Easy escape" feature
Message-id: <PEPMNT.880323.154243.B0@CFAAMP.BITNET>
Well, there was no reaction to the described implementation. Does
that mean that no one would prefer FINISH to STOP as the key word?
That no one has any objections to the implementation?
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Apr 11 16:42:56 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 11 Apr 88 15:42:49-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 11 Apr 88 15:41:04 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 8781; Mon, 11 Apr 88 15:41:00 EDT
Date: Mon, 1988 Apr 11 15:18 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Sequence numbers
Message-id: <PEPMNT.880411.151847.B0@CFAAMP.BITNET>
Given that it would be nice to have Kermit ignore the sequence numbers
in numbered TAKE files, is it reasonable to adopt the TSO model of line
numbers in the generic Kermit-370? What I would propose is simply to
ignore the last 8 bytes of any F/80 record if they're all numeric or the
first 8 of any varying-length record (again, if they're all numeric)?
CMS, for example, doesn't believe in line numbers for V files, but
surely it wouldn't hurt to test each record anyway. Can anyone think of
any drawback to this scheme?
John
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon Apr 11 17:12:52 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 11 Apr 88 16:12:45-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 11 Apr 88 16:11:06 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 8889; Mon, 11 Apr 88 16:11:04 EDT
Date: Mon, 1988 Apr 11 16:00 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Line numbers again
Message-id: <PEPMNT.880411.160057.B0@CFAAMP.BITNET>
In case I didn't make it perfectly clear, my question about line numbers
referred to TAKE files being executed by Kermit-370. The broader context
of the question is this: is there any system on an IBM/370 that would
have system commands beginning with 8 digits? I'm going to assume that
there will never be any Kermit subcommands like that. I realize that
it's possible to have a private EXEC under CMS with a name consisting of
8 digits, but I don't think that's much of a problem.
John
From "Vace Kundakci <VVVCU@CUVMA>" Mon Apr 11 21:30:24 1988
Flags: 000000000000
Return-Path: <VVVCU@CUVMA.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 11 Apr 88 20:30:17-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 11 Apr 88 20:28:40 EDT
Received: by CUVMA (Mailer X1.25) id 9260; Mon, 11 Apr 88 20:28:38 EDT
Date: Mon, 11 Apr 88 20:28 EDT
From: Vace Kundakci <VVVCU@CUVMA>
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: Sequence numbers; "John F. Chandler" <PEPMNT@CFAAMP>
In-Reply-To: Your msg of : Mon, 11 Apr 88 15:42:13 EDT
It is welcome!
/Vace
------
From "Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>" Tue Apr 12 10:51:50 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:TUCSEB@TUCC.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 09:51:45-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 09:50:09 EDT
Received: from TUCC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
0140; Tue, 12 Apr 88 09:50:07 EDT
Date: Tue, 12 Apr 88 09:50 EDT
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: Sequence numbers
> Given that it would be nice to have Kermit ignore the sequence numbers
> in numbered TAKE files, is it reasonable to adopt the TSO model of line
> numbers in the generic Kermit-370? What I would propose is simply to
> ignore the last 8 bytes of any F/80 record if they're all numeric or the
> first 8 of any varying-length record (again, if they're all numeric)?
> CMS, for example, doesn't believe in line numbers for V files, but
> surely it wouldn't hurt to test each record anyway. Can anyone think of
> any drawback to this scheme?
> John
This certainly seems like a reasonable thing to do.
Steve
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Tue Apr 12 14:59:48 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 13:59:44-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 13:58:10 EDT
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
0740; Tue, 12 Apr 88 13:58:07 EDT
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Tue, 12 Apr 88 13:57:52 EDT
Subject: Re: Sequence numbers
> Given that it would be nice to have Kermit ignore the sequence numbers
> in numbered TAKE files, is it reasonable to adopt the TSO model of line
> numbers in the generic Kermit-370? What I would propose is simply to
> ignore the last 8 bytes of any F/80 record if they're all numeric or the
> first 8 of any varying-length record (again, if they're all numeric)?
> CMS, for example, doesn't believe in line numbers for V files, but
> surely it wouldn't hurt to test each record anyway. Can anyone think of
> any drawback to this scheme?
> John
WYLBUR line numbers are not all numeric. They also contain
spaces and a decimal point.
From "Thomas Kern <BOBLITT%VTVM1.BITNET@CUVMA.COLUMBIA.EDU>" Wed Apr 13 10:42:47 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:BOBLITT@VTVM1.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 13 Apr 88 09:42:40-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 13 Apr 88 09:40:53 EDT
Received: from VTVM1.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
1720; Wed, 13 Apr 88 09:40:51 EDT
Received: by VTVM1 (Mailer X1.25) id 0621; Wed, 13 Apr 88 09:40:23 EDT
Date: Wed, 13 Apr 88 09:35:41 EDT
From: Thomas Kern <BOBLITT%VTVM1.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: Sequence numbers
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Message of Mon, 11 Apr 88 15:42:13 EDT from <PEPMNT@CFAAMP>
The default serialization in CMS is the first three characters of
filename follwed by 5 digits. I think if you want to get around
sequence numbers simply use only columns 1-72 of F/80 files and first
token of V/* files if the token is numeric. This should only catch those
people who use all numeric CMS exec names.
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Thu Apr 21 18:24:19 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 21 Apr 88 17:24:16-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 21 Apr 88 17:24:15 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 7839; Thu, 21 Apr 88 17:24:13 EDT
Date: Thu, 1988 Apr 21 17:07 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Record truncation/folding
Message-id: <PEPMNT.880421.170754.B0@CFAAMP.BITNET>
> From: Steve Blankinship <TUCSEB@TUCC>
>
> My Kermit-TSO presently truncates RECFM=F and gives an error on
> RECFM=V if the records exceed LRECL. I have gotten a complaint from
> the EPA about the RECFM=F truncation so I plan to change it to give
> the same error message that RECFM=V gives, i.e., "Record length exceeds
> LRECL". I believe this is the best thing to do because of the nature
> of data in TSO. Since it consists of records and is not a "stream"
> of data neither truncation nor folding is satisfactory to the user.
> He wants the data to be in records just like they were before they
> were transmitted. He also doesn't want the records "chopped off".
> This has been a strong complaint from EPA. Therefore my suggestion
> would be not to allow records to be either folded or truncated in
> either of the RECFM cases but to give an error message instead.
This has become a hot topic. Kermit on IBM mainframes has traditionally
either truncated or folded, and no one has ever complained to me about
that, but I can certainly understand a user getting upset about getting
a file that isn't exactly what was sent. Is this another case where
there should be an option the user must set one way or the other, or
would people be satisfied to have a transfer halt if records would have
to be mangled in one of these ways? Bear in mind that binary files are
a separate issue from text files, so comments should be clearly marked.
John
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Thu Apr 21 20:22:27 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 21 Apr 88 19:21:40-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 21 Apr 88 19:21:29 EDT
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
7981; Thu, 21 Apr 88 19:21:27 EDT
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
cc: DAD@NIHCU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Thu, 21 Apr 88 19:21:24 EDT
Subject: Re: Record truncation/folding
In NIH TSO Kermit we started out truncating text files for both
RECFM=F and V, but changed to folding at the request of some users.
These users had fixed length random access text files that were not
delimited by CR-LF. So far I'm not aware of any complaints about
folding instead of truncating. Of course, our default LRECL is
quite long (500 data bytes), so users rarely get folding unless they
have reset the LRECL. It seems to me that it is better to complete
a file transfer if possible. Should one extra long line cause a 500
KB file transfer to abort with 10 KB remaining? I don't think so.
It would make sense to put a warning message into the status. I'm
not sure if we do this now. I do wish there were provision in
Kermit protocol for sending warning messages to the other Kermit.
Of course we have always folded binary files. I don't think
anything else makes sense.
From "Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>" Fri Apr 22 05:45:17 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 22 Apr 88 04:45:01-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 22 Apr 88 04:44:53 EDT
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
8380; Fri, 22 Apr 88 04:44:52 EDT
Received: by BLIULG11 (Mailer X1.25) id 5367; Fri, 22 Apr 88 10:42:49 +0200
Date: Fri, 22 Apr 88 10:17:59 +0200
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: Record truncation/folding
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Message of Thu, 21 Apr 88 17:25:28 EDT from <PEPMNT@CFAAMP>
>> From: Steve Blankinship <TUCSEB@TUCC>
>>
>> My Kermit-TSO presently truncates RECFM=F and gives an error on
>> RECFM=V if the records exceed LRECL. I have gotten a complaint from
>> the EPA about the RECFM=F truncation so I plan to change it to give
>> the same error message that RECFM=V gives, i.e., "Record length exceeds
>> LRECL". I believe this is the best thing to do because of the nature
>> of data in TSO. Since it consists of records and is not a "stream"
>> of data neither truncation nor folding is satisfactory to the user.
>> He wants the data to be in records just like they were before they
>> were transmitted. He also doesn't want the records "chopped off".
>> This has been a strong complaint from EPA. Therefore my suggestion
>> would be not to allow records to be either folded or truncated in
>> either of the RECFM cases but to give an error message instead.
>
>This has become a hot topic. Kermit on IBM mainframes has traditionally
>either truncated or folded, and no one has ever complained to me about
>that, but I can certainly understand a user getting upset about getting
>a file that isn't exactly what was sent. Is this another case where
>there should be an option the user must set one way or the other, or
>would people be satisfied to have a transfer halt if records would have
>to be mangled in one of these ways? Bear in mind that binary files are
>a separate issue from text files, so comments should be clearly marked.
> John
Text files:
Nobody complained about mainframe-received fixed files truncation
problems here. But that's maybe because, after discovering
their data is truncated, the users feel guilty for not having set
the proper LRECL first hand and don't feel it worth the fuss.
Truncating data does not make much sense (padding does). Aborting
transfer with an error packet would probably save users the time
discovering or processing the wrong data.
Variable format should imply a LRECL high enough for most cases.
Binary files:
I see nothing else than folding. I default to variable 128 when a
user elects upload binary mode. This both keeps files true lengths
and fits a conventional size based on the smallest (and CP/M)
sector size. If truncation were ever to be invented, it would
have to be post-folding.
Both:
If truncating were to be found of some use, shouldn't it be
allowed only by the setting of MARGINS, as the reverse of what we
already have for 370-send?
Andr).
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Apr 22 17:43:40 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 22 Apr 88 16:43:30-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 22 Apr 88 16:42:52 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 9268; Fri, 22 Apr 88 16:42:50 EDT
Date: 1988 Apr 22 16:23 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Fold vs. Truncate
Message-id: <PEPMNT.880422.162342.B0@CFAAMP.BITNET>
As I suspected, the viewpoints vary widely. More importantly, the two
opposite scenarios provide convincing reasons not to stick to a single
routine method: (A) suppose the user wants an intact file, but virtually
every line gets folded or truncated, or (B) suppose that user is willing
to repair any minor chopping, but the transfer halts after 99% of a long
transfer. It wouldn't be very hard to come up with a set of options,
and the only drawback is that there would be yet another item on the
nearly full screen resulting from SHOW ALL. How about the following:
SET EXCESS (FOLD | TRUNC | HALT)
The behavior of this setting would be different under different systems.
For example, under CMS, the LRECL is ignored for RECFM=V files, so the
option would only apply to records exceeding 65535 bytes. CMS RECFM=F
files, however, and all TSO files would be affected. Binary files
have to get special treatment, of course -- they are always folded, no
matter what. V-binary and D-binary files, though, are an intermediate
case -- they are, in a sense, being folded (in a context-dependent way),
and that wouldn't ever change, but they could also be subject to the
same logic as regards TRUNC vs. HALT (if you don't understand how a
file that's being folded can also need truncation, read IK0KER.DOC).
How does this sound?
John
From "Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>" Fri Apr 22 18:16:45 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:TUCSEB@TUCC.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 22 Apr 88 17:16:39-EST
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 22 Apr 88 17:16:29 EDT
Received: from TUCC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
9354; Fri, 22 Apr 88 17:16:25 EDT
Date: Fri, 22 Apr 88 17:15 EDT
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: Steve Blankinship <TUCSEB%TUCC.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Re: Fold vs. Truncate
> As I suspected, the viewpoints vary widely. More importantly, the two
> opposite scenarios provide convincing reasons not to stick to a single
> routine method: (A) suppose the user wants an intact file, but virtually
> every line gets folded or truncated, or (B) suppose that user is willing
> to repair any minor chopping, but the transfer halts after 99% of a long
> transfer. It wouldn't be very hard to come up with a set of options,
> and the only drawback is that there would be yet another item on the
> nearly full screen resulting from SHOW ALL. How about the following:
> SET EXCESS (FOLD | TRUNC | HALT)
> The behavior of this setting would be different under different systems.
> For example, under CMS, the LRECL is ignored for RECFM=V files, so the
> option would only apply to records exceeding 65535 bytes. CMS RECFM=F
> files, however, and all TSO files would be affected. Binary files
> have to get special treatment, of course -- they are always folded, no
> matter what. V-binary and D-binary files, though, are an intermediate
> case -- they are, in a sense, being folded (in a context-dependent way),
> and that wouldn't ever change, but they could also be subject to the
> same logic as regards TRUNC vs. HALT (if you don't understand how a
> file that's being folded can also need truncation, read IK0KER.DOC).
> How does this sound?
> John
I think that you have a good solution. The user (or installation
via the system KERMINI file) can choose a default if they wish.
Steve
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Mon May 2 15:25:23 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 2 May 88 13:25:17-EDT
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 02 May 88 13:24:47 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMA.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 9175; Mon, 02 May 88 13:24:44 EDT
Date: 1988 May 2 13:03 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: LRECL
Message-id: <PEPMNT.880502.130339.B0@CFAAMP.BITNET>
In implementing Kermit-370 file attributes for TSO I seized the chance
to do something "right" (i.e., generic) where OS/360 and its successors
right down through TSO have always had a weak point. I refer to the
LRECL, which must include an extra four bytes for varying-length records
to hold the RDW. I, for one, have always considered that a misfeature
(an ILLOGICAL record length), and I purposely kept the generic name of
LRECL for the Kermit-370 attribute which defines the maximum length of
DATA in each record. The documentation, of course, points out the
difference in usage, and I have received only one complaint to date,
but I don't want to insist on a position that will cause undue confusion
among Kermit users. Thus, I solicit opinions (not just from MVS/TSO
people) on a matter of philosophy: is it better to implement logically
or to follow the conventions of the operating system?
John
From "Roger Fajman <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>" Mon May 2 16:16:10 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:RAF@NIHCU.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 2 May 88 14:16:05-EDT
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 02 May 88 14:15:35 EDT
Received: from NIHCU.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
9314; Mon, 02 May 88 14:15:33 EDT
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
From: "Roger Fajman" <RAF%NIHCU.BITNET@CUVMA.COLUMBIA.EDU>
Date: Mon, 02 May 88 14:15:19 EDT
Subject: Re: LRECL
Better to stick with the operating system conventions.
From "Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>" Fri May 27 15:30:50 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 27 May 88 13:30:12-EDT
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 27 May 88 13:30:51 EDT
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
9868; Fri, 27 May 88 13:30:40 EDT
Received: by BLIULG11 (Mailer X1.25) id 0197; Fri, 27 May 88 19:24:18 +0200
Date: Fri, 27 May 1988 19:20:18 +0200
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: c'mon to the pictures
To: ISO8859@JHUVM,
Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>,
IBM-KERMIT@CU20B.COLUMBIA.EDU,
Paul Placeway <PAUL@TUT.CIS.OHIO-STATE.EDU>,
Matthias Aebi <K116430@CZHRZU1A>
Well, several people were wishing for the ISO 8859/1 standard. I
don't have the official document myself, and I don't know what it
contains in addition to a graphics to codes assignment. But I
have collected several machine readable documents and papers, all
>From official sources, IBM, SEAS, SHARE... And I had to cross-
check them (what they did) and produce documentation to use here.
A couple of hours of Forth programming got me to stir the
ingredients into an ISO cake. And as a picture is worth a
thousand words, I've stuck them in as well, no cinemascope but
enough to roughly materialize the graphic description in a
reasonably sized file.
Some remarks are needed:
- The textual description is somewhat different from a seemingly
more ISO like paper, sorry.
- IBM PC 437 is based on the older PC character set. It does not
conform to ISO, but IBM has defined a translation table anyway.
- IBM PC 850 is their new code page whose reason for living is to
conform to ISO.
- EBCDIC CECP 037 and 500 are IBM mainframe "Country Extended
Code Pages" conforming to ISO. 037 is mainly used in the States,
500 is boasting an "international" label which could simply mean
non-US just like for the Commodore 64 (funny the way they have
the same problems with character codes).
- 037 and 500 differ only for the translation of ISO 21, 5B, 5D,
5E, 7C, A2, and AC. 037 is EBCDIC compatible, 500 is not.
- KERM EBCDIC is 370-Kermit translation, very common on BITNET,
extended to 8-bit with 037 or 500 equivalently with two of their
characters relodged. It differs from 037 for the characters
below. I changed the translation of 7F to conform to ISO however.
It puts the brackets where many people like them, but sadly
reverses circumflex and not.
ISO 037 Kermit-370 EBCDIC (and several others)
5B BA AD ISO left bracket
5D BB BD ISO right bracket
5E B0 5F ISO circumflex to 037 not, ugly but so ...
7F FF FF was 07, should be changed to FF
and to compensate and keep a one to one translation:
A8 BD BB ISO diaeresis
AC 5F B0 ISO not to 037 circumflex, just as ugly ...
DD AD BA capital Y acute accent
Andre'.
--------------------------------------------------------------------------
| | | ISO |IBM |IBM |EBC |EBC |EBC | |
hex | ISO 8859/1 | | |PC |PC |DIC |DIC |DIC |MORE|
seq | Graphic Description | GCID |8859/1 |CP |CP |CECP|CECP|KERM|????|
| | | LIST |437 |850 |037 |500 |370 | |
====+=======================+======+=======+====+====+====+====+====+====+
00 | CC / NULL | | 00/00 | 00 | 00 | 00 | 00 | 00 |
---------------------------------------------------------------------
01 | CC / SOH | | 00/01 | 01 | 01 | 01 | 01 | 01 |
---------------------------------------------------------------------
02 | CC / STX | | 00/02 | 02 | 02 | 02 | 02 | 02 |
---------------------------------------------------------------------
03 | CC / ETX | | 00/03 | 03 | 03 | 03 | 03 | 03 |
---------------------------------------------------------------------
04 | CC / EOT | | 00/04 | 04 | 04 | 37 | 37 | 37 |
---------------------------------------------------------------------
05 | CC / ENQ | | 00/05 | 05 | 05 | 2D | 2D | 2D |
---------------------------------------------------------------------
06 | CC / ACK | | 00/06 | 06 | 06 | 2E | 2E | 2E |
---------------------------------------------------------------------
07 | CC / BEL | | 00/07 | 07 | 07 | 2F | 2F | 2F |
---------------------------------------------------------------------
08 | CC / BS | | 00/08 | 08 | 08 | 16 | 16 | 16 |
---------------------------------------------------------------------
09 | CC / HT, PT | | 00/09 | 09 | 09 | 05 | 05 | 05 |
---------------------------------------------------------------------
0A | CC / LF | | 00/10 | 0A | 0A | 25 | 25 | 25 |
---------------------------------------------------------------------
0B | CC / VT | | 00/11 | 0B | 0B | 0B | 0B | 0B |
---------------------------------------------------------------------
0C | CC / FF | | 00/12 | 0C | 0C | 0C | 0C | 0C |
---------------------------------------------------------------------
0D | CC / CR | | 00/13 | 0D | 0D | 0D | 0D | 0D |
---------------------------------------------------------------------
0E | CC / LS1 (SO) | | 00/14 | 0E | 0E | 0E | 0E | 0E |
---------------------------------------------------------------------
0F | CC / LS0 (SI) | | 00/15 | 0F | 0F | 0F | 0F | 0F |
---------------------------------------------------------------------
10 | CC / DLE | | 01/00 | 10 | 10 | 10 | 10 | 10 |
---------------------------------------------------------------------
11 | CC / DC1, SBA | | 01/01 | 11 | 11 | 11 | 11 | 11 |
---------------------------------------------------------------------
12 | CC / DC2, EUA | | 01/02 | 12 | 12 | 12 | 12 | 12 |
---------------------------------------------------------------------
13 | CC / DC3, IC | | 01/03 | 13 | 13 | 13 | 13 | 13 |
---------------------------------------------------------------------
14 | CC / DC4, RA | | 01/04 | F4 | 14 | 3C | 3C | 3C |
---------------------------------------------------------------------
15 | CC / NAK | | 01/05 | F5 | 15 | 3D | 3D | 3D |
---------------------------------------------------------------------
16 | CC / SYN | | 01/06 | 16 | 16 | 32 | 32 | 32 |
---------------------------------------------------------------------
17 | CC / ETB | | 01/07 | 17 | 17 | 26 | 26 | 26 |
---------------------------------------------------------------------
18 | CC / CAN | | 01/08 | 18 | 18 | 18 | 18 | 18 |
---------------------------------------------------------------------
19 | CC / EM | | 01/09 | 19 | 19 | 19 | 19 | 19 |
---------------------------------------------------------------------
1A | CC / SUB | | 01/10 | 1A | 1A | 3F | 3F | 3F |
---------------------------------------------------------------------
1B | CC / ESC | | 01/11 | 1B | 1B | 27 | 27 | 27 |
---------------------------------------------------------------------
1C | CC / IS4 | | 01/12 | 1C | 1C | 1C | 1C | 1C |
---------------------------------------------------------------------
1D | CC / IS3 | | 01/13 | 1D | 1D | 1D | 1D | 1D |
---------------------------------------------------------------------
1E | CC / IS2 | | 01/14 | 1E | 1E | 1E | 1E | 1E |
---------------------------------------------------------------------
1F | CC / IS1 | | 01/15 | 1F | 1F | 1F | 1F | 1F |
---------------------------------------------------------------------
20 | space | SP01 | 02/00 | 20 | 20 | 40 | 40 | 40 |
---------------------------------------------------------------------
---------------------------------------------------------------------
21 | exclamation point | SP02 | 02/01 | 21 | 21 | 5A | 4F | 5A |
---------------------------------------------------------------------
XX
XXXX
XXXX
XX
XX
XX
---------------------------------------------------------------------
22 | quotation marks | SP04 | 02/02 | 22 | 22 | 7F | 7F | 7F |
---------------------------------------------------------------------
XX XX
XX XX
X X
---------------------------------------------------------------------
23 | number sign | SM01 | 02/03 | 23 | 23 | 7B | 7B | 7B |
---------------------------------------------------------------------
XX XX
XX XX
XXXXXXX
XX XX
XXXXXXX
XX XX
XX XX
---------------------------------------------------------------------
24 | dollar sign | SC03 | 02/04 | 24 | 24 | 5B | 5B | 5B |
---------------------------------------------------------------------
XX
XXXXX
XX
XXXX
XX
XXXXX
XX
---------------------------------------------------------------------
25 | percent sign | SM02 | 02/05 | 25 | 25 | 6C | 6C | 6C |
---------------------------------------------------------------------
XX XX
XX XX
XX
XX
XX XX
XX XX
---------------------------------------------------------------------
26 | ampersand | SM03 | 02/06 | 26 | 26 | 50 | 50 | 50 |
---------------------------------------------------------------------
XXX
XX XX
XXX
XXX XX
XX XXX
XX XX
XXX XX
---------------------------------------------------------------------
27 | apostrophe | SP05 | 02/07 | 27 | 27 | 7D | 7D | 7D |
---------------------------------------------------------------------
XX
XX
XX
---------------------------------------------------------------------
28 | left parenthesis | SP06 | 02/08 | 28 | 28 | 4D | 4D | 4D |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
XX
XX
---------------------------------------------------------------------
29 | right parenthesis | SP07 | 02/09 | 29 | 29 | 5D | 5D | 5D |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
XX
XX
---------------------------------------------------------------------
2A | asterisk | SM04 | 02/10 | 2A | 2A | 5C | 5C | 5C |
---------------------------------------------------------------------
XX XX
XXXX
XXXXXXXX
XXXX
XX XX
---------------------------------------------------------------------
2B | plus sign | SA01 | 02/11 | 2B | 2B | 4E | 4E | 4E |
---------------------------------------------------------------------
XX
XX
XXXXXX
XX
XX
---------------------------------------------------------------------
2C | comma | SP08 | 02/12 | 2C | 2C | 6B | 6B | 6B |
---------------------------------------------------------------------
XX
XX
XX
---------------------------------------------------------------------
2D | hyphen, minus sign | SP10 | 02/13 | 2D | 2D | 60 | 60 | 60 |
---------------------------------------------------------------------
XXXXXX
---------------------------------------------------------------------
2E | period | SP11 | 02/14 | 2E | 2E | 4B | 4B | 4B |
---------------------------------------------------------------------
XX
XX
---------------------------------------------------------------------
2F | slash | SP12 | 02/15 | 2F | 2F | 61 | 61 | 61 |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
XX
X
---------------------------------------------------------------------
30 | zero | ND10 | 03/00 | 30 | 30 | F0 | F0 | F0 |
---------------------------------------------------------------------
XXX
XX XX
XX XX
XX X XX
XX XX
XX XX
XXX
---------------------------------------------------------------------
31 | one | ND01 | 03/01 | 31 | 31 | F1 | F1 | F1 |
---------------------------------------------------------------------
XX
XXX
XX
XX
XX
XX
XXXXXX
---------------------------------------------------------------------
32 | two | ND02 | 03/02 | 32 | 32 | F2 | F2 | F2 |
---------------------------------------------------------------------
XXXXX
XX XX
XX
XXX
XX
XX XX
XXXXXXX
---------------------------------------------------------------------
33 | three | ND03 | 03/03 | 33 | 33 | F3 | F3 | F3 |
---------------------------------------------------------------------
XXXXX
XX XX
XX
XXXX
XX
XX XX
XXXXX
---------------------------------------------------------------------
34 | four | ND04 | 03/04 | 34 | 34 | F4 | F4 | F4 |
---------------------------------------------------------------------
XXX
XXXX
XX XX
XX XX
XXXXXXX
XX
XXXX
---------------------------------------------------------------------
35 | five | ND05 | 03/05 | 35 | 35 | F5 | F5 | F5 |
---------------------------------------------------------------------
XXXXXXX
XX
XX
XXXXXX
XX
XX XX
XXXXX
---------------------------------------------------------------------
36 | six | ND06 | 03/06 | 36 | 36 | F6 | F6 | F6 |
---------------------------------------------------------------------
XXX
XX
XX
XXXXXX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
37 | seven | ND07 | 03/07 | 37 | 37 | F7 | F7 | F7 |
---------------------------------------------------------------------
XXXXXXX
XX XX
XX
XX
XX
XX
XX
---------------------------------------------------------------------
38 | eight | ND08 | 03/08 | 38 | 38 | F8 | F8 | F8 |
---------------------------------------------------------------------
XXXXX
XX XX
XX XX
XXXXX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
39 | nine | ND09 | 03/09 | 39 | 39 | F9 | F9 | F9 |
---------------------------------------------------------------------
XXXXX
XX XX
XX XX
XXXXXX
XX
XX
XXXX
---------------------------------------------------------------------
3A | colon | SP13 | 03/10 | 3A | 3A | 7A | 7A | 7A |
---------------------------------------------------------------------
XX
XX
XX
XX
---------------------------------------------------------------------
3B | semicolon | SP14 | 03/11 | 3B | 3B | 5E | 5E | 5E |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
---------------------------------------------------------------------
3C | less than sign | SA03 | 03/12 | 3C | 3C | 4C | 4C | 4C |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
XX
XX
---------------------------------------------------------------------
3D | equal sign | SA04 | 03/13 | 3D | 3D | 7E | 7E | 7E |
---------------------------------------------------------------------
XXXXXX
XXXXXX
---------------------------------------------------------------------
3E | greater than sign | SA05 | 03/14 | 3E | 3E | 6E | 6E | 6E |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
XX
XX
---------------------------------------------------------------------
3F | question mark | SP15 | 03/15 | 3F | 3F | 6F | 6F | 6F |
---------------------------------------------------------------------
XXXXX
XX XX
XX
XX
XX
XX
---------------------------------------------------------------------
40 | at sign | SM05 | 04/00 | 40 | 40 | 7C | 7C | 7C |
---------------------------------------------------------------------
XXXXX
XX XX
XX XXXX
XX XXXX
XX XXXX
XX
XXXX
---------------------------------------------------------------------
41 | A capital | LA02 | 04/01 | 41 | 41 | C1 | C1 | C1 |
---------------------------------------------------------------------
XXX
XX XX
XX XX
XXXXXXX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
42 | B capital | LB02 | 04/02 | 42 | 42 | C2 | C2 | C2 |
---------------------------------------------------------------------
XXXXXX
XX XX
XX XX
XXXXX
XX XX
XX XX
XXXXXX
---------------------------------------------------------------------
43 | C capital | LC02 | 04/03 | 43 | 43 | C3 | C3 | C3 |
---------------------------------------------------------------------
XXXX
XX XX
XX
XX
XX
XX XX
XXXX
---------------------------------------------------------------------
44 | D capital | LD02 | 04/04 | 44 | 44 | C4 | C4 | C4 |
---------------------------------------------------------------------
XXXXX
XX XX
XX XX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
45 | E capital | LE02 | 04/05 | 45 | 45 | C5 | C5 | C5 |
---------------------------------------------------------------------
XXXXXXX
XX X
XX X
XXXX
XX X
XX X
XXXXXXX
---------------------------------------------------------------------
46 | F capital | LF02 | 04/06 | 46 | 46 | C6 | C6 | C6 |
---------------------------------------------------------------------
XXXXXXX
XX X
XX X
XXXX
XX X
XX
XXXX
---------------------------------------------------------------------
47 | G capital | LG02 | 04/07 | 47 | 47 | C7 | C7 | C7 |
---------------------------------------------------------------------
XXXX
XX XX
XX
XX
XX XXX
XX XX
XXX X
---------------------------------------------------------------------
48 | H capital | LH02 | 04/08 | 48 | 48 | C8 | C8 | C8 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XXXXXXX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
49 | I capital | LI02 | 04/09 | 49 | 49 | C9 | C9 | C9 |
---------------------------------------------------------------------
XXXX
XX
XX
XX
XX
XX
XXXX
---------------------------------------------------------------------
4A | J capital | LJ02 | 04/10 | 4A | 4A | D1 | D1 | D1 |
---------------------------------------------------------------------
XXXX
XX
XX
XX
XX XX
XX XX
XXXX
---------------------------------------------------------------------
4B | K capital | LK02 | 04/11 | 4B | 4B | D2 | D2 | D2 |
---------------------------------------------------------------------
XXX XX
XX XX
XX XX
XXXX
XX XX
XX XX
XXX XX
---------------------------------------------------------------------
4C | L capital | LL02 | 04/12 | 4C | 4C | D3 | D3 | D3 |
---------------------------------------------------------------------
XXXX
XX
XX
XX
XX X
XX XX
XXXXXXX
---------------------------------------------------------------------
4D | M capital | LM02 | 04/13 | 4D | 4D | D4 | D4 | D4 |
---------------------------------------------------------------------
XX XX
XXX XXX
XXXXXXX
XXXXXXX
XX X XX
XX XX
XX XX
---------------------------------------------------------------------
4E | N capital | LN02 | 04/14 | 4E | 4E | D5 | D5 | D5 |
---------------------------------------------------------------------
XX XX
XXX XX
XXXX XX
XX XXXX
XX XXX
XX XX
XX XX
---------------------------------------------------------------------
4F | O capital | LO02 | 04/15 | 4F | 4F | D6 | D6 | D6 |
---------------------------------------------------------------------
XXXXX
XX XX
XX XX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
50 | P capital | LP02 | 05/00 | 50 | 50 | D7 | D7 | D7 |
---------------------------------------------------------------------
XXXXXX
XX XX
XX XX
XXXXX
XX
XX
XXXX
---------------------------------------------------------------------
51 | Q capital | LQ02 | 05/01 | 51 | 51 | D8 | D8 | D8 |
---------------------------------------------------------------------
XXXXX
XX XX
XX XX
XX XX
XX XX
XX XXX
XXXXX
XXX
---------------------------------------------------------------------
52 | R capital | LR02 | 05/02 | 52 | 52 | D9 | D9 | D9 |
---------------------------------------------------------------------
XXXXXX
XX XX
XX XX
XXXXX
XX XX
XX XX
XXX XX
---------------------------------------------------------------------
53 | S capital | LS02 | 05/03 | 53 | 53 | E2 | E2 | E2 |
---------------------------------------------------------------------
XXXX
XX XX
XX
XX
XX
XX XX
XXXX
---------------------------------------------------------------------
54 | T capital | LT02 | 05/04 | 54 | 54 | E3 | E3 | E3 |
---------------------------------------------------------------------
XXXXXX
XXXXXX
X XX X
XX
XX
XX
XXXX
---------------------------------------------------------------------
55 | U capital | LU02 | 05/05 | 55 | 55 | E4 | E4 | E4 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
56 | V capital | LV02 | 05/06 | 56 | 56 | E5 | E5 | E5 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
XXX
---------------------------------------------------------------------
57 | W capital | LW02 | 05/07 | 57 | 57 | E6 | E6 | E6 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX X XX
XX X XX
XXXXXXX
XX XX
---------------------------------------------------------------------
58 | X capital | LX02 | 05/08 | 58 | 58 | E7 | E7 | E7 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XXX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
59 | Y capital | LY02 | 05/09 | 59 | 59 | E8 | E8 | E8 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XXXX
XX
XX
XXXX
---------------------------------------------------------------------
5A | Z capital | LZ02 | 05/10 | 5A | 5A | E9 | E9 | E9 |
---------------------------------------------------------------------
XXXXXXX
XX XX
X XX
XX
XX X
XX XX
XXXXXXX
---------------------------------------------------------------------
5B | left bracket | SM06 | 05/11 | 5B | 5B | BA | 4A | AD |
---------------------------------------------------------------------
XXXX
XX
XX
XX
XX
XX
XXXX
---------------------------------------------------------------------
5C | backslash | SM07 | 05/12 | 5C | 5C | E0 | E0 | E0 |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
XX
X
---------------------------------------------------------------------
5D | right bracket | SM08 | 05/13 | 5D | 5D | BB | 5A | BD |
---------------------------------------------------------------------
XXXX
XX
XX
XX
XX
XX
XXXX
---------------------------------------------------------------------
5E | circumflex | SD15 | 05/14 | 5E | 5E | B0 | 5F | 5F |
---------------------------------------------------------------------
X
XXX
XX XX
XX XX
---------------------------------------------------------------------
5F | underline | SP09 | 05/15 | 5F | 5F | 6D | 6D | 6D |
---------------------------------------------------------------------
XXXXXXXX
---------------------------------------------------------------------
60 | grave accent | SD13 | 06/00 | 60 | 60 | 79 | 79 | 79 |
---------------------------------------------------------------------
XX
XX
XX
---------------------------------------------------------------------
61 | a small | LA01 | 06/01 | 61 | 61 | 81 | 81 | 81 |
---------------------------------------------------------------------
XXXX
XX
XXXXX
XX XX
XXX XX
---------------------------------------------------------------------
62 | b small | LB01 | 06/02 | 62 | 62 | 82 | 82 | 82 |
---------------------------------------------------------------------
XXX
XX
XXXXX
XX XX
XX XX
XX XX
XX XXX
---------------------------------------------------------------------
63 | c small | LC01 | 06/03 | 63 | 63 | 83 | 83 | 83 |
---------------------------------------------------------------------
XXXXX
XX XX
XX
XX XX
XXXXX
---------------------------------------------------------------------
64 | d small | LD01 | 06/04 | 64 | 64 | 84 | 84 | 84 |
---------------------------------------------------------------------
XXX
XX
XXXXX
XX XX
XX XX
XX XX
XXX XX
---------------------------------------------------------------------
65 | e small | LE01 | 06/05 | 65 | 65 | 85 | 85 | 85 |
---------------------------------------------------------------------
XXXXX
XX XX
XXXXXXX
XX
XXXXX
---------------------------------------------------------------------
66 | f small | LF01 | 06/06 | 66 | 66 | 86 | 86 | 86 |
---------------------------------------------------------------------
XXXX
XX XX
XX
XXXXX
XX
XX
XXXX
---------------------------------------------------------------------
67 | g small | LG01 | 06/07 | 67 | 67 | 87 | 87 | 87 |
---------------------------------------------------------------------
XXX XX
XX XX
XX XX
XXXXX
XX
XXXXX
---------------------------------------------------------------------
68 | h small | LH01 | 06/08 | 68 | 68 | 88 | 88 | 88 |
---------------------------------------------------------------------
XXX
XX
XX XX
XXX XX
XX XX
XX XX
XXX XX
---------------------------------------------------------------------
69 | i small | LI01 | 06/09 | 69 | 69 | 89 | 89 | 89 |
---------------------------------------------------------------------
XX
XXX
XX
XX
XX
XXXX
---------------------------------------------------------------------
6A | j small | LJ01 | 06/10 | 6A | 6A | 91 | 91 | 91 |
---------------------------------------------------------------------
XX
XX
XX
XX
XX XX
XX XX
XXXX
---------------------------------------------------------------------
6B | k small | LK01 | 06/11 | 6B | 6B | 92 | 92 | 92 |
---------------------------------------------------------------------
XXX
XX
XX XX
XX XX
XXXX
XX XX
XXX XX
---------------------------------------------------------------------
6C | l small | LL01 | 06/12 | 6C | 6C | 93 | 93 | 93 |
---------------------------------------------------------------------
XXX
XX
XX
XX
XX
XX
XXXX
---------------------------------------------------------------------
6D | m small | LM01 | 06/13 | 6D | 6D | 94 | 94 | 94 |
---------------------------------------------------------------------
XXX XX
XXXXXXX
XX X XX
XX X XX
XX X XX
---------------------------------------------------------------------
6E | n small | LN01 | 06/14 | 6E | 6E | 95 | 95 | 95 |
---------------------------------------------------------------------
XX XXX
XX XX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
6F | o small | LO01 | 06/15 | 6F | 6F | 96 | 96 | 96 |
---------------------------------------------------------------------
XXXXX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
70 | p small | LP01 | 07/00 | 70 | 70 | 97 | 97 | 97 |
---------------------------------------------------------------------
XX XXX
XX XX
XX XX
XXXXX
XX
XXXX
---------------------------------------------------------------------
71 | q small | LQ01 | 07/01 | 71 | 71 | 98 | 98 | 98 |
---------------------------------------------------------------------
XXX XX
XX XX
XX XX
XXXXX
XX
XXXX
---------------------------------------------------------------------
72 | r small | LR01 | 07/02 | 72 | 72 | 99 | 99 | 99 |
---------------------------------------------------------------------
XX XXX
XXX XX
XX
XX
XXXX
---------------------------------------------------------------------
73 | s small | LS01 | 07/03 | 73 | 73 | A2 | A2 | A2 |
---------------------------------------------------------------------
XXXXXX
XX
XXXXX
XX
XXXXXX
---------------------------------------------------------------------
74 | t small | LT01 | 07/04 | 74 | 74 | A3 | A3 | A3 |
---------------------------------------------------------------------
XX
XX
XXXXXX
XX
XX
XX XX
XXX
---------------------------------------------------------------------
75 | u small | LU01 | 07/05 | 75 | 75 | A4 | A4 | A4 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XXX XX
---------------------------------------------------------------------
76 | v small | LV01 | 07/06 | 76 | 76 | A5 | A5 | A5 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XXX
---------------------------------------------------------------------
77 | w small | LW01 | 07/07 | 77 | 77 | A6 | A6 | A6 |
---------------------------------------------------------------------
XX XX
XX X XX
XX X XX
XXXXXXX
XX XX
---------------------------------------------------------------------
78 | x small | LX01 | 07/08 | 78 | 78 | A7 | A7 | A7 |
---------------------------------------------------------------------
XX XX
XX XX
XXX
XX XX
XX XX
---------------------------------------------------------------------
79 | y small | LY01 | 07/09 | 79 | 79 | A8 | A8 | A8 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XXXXXX
XX
XXXXXX
---------------------------------------------------------------------
7A | z small | LZ01 | 07/10 | 7A | 7A | A9 | A9 | A9 |
---------------------------------------------------------------------
XXXXXX
X XX
XX
XX X
XXXXXX
---------------------------------------------------------------------
7B | left brace | SM11 | 07/11 | 7B | 7B | C0 | C0 | C0 |
---------------------------------------------------------------------
XXX
XX
XX
XXX
XX
XX
XXX
---------------------------------------------------------------------
7C | Vertical Line | SM13 | 07/12 | 7C | 7C | 4F | BB | 4F |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
XX
XX
---------------------------------------------------------------------
7D | right brace | SM14 | 07/13 | 7D | 7D | D0 | D0 | D0 |
---------------------------------------------------------------------
XXX
XX
XX
XXX
XX
XX
XXX
---------------------------------------------------------------------
7E | tilde accent | SD19 | 07/14 | 7E | 7E | A1 | A1 | A1 |
---------------------------------------------------------------------
XXX XX
XX XXX
---------------------------------------------------------------------
7F | Small House (DEL) | SM79 | 07/15 | 7F | 7F | FF | FF | FF |
---------------------------------------------------------------------
X
XXX
XX XX
XX XX
XX XX
XXXXXXX
---------------------------------------------------------------------
80 | Center Box Bar Vert D | SF24 | 08/00 | BA | BA | 31 | 31 | 31 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
81 | Center Box Bar Horiz D| SF43 | 08/01 | CD | CD | 30 | 30 | 30 |
---------------------------------------------------------------------
XXXXXXXX
XXXXXXXX
---------------------------------------------------------------------
82 | Upp Left Box Corner D | SF39 | 08/02 | C9 | C9 | 35 | 35 | 35 |
---------------------------------------------------------------------
XXXXXX
XX
XX XXX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
83 | Upper Right Box Corn D| SF25 | 08/03 | BB | BB | 34 | 34 | 34 |
---------------------------------------------------------------------
XXXXXXX
XX
XXXX XX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
84 | Low Left Box Corner D | SF38 | 08/04 | C8 | C8 | 1A | 1A | 1A |
---------------------------------------------------------------------
XX XX
XX XX
XX XXX
XX
XXXXXX
---------------------------------------------------------------------
85 | Lower Right Box Corn D| SF26 | 08/05 | BC | BC | 33 | 33 | 33 |
---------------------------------------------------------------------
XX XX
XX XX
XXXX XX
XX
XXXXXXX
---------------------------------------------------------------------
86 | Left Box Side Double | SF42 | 08/06 | CC | CC | 36 | 36 | 36 |
---------------------------------------------------------------------
XX XX
XX XX
XX XXX
XX
XX XXX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
87 | Right Box Side Double | SF23 | 08/07 | B9 | B9 | 38 | 38 | 38 |
---------------------------------------------------------------------
XX XX
XX XX
XXXX XX
XX
XXXX XX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
88 | Middle Box Top Double | SF41 | 08/08 | CB | CB | 39 | 39 | 39 |
---------------------------------------------------------------------
XXXXXXXX
XXXX XXX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
89 | Middle Box Bottom D | SF40 | 08/09 | CA | CA | 08 | 08 | 08 |
---------------------------------------------------------------------
XX XX
XX XX
XXXX XXX
XXXXXXXX
---------------------------------------------------------------------
8A | Box Intersection Doubl| SF44 | 08/10 | CE | CE | 3A | 3A | 3A |
---------------------------------------------------------------------
XX XX
XX XX
XXXX XXX
XXXX XXX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
8B | Solid Fill Ch,Top Half| SF60 | 08/11 | DF | DF | 3B | 3B | 3B |
---------------------------------------------------------------------
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
---------------------------------------------------------------------
8C | Solid Fill Ch,Bottom H| SF57 | 08/12 | DC | DC | 04 | 04 | 04 |
---------------------------------------------------------------------
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
---------------------------------------------------------------------
8D | Solid Fill Character | SF61 | 08/13 | DB | DB | 14 | 14 | 14 |
---------------------------------------------------------------------
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
XXXXXXXX
---------------------------------------------------------------------
8E | Small Solid Square | SM47 | 08/14 | FE | FE | 3E | 3E | 3E |
---------------------------------------------------------------------
XXXX
XXXX
XXXX
XXXX
---------------------------------------------------------------------
8F | Double Underscore | SM10 | 08/15 | F2 | F2 | 1B | 1B | 1B |
---------------------------------------------------------------------
XXXXXXXX
XXXXXXXX
---------------------------------------------------------------------
90 | Center Box Bar Vertic | SF11 | 09/00 | B3 | B3 | 21 | 21 | 21 |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
XX
XX
XX
---------------------------------------------------------------------
91 | Center Box Bar Horiz | SF10 | 09/01 | C4 | C4 | 20 | 20 | 20 |
---------------------------------------------------------------------
XXXXXXXX
---------------------------------------------------------------------
92 | Upper Left Box Corner | SF01 | 09/02 | DA | DA | 15 | 15 | 15 |
---------------------------------------------------------------------
XXXXX
XX
XX
XX
---------------------------------------------------------------------
93 | Upper Right Box Corner| SF03 | 09/03 | BF | BF | 24 | 24 | 24 |
---------------------------------------------------------------------
XXXXX
XX
XX
XX
---------------------------------------------------------------------
94 | Lower Left Box Corner | SF02 | 09/04 | C0 | C0 | 22 | 22 | 22 |
---------------------------------------------------------------------
XX
XX
XX
XX
XXXXX
---------------------------------------------------------------------
95 | Lower Right Box Corner| SF04 | 09/05 | D9 | D9 | 23 | 23 | 23 |
---------------------------------------------------------------------
XX
XX
XX
XX
XXXXX
---------------------------------------------------------------------
96 | Left Middle Box Side | SF08 | 09/06 | C3 | C3 | 06 | 06 | 06 |
---------------------------------------------------------------------
XX
XX
XX
XX
XXXXX
XX
XX
XX
---------------------------------------------------------------------
97 | Right Middle Box Side | SF09 | 09/07 | B4 | B4 | 28 | 28 | 28 |
---------------------------------------------------------------------
XX
XX
XX
XX
XXXXX
XX
XX
XX
---------------------------------------------------------------------
98 | Middle Box Top | SF06 | 09/08 | C2 | C2 | 29 | 29 | 29 |
---------------------------------------------------------------------
XXXXXXXX
XX
XX
XX
---------------------------------------------------------------------
99 | Middle Box Bottom | SF07 | 09/09 | C1 | C1 | 17 | 17 | 17 |
---------------------------------------------------------------------
XX
XX
XX
XX
XXXXXXXX
---------------------------------------------------------------------
9A | Box Intersection | SF05 | 09/10 | C5 | C5 | 2A | 2A | 2A |
---------------------------------------------------------------------
XX
XX
XX
XX
XXXXXXXX
XX
XX
XX
---------------------------------------------------------------------
9B | Fill Character, Light | SF14 | 09/11 | B0 | B0 | 2B | 2B | 2B |
---------------------------------------------------------------------
X X
X X
X X
X X
X X
X X
X X
X X
---------------------------------------------------------------------
9C | Fill Character, Medium| SF15 | 09/12 | B1 | B1 | 2C | 2C | 2C |
---------------------------------------------------------------------
X X X X
X X X X
X X X X
X X X X
X X X X
X X X X
X X X X
X X X X
---------------------------------------------------------------------
9D | Fill Character, Heavy | SF16 | 09/13 | B2 | B2 | 09 | 09 | 09 |
---------------------------------------------------------------------
XXX XXX
XX XXX X
XXX XXX
XX XXX X
XXX XXX
XX XXX X
XXX XXX
XX XXX X
---------------------------------------------------------------------
9E | i dotless small | LI61 | 09/14 | D5 | D5 | 0A | 0A | 0A |
---------------------------------------------------------------------
XXX
XX
XX
XX
XXXX
---------------------------------------------------------------------
9F | Florin Sign | SC07 | 09/15 | 9F | 9F | 07 | 07 | 07 |
---------------------------------------------------------------------
XXX
XX XX
XX
XXXX
XX
XX XX
XXX
---------------------------------------------------------------------
A0 | required space | SP30 | 10/00 | FF | FF | 41 | 41 | 41 |
---------------------------------------------------------------------
---------------------------------------------------------------------
A1 | exclamation point inv | SP03 | 10/01 | AD | AD | AA | AA | AA |
---------------------------------------------------------------------
XX
XX
XX
XXXX
XXXX
XX
---------------------------------------------------------------------
A2 | cent sign | SC04 | 10/02 | 9B | BD | 4A | B0 | 4A |
---------------------------------------------------------------------
XX
XX
XXXXXX
XX
XX
XXXXXX
XX
XX
---------------------------------------------------------------------
A3 | pound sign | SC02 | 10/03 | 9C | 9C | B1 | B1 | B1 |
---------------------------------------------------------------------
XXX
XX XX
XX X
XXXX
XX
XX XX
XXXXXX
---------------------------------------------------------------------
A4 | int. currency symbol | SC01 | 10/04 | CF | CF | 9F | 9F | 9F |
---------------------------------------------------------------------
XX XX
XXXXX
XX XX
XX XX
XXXXX
XX XX
---------------------------------------------------------------------
A5 | Yen sign | SC05 | 10/05 | 9D | BE | B2 | B2 | B2 |
---------------------------------------------------------------------
XX XX
XX XX
XXXX
XXXXXX
XX
XXXXXX
XX
XX
---------------------------------------------------------------------
A6 | Vertical Line, Broken | SM65 | 10/06 | DD | DD | 6A | 6A | 6A |
---------------------------------------------------------------------
XX
XX
XX
XX
XX
XX
---------------------------------------------------------------------
A7 | section/paragraph symb| SM24 | 10/07 | 15 | F5 | B5 | B5 | B5 |
---------------------------------------------------------------------
XXXXX
XX X
XXXX
XX XX
XX XX
XXXX
X XX
XXXXX
---------------------------------------------------------------------
A8 | diaeresis,umlaut acc | SD17 | 10/08 | F9 | F9 | BD | BD | BB |
---------------------------------------------------------------------
XX XX
---------------------------------------------------------------------
A9 | Copyright sign | SM52 | 10/09 | B8 | B8 | B4 | B4 | B4 |
---------------------------------------------------------------------
XXXXXX
X X
X XXX X
X X X
X X X
X XXX X
X X
XXXXXX
---------------------------------------------------------------------
AA | ordinal indicator fem | SM21 | 10/10 | A6 | A6 | 9A | 9A | 9A |
---------------------------------------------------------------------
XXXX
XX XX
XX XX
XXXXX
XXXXXX
---------------------------------------------------------------------
AB | left angle quotes | SP17 | 10/11 | AE | AE | 8A | 8A | 8A |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
AC | logical NOT, EOL symb | SM66 | 10/12 | AA | AA | 5F | BA | B0 |
---------------------------------------------------------------------
XXXXXXX
XX
XX
---------------------------------------------------------------------
AD | Syllabe Hyphen | SP32 | 10/13 | F0 | F0 | CA | CA | CA |
---------------------------------------------------------------------
XXXXXX
---------------------------------------------------------------------
AE | Regist.Trade Mark sym | SM53 | 10/14 | A9 | A9 | AF | AF | AF |
---------------------------------------------------------------------
XXXXXX
X X
X XXX X
X X X X
X XXX X
X X X X
X X
XXXXXX
---------------------------------------------------------------------
AF | overline | SM15 | 10/15 | EE | EE | BC | BC | BC |
---------------------------------------------------------------------
XXXXXXXX
---------------------------------------------------------------------
B0 | Degree Symbol | SM19 | 11/00 | F8 | F8 | 90 | 90 | 90 |
---------------------------------------------------------------------
XXX
XX XX
XX XX
XXX
---------------------------------------------------------------------
B1 | plus or minus sign | SA02 | 11/01 | F1 | F1 | 8F | 8F | 8F |
---------------------------------------------------------------------
XX
XX
XXXXXX
XX
XX
XXXXXX
---------------------------------------------------------------------
B2 | 2 superscript | ND021| 11/02 | FD | FD | EA | EA | EA |
---------------------------------------------------------------------
XXXX
XX
XX
XX
XXXXX
---------------------------------------------------------------------
B3 | 3 superscript | ND031| 11/03 | FC | FC | FA | FA | FA |
---------------------------------------------------------------------
XXXX
XX
XXX
XX
XXXX
---------------------------------------------------------------------
B4 | acute accent | SD11 | 11/04 | EF | EF | BE | BE | BE |
---------------------------------------------------------------------
XX
XX
XX
---------------------------------------------------------------------
B5 | micro symbol | SM17 | 11/05 | E6 | E6 | A0 | A0 | A0 |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XXXXX
XX
---------------------------------------------------------------------
B6 | paragraph symbol USA | SM25 | 11/06 | 14 | F4 | B6 | B6 | B6 |
---------------------------------------------------------------------
XXXXXXX
XX XX XX
XX XX XX
XXXX XX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
B7 | Middle dot accent | SD63 | 11/07 | FA | FA | B3 | B3 | B3 |
---------------------------------------------------------------------
XX
---------------------------------------------------------------------
B8 | cedilla accent | SD41 | 11/08 | F7 | F7 | 9D | 9D | 9D |
---------------------------------------------------------------------
XX
XX
XXX
---------------------------------------------------------------------
B9 | 1 superscript | ND011| 11/09 | FB | FB | DA | DA | DA |
---------------------------------------------------------------------
XX
XXX
XX
XX
XXXX
---------------------------------------------------------------------
BA | ordinal indicator mas | SM20 | 11/10 | A7 | A7 | 9B | 9B | 9B |
---------------------------------------------------------------------
XXX
XX XX
XX XX
XXX
XXXXX
---------------------------------------------------------------------
BB | right angle quotes | SP18 | 11/11 | AF | AF | 8B | 8B | 8B |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
BC | one quarter | NF04 | 11/12 | AC | AC | B7 | B7 | B7 |
---------------------------------------------------------------------
XX XX
XXX XX
XX XX
XXXX X
XX XX
XX X X
XX XXXXX
XX
---------------------------------------------------------------------
BD | one half | NF01 | 11/13 | AB | AB | B8 | B8 | B8 |
---------------------------------------------------------------------
XX XX
XXX XX
XX XX
XXXXXX
XX XX
XX XX
XX XX
XXXX
---------------------------------------------------------------------
BE | three quarters | NF05 | 11/14 | F3 | F3 | B9 | B9 | B9 |
---------------------------------------------------------------------
XXX X
XX X
XXX X
XXX X
XXXX XX
X X X
X XXXXX
X XX
---------------------------------------------------------------------
BF | Question mark inverted| SP16 | 11/15 | A8 | A8 | AB | AB | AB |
---------------------------------------------------------------------
XX
XX
XX
XX
XX XX
XXXXX
---------------------------------------------------------------------
C0 | A grave capital | LA14 | 12/00 | B7 | B7 | 64 | 64 | 64 |
---------------------------------------------------------------------
XX
XX
XXX
XX XX
XX XX
XXXXXXX
XX XX
---------------------------------------------------------------------
C1 | A acute capital | LA12 | 12/01 | B5 | B5 | 65 | 65 | 65 |
---------------------------------------------------------------------
XX
XX
XXX
XX XX
XX XX
XXXXXXX
XX XX
---------------------------------------------------------------------
C2 | A circumflex capital | LA16 | 12/02 | B6 | B6 | 62 | 62 | 62 |
---------------------------------------------------------------------
XXXXX
X X
XXX
XX XX
XX XX
XXXXXXX
XX XX
---------------------------------------------------------------------
C3 | A tilde capital | LA20 | 12/03 | C7 | C7 | 66 | 66 | 66 |
---------------------------------------------------------------------
XXX XX
XX XXX
XXX
XX XX
XX XX
XXXXXXX
XX XX
---------------------------------------------------------------------
C4 | A diaeresis capital | LA18 | 12/04 | 8E | 8E | 63 | 63 | 63 |
---------------------------------------------------------------------
XX XX
XXX
XX XX
XX XX
XXXXXXX
XX XX
XX XX
---------------------------------------------------------------------
C5 | A overcircle capital | LA28 | 12/05 | 8F | 8F | 67 | 67 | 67 |
---------------------------------------------------------------------
XXX
XX XX
XXXXX
XX XX
XXXXXXX
XX XX
XX XX
---------------------------------------------------------------------
C6 | AE diphthong capital | LA52 | 12/06 | 92 | 92 | 9E | 9E | 9E |
---------------------------------------------------------------------
XXXXX
XX XX
XX XX
XXXXXXX
XX XX
XX XX
XX XXX
---------------------------------------------------------------------
C7 | C cedilla capital | LC42 | 12/07 | 80 | 80 | 68 | 68 | 68 |
---------------------------------------------------------------------
XXXXX
XX XX
XX
XX
XX XX
XXXXX
XX
XXXX
---------------------------------------------------------------------
C8 | E grave capital | LE14 | 12/08 | D4 | D4 | 74 | 74 | 74 |
---------------------------------------------------------------------
XX
XX
XXXXXXX
XX
XXXXXX
XX
XXXXXXX
---------------------------------------------------------------------
C9 | E acute capital | LE12 | 12/09 | 90 | 90 | 71 | 71 | 71 |
---------------------------------------------------------------------
XX
XX
XXXXXXX
XX
XXXXX
XX
XXXXXXX
---------------------------------------------------------------------
CA | E circumflex capital | LE16 | 12/10 | D2 | D2 | 72 | 72 | 72 |
---------------------------------------------------------------------
XXXXX
X X
XXXXXXX
XX
XXXXXX
XX
XXXXXXX
---------------------------------------------------------------------
CB | E diaeresis capital | LE18 | 12/11 | D3 | D3 | 73 | 73 | 73 |
---------------------------------------------------------------------
XX XX
XXXXXXX
XX
XXXXXX
XX
XXXXXXX
---------------------------------------------------------------------
CC | I grave capital | LI14 | 12/12 | DE | DE | 78 | 78 | 78 |
---------------------------------------------------------------------
XX
XX
XXXX
XX
XX
XX
XXXX
---------------------------------------------------------------------
CD | I acute capital | LI12 | 12/13 | D6 | D6 | 75 | 75 | 75 |
---------------------------------------------------------------------
XX
XX
XXXX
XX
XX
XX
XXXX
---------------------------------------------------------------------
CE | I circumflex capital | LI16 | 12/14 | D7 | D7 | 76 | 76 | 76 |
---------------------------------------------------------------------
XXXX
X X
XXXX
XX
XX
XX
XXXX
---------------------------------------------------------------------
CF | I diaeresis capital | LI18 | 12/15 | D8 | D8 | 77 | 77 | 77 |
---------------------------------------------------------------------
XX XX
XXXX
XX
XX
XX
XXXX
---------------------------------------------------------------------
D0 | Eth islandic capital | LD62 | 13/00 | D1 | D1 | AC | AC | AC |
---------------------------------------------------------------------
XXXXX
XX XX
XX XX
XXXX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
D1 | N tilde capital | LN20 | 13/01 | A5 | A5 | 69 | 69 | 69 |
---------------------------------------------------------------------
XXX XX
XX XXX
XXX XX
XXXX XX
XX XXXX
XX XXX
---------------------------------------------------------------------
D2 | O grave capital | LO14 | 13/02 | E3 | E3 | ED | ED | ED |
---------------------------------------------------------------------
XX
XX
XXX
XX XX
XX XX
XX XX
XXX
---------------------------------------------------------------------
D3 | O acute capital | LO12 | 13/03 | E0 | E0 | EE | EE | EE |
---------------------------------------------------------------------
XX
XX
XXX
XX XX
XX XX
XX XX
XXX
---------------------------------------------------------------------
D4 | O circumflex capital | LO16 | 13/04 | E2 | E2 | EB | EB | EB |
---------------------------------------------------------------------
XXXXX
X X
XXX
XX XX
XX XX
XX XX
XXX
---------------------------------------------------------------------
D5 | O tilde capital | LO20 | 13/05 | E5 | E5 | EF | EF | EF |
---------------------------------------------------------------------
XXX XX
XX XXX
XXX
XX XX
XX XX
XX XX
XXX
---------------------------------------------------------------------
D6 | O diaeresis capital | LO18 | 13/06 | 99 | 99 | EC | EC | EC |
---------------------------------------------------------------------
XX XX
XXX
XX XX
XX XX
XX XX
XX XX
XXX
---------------------------------------------------------------------
D7 | Multiply sign | SA07 | 13/07 | 9E | 9E | BF | BF | BF |
---------------------------------------------------------------------
XX XX
XX XX
XXX
XX XX
XX XX
---------------------------------------------------------------------
D8 | O slash capital | LO62 | 13/08 | BE | 9D | 80 | 80 | 80 |
---------------------------------------------------------------------
XXX X
XX XX
XX XXX
XX X XX
XXX XX
XX XX
X XXX
---------------------------------------------------------------------
D9 | U grave capital | LU14 | 13/09 | EB | EB | FD | FD | FD |
---------------------------------------------------------------------
XX
XX
XX XX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
DA | U acute capital | LU12 | 13/10 | E9 | E9 | FE | FE | FE |
---------------------------------------------------------------------
XX
XX
XX XX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
DB | U circumflex capital | LU16 | 13/11 | EA | EA | FB | FB | FB |
---------------------------------------------------------------------
XXXXX
X X
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
DC | U diaeresis capital | LU18 | 13/12 | 9A | 9A | FC | FC | FC |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
DD | Y acute Capital | LY12 | 13/13 | ED | ED | AD | AD | BA |
---------------------------------------------------------------------
XX
XX
XX XX
XX XX
XXXX
XX
XXXX
---------------------------------------------------------------------
DE | Thorn islandic capital| LT64 | 13/14 | E8 | E8 | AE | AE | AE |
---------------------------------------------------------------------
XXXX
XX
XXXXX
XX XX
XXXXX
XX
XXXX
---------------------------------------------------------------------
DF | sharp s small | LS61 | 13/15 | E1 | E1 | 59 | 59 | 59 |
---------------------------------------------------------------------
XXXX
XX XX
XX XX
XX XX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
E0 | a grave small | LA13 | 14/00 | 85 | 85 | 44 | 44 | 44 |
---------------------------------------------------------------------
XX
XX
XXXX
XX
XXXXX
XX XX
XXX XX
---------------------------------------------------------------------
E1 | a acute small | LA11 | 14/01 | A0 | A0 | 45 | 45 | 45 |
---------------------------------------------------------------------
XX
XX
XXXX
XX
XXXXX
XX XX
XXX XX
---------------------------------------------------------------------
E2 | a circumflex small | LA15 | 14/02 | 83 | 83 | 42 | 42 | 42 |
---------------------------------------------------------------------
XXXXX
X X
XXXX
XX
XXXXX
XX XX
XXX XX
---------------------------------------------------------------------
E3 | a tilde small | LA19 | 14/03 | C6 | C6 | 46 | 46 | 46 |
---------------------------------------------------------------------
XXX XX
XX XXX
XXXXX
XX
XXXXXX
XX XX
XXXXXX
---------------------------------------------------------------------
E4 | a diaeresis small | LA17 | 14/04 | 84 | 84 | 43 | 43 | 43 |
---------------------------------------------------------------------
XX XX
XXXX
XX
XXXXX
XX XX
XXX XX
---------------------------------------------------------------------
E5 | a overcircle small | LA27 | 14/05 | 86 | 86 | 47 | 47 | 47 |
---------------------------------------------------------------------
XX
XX
XXXX
XX
XXXXX
XX XX
XXX XX
---------------------------------------------------------------------
E6 | ae diphthong small | LA51 | 14/06 | 91 | 91 | 9C | 9C | 9C |
---------------------------------------------------------------------
XXXXXX
X X
XXXXXXX
X X
XXXXXXX
---------------------------------------------------------------------
E7 | c cedilla small | LC41 | 14/07 | 87 | 87 | 48 | 48 | 48 |
---------------------------------------------------------------------
XXXXXX
XX
XX
XXXXXX
XX
XXX
---------------------------------------------------------------------
E8 | e grave small | LE13 | 14/08 | 8A | 8A | 54 | 54 | 54 |
---------------------------------------------------------------------
XX
XX
XXXXX
XX XX
XXXXXXX
XX
XXXXX
---------------------------------------------------------------------
E9 | e acute small | LE11 | 14/09 | 82 | 82 | 51 | 51 | 51 |
---------------------------------------------------------------------
XX
XX
XXXXX
XX XX
XXXXXXX
XX
XXXXX
---------------------------------------------------------------------
EA | e circumflex small | LE15 | 14/10 | 88 | 88 | 52 | 52 | 52 |
---------------------------------------------------------------------
XXXXX
X X
XXXXX
XX XX
XXXXXXX
XX
XXXXX
---------------------------------------------------------------------
EB | e diaeresis small | LE17 | 14/11 | 89 | 89 | 53 | 53 | 53 |
---------------------------------------------------------------------
XX XX
XXXXX
XX XX
XXXXXXX
XX
XXXXX
---------------------------------------------------------------------
EC | i grave small | LI13 | 14/12 | 8D | 8D | 58 | 58 | 58 |
---------------------------------------------------------------------
XX
XX
XXX
XX
XX
XXXX
---------------------------------------------------------------------
ED | i acute small | LI11 | 14/13 | A1 | A1 | 55 | 55 | 55 |
---------------------------------------------------------------------
XX
XX
XXX
XX
XX
XXXX
---------------------------------------------------------------------
EE | i circumflex small | LI15 | 14/14 | 8C | 8C | 56 | 56 | 56 |
---------------------------------------------------------------------
XXXXX
X X
XXX
XX
XX
XX
XXXX
---------------------------------------------------------------------
EF | i diaeresis small | LI17 | 14/15 | 8B | 8B | 57 | 57 | 57 |
---------------------------------------------------------------------
XX XX
XXX
XX
XX
XX
XXXX
---------------------------------------------------------------------
F0 | Eth Islandic small | LD63 | 15/00 | D0 | D0 | 8C | 8C | 8C |
---------------------------------------------------------------------
XX
XXXXXX
XX
XXXXX
XX XX
XX XX
XXXX
---------------------------------------------------------------------
F1 | n tilde small | LN19 | 15/01 | A4 | A4 | 49 | 49 | 49 |
---------------------------------------------------------------------
XXX XX
XX XXX
XX XXX
XX XX
XX XX
XX XX
---------------------------------------------------------------------
F2 | o grave small | LO13 | 15/02 | 95 | 95 | CD | CD | CD |
---------------------------------------------------------------------
XX
XX
XXXXX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
F3 | o acute small | LO11 | 15/03 | A2 | A2 | CE | CE | CE |
---------------------------------------------------------------------
XX
XX
XXXXX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
F4 | o circumflex small | LO15 | 15/04 | 93 | 93 | CB | CB | CB |
---------------------------------------------------------------------
XXXXX
X X
XXXXX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
F5 | o tilde small | LO19 | 15/05 | E4 | E4 | CF | CF | CF |
---------------------------------------------------------------------
XXX XX
XX XXX
XXXXX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
F6 | o diaeresis small | LO17 | 15/06 | 94 | 94 | CC | CC | CC |
---------------------------------------------------------------------
XX XX
XXXXX
XX XX
XX XX
XX XX
XXXXX
---------------------------------------------------------------------
F7 | Divide sign | SA06 | 15/07 | F6 | F6 | E1 | E1 | E1 |
---------------------------------------------------------------------
XX
XXXXXX
XX
---------------------------------------------------------------------
F8 | o slash small | LO61 | 15/08 | BD | 9B | 70 | 70 | 70 |
---------------------------------------------------------------------
X
XXXXX
XX XXX
XX X XX
XXX XX
XXXXX
X
---------------------------------------------------------------------
F9 | u grave small | LU13 | 15/09 | 97 | 97 | DD | DD | DD |
---------------------------------------------------------------------
XX
XX
XX XX
XX XX
XX XX
XX XX
XXX XX
---------------------------------------------------------------------
FA | u acute small | LU11 | 15/10 | A3 | A3 | DE | DE | DE |
---------------------------------------------------------------------
XX
XX
XX XX
XX XX
XX XX
XX XX
XXX XX
---------------------------------------------------------------------
FB | u circumflex small | LU15 | 15/11 | 96 | 96 | DB | DB | DB |
---------------------------------------------------------------------
XXXX
X X
XX XX
XX XX
XX XX
XXX XX
---------------------------------------------------------------------
FC | u diaeresis small | LU17 | 15/12 | 81 | 81 | DC | DC | DC |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XX XX
XXX XX
---------------------------------------------------------------------
FD | y acute small | LY11 | 15/13 | EC | EC | 8D | 8D | 8D |
---------------------------------------------------------------------
XX
XX
XX XX
XX XX
XX XX
XXXXXX
XX
XXXXXX
---------------------------------------------------------------------
FE | Thorn islandic small | LT63 | 15/14 | E7 | E7 | 8E | 8E | 8E |
---------------------------------------------------------------------
XXX
XX
XXXXX
XX XX
XX XX
XXXXX
XX
XXXX
---------------------------------------------------------------------
FF | y diaeresis small | LY17 | 15/15 | 98 | 98 | DF | DF | DF |
---------------------------------------------------------------------
XX XX
XX XX
XX XX
XX XX
XXXXXX
XX
XXXXXX
---------------------------------------------------------------------
From "Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>" Sat May 28 08:13:43 1988
Flags: 000000000000
Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Sat 28 May 88 06:13:30-EDT
Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Sat, 28 May 88 06:13:55 EDT
Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
0716; Sat, 28 May 88 06:13:53 EDT
Received: by BLIULG11 (Mailer X1.25) id 1548; Sat, 28 May 88 12:12:35 +0200
Date: Sat, 28 May 88 12:11:26 +0200
From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Precision to my ISO8859/1 document
To: ISO8859@JHUVM,
Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>,
IBM-KERMIT@CU20B.COLUMBIA.EDU,
Paul Placeway <PAUL@TUT.CIS.OHIO-STATE.EDU>,
Matthias Aebi <K116430@CZHRZU1A>
In the document describing the ISO8859/1 and related character
sets, I forgot to make the following remark to be added to the
file. Sorry.
Andre'.
- The character range 80-9F is undefined in the description of
ISO885/1 I have. I don't know its real status, but this feature
is welcome for two reasons.
First, it avoids control characters during transmission on a
7-bit line (ISO2022: an SO code shifts to the upper half of the
set, an SI code reverts to the lower one). As an added bonus,
this keeps Kermit overhead (8-th bit quoting) to a minimum.
Second, it allows rearranging a previous 8-bit code set that
used this range for national characters. These are moved to the
ISO positions and the expelled non-ISO characters can be moved
to the 80-9F range.
What appears in my listing is the assignment made by IBM for
its graphic characters mainly.
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Tue Jul 5 14:00:21 1988
Flags: 000000000000
Return-Path: <@CUVMA.CC.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMA.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Tue 5 Jul 88 12:00:17-EDT
Received: from CUVMA.CC.COLUMBIA.EDU(MAILER) by CUVMA.CC.COLUMBIA.EDU(SMTP) ; Tue, 05 Jul 88 12:01:02 EDT
Received: from CFAAMP.BITNET by CUVMA.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 8962; Tue, 05 Jul 88 12:00:59 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer X1.25) with
BSMTP id 1456; Tue, 05 Jul 88 11:55:48 EDT
Date: Tue, 1988 Jul 5 11:30 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU, (Georges Mayer) APLGEOR@TECHNION.BITNET,
(IBM KERMIT developers) IBM-KERM@CUVMA.BITNET
Subject: Re: kermit cms ver. 4.0
In-reply-to: APLGEOR@TECHNION message of Mon, 4 Jul 88 11:09:25 IST
Message-id: <PEPMNT.880705.113037.B0@CFAAMP.BITNET>
> when i want to send files with large packet-size (1000) :
> set send packet-size 1000
> the KERMIT respond : Operand must be 20-94 for SEND .
> but when i see the parameters for SEND : sh send
> it is written :packet-size 1000
> so please has someone allready deal with this anomaly or it is a BUG ??
> when i send the file ,it is sended with packet-size 1000 !!!
There is a difference of opinion between Joe Doupnik on the one hand and
Bob Bolch and me on the other. MS Kermit believes in offering long-
packet transfer by default, that is, it sets the corresponding CAPAS
flag, defaults the SEND size to 1000, and treats any user command as a
*restrictive limit*. Kermit-370, on the other hand, believes in
defaulting everything to the basic, ungarnished Kermit protocol and
allows extras only if the user asks, that is, the default size is 80
for both SEND and RECEIVE, but it uses the packet size the other Kermit
specifies (for sending), advertises the size the user requests via
SET REC PACKET (for receiving), and doesn't set the long-packet flag in
the CAPAS unless its RECEIVE size exceeds 94 (what would be the point?).
Setting the SEND size has no effect at all, unless the other Kermit
doesn't specify a size of its own (the documentation states this fact,
by the way).
John
From "Frank da Cruz <SY.FDC@CU20B.CC.COLUMBIA.EDU>" Fri Jul 8 12:21:59 1988
Flags: 000000000000
Mail-From: SY.FDC created at 8-Jul-88 10:21:53
Date: Fri 8 Jul 88 10:21:52-EDT
From: Frank da Cruz <SY.FDC@CU20B.CC.COLUMBIA.EDU>
Subject: Re: kermit cms ver. 4.0
To: PEPMNT@CFAAMP, IBM-KERMIT@CU20B.CC.COLUMBIA.EDU, APLGEOR@TECHNION,
IBM-KERM@CUVMA
In-Reply-To: <PEPMNT.880705.113037.B0@CFAAMP.BITNET>
Message-ID: <12412675299.35.SY.FDC@CU20B.CC.COLUMBIA.EDU>
Operationally, I don't think there's any difference between Kermit-370
and MS-Kermit. They both use regular (short) packets by default. The only
way to get either of them to use long packets is to give the
SET RECEIVE PACKET-LENGTH n
command, where n > 94. Kermit-MS has the SET SEND PACKET-LENGTH at 1000
by default, but if you look at the manual or the Kermit book, you'll see that
this parameter is only operational if the other Kermit asks to receive
packets that are longer than that. In other words, SET SEND parameters are
only used to override negotiated parameters, but then ONLY DOWNWARDS.
- Frank
-------
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Fri Jul 8 16:32:52 1988
Flags: 000000000000
Return-Path: <@cuvma.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from columbia.edu by CU20B.CC.COLUMBIA.EDU with TCP; Fri 8 Jul 88 14:32:47-EDT
Received: from CUVMA.CC.COLUMBIA.EDU by columbia.edu (5.54/1.14)
id AA17628; Fri, 8 Jul 88 14:33:56 EDT
Received: from CUVMA.CC.COLUMBIA.EDU(MAILER) by CUVMA.CC.COLUMBIA.EDU(SMTP) ; Fri, 08 Jul 88 14:33:26 EDT
Received: from CFAAMP.BITNET by CUVMA.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 3717; Fri, 08 Jul 88 14:33:25 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer X1.25) with
BSMTP id 1929; Fri, 08 Jul 88 11:45:29 EDT
Date: Fri, 1988 Jul 8 11:26 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: (Frank da Cruz) SY.FDC@cu20b.cc.columbia.edu,
IBM-KERMIT@cu20b.cc.columbia.edu
Subject: Re: kermit cms ver. 4.0
In-Reply-To: SY.FDC@CU20B.CC.COLUMBIA.EDU message
<12412675299.35.SY.FDC@CU20B.CC.COLUMBIA.EDU> of Fri 8 Jul 88 10:21:52-EDT
Message-Id: <PEPMNT.880708.112621.B0@CFAAMP.BITNET>
I may be wrong, but I thought the default for MS Kermit also included
a RECEIVE size of 1000, i.e., the default S-init or ACK would give a
"short" size of 80 and a "long" size of 1000 and promise to understand
"long" packets. Believe it or not, I haven't used MS Kermit since long
packets were introduced therein, so I was basing my statement on my
interpretation of what Joe D. told me once last fall.
From "David Sitman <A79%TAUNIVM.BITNET@CUVMA.CC.COLUMBIA.EDU>" Sun Jul 10 04:38:04 1988
Flags: 000000000000
Return-Path: <@CUVMA.CC.COLUMBIA.EDU:A79@TAUNIVM.BITNET>
Received: from CUVMA.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Sun 10 Jul 88 02:38:01-EDT
Received: from CUVMA.CC.COLUMBIA.EDU(MAILER) by CUVMA.CC.COLUMBIA.EDU(SMTP) ; Sun, 10 Jul 88 02:38:39 EDT
Received: from VM1.TAU.AC.IL by CUVMA.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 4924; Sun, 10 Jul 88 02:38:38 EDT
Received: by TAUNIVM (Mailer X1.24) id 8840; Sun, 10 Jul 88 09:39:13 IST
Date: Sun, 10 Jul 88 09:30:30 IST
From: David Sitman <A79%TAUNIVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
Subject: Re: kermit cms ver. 4.0
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
In-Reply-To: Message of Fri, 8 Jul 88 10:24:45 EDT from
<SY.FDC@CU20B.CC.COLUMBIA.EDU>
I no longer have the letter that Georges sent to the list, but I thought
that he was pointing out a little bug that I had noticed: KERMIT-370
gives an incorrect warning message to the command:
SET SEND PACKET-SIZE 1000
Kermit sets the packet size to 1000 correctly, but it gives the warning
message: Operand must be 20-94 for SEND
If, on the other hand, you type: SET SEND PACKET-SIZE ?
then Kermit (correctly) answers: Operand must be <1914.
David
From pepap%cfa3.span%CFA.BITNET@cuvmb.cc.columbia.edu Mon Jul 18 22:52:37 1988
Flags: 000000000000
Return-Path: <@cuvmb.cc.columbia.edu:pepap%cfa3.span@cfa.bitnet>
Received: from columbia.edu by CU20B.CC.COLUMBIA.EDU with TCP; Mon 18 Jul 88 20:52:26-EDT
Received: from CUVMB.CC.COLUMBIA.EDU by columbia.edu (5.54/1.14)
id AA15448; Mon, 18 Jul 88 20:53:16 EDT
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 18 Jul 88 20:53:35 EDT
Received: from cfa.bitnet by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
0026; Mon, 18 Jul 88 20:53:34 EDT
Received: from cfa3.Span by cfaps2 with VMSmail ;
Mon, 18 Jul 88 20:28:23 EDT
Date: Mon, 18 Jul 88 20:28:23 EDT
From: pepap%cfa3.span%CFA.BITNET@cuvmb.cc.columbia.edu
Message-Id: <880718202837.047@cfa>
Subject: Controller type "FULLSCREEN"
To: ibm-kermit@cu20b.cc.columbia.edu
X-St-Vmsmail-To: ST%"ibm-kermit@cu20b.cc.columbia.edu"
I'm still looking for conclusive evidence of the limitations of 3708's
for file-transfer. Last fall I received a phone call from someone who
claimed that it was possible to switch a 3708 back and forth from
protocol conversion to protocol enveloping mode, and on the basis of
that claim and existence of TS3KER, I implemented a controller type
called FULLSCREEN to be used with 3708 transmission. My informant,
however, never followed through with the promised information on the
exact commands a mainframe could send to a 3708 to switch modes, and
subsequent conversations with people interested in the topic indicate
that the promised commands are not documented in any IBM manuals and
possibly don't even exist. Still, it turns out that file transfer is
possible through a 3708 (but only in non-fullscreen mode), and that
under TSO it is necessary to set the controller type to FULLSCREEN,
but only because 3708's are invariably connected via VTAM! Thus, I
want to know:
1. Does anybody know how to read Geoffrey Mendelson, formerly of
SUNGARD in Philadelphia?
2. Does anybody know of any 3708 experts who might be able to say
whether some kind of host-controlled dynamic switching between
protocol conversion mode and a transparent mode exists?
3. Can anyone think of a reason for NOT changing the name of the
Kermit-370 option from FULLSCREEN to VTAMTTY?
John
P.S. For the next several days, at least, my usual incarnation at
CFAAMP is off the net, but mail sent there will probably
reach me anyway. For the time being, PEPAP@CFA3 is a suitable
alternative.
From "(John F. Chandler) PEPMNT@CFAAMP.BITNET" Tue Jul 26 12:36:25 1988
Flags: 000000000000
Return-Path: <@CUVMB.CC.COLUMBIA.EDU:PEPMNT@CFAAMP.BITNET>
Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Tue 26 Jul 88 10:36:19-EDT
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 26 Jul 88 10:38:04 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 6095; Tue, 26 Jul 88 10:38:03 EDT
Date: Mon, 1988 Jul 11 17:20 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Subject: Re: kermit cms ver. 4.0
In-reply-to: A79%TAUNIVM.BITNET@CUVMA.CC.COLUMBIA.EDU message of Sun, 10 Jul 88
09:30:30 IST
Message-id: <PEPMNT.880711.172017.B0@CFAAMP.BITNET>
> I no longer have the letter that Georges sent to the list, but I thought
> that he was pointing out a little bug ...
The thing that puzzles me is why so many people seem to think that they
should set the SEND packet size in the first place. Judging by the
feedback I have seen (of which this is only the latest example), users
have an irresistable urge to do so, even though they (perhaps) know that
the size is determined by the RECEIVING Kermit. Would it be better to
have Kermit-370 respond "Size irrelevant for SEND" whenever a user tries
to set the send packet size above 96? Or possibly always? Should I
make the User's Guide even more explicit that the send packet size merely
reflects the size negotiated in the previous transfer?
John
From "Frank da Cruz <SY.FDC@CU20B.CC.COLUMBIA.EDU>" Tue Jul 26 13:18:21 1988
Flags: 000000000000
Mail-From: SY.FDC created at 26-Jul-88 11:18:15
Date: Tue 26 Jul 88 11:18:15-EDT
From: Frank da Cruz <SY.FDC@CU20B.CC.COLUMBIA.EDU>
Subject: Re: kermit cms ver. 4.0
To: IBM-KERMIT@CU20B.CC.COLUMBIA.EDU
In-Reply-To: <PEPMNT.880711.172017.B0@CFAAMP.BITNET>
Message-ID: <12417404155.43.SY.FDC@CU20B.CC.COLUMBIA.EDU>
The command SET SEND PACKET-LENGTH is for one thing only -- overriding the
negotiated length, but ONLY if the specified size is less than (or equal)
to the negotiated length. For example, if you're talking to a server that
has set its receive packet-length to, say, 1000, but you happen to know
that there's a multiplexor in the way which can't handle bursts of more than
200 characters, then you would SET SEND PACKET-LENGTH 200. On the other hand,
you can't use SET SEND PACKET-LENGTH to force the use of long packets when
the other Kermit doesn't want to (or can't). - Frank
-------
From fdc Tue Aug 23 18:45:39 1988
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA12713; Tue, 23 Aug 88 18:45:39 EDT
Date: Tue, 23 Aug 1988 18:45:38 EDT
From: Frank da Cruz <fdc@cunixc.cc.columbia.edu>
Subject: Testing
To: IBM-Kermit@cunixc.cc.columbia.edu
Message-Id: <CMM.0.88.588379538.fdc@cunixc.cc.columbia.edu>
The IBM-Kermit mailing list has been moved from CU20B to CUNIXC. If you
get this message, then it survived the move and still works. Otherwise...
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Tue Nov 8 17:11:57 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA00660; Tue, 8 Nov 88 17:11:57 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 08 Nov 88 17:12:09 EDT
Received: from MITVMA.MIT.EDU by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 0604; Tue, 08 Nov 88 17:12:08 EDT
Received: from CFAAMP.BITNET (PEPMNT) by MITVMA.MIT.EDU (Mailer X1.25) with
BSMTP id 1766; Tue, 08 Nov 88 12:37:39 EST
Date: Tue, 1988 Nov 8 12:19 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-Kermit@cunixc.cc.columbia.edu
Subject: Passwords in TSO
Message-Id: <PEPMNT.881108.121937.B0@CFAAMP.BITNET>
Roger Fajman tells me that he has support for reading password-protected
files in the NIH TSO Kermit, and it seems to me that it would be fairly
simple to add that capability to TSO Kermit-370. On the other hand, it
occurs to me that encouraging the use of passwords might be contrary to
the "openness" philosophy. Does anybody have any feelings about that?
John
From @cuvmb.cc.columbia.edu:MAINT@UQAM.BITNET Sat Nov 12 13:17:09 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA08590; Sat, 12 Nov 88 13:17:09 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Sat, 12 Nov 88 13:18:01 EDT
Received: from UQAM.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 5673; Sat, 12 Nov 88 13:18:00 EDT
Received: by UQAM (Mailer X1.25) id 7341; Wed, 09 Nov 88 16:36:18 EST
Resent-Date: Wed, 09 Nov 88 16:35:27 EST
Resent-From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Resent-To: IBM-KERMIT@cunixc.cc.columbia.edu
Date: Wed, 09 Nov 88 10:44:06 EST
From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Passwords in TSO
To: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Tue, 8 Nov 88 17:13:33 EDT from <PEPMNT@CFAAMP>
----------------------------Original message----------------------------
I don't see why the "openness" philosophy should necessarily apply to the
actual files transmitted with KERMIT. Indeed, KERMIT can be used to transmit
object code and word processing documents; both of these formats are, to some
extent "in code".I do feel, however that the workings of KERMIT itself and its
source code should always be readable.
From @cuvmb.cc.columbia.edu:MAINT@UQAM.BITNET Sat Nov 12 13:17:50 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA08609; Sat, 12 Nov 88 13:17:50 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Sat, 12 Nov 88 13:18:41 EDT
Received: from UQAM.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 5690; Sat, 12 Nov 88 13:18:39 EDT
Received: by UQAM (Mailer X1.25) id 7350; Wed, 09 Nov 88 16:42:01 EST
Resent-Date: Wed, 09 Nov 88 16:41:43 EST
Resent-From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Resent-To: IBM-KERMIT@cunixc.cc.columbia.edu
Date: Wed, 09 Nov 88 11:00:04 EST
From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Subject: REPLY TO OPENNESS COMMENT
To: IBM-KERMIT@cunixc.cc.columbia.edu
----------------------------Original message----------------------------
I don't see why the "openness" philosophy should necessarily apply to the
actual files transmitted with KERMIT. Indeed, KERMIT can be used to transmit
object code and word processing documents; both of these formats are, to some
extent "in code".I do feel, however that the workings of KERMIT itself and its
source code should always be readable.
From @cuvmb.cc.columbia.edu:MAINT@UQAM.BITNET Mon Nov 14 10:42:00 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA10689; Mon, 14 Nov 88 10:42:00 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 14 Nov 88 10:31:27 EDT
Received: from UQAM.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 7204; Mon, 14 Nov 88 10:31:25 EDT
Received: by UQAM (Mailer X1.25) id 0422; Mon, 14 Nov 88 10:28:33 EST
Resent-Date: Mon, 14 Nov 88 10:27:34 EST
Resent-From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Resent-To: IBM-KERMIT@cunixc.cc.columbia.edu
Received: from CUVMB.CC.COLUMBIA.EDU by UQAM.BITNET (Mailer X1.25) with BSMTP
id 9633; Sat, 12 Nov 88 13:22:23 EST
Received: by CUVMB (Mailer X1.25) id 5732; Sat, 12 Nov 88 13:19:02 EDT
Date: Wed, 9 Nov 88 16:35:27 EST
Reply-To: IBM-KERMIT@cunixc.cc.columbia.edu
Sender: IBM KERMIT developers <IBM-KERM%CUVMA.BITNET@cuvmb.cc.columbia.edu>
Comments: Resent-From: Peter Jones
<MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Comments: Originally-From: Peter Jones
<MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Passwords in TSO
Comments: To: IBM-KERMIT@cunixc.cc.columbia.edu
To: Peter Jones <MAINT@UQAM>
In-Reply-To: Message of Tue, 8 Nov 88 17:13:33 EDT from <PEPMNT@CFAAMP>
----------------------------Original message----------------------------
----------------------------Original message----------------------------
I don't see why the "openness" philosophy should necessarily apply to the
actual files transmitted with KERMIT. Indeed, KERMIT can be used to transmit
object code and word processing documents; both of these formats are, to some
extent "in code".I do feel, however that the workings of KERMIT itself and its
source code should always be readable.
From @cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET Tue Nov 22 04:40:42 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA22282; Tue, 22 Nov 88 04:40:42 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 22 Nov 88 04:41:08 EDT
Received: from VM1.EARN-ULG.AC.BE by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 8026; Tue, 22 Nov 88 04:41:07 EDT
Received: by BLIULG11 (Mailer X2.00) id 2679; Tue, 22 Nov 88 10:12:04 +0100
Date: Tue, 22 Nov 1988 10:11:55 +0100
From: Andre' PIRARD <A-PIRARD%BLIULG11.BITNET@cuvmb.cc.columbia.edu>
Subject: Kermit 370 trailing blanks trimming
To: IBM-KERMIT@cunixc.cc.columbia.edu,
Columbia University Center for Computing Activities
<INFO-KERMIT@cunixc.cc.columbia.edu>
A proposal was accepted someday not to trim trailing blanks
off variable length text records sent by 370 Kermit.
I just found a little hitch to this otherwise sensible decision.
God knows why, the CMS file system hates null-length records (as well as
empty files). CMS Kermit has consequently no other way to store a null line
than to make it a single blank. On its way back, this blank remains.
Software on micros can be sensitive to a record size being null and I used
to be pleased to see my long dated first tests of CMS Kermit get a file back
correctly, as opposed to what we used before.
It's an occasional nuisance only, but I wonder if it wouldn't be nice
to consider a record containing a single blank as the result of the above
and, by exception, send it with null length.
I can't think of another way to bypass this "feature".
The "other way round" nuisance (single blanks converted to nulls)
should be much less frequent in my opinion.
Andr).
From @cuvmb.cc.columbia.edu:GUCSL@SEGUC21.BITNET Tue Nov 22 04:41:10 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA22291; Tue, 22 Nov 88 04:41:10 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 22 Nov 88 04:41:37 EDT
Received: from gd3090.gd.chalmers.se by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 8036; Tue, 22 Nov 88 04:41:36 EDT
Received: from SEGUC21.BITNET (GUCSL) by gd3090.gd.chalmers.se (Mailer X1.25)
with BSMTP id 0448; Mon, 21 Nov 88 17:48:16 CET
Date: Mon, 21 Nov 88 17:36 CET
From: Stefan Lundberg <GUCSL%SEGUC21.BITNET@cuvmb.cc.columbia.edu>
Subject: Kermit-CMS for VM/XA?
To: <ibm-kermit@cunixc.cc.columbia.edu>
Hello,
Is there a version available of Kermit-CMS that works under
VM/XA SP1? I have tried to use Kermit-CMS V4.0 on our VM/XA system
but it does not work.
Best regards
Stefan Lundberg EARN/BITNET: <GUCSL@SEGUC21.BITNET>
Internet: <GUCSL@gd.chalmers.se>
Gothenburg Universities'
Computing Centre Phone: +46-31810720
Box 19070 Fax: +46-31185006
S-400 12 Gothenburg
SWEDEN
From VVVCU@CUVMB.BITNET Tue Nov 22 11:42:10 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA17448; Tue, 22 Nov 88 11:42:10 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 22 Nov 88 11:42:37 EDT
Received: by CUVMB (Mailer X1.25) id 8741; Tue, 22 Nov 88 11:42:36 EDT
Date: Tue, 22 Nov 88 11:42 EST
From: Vace Kundakci <VVVCU@CUVMB.columbia.edu>
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Kermit 370 trailing blanks trimming; Andre' PIRARD <A-PIRARD%BLIULG
In-Reply-To: Your msg of : Tue, 22 Nov 88 10:11:55 +0100
I agree. I would like to see a CMS variable file record containing
a single blank to be sent to the micro as a null line. No other
blanks should be trimmed from variable records.
/Vace
------
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Tue Nov 22 12:35:38 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA20987; Tue, 22 Nov 88 12:35:38 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 22 Nov 88 12:36:05 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 8949; Tue, 22 Nov 88 12:36:04 EDT
Date: Tue, 1988 Nov 22 12:26 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Kermit-CMS for VM/XA?
In-Reply-To: GUCSL%SEGUC21.BITNET@CUVMB.CC.COLUMBIA.EDU message of Mon, 21 Nov
88 17:36:00 CET
Message-Id: <PEPMNT.881122.122634.B0@CFAAMP.BITNET>
According to Bob Bolch, the problem is not VM/XA, but CMS/XA. In other
words, Kermit-CMS 4.0 works under CMS 5 under VM/XA. Bob says that IBM
doesn't bless that combination, but that it works fine at TUCCVM. He has
also volunteered to make the updates needed for getting Kermit to work
under CMS/XA, but I don't know what the time scale is. I also don't
know whether the end result will be compatible with non-XA CMS, but
we'll see. If anyone else is in a hurry to get a Kermit-XA, I'm sure
Bob won't mind if you beat him to it, but let's try not to duplicate
effort -- let Bob or me know what you have in mind before coding.
John
From VVVCU@CUVMB.BITNET Wed Nov 23 12:48:39 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA09541; Wed, 23 Nov 88 12:48:39 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 23 Nov 88 12:48:20 EDT
Received: by CUVMB (Mailer X1.25) id 1397; Wed, 23 Nov 88 12:48:19 EDT
Received: from CUNYVM.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 1117; Wed, 23 Nov 88 11:21:38 EDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer X2.00) with BSMTP id 3683; Wed,
23 Nov 88 11:19:47 EDT
Received: from operations.dccs.upenn.edu by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1)
with TCP; Wed, 23 Nov 88 11:15:30 EDT
Return-Path: <YATES@a.chem.upenn.edu>
Received: from A.CHEM.UPENN.EDU by operations.dccs.upenn.edu
id AA25266; Wed, 23 Nov 88 11:07:05 EST
Message-Id: <8811231607.AA25266@operations.dccs.upenn.edu>
Date: Wed, 23 Nov 88 11:16 EST
From: "Yates, John H." <YATES@a.chem.upenn.edu>
Subject: IBM 9000 KERMIT version?
To: vvvcu@cuvma.bitnet
X-Vms-To: IN%"vvvcu@cuvma.bitnet",YATES
Resent-Date: Wed, 23 Nov 88 12:48 EST
Resent-From: Vace Kundakci <VVVCU@CUVMB.columbia.edu>
Resent-To: ibm-kermit@cunixc.cc.columbia.edu
I have a user with an IBM 9000 (sold by IBM Instrument Division to
spectroscopy customers a few years back). The processor is based
on a 68000 8-MHz microprocessor, and the operating system is
CSOS (Computer System Operating System).
It has Fortran, Pascal, Basic, and Assembler.
Do you have any idea which version(s) of KERMIT would or might
work on it? Thanks, John
*************************************************
John H. Yates , Ph.D.
Director of the Chemistry Computer Facility
Department of Chemistry
University of Pennsylvania
Philadelphia, PA 19104
yates%a.chem@upenn.edu (INTERNET)
(215)898-4714
*************************************************
From @cuvmb.cc.columbia.edu:MAINT@UQAM.BITNET Mon Dec 5 12:37:52 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA22789; Mon, 5 Dec 88 12:37:52 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 05 Dec 88 12:37:12 EDT
Received: from UQAM.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 3962; Mon, 05 Dec 88 12:37:10 EDT
Received: by UQAM (Mailer X1.25) id 2532; Mon, 05 Dec 88 12:28:39 EST
Resent-Date: Mon, 05 Dec 88 12:27:30 EST
Resent-From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Resent-To: IBM-KERMIT@cunixc.cc.columbia.edu
Date: Mon, 05 Dec 88 11:11:14 EST
From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Kermit-CMS
To: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Mon, 5 Dec 88 10:48:59 SET from <FUTO@CGEUGE11>
We have a similar problem at UQAM. We use a STKM11 protocol converter.
This is a locally-made product that converts between 3278 BSC and ASCII, but
lacks a transparency mode. We also used to have SIM3278, a 370 software-only
protocol converter that runs in a service machine under VM. I've seen
reports that KERMIT file transfers don't work under SIM3278. Maybe SIM3278 is
a solution, but needs some work.
Peter Jones
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Mon Dec 5 15:58:16 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA07579; Mon, 5 Dec 88 15:58:16 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 05 Dec 88 15:57:38 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 4364; Mon, 05 Dec 88 15:57:36 EDT
Date: Mon, 1988 Dec 5 15:53 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Kermit-CMS
In-Reply-To: FUTO@CGEUGE11 message of Mon, 5 Dec 88 10:48:59 SET
Message-Id: <PEPMNT.881205.155300.B0@CFAAMP.BITNET>
There is a file containing a guide to implementing support for new
types of terminal controller. It is called IK0CON.HLP and is
available from KERMSRV, etc. With this guide it should be possible
for any assembly language programmer to add support for any controller
that provides a usable transparent mode. As far as I know, SIM3270
is still not suitable. I welcome comments on strenths and weaknesses
of IK0CON.HLP -- if any improvements seem warranted, I'll revise it
for the 4.1 release (coming soon).
From @cuvmb.cc.columbia.edu:XRHAH@SCFVM.BITNET Mon Dec 5 16:33:01 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA10072; Mon, 5 Dec 88 16:33:01 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 05 Dec 88 16:32:23 EDT
Received: from SCFVM.GSFC.NASA.GOV by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 4524; Mon, 05 Dec 88 16:32:21 EDT
Received: by SCFVM (Mailer X1.25) id 2751; Mon, 05 Dec 88 16:23:19 EST
Date: Mon, 05 Dec 88 16:14:34 EST
From: "Herbert A. Huston" <XRHAH%SCFVM.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Kermit-CMS
To: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>,
IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Mon, 5 Dec 88 12:27:30 EST from
<MAINT%UQAM.BITNET@CUVMB.CC.COLUMBIA.EDU>
> We also used to have SIM3278, a 370 software-only
>protocol converter that runs in a service machine under VM. I've seen
>reports that KERMIT file transfers don't work under SIM3278. Maybe SIM3278 is
>a solution, but needs some work.
Just recently I was handed the installation tape for SIM3278/VM, Version 3.6.
To check transparency I brought up the module on the tape in a test virtual
machine and found that it did not work correctly using CMS Kermit 4.0 and
MS-DOS Kermit 2.31. I have not had time to investigate. However, for every-
one's edification I am appending an extract from the installation guide.
SIM3278/VM is marketed by SIMWARE, Inc., 20 Colonnade Road, Ottawa, Ontario,
Canada K2E 7M6. Their telephone number is (613)727-1779.
-- Herb
APPENDIX C. DATA TRANSPARENCY
_____________________________
You may wish to use data transparency for one of the following
reasons:
To send non-protocol converted data to an ASCII terminal.
Your terminal may permit incoming data to go directly to a printer
port, or your terminal may have graphic capabilities which require
special ASCII control codes to draw complex screen images.
In either case, the SIM3278/VM conversion software must not tamper
with the ASCII data. A signal can be used to inform SIM3278/VM to
leave the data "as is", and let it pass transparently through to the
terminal or PC.
SIM3278/VM uses a special 3270 screen address sequence to invoke the
data transparency mode of operation. All data following this special
screen address will be routed directly through to the output device
without going through the 3270 to ASCII protocol conversion process.
This feature is useful for downloading special control codes or
functions to program function (PF) keys or softkeys. Although
SIM3278/VM performs optional downloading of softkeys during
connection, the data transparency feature allows softkey or PF key
loading anytime during the SIM3278/VM session. Information about
downloading softkeys is contained in Appendix D of this manual.
Simware has chosen to be compatible with a suggested IBM
implementation of data transparency as defined for the IBM Series/1
YALE IUP emulation system. The IBM/YALE system defines a special
screen address sequence which is impossible to use on a real 3278
terminal, but is easily detectable by a 3270 emulation system,
including SIM3278/VM.
Your own module may be created using VM/CMS software such as IBM's
DMS/CMS product, or, you could write your own assembler language
program using the documented IBM 3270 interface called DIAGNOSE X'58'
(see the VM/SP System Programmer's Guide for more information).
The special screen address sequence must precede the transparent data,
so that SIM3278/VM will not interfere with it as it passes through to
the terminal or PC. The special screen address is the six byte
hexadecimal string X'115D7F110000'. The last three bytes are actually
the "impossible" screen address (the IBM/YALE sequence). If you write
your own program, it will have to issue a fullscreen output command
with a buffer that begins the 3270 opcode (for example, WRITE, or
ERASE WRITE), a Write Control Character (WCC), and the special data
transparency sequence, followed by the transparent data itself.
Appendix C. Data Transparency 79
An example of the command might be:
opcode WCC X'115D7F110000' special-data
...... which in assembler language might be ......
BUFFER DC X'F1',X'C2',X'115D7F110000',X'0227ADF7950E27ADF18303'
All transparent data or groups of data containing transparency sent by
the host must be preceded by the special data transparency sequence.
SIM3278/VM returns to normal mode upon completion of transmission of
the datastream; therefore, data transparency only applies to a single
buffer of data.
Note that SIM3278/VM will perform EBCDIC-to-ASCII translation on the
data in the file. This translation to ASCII is the only modification
of the data done by SIM3278/VM. It is useful to note that the special
screen address transparency sequence is not passed on to the terminal.
In the case where a printer is attached, the terminal permits
"print-through" by means of some type of Escape or Control code, so a
code that turns the terminal's printer port on must be supplied. An
EXEC called SIMPRINT can now be used to transfer host data files onto
a PC-attached printer or plotter.
The following represents the contents of a sample data file to be
transmitted to a PC-attached printer:
X'F1C3115D7F110000' (begin-transparency sequence)
X'27C3AD03' (a sample print-through sequence)
...data for the attached printer...
A screen CLEAR (pressing Clear or the assigned key sequence) should be
issued following a transparent screen write. SIM3278/VM assumes that
the data sent to the ASCII line is going to a terminal. The state of
the virtual screen is somewhat unpredictable once transparent mode is
entered, and may vary from terminal to terminal.
Appendix C. Data Transparency 80
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Mon Dec 5 18:43:10 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA18874; Mon, 5 Dec 88 18:43:10 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 05 Dec 88 18:42:33 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 4801; Mon, 05 Dec 88 18:42:32 EDT
Date: Mon, 1988 Dec 5 17:37 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Kermit-CMS
In-Reply-To: XRHAH%SCFVM.BITNET@CUVMB.CC.COLUMBIA.EDU message of Mon, 5 Dec 88
16:14:34 EST
Message-Id: <PEPMNT.881205.173739.B0@CFAAMP.BITNET>
> Just recently I was handed the installation tape for SIM3278/VM, Version 3.6.
..
> You may wish to use data transparency for one of the following
> reasons:
>
> To send non-protocol converted data to an ASCII terminal.
>
> Your terminal may permit incoming data to go directly to a printer
> port...
Note that both of these are purely for downloading. No mention is made
of uploading anything! mper
> hexadecimal string X'115D7F110000'. The last three bytes are actually
> the "impossible" screen address (the IBM/YALE sequence).
Note that this is the string defined in the Yale ASCII system for Write
only, not Write/Read.
> Note that SIM3278/VM will perform EBCDIC-to-ASCII translation on the
> data in the file. This translation to ASCII is the only modification
> of the data done by SIM3278/VM.
This is specifically INcompatible with the Yale ASCII implementation.
Say it ain't so! (Note that there are no examples in the text of what
comes out to the terminal). If this is true, then all the Series/1-type
transparent utilities, including Kermit and Yale's TPRINT will fail
when going through SIM3270.
John
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Wed Dec 21 15:26:21 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA23427; Wed, 21 Dec 88 15:26:21 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 21 Dec 88 15:25:49 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 2661; Wed, 21 Dec 88 15:25:48 EDT
Date: Wed, 1988 Dec 21 13:51:05 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-Kermit@cunixc.cc.columbia.edu
Subject: New guide for porting Kermit-370
Message-Id: <PEPMNT.881221.135105.B0@CFAAMP.BITNET>
The following is a first cut at a "porting" guide. I welcome any
comments or suggestions. For example, the text now includes some
extracts from the Kermit source code -- should it have *all* the
similar source self-documentation? Also, what questions come to
mind that are not covered here? This document is the result of
answering questions that came up in the course of porting Kermit-370
to the MUSIC operating system (done by Pierre Goyette at McGill),
so everything that he figured out on his own is glossed over.
John
---------
Notes on porting Kermit-370 to other operating systems.
In general, the operation of porting Kermit-370 entails starting from
one or more existing versions of the system-specific code (IKxMAC.ASM
and IKxUTL.ASM) and replacing one set of system-specific code with
another. Each subroutine has comments documenting the interface with
the rest of the program, and a fair amount of the code itself deals with
such bookkeeping details and can be carried over. Similarly, each macro
begins with a brief function/syntax description.
------------------------------------------------------------------------
FSPEC. Notes from source code:
* Entry: R1->name field, R0=flags selecting operation (see below)
* For parse operations, SCANPTR defines the input string.
* For getting foreign or display filespec, R7->output buffer
* Exit: if not FFNEW, then R15=0 if ok, 1 if ?, 2 if bad.
* For R15=1 or 2 R3,R4 give message. ERRNUM may be leftover.
*
* Flags: Notes:
* Tasks: FFRCF FFSND FFGET FFNEW
* Parse RECV X set ROVR properly
* Parse SEND 1st X
* Parse SEND 2nd X X
* Parse GET 1st X
* Parse GET 2nd X X set ROVR properly
* Parse F-packet (FFHDR) X X X
* Parse for Generic(FFUTL) X X FFWLD: allow partial
* Parse TAKE
*
* Get unique name X R15: 0=>ok, 1=>bad
* Interactive name check X X R15: 0=>ok, 1=>bad
* Get foreign name (FFENC) X X R15->end of string
* Get display form (FFDSP) X X R15->end of string
Further explanation of entry conditions -
"name field" is a fixed-length string of length LFID to be filled with
the internal representation of a file name. SCANPTR is a pair of
pointers (LEN, ADR) of a character string to be parsed, typically a
string typed by the user, possibly in lower case.
FSPEC parses out one filename at a time. There is, of course, the
alternate command syntax for SEND that allows the user to specify a list
of files. The only contribution of FSPEC, to the parsing is to note the
delimiter it finds after the name, and the list control is managed by
the generic code.
SEND takes one or two parameters, namely, the native filename and,
optionally, a different filename to send to the other Kermit. A
reversed pair of parameters is taken for the GET subcommand: a required
"foreign" filename and an optional overriding "native" one. Foreign
filenames, since they depend on the system of the other Kermit, might be
thought of as independent of the IBM/370 operating system, but
Kermit-CMS offers a special syntax extension that isn't implemented in
Kermit-TSO. Anyway, that is the meaning of SEND 1st, etc. The foreign
filename, by the way, is stored in JFSPEC, which is a varying-length
string in COMMON (one-byte length indicator, followed by a maximum of 47
bytes). "Parse RECV", in case that's not clear, means grab the
filename, if any, entered on the RECEIVE subcommand, and (as the Note
says), set flag ROVR in FL1, if a filename is actually found. I also
note that the code clears flag NMOK in FL4 (in the CMS version), but
that happens to be part of the internal logic of FSPEC to avoid
duplicate efforts in filename collision testing. "Parse F-packet" means
grab a (valid) filename from the file header sent from the other Kermit.
"Parse for Generic" means grab a filename from the text string sent by
the other Kermit for one of the Generic Server mode commands. The
corresponding Note says that FFWLD set in the input flags means that
part or all of the filename can be omitted to indicate all matching
files, as in the DIRECTORY command. "Parse TAKE" means grab a file name
from the text of a TAKE subcommand.
The difference between "Get unique name" and "Interactive name check" is
that the latter is permitted to type out a message and query the user
for further instructions if necessary (as might be the case when the
user types RECEIVE DUP.FILE), while the former must either find a unique
name, or return an error condition. "Get foreign name" means putting
the foreign filespec into a buffer (in ASCII) with JFSPEC taking
precedence over whatever is found at (R1). Finally, "Get display form"
is just the reverse of the various parse operations: the internal
representation is converted to conventional external representation
(with excess blanks, if any, removed according to whatever convention
holds).
------------------------------------------------------------------------
FDB. File Descriptor Block + File Access Block:
In IKxMAC.ASM, the FDBD macro has two parts, an FAB and FDB. The FAD is
intended to map the operating system's macro, whereas the FDB is
Kermit's local variables. Some of the variables in the FDB are used
throughout the generic Kermit code. The common part begins at FDBD and
includes everything mapped by FDBPAT macro, and also includes FABLRTR,
which is a recent addition giving the maximum record length for output
to a file (which may in CMS, for example, differ from the current
largest record length).
------------------------------------------------------------------------
SCRNIO. Fullscreen packet I/O. Comments from source:
* R1 points to a pair of (adr,len) for read or write. If I/O is
* successfull, R15 returns transferred byte count (else returns -1).
* Command code is in R0:
* 1 => Open screen for I/O 4 => Write packet
* 2 => Close screen 5 => Read packet
* 3 => Reset screen status after 6 => Write message
* environment changes
For the Series/1 interface (and whenever else possible), Kermit-370
takes advantage of a Read chained to a Write to speed up the I/O.
Actually, the operation is chained by the Series/1, so Kermit issues
both a write and a read synchronized by a hardware interrupt from the
Series/1.
In principle, all you need to know is the sequence of calls to SCRNIO.
You can handle the system interface in any convenient manner. The
sequence is (by R0 code): 1, 6 (with greetings message), 4, 5, 4, 5, ...
4, 5, 2. The value of WRRD determines whether a "4" means Write/Read
(value is 5) or just Write (value is 0) -- that value will always be 5
except possibly the last time. Even if WRRD is 0 on the last call with
R0=4, there will still be a call with R0=5 just afterwards, followed by
a call to release control of the screen.
The difference between "4" and "6" is just that no read is required
following a "6". Also, "6" is intended for displaying messages to the
user, in case he's watching, but "4" is for sending to the micro Kermit.
------------------------------------------------------------------------
TERMIO. Similar to SCRNIO in many respoects.
TTY buffer limits are defined by symbols MAXWT and MAXRT set in the
macro SSYMS. Note that everything in SSYMS must be redefined in porting
as well as most things in KSYSTF.
The way to signal a timeout from TERMIO is to return a packet of exactly
one character: an ASCII 'T'. You can see an example by looking at the
TSO version.
------------------------------------------------------------------------
Type-out interception.
Intercepting host command output depends on the operating system
facilities. In any case, the info would go directly to the screen
unless you first call SUPFNC,1 to start typeout interception. For
example, under CMS that means intercepting all SVC's (and BALR's to the
system typeout entry point) and copying the corresponding info into a
buffer as it's generated (leaving x'15' separators). That sort of
operation is self-pacing, so that the cleanup consists of nothing more
than copying the end-of-buffer pointer into a global variable. Under
TSO, the setup call creates a STACK entry such that the TSO-type
utilities will write to a pre-allocated dataset. Cleanup in that case
consists of closing the file and then reading the file into the buffer,
again with X'15' (Newline) characters separating lines, and finally
copying out the end-of-buffer pointer.
If there's no general way to save the output of a class of utility
programs, then you would just have to do what you can: put any
preliminaries in SUPFNC,1 and the nitty-gritty (for, say, DIR) in
DISKIO,13 with the buffer-read-back in SUPFNC,2/SUPFNC,5. You might
want to get a copy of TSO Kermit to see how it does things.
The expansion for WTEXT in the TSO version generates a call to a
subroutine in COMMON which checks the interception flags and then either
issues a TPUT or copies the info into the output buffer.
------------------------------------------------------------------------
GUPI.
Updates for Kermit-370 are in the same format as in CMS, except that the
multi-level updates are applied from a single, concatenated file, rather
than a flock of separate updates listed by an AUX. You should take a
look at implementing the generic update program GUPI for your operating
system.
Bear in mind that you're starting off with lots of updates to the base
generic source, so the "package" for installation must include a means
of applying those, and it would also be nice if subsequent changes can
be transmitted to MUSIC systems in the same form as is used for CMS and
TSO. In any case, instructions for applying updates should be included
in the IKxKER.BWR file (see IKCKER.BWR for a pattern). It is pretty
easy to make a GUPI, once you've got Kermit: just take subroutine DISKIO
(functions 1, 2, 3, 4, 9, and 10) plus any associated data structures
and tack on a command interface. GUPI uses the same macros as Kermit.
You can see a working example by getting IKTGUP.ASM + IK0GUP.ASM from
Columbia. The only complication is that you'll need to make a macro
library consisting of the macros in IK0MAC.ASM, IKxMAC.ASM, and
IKxGUP.ASM.
------------------------------------------------------------------------
Miscellaneous notes.
1. Does your o.s. have a LINEND character facility like VM? If not, it
might pay to copy the implementation of that from TSO Kermit. This
will, of course, mean some changes to IKxMAC.
2. Would TAKE files generated by Kermit users tend to have line
numbers imbedded? If so, it would pay to copy/adapt the stripping
facility of TSO or CMS Kermit.
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Thu Dec 29 12:05:06 1988
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA22838; Thu, 29 Dec 88 12:05:06 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 29 Dec 88 12:04:59 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 7003; Thu, 29 Dec 88 12:04:58 EDT
Date: Thu, 1988 Dec 29 11:40:35 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-Kermit@cunixc.cc.columbia.edu
Subject: Packet-length tuning
Message-Id: <PEPMNT.881229.114035.B0@CFAAMP.BITNET>
Currently, Kermit-370 responds to a noisy transmission line by computing
the optimum packet size (based on the cumulative error statistics) after
the first 30 packets and every 20 packets thereafter. This applies, of
course, only when long packets are being transmitted. I am in the
process of upgrading this procedure by (A) taking a possible fixed
packet turnaround delay into account, (B) requiring the user to specify
the baud rate on the line, (C) allowing the user to suppress the tuning
by specifying a rate of 0, and (D) changing the computation to refer to
a moving average of the (instead of the cumulative) transmission
statistics. Two questions: how often should the tuning be done and how
long a memory should the moving average have? These are, in fact,
closely related, since I am figuring on averaging over a period equal to
three times the spacing. Clearly, even temporal spacing would be
attractive, but it would require a good deal of new system-specific
programming. Hence, I think a spacing based on counting packets is the
only option. Perhaps the count should be tied to the current packet size
and the transmission speed -- does that seem worthwhile?
John
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Mon Jan 9 22:14:56 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA21993; Mon, 9 Jan 89 22:14:56 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 09 Jan 89 22:13:08 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 5271; Mon, 09 Jan 89 22:13:07 EDT
Date: Mon, 1989 Jan 9 21:59:34 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-Kermit@cunixc.cc.columbia.edu
Subject: TSO password-protected datasets
Message-Id: <PEPMNT.890109.215934.B0@CFAAMP.BITNET>
I'm looking for someone to test a new version of Kermit that can read
password-protected datasets. The updates relative to the current IK0 +
IKT sources at Columbia are relatively compact, but they're of interest
only to TSO people, so I won't include them here. The new version also
can read uncataloged datasets. So far, the only people who have "fully"
tested the new code either don't have password-protected datasets or
have "funny" local mods to the password system. Anybody out there have
(or have the possibility of creating) vanilla password-protected datasets
and care to try Kermit on them?
John
From VVVCU@CUVMB.BITNET Tue Jan 10 17:48:31 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA27470; Tue, 10 Jan 89 17:48:31 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 10 Jan 89 17:46:44 EDT
Received: by CUVMB (Mailer X1.25) id 6555; Tue, 10 Jan 89 17:46:43 EDT
Date: Tue, 10 Jan 89 17:46 EST
From: Vace Kundakci <VVVCU@CUVMB.columbia.edu>
To: ibm-kermit@cunixc.cc.columbia.edu
Subject: Sending a piece of a file
Although I mentioned this to John recently, I would like to solicit
public comments about this: How would you like to be able to send
from IBM-kermit a file starting at a specific recno thru an
ending recno or a certain numrec? It may be difficult to add
these options on the SEND command syntax, but a separate SET
command may specify these prior to the send command. One possible
use may be to continue transfering a large file which aborted
due to line noise, or sending a chunk of a large file (such as a
Maclib member) without constructing a temp file using COPYFILE or
whatever equivalent there are in other IBM environments.
/Vace
------
From @cuvmb.cc.columbia.edu:MAINT@UQAM.BITNET Wed Jan 11 18:11:32 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA29091; Wed, 11 Jan 89 18:11:32 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 11 Jan 89 18:10:11 EDT
Received: from UQAM.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 8156; Wed, 11 Jan 89 18:10:09 EDT
Received: by UQAM (Mailer X1.25) id 7866; Wed, 11 Jan 89 18:06:49 EST
Resent-Date: Wed, 11 Jan 89 18:06:36 EST
Resent-From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Resent-To: ibm-kermit@cunixc.cc.columbia.edu
Date: Wed, 11 Jan 89 17:59:02 EST
From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Sending a piece of a file
To: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Tue, 10 Jan 89 17:46:00 EST from
<VVVCU@CUVMB.COLUMBIA.EDU>
----------------------------Original message----------------------------
Good idea. How about making it possible for the recipient to be able
to specify what he wants, e. g. a SERVER user could pick out pages 47 to 51
of a large listing file, for example, using a variant of the GET command.
Ability to specify the limits of the transmission by string search would
also be useful.
From @cuvmb.cc.columbia.edu:RAF@NIHCU.BITNET Wed Jan 11 18:22:40 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA29730; Wed, 11 Jan 89 18:22:40 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 11 Jan 89 18:21:17 EDT
Received: from NIHCU.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 8285; Wed, 11 Jan 89 18:21:16 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: "Roger Fajman" <RAF%NIHCU.BITNET@cuvmb.cc.columbia.edu>
Date: Wed, 11 Jan 89 18:18:13 EST
Subject: Re: Sending a piece of a file
> Although I mentioned this to John recently, I would like to solicit
> public comments about this: How would you like to be able to send
> from IBM-kermit a file starting at a specific recno thru an
> ending recno or a certain numrec? It may be difficult to add
> these options on the SEND command syntax, but a separate SET
> command may specify these prior to the send command. One possible
> use may be to continue transfering a large file which aborted
> due to line noise, or sending a chunk of a large file (such as a
> Maclib member) without constructing a temp file using COPYFILE or
> whatever equivalent there are in other IBM environments.
> /Vace
> ------
I don't see that as being terribly useful. What would be nice is the
ability to resume an interrupted file transfer. Of course that
requires a protocol change, whereas sending a piece of a file does not.
Roger
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Wed Jan 11 19:01:07 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA01734; Wed, 11 Jan 89 19:01:07 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 11 Jan 89 18:59:46 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 8457; Wed, 11 Jan 89 18:59:44 EDT
Date: Wed, 1989 Jan 11 18:50:32 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Sending a piece of a file
In-Reply-To: Message of Tue,
10 Jan 89 17:46:00 EST from <VVVCU@CUVMB.COLUMBIA.EDU>
Message-Id: <PEPMNT.890111.185032.B0@CFAAMP.BITNET>
It occurs to me that Kermit-370, already having SET MARGIN LEFT|RIGHT,
would easily adopt TOP and BOTTOM margins.
In a similar vein, is there a consensus on syntax for specifying that a
wildcard SEND should begin with some file after the first?
John
From @cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET Thu Jan 12 08:52:49 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA10979; Thu, 12 Jan 89 08:52:49 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 12 Jan 89 08:51:26 EDT
Received: from VM1.EARN-ULG.AC.BE by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 9240; Thu, 12 Jan 89 08:51:25 EDT
Received: by BLIULG11 (Mailer R2.02) id 2303; Thu, 12 Jan 89 14:50:48 +0100
Date: Thu, 12 Jan 89 14:38:53 +0100
From: Andre' PIRARD <A-PIRARD%BLIULG11.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Sending a piece of a file
To: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Wed, 11 Jan 89 19:01:02 EDT from <PEPMNT@CFAAMP>
>In a similar vein, is there a consensus on syntax for specifying that a
>wildcard SEND should begin with some file after the first?
This needs the prerequisite consensus of *what* is the first, so that it
be repeatable on all systems from one transfer to the next.
I guess CMS Kermit uses the same search order as the LIST command.
Beware this order is not always alphabetical until you reaccess the minidisk.
And even then, I would not swear.
This could play bad tricks.
Andr).
From @cuvmb.cc.columbia.edu:MAINT@UQAM.BITNET Thu Jan 12 12:30:45 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA26236; Thu, 12 Jan 89 12:30:45 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 12 Jan 89 12:29:43 EDT
Received: from UQAM.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 9752; Thu, 12 Jan 89 12:29:40 EDT
Received: by UQAM (Mailer X1.25) id 8281; Thu, 12 Jan 89 12:19:49 EST
Date: Thu, 12 Jan 89 12:19:13 EST
From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Subject: Partial transmission of files in KERMIT
To: IBM-KERMIT@cunixc.cc.columbia.edu
Good idea. How about making it possible for the recipient to be able
to specify what he wants, e. g. a SERVER user could pick out pages 47 to 51
of a large listing file, for example, using a variant of the GET command.
Ability to specify the limits of the transmission by string search would
also be useful.
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Thu Jan 12 15:32:47 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA08676; Thu, 12 Jan 89 15:32:47 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 12 Jan 89 15:31:45 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 0355; Thu, 12 Jan 89 15:31:43 EDT
Date: Thu, 1989 Jan 12 14:59:11 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Sending a piece of a file
In-Reply-To: A-PIRARD%BLIULG11.BITNET@CUVMB.CC.COLUMBIA.EDU message of Thu, 12
Jan 89 14:38:53 +0100
Message-Id: <PEPMNT.890112.145911.B0@CFAAMP.BITNET>
> Beware this order is not always alphabetical until you reaccess the minidisk.
> And even then, I would not swear.
It's true that a read/write minidisk can get out of order, but the only
files out of place are the new ones (since the disk was last accessed).
Re-accessing always puts everything back in order. In any case, if a
wildcard send is interrupted and then promptly resumed, the order will
be exactly the same the second time (unless some of the files are
changed/added/deleted). I believe the order of catalog scan for TSO
files is invariant -- what about other operating systems? Does
anyone have any info to offer?
On the other hand, no one has come up with a syntax. What I had in
mind was something like
SEND filespec[starting-file]
or
SEND filespec[last-file-to-skip]
Unfortunately (from the standpoint of generality), square brackets are
among those characters that get mangled in translation. Also, lots of
other special characters are out of the question for various reasons,
including TSO, CMS, Series/1, and translation concerns. What's left is:
!"&^=~}`;<>
I'm sure there are other reasons for eliminating some more of these --
any comments?
John
From @cuvmb.cc.columbia.edu:RAF@NIHCU.BITNET Thu Jan 12 18:59:33 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA21106; Thu, 12 Jan 89 18:59:33 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 12 Jan 89 18:58:31 EDT
Received: from NIHCU.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 0832; Thu, 12 Jan 89 18:58:30 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: "Roger Fajman" <RAF%NIHCU.BITNET@cuvmb.cc.columbia.edu>
Date: Thu, 12 Jan 89 18:59:09 EST
Subject: Re: Sending a piece of a file
In NIH TSO Kermit we use
SEND wildcard-dsname:starting-dsname
For non-wildcard dsnames we allow sending the file with a different name:
SEND dsname:filename
or
SEND dsname:"filename"
The second form is used when the filename contains special characters
(such as colon).
Any of the forms may be specified multiple times in a SEND command,
allowing several files with unrelated names to be sent in one command.
The same forms are also allowed in GET packets.
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Thu Jan 12 19:57:38 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA22844; Thu, 12 Jan 89 19:57:38 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 12 Jan 89 19:56:36 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 1040; Thu, 12 Jan 89 19:56:35 EDT
Date: Thu, 1989 Jan 12 19:14:14 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Sending a piece of a file
In-Reply-To: RAF%NIHCU.BITNET@CUVMB.CC.COLUMBIA.EDU message of Thu, 12 Jan 89
18:59:09 EST
Message-Id: <PEPMNT.890112.191414.B0@CFAAMP.BITNET>
> In NIH TSO Kermit we use
>
> SEND wildcard-dsname:starting-dsname
Aha. That's similar to what I had in mind. Of course, the colon ":"
is no good for a generic syntax (you'll notice it was not on my list)
because it is a valid character for filespecs in CMS and in MUSIC.
Would anybody be upset by this syntax:
SEND filespec > last-filespec-to-skip
There is the basic question of whether it's better to give the name of
the last file to skip or the first one to send -- I'm inclined to
favor the former because it will be apparent from the list of files
already received by the other Kermit, while the first file NOT sent is
a bit more tedious to figure out. All this, of course, would have to
fit into the overall SEND syntax:
SEND [ fspec1 [> last-skip1] [foreign-fspec1] ] [, fspec2 ...]
Other suggestions?
John
From @cuvmb.cc.columbia.edu:RAF@NIHCU.BITNET Thu Jan 12 21:05:38 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA04760; Thu, 12 Jan 89 21:05:38 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 12 Jan 89 21:04:37 EDT
Received: from NIHCU.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 1280; Thu, 12 Jan 89 21:04:35 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: "Roger Fajman" <RAF%NIHCU.BITNET@cuvmb.cc.columbia.edu>
Date: Thu, 12 Jan 89 21:05:03 EST
Subject: Re: Sending a piece of a file
The character > has a pretty well-established meaning in Unix and
MS-DOS. Could be confusing to people (and disastrous if specified on
the Kermit command line). We figured that just about any character we
picked would be legal in someone's file names. That's why we allow the
foreign filespec to be quoted. Colons are legal in MS DOS. Commas are
legal on the DEC-10 (as in XXX.TXT[411,747]). Of course, I realize
that what you are most concerned about is what characters are legal on
the system where Kermit-370 is running.
I believe that the "ideal Kermit" specification calls for starting file
name, rather than last sent.
From @cuvmb.cc.columbia.edu:MAINT@UQAM.BITNET Fri Jan 13 11:56:03 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA14601; Fri, 13 Jan 89 11:56:03 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 13 Jan 89 11:55:02 EDT
Received: from UQAM.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 2049; Fri, 13 Jan 89 11:55:00 EDT
Received: by UQAM (Mailer X1.25) id 8843; Fri, 13 Jan 89 11:55:13 EST
Resent-Date: Fri, 13 Jan 89 11:54:24 EST
Resent-From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Resent-To: IBM-KERMIT@cunixc.cc.columbia.edu
Date: Fri, 13 Jan 89 11:35:51 EST
From: Peter Jones <MAINT%UQAM.BITNET@cuvmb.cc.columbia.edu>
Subject: Sending partial files in KERMIT
To: IBM-KERMIT@cunixc.cc.columbia.edu
For the syntax of a partial send command, I suggest looking at
the EXECIO command in CMS. The only special character required is the
left parenthesis. This command allows partial transmission based on
record numbers and/or strings, selecting margins, negative searches, and
searches at the beginning of a record or aynwhere in the record. The only
functionality missing is compound expression searches like in XEDIT, i.e.
there is currently no way to search for "apple" AND NOT "orange", in
CMS version 5.
Peter Jones
From @cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET Fri Jan 13 15:21:41 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA29632; Fri, 13 Jan 89 15:21:41 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 13 Jan 89 15:20:40 EDT
Received: from VM1.EARN-ULG.AC.BE by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 2510; Fri, 13 Jan 89 15:20:38 EDT
Received: by BLIULG11 (Mailer R2.02) id 2660; Fri, 13 Jan 89 10:37:09 +0100
Date: Fri, 13 Jan 1989 10:23:22 +0100
From: Andre' PIRARD <A-PIRARD%BLIULG11.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Sending a piece of a file
To: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Thu, 12 Jan 89 15:33:03 EDT from <PEPMNT@CFAAMP>
>Re-accessing always puts everything back in order. In any case, if a
>wildcard send is interrupted and then promptly resumed, the order will
>be exactly the same the second time (unless some of the files are
>changed/added/deleted).
If a user adds some A.. X files, downloads * X, gets interrupted at B..
(typical case is system failure), causes reordering (typical case is LOGON)
and restarts download where interrupted, he would miss those A.. X files. If he
notices, he gets forced to manual recovery anyway.
In order to be foolproof, Kermit should trigger the reordering of search
on *every* download preventively for stable search order.
What is dangerous is that we would rely on the typical "subject to change
without notice" feature, because reordering can be a CMS whim any time.
Doing an ACCESS looks very dangerous if files are open (such as a procedure),
some insight of the file system is needed to check or find another stable
means.
On a more general scope, I would not favour tucking into 370-Kermit duplication
of what's already in most operating systems, except if it really eases things
because of performance or usability.
That's adding each time to the problem of portability by increasing the number
of system interfaces, or imposing limits by reluctance to add more.
Resuming a transfer is Kermit's own concern, data transformation
is an example of too wide a matter for Kermit.
If we focus on assuring in each implementation any procedure call
with parameters, limitless fancy features can be invented by the user
or generalized by a set of system macros hiding system specifics and
distributed with Kermit.
If a means like parameters passing on the TAKE command is available,
we could do from the micro side things like:
REMOTE KERMIT TAKE preprocess parameters
SEND/GET ...
REMOTE KERMIT TAKE postprocess parameters
or if a macro feature exists in the local Kermit or system, just
PROCESS parameters
I'm just in time for a Happy New Year to all.
Andr).
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Fri Jan 13 16:33:49 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA05299; Fri, 13 Jan 89 16:33:49 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 13 Jan 89 16:32:49 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 2803; Fri, 13 Jan 89 16:32:48 EDT
Date: Fri, 1989 Jan 13 16:03:52 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Sending a piece of a file
In-Reply-To: A-PIRARD%BLIULG11.BITNET@CUVMB.CC.COLUMBIA.EDU message of Fri, 13
Jan 89 10:23:22 +0100
Message-Id: <PEPMNT.890113.160352.B0@CFAAMP.BITNET>
> In order to be foolproof, Kermit should trigger the reordering of search
> on *every* download preventively for stable search order.
That's a good idea (only for wildcard downloads, of course).
> Doing an ACCESS looks very dangerous if files are open (such as a procedure),
> some insight of the file system is needed to check or find another stable
> means.
As a matter of fact, there is a nucleus module that alphabetizes the
in-core directory without re-ACCESSing. This is still a bit dangerous
if Kermit has been invoked from a program, rather than from command
level or an EXEC.
> If a means like parameters passing on the TAKE command is available,
> we could do from the micro side things like:
> REMOTE KERMIT TAKE preprocess parameters
> SEND/GET ...
> REMOTE KERMIT TAKE postprocess parameters
> or if a macro feature exists in the local Kermit or system, just
> PROCESS parameters
I'm not sure how this relates to resuming a wildcard send. Anyway, I
should point out that, in both the CMS and TSO versions of Kermit-370,
command procedures can be invoked and can invoke Kermit subcommands in
turn.
> I'm just in time for a Happy New Year to all.
"just in time"??? In the Julian calendar? Yes, this is Jan 1 (O.S.),
but the English-speaking world switched to the Gregorian calendar about
250 years ago.
John
From @cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET Mon Jan 16 06:02:06 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA11741; Mon, 16 Jan 89 06:02:06 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 16 Jan 89 06:01:11 EDT
Received: from VM1.EARN-ULG.AC.BE by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 4138; Mon, 16 Jan 89 06:01:09 EDT
Received: by BLIULG11 (Mailer R2.02) id 3363; Mon, 16 Jan 89 11:59:58 +0100
Date: Mon, 16 Jan 89 10:59:48 +0100
From: Andre' PIRARD <A-PIRARD%BLIULG11.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Sending a piece of a file
To: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Fri, 13 Jan 89 16:35:19 EDT from <PEPMNT@CFAAMP>
>> REMOTE KERMIT TAKE preprocess parameters
>I'm not sure how this relates to resuming a wildcard send. Anyway, I
>should point out that, in both the CMS and TSO versions of Kermit-370,
>command procedures can be invoked and can invoke Kermit subcommands in
>turn.
Don't misunderstand me, *I am* a very happy daily user of the HOST command.
It does not relate to wildcard send. I am only suggesting that parameters in
TAKE commands (or maybe other means?) could hide system dependencies as to
the syntax of parameters, for such things as files contents selection.
Only suggesting.
>> I'm just in time for a Happy New Year to all.
>
>"just in time"??? In the Julian calendar? Yes, this is Jan 1 (O.S.),
>but the English-speaking world switched to the Gregorian calendar about
>250 years ago.
I've had a good laugh with this one.
My bad English didn't show I was back from a holiday. And our time out for
the wishing period allows for that.
But feel reassured, we're *not* middle-agers ;-)
Andr).
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Fri Feb 3 15:02:57 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA28726; Fri, 3 Feb 89 15:02:57 EST
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 03 Feb 89 15:00:26 EST
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 0955; Fri, 03 Feb 89 15:00:25 EST
Date: Fri, 1989 Feb 3 13:39:23 EST
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-Kermit@cunixc.cc.columbia.edu, Info-Kermit@cunixc.cc.columbia.edu
Subject: Re: ISO 8859 tables
In-Reply-To: A-PIRARD@BLIULG11 message of Fri, 03 Feb 89 10:23:39 +0100
Message-Id: <PEPMNT.890203.133923.B0@CFAAMP.BITNET>
I am sending this to both IBM-Kermit and Info-Kermit on the grounds that
many people not interested in Implementation of IBM mainframe Kermits
are nonetheless very much interested in Use of same.
The issue is what to do about the increasing popularity of extended
(8-bit) "ASCII" character sets. In the non-IBM world, there's no
particular problem, but EBCDIC users face the difficulty of translating
between two different, fluctuating, often incompatible 8-bit character
sets. What Kermit-370 does now is the least-common-denominator, consis-
ting of the traditional CMS and TSO Kermit table, which is one-to-one
for the 7-bit ASCII codes augmented by five alternate mappings of braces
and strokes (4A->5C, 6A->7C, 8B->7B, 9B->7D, FA->7C). Actually, the
first of these five is a relatively recent addition (EBCDIC Cent Sign to
ASCII Backslash) occasioned by the (to many) idiosyncratic mapping of
the Yale ASCII System for the Series/1. Since the extended character
sets are typically nation- or vendor-specific, there is no point (I
claim) in doing *anything* until there is an internationally recognized
standard mapping. Well, there *is* something of the sort, known as the
ISO 8859 table, which has generated considerable discussion on BITNET.
8859 has the following properties:
1. With one exception, it agrees with the one-to-one part of Kermit's
traditional mapping.
2. That exception is DEL -- 07->9F and FF->7F (E->A).
3. The entire 8-bit mapping is one-to-one and invertible.
Now for my opinions:
a) It would be a mistake for Kermit to adopt ISO 8859 outright because
that would clash with the traditional tables.
b) If Kermit doesn't do anything, then individual sites with motivation
will adopt 8-bit standards arbitrarily, probably all different. The
motivation is increasing, so the time to act is now if ever.
c) While (a) and (b) are nearly irreconcilable, there is a compromise
position, namely, to adopt ISO 8859 mappings for all the EBCDIC codes
that currently map into ASCII nulls. This has the advantage of not
hurting anybody (I claim) while making it convenient for Kermit users
to adopt a single standard.
d) The question really is: Is ISO 8859 the wave of the future? If we
jump on the bandwagon, that may tip the scales. Of course, I think
Item 2 above was a mistake, but surely not a very serious one.
e) The ATOE table is a little bit trickier -- there are no null-filled
gaps to take over. However, the addition of a simple command could
effect the needed compromise, I think. That command would copy the
first half of the ATOE table onto the second half (and ditto for the
TATOE). Thus, the default table could be pure ISO 8859 (except for
the DEL, I guess), but traditionalists could restore the status quo
with a single command.
f) This is not something to rush into -- I waited for release 4.1 of
Kermit-370 to come out before re-raising this issue. One possibility,
of course, is to make the requisite updates available through
Columbia and see how users react.
g) If ISO 8859 *is* truly the wave of the future, Kermit's traditional
alternate mappings will presumably become less desirable as time goes
by, and Kermit installations will presumably tend to replace them
more and more with the standard. So be it. Someday, then, we could
go the rest of the way.
John
From @cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET Fri Feb 10 10:34:27 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA25710; Fri, 10 Feb 89 10:34:27 EST
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 4847; Fri, 10 Feb 89 10:31:59 EST
Received: from VM1.EARN-ULG.AC.BE by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 9439; Fri, 10 Feb 89 10:31:58 EST
Received: by BLIULG11 (Mailer R2.02) id 1031; Fri, 10 Feb 89 11:12:37 +0100
Date: Fri, 10 Feb 89 09:01:46 +0100
From: Andre' PIRARD <A-PIRARD%BLIULG11@cuvmb.cc.columbia.edu>
Subject: Re: ISO 8859 tables
To: IBM-KERMIT@cunixc.cc.columbia.edu, ISO8859@JHUVM
In-Reply-To: Message of Fri, 3 Feb 89 15:04:59 EST from <PEPMNT@CFAAMP>
In reply to John Chandler asking how to extend IBM Kermit ASCII/EBCDIC
to 8-bit, and if a decision is desirable right now, I think this summary
may help understanding the problem.
Two issues regard IBM Kermit which must translate ASCII to EBCDIC.
The EBCDIC one is its own.
The ISO8859 has wider scope and may apply to other Kermits.
1) Should ISO8859 be chosen as 8-bit "ASCII" code?
As long as readable text is concerned, this is the only true standard.
Many machines extend ASCII to 8-bit, but each its own incomplete way.
Choosing another nonstandard code would favour a particular brand like
IBM PC, Apple or whatever.
I doubt yet another standard would appear before a 16-bit revolution.
2) Which ISO8859-x version should be chosen?
Several exist for different language groups.
For ASCII only transmission, the question is irrelevant, because the
different versions cannot translate from one to another, unless
an 16-bit or more code were used to store the data.
For EBCDIC/ASCII translation, the same holds if IBM sets up the
corresponding EBCDIC codes so that the same translation applies.
Alas, this would be too simple, at least one differs lightly.
3) Which EBCDIC version should be chosen for a particular ISO one.
This question looks nonsense, but for the prominent ISO8859-1,
IBM has defined at least 2 corresponding EBCDIC codes: 037 and 500.
And this is yet different from Kermit's.
A real problem now, consequently.
Edwin Hart is putting SHARE requirements, among them:
- that IBM use a single EBCDIC codepage for each ISO version.
- that the same EBCDIC/ASCII translation be used.
- that ISO8859 be available on the PC's.
4)
> [...] In the non-IBM world, there's no
>particular problem, [...]
Not exactly. Only if all machines adopt ISO 8859 in their "hardware".
The present many codes imply that translation occur somewhere.
Always using ISO8859 to transport data between machines really simplifies
the problem of present code multiplicity, because each machine user needs
to cater with a single conversion table.
Having Kermits translate the transferred data is a real convenience to
the user, but a necessity for terminal mode.
It is a simple thing to a Kermit program to implement both data translation
(terminal mode with SI/SO switching).
Even patchable internal translation tables would do, because only two
versions of a single module would be needed: no translation (compatibility)
and ISO8859 to local.
>2. That exception is DEL -- 07->9F and FF->7F (E->A).
That is the result of the IBM present choice of EBCDIC assignment of DEL.
Subject to revision as per the SHARE requirements.
Edwin already knows this.
Andr).
From @cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET Mon Feb 13 09:16:25 1989
Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA00560; Mon, 13 Feb 89 09:16:25 EST
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 5564; Mon, 13 Feb 89 09:15:24 EST
Received: from VM1.EARN-ULG.AC.BE by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with
BSMTP id 2171; Mon, 13 Feb 89 09:15:23 EST
Received: by BLIULG11 (Mailer R2.02) id 2038; Mon, 13 Feb 89 09:43:36 +0100
Date: Mon, 13 Feb 89 09:08:23 +0100
From: Andre' PIRARD <A-PIRARD%BLIULG11@cuvmb.cc.columbia.edu>
Subject: Re: ISO 8859 tables
To: ASCII/EBCDIC character set related issues <ISO8859@JHUVM>
Cc: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Fri, 10 Feb 89 11:56:49 EST from <HART@APLVM>
(From Edwin Hart).
> The translation requirement was intended to require that translations
> exist between EBCDIC code pages and the various ISO 8859-x standard codes.
> The requirement was NOT intended to specify the same translate table for
> each. The reason I left this requirement open was that I have been told
> that the EBCDIC code page for ISO Latin Alphabet Number 2 (ISO 8859-2)
> could not use the same translate table as Code Page 37 or Code Page 500.
> If you want, we can make a recommendation that the translate tables be the
> same for each of the ISO 8859-x codes to the corresponding EBCDIC codes.
Sorry I misunderstood.
YES, I feel a single translation table is of utmost importance.
If some systems may decide to tag files with an ISO version, I leave it to
them to enjoy the experiment.
But I think it would be unreasonable to require this from each and every
software involved in ASCII/EBCDIC translation. *That* would really take time.
Getting 8-bit through things like gateways correctly is no given thing already.
Andr).
From fdc Sat Feb 25 14:30:07 1989
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA16751; Sat, 25 Feb 89 14:30:07 EST
Date: Sat, 25 Feb 1989 14:30:06 EST
From: Frank da Cruz <fdc@cunixc.cc.columbia.edu>
To: IBM-Kermit, Joe Doupnik <jrd@usu.bitnet>
Subject: Bug in MS-Kermit
Message-Id: <CMM.0.88.604438206.fdc@cunixc.cc.columbia.edu>
I checked out John DeDourek's complaint, and he's right. If MS-Kermit
sends a GET command, and there is no response from the server within the
timeout interval, then MS-Kermit retransmits the GET (R) packet, but it
is garbled. Further retransmissions (as when the host NAKs the garbled
R packet) are also garbled. This will hve to be fixed in the next release.
Meanwhile, the workaround is to issue another GET command and hope that
no packets get lost. Here's the relevant packet log:
Spack: ^A0 I~- @-#&1~* ~S^M <-- PC sends Init packet
Rpack: ^A0 Y~% @-#&1~* *R9^M <-- mainframe responds
Spack: ^A+ Rvspc.dir)^M <-- PC sends GET command
Rpack: <-- PC times out waiting for reply
Spack: ^A+ R^@^@pc.dir@^M <-- PC retransmits garbled GET command
Rpack: (^@ = NUL)
Spack: ^A+ R^@^@pc.dir@^M <-- etc.
- Frank
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Mon Feb 27 14:22:34 1989
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA14689; Mon, 27 Feb 89 14:22:34 EST
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 1778; Mon, 27 Feb 89 14:19:14 EST
Received: from CFAAMP.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 5163; Mon, 27 Feb 89 14:19:13 EST
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer R2.02A) with
BSMTP id 0856; Mon, 27 Feb 89 13:34:04 EST
Date: Mon, 1989 Feb 27 13:31:48 EST
Subject: Terminal controller detection in Kermit-370
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-Kermit@cunixc.cc.columbia.edu, IBM-MAIN@RUTVM1.BITNET
Message-Id: <PEPMNT.890227.133148.B0@CFAAMP.BITNET>
Release 4.1 of Kermit-370 has code for automatically detecting whether
a full-screen terminal is a Series/1-type or not by issuing a Yale ASCII
status request (which is "illegal" for controllers not compatible with
the Yale ASCII communication system). Unfortunately, some users report
that VTAM refuses to allow such a command through. Can anyone familiar
with VTAM operation suggest a way of making it more amenable? Thanks.
John
From fdc Tue Apr 4 19:48:18 1989
Return-Path: <fdc>
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA12230; Tue, 4 Apr 89 19:48:18 EDT
Date: Tue, 4 Apr 1989 19:48:17 EDT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
To: ibm-kermit
Subject: [(John F. Chandler) PEPMNT@cfaamp.bitnet: Forwarding error...]
Message-Id: <CMM.0.88.607736897.fdc@watsun.cc.columbia.edu>
After fixing the mailing list, apologies to anyone who gets this twice...
---------------
Date: Tue, 1989 Apr 4 15:27:49 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Reply-To: PEPMNT%CFAAMP.BITNET@cuvmb.cc.columbia.edu
To: IBM-Kermit@cunixc.cc.columbia.edu, IBM7171@TCSVM.BITNET
Subject: Graphics devices and CMS Kermit
I'm looking for anyone who is interested in running Kermit through any
of the protocol converters with what's known as "graphics passthrough"
mode. Kermit long ago demonstrated that ability under TSO, but hasn't
yet under CMS. However, there is a good chance that the breakthrough
is upon us, and I want to find people to test the code. To give you an
idea of what devices I mean, I'll give a definition and some examples:
these devices interpret packets beginning with the order x'70' as
graphics sequences in ASCII to be transmitted untranslated. Examples
are the various PCI converters, the Renex TMS-1, various LeeData
Datastream models, the MICOM 7400, and so on. All you need to do the
test is the source code for CMS Kermit 4.1 (which you can get from
Columbia) and a few updates which I can supply. I actually have two
new approaches, either of which may do the trick.
John
From @cuvmb.cc.columbia.edu:DEDOUREK@UNB.CA Fri Apr 7 09:24:59 1989
Return-Path: <@cuvmb.cc.columbia.edu:DEDOUREK@UNB.CA>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA23124; Fri, 7 Apr 89 09:24:59 EDT
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA20026; Fri, 7 Apr 89 10:24:57 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8063; Fri, 07 Apr 89 09:25:11 EDT
Received: from UNB.CA by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
3356; Fri, 07 Apr 89 09:25:03 EDT
Received: by UNBMVS1 (Mailer 09.01) id 7655; Fri, 07 Apr 89 10:23:06 ADT
Date: Fri, 07 Apr 89 10:23:06 ADT
To: ibm-kermit@cunixc.cc.columbia.edu
Subject: use of "backwards server" mode with TSO-kermit
From: DEDOUREK%UNB.CA@cuvmb.cc.columbia.edu
Message-Id: <ID5251.D890407.T102307.DEDOUREK@UNB.CA>
When I use TSO-Kermit, I usually put it into server mode,
escape back to my PC and operate there. Everything works fine.
The director of our Computing Services suggests that there are
a number of users who would feel more comfortable working within
the TSO environment rather than the PC-DOS environment. (I'm not
sure that I believe him, but this is, after all, an IBM mainframe
campus.) For example MUSIC (a time sharing system from McGill U.
running under IBM's VM operating system) comes with a PCWS utility
which permits a MUSIC user to transfer files between the mainframe
and the PC while remaining in "mainframe" mode without escaping
back to the PC.
It occurred to me, after reading the PC-Kermit manual and the TSO
Kermit manual that it might be possible to run Kermit in this mode.
What I had in mind was to attach a macro to the "terminalr/terminals
connect mode" feature of the PC Kermit VT102 emulator which placed
the PC in server mode. CLISTS's would be provided on the TSO side
to upload/download files by issuing the appropriate escape sequence
to the PC and then starting Kermit and issuing the appropriate
commands followed by a finish.
Now the questions. Has someone done this? Any major known
problems which would make an investigation futil at the outset?
Any suggestions?
[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
John DeDourek
dedourek@unb.ca -- Registered Domain Name
DEDOUREK@UNB -- BITNET / NETNORTH (Canada)
dedourek@unb.bitnet -- For mailers which only know how to get to
bitnet this way.
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Fri Apr 7 12:36:10 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA24105; Fri, 7 Apr 89 12:36:10 EDT
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA04929; Fri, 7 Apr 89 12:35:55 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8181; Fri, 07 Apr 89 12:36:08 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 3871; Fri, 07 Apr 89 12:36:07 EDT
Date: Fri, 1989 Apr 7 12:25:22 EDT
From: (John F. Chandler) PEPMNT@cfaamp.bitnet
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: use of "backwards server" mode with TSO-kermit
In-Reply-To: DEDOUREK@UNB.CA message of Fri, 7 Apr 89 10:23:06 ADT
Message-Id: <PEPMNT.890407.122522.C0@CFAAMP.BITNET>
> What I had in mind was to attach a macro to the "terminalr/terminals
> connect mode" feature of the PC Kermit VT102 emulator which placed
> the PC in server mode. CLISTS's would be provided on the TSO side
> to upload/download files by issuing the appropriate escape sequence
> to the PC and then starting Kermit and issuing the appropriate
> commands followed by a finish.
Yes, this has been done for several years at the Harvard Business School
(which has its own divergent brand of MS Kermit, known as HBSCOM). As
a matter of fact, this was the motivation behind implementing the
XECHO subcommand in Kermit-370 (originally in CMS Kermit).
John
From @cuvmb.cc.columbia.edu:RAF@NIHCU.BITNET Fri Apr 7 21:54:50 1989
Return-Path: <@cuvmb.cc.columbia.edu:RAF@NIHCU.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA26969; Fri, 7 Apr 89 21:54:50 EDT
Message-Id: <8904080154.AA26969@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA19602; Fri, 7 Apr 89 21:54:46 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8417; Fri, 07 Apr 89 21:55:03 EDT
Received: from NIHCU.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
id 4702; Fri, 07 Apr 89 21:55:02 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: "Roger Fajman" <RAF%NIHCU@cuvmb.cc.columbia.edu>
Date: Fri, 07 Apr 89 21:52:10 EDT
Subject: Re: use of 'backwards server' mode with TSO-kermit
We also think that being able to put the PC into server mode is a good
idea. We've done some work on it. We didn't use TERMINALR/S, since
those were not available at the time. There are reasons not to do that
anyway. We added support to MS Kermit to receognize an escape sequence
and go into server mode. We also added the commands (GET, etc.)
required to talk to a server to NIH TSO Kermit, plus a command to put
the other Kermit into server mode. We've been calling it AUTOSERVER.
Some of the considerations we've come up with are:
(1) Suppose the escape sequence that puts the PC into server mode gets
garbled? TSO Kermit's AUTOSERVER command sends the escape sequence,
then waits for a NACK from the MS Kermit server. If TSO Kermit does
not receive the NACK within a timeout interval, it resends the escape
sequence. MS Kermit sends a NACK immediately upon entering server mode
due to the autoserver escape sequence. If that NACK gets lost, another
is sent after the normal timeout. Thus entry into autoserver is
reliable, albeit kludgy.
(2) Any escape sequence you choose might interfere with some future
terminal emulation. Perhaps it should be settable.
(3) Once the PC is in server mode, one may wish to do things other than
file transfers. One example is a user using an email system on the
mainframe. If he wants to reply to a message, that message could be
downloaded to his PC, he could be put into his favorite PC editor to
compose the reply, and the result could be uploaded back to the
mainframe. The REMOTE HOST command gives the capability to execute
commands through the server, but the assumption is that the output goes
back to the requester. In this case, one is likely to want the output
to go to the PC's screen. With many programs, this will happen anyway
because they write directly to the screen, but where the output is
supposed to go should be explicitly indicated.
Anyway, we need to play around with this stuff some more to see if it
all fits together the way we envision it.
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Fri Apr 7 23:45:07 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA27058; Fri, 7 Apr 89 23:45:07 EDT
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA23987; Fri, 7 Apr 89 23:45:01 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8447; Fri, 07 Apr 89 23:45:18 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25)
with BSMTP id 4910; Fri, 07 Apr 89 23:45:17 EDT
Date: Fri, 1989 Apr 7 22:58:10 EDT
From: (John F. Chandler) PEPMNT@cfaamp.bitnet
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: use of 'backwards server' mode with TSO-kermit
In-Reply-To: RAF%NIHCU@CUVMB.CC.COLUMBIA.EDU message of Fri, 7 Apr 89 21:52:10
EDT
Message-Id: <PEPMNT.890407.225810.C0@CFAAMP.BITNET>
> (1) Suppose the escape sequence that puts the PC into server mode gets
> garbled?
Here's what happens with Kermit-370 (either CMS, TSO, or MUSIC): the
PC remains a terminal, and the user sees a Kermit packet appear on the
screen and types STOP, whereupon Kermit-370 halts the transaction. At
that point the user may try again.
> MS Kermit sends a NACK immediately upon entering server mode
> due to the autoserver escape sequence.
I'm leery of a mechanism that requires the micro Kermit not only to have
a magic escape sequence to enter server mode, but also to respond with
an immediate NAK. Such an approach holds the idea hostage to the
cooperation of too many Kermit developers.
> (2) Any escape sequence you choose might interfere with some future
> terminal emulation. Perhaps it should be settable.
Absolutely. Don't forget there's more than one kind of micro Kermit!
John
From ken@watsun.cc.columbia.edu Wed Apr 19 16:17:18 1989
Return-Path: <ken@watsun.cc.columbia.edu>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA19028; Wed, 19 Apr 89 16:17:18 EDT
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.54/5.10) id AA05256; Wed, 19 Apr 89 16:17:11 EDT
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA19024; Wed, 19 Apr 89 16:17:09 EDT
Date: Wed, 19 Apr 1989 16:17:08 EDT
From: Ken Rossman <ken@watsun.cc.columbia.edu>
To: ibm-kermit@cunixc.cc.columbia.edu
Subject: test mail, please ignore
Message-Id: <CMM.0.88.609020228.ken@watsun.cc.columbia.edu>
Testing the mailing list routing for ibm-kermit. Please ignore... /Ken
From fdc Wed Apr 19 16:18:57 1989
Return-Path: <fdc>
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA19064; Wed, 19 Apr 89 16:18:57 EDT
Date: Wed, 19 Apr 1989 16:18:57 EDT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
To: ibm-kermit
Subject: Generalized Kermit-370 File I/O
Message-Id: <CMM.0.88.609020337.fdc@watsun.cc.columbia.edu>
...
---------------
Date: Wed, 1989 Apr 19 14:57:09 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
To: IBM-Kermit@cunixc.cc.columbia.edu
Subject: Generalized Kermit file I/O
> From: Peter Jones <MAINT@uqam.bitnet>
>
> Has anyone considered the possibility of KERMIT's file transfers being
> able to access the XEDIT text buffer, the console stack and/or the
> EXEC variables.
>
> Thus, my particular need would simply entail ability to read from
> XEDIT. I've included the other possibilities for discussion purposes.
>
> Among other things, KERMIT will need to recognize whether it is in a
> CMS or XEDIT environment, and process the options (on SEND and
> RECEIVE) dealing with the stack, XEDIT buffer and/or EXEC variables.
> Maybe this idea would make KERMIT/CMS too specific.
>
Yes, I think it would be too system-specific, and I wonder what's wrong
with using the facilities already available. For example, Kermit-370
in general allows the execution of system commands. In particular,
any desired transfer to or from the CMS console stack, an XEDIT file or
EXEC variables can be effected by a combination of a normal Kermit
transfer to or from disk and a CMS transfer between the disk file and
the desired repository. It is quite simple, for example, to write an
EXEC that issues a &SUBCOMMAND XEDIT READ to switch into fullscreen
XEDIT display mode when Kermit is running under XEDIT. The only
complication in using a disk file as the intermediate storage is the
question of whether there is enough space, and my answer to that is that
you can create a TDISK as needed while running Kermit. Admittedly,
there is a price to pay in terms of execution time for the advantage of
simplicity in always reading/writing disk files, but CMS helps out by
by buffering to optimize sequential disk I/O.
There is one option, by the way, that was left out of the above
suggestions, namely, SPOOL files. The same arguments apply.
John
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Mon May 1 21:46:48 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA14416; Mon, 1 May 89 21:46:48 EDT
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA21845; Mon, 1 May 89 21:44:28 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8517; Mon, 01 May 89 21:46:41 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B)
with BSMTP id 0056; Mon, 01 May 89 21:46:40 EDT
Date: Mon, 1989 May 1 20:43:56 EDT
From: (John F. Chandler) PEPMNT@cfaamp.bitnet
To: IBM-Kermit@cunixc.cc.columbia.edu
Subject: Sending partial files
Message-Id: <PEPMNT.890501.204356.C0@CFAAMP.BITNET>
I'm trying to decide on the proper means of sending only part of a file
(based on record numbers). One way is to implement SET MARGIN TOP and
BOTTOM, but that would require setting one or two parameters before
requesting a file (and resetting afterwards to be safe). Another way
would be to augment the syntax of filespec's such that the record
numbers could be built in. The problem is finding a syntax that is
both mnemonic and acceptable to all parties. Here's how I analyze it:
Valid in CMS filenames: A-Z 0-9 # $ @ - _ : +
Valid MVS/TSO in DSN's: A-Z 0-9 # $ @ - { . ( ) '
Valid MUSIC in filenames: A-Z 0-9 # $ @ .
Used for wildcards: * % =
Used as delimiters: blank ,
Translation problems: [ ] ! | \ }
(brackets, exclamation mark, vertical bar,
backslash, right brace)
Used by TSO for passwords: /
Used for interactive help: ?
Translated to uppercase: a-z
Control characters: x'00'-x'1F' x'7F'
Available: " & ~ ^ ` ; < >
(double quote, ampersand, tilde, circumflex,
grave accent, semicolon, angle brackets)
One of those eight characters would serve as a delimiter and denote the
presence of one or more line numbers. One mnemonic syntax would be
filespec<nnn:mmm>
indicating a request for lines nnn through mmm. The closing ">" isn't
at all needed for parsing, but I think it makes the meaning clearer.
UNIX folk will, of course, object that this notation clashes with
redirection, but I doubt if that's relevant in 370-style filespec's.
Note that the separator between nnn and mmm can be any non-numeric
character that makes sense, so we could have something like
filespec&nnn-mmm
or even
filespec~nnn~mmm
Does anyone have any further limitations to offer or any strong
preferences. I'd be particularly interested in limitations imposed by
the file name syntax of systems other than CMS, MVS/TSO, and MUSIC.
By the way, if any of the eight "available" characters doesn't look (on
your screen) like what I said it was, that's probably a limitation
right there. Comments, anyone?
John
From @cuvmb.cc.columbia.edu:XRHAH@SCFVM.BITNET Tue May 2 11:45:45 1989
Return-Path: <@cuvmb.cc.columbia.edu:XRHAH@SCFVM.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA20987; Tue, 2 May 89 11:45:45 EDT
Message-Id: <8905021545.AA20987@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA17572; Tue, 2 May 89 11:43:23 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8688; Tue, 02 May 89 11:45:38 EDT
Received: from SCFVM.GSFC.NASA.GOV by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B)
with BSMTP id 0802; Tue, 02 May 89 11:45:37 EDT
Received: by SCFVM (Mailer R2.03B) id 0290; Tue, 02 May 89 11:42:18 EDT
Date: Tue, 02 May 89 11:36:36 EDT
From: "Herbert A. Huston" <XRHAH%SCFVM@cuvmb.cc.columbia.edu>
Subject: Re: Sending partial files
To: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Mon, 1 May 89 21:48:43 EDT from <PEPMNT@CFAAMP>
>One of those eight characters would serve as a delimiter and denote the
>presence of one or more line numbers. One mnemonic syntax would be
> filespec<nnn:mmm>
>indicating a request for lines nnn through mmm. The closing ">" isn't
>at all needed for parsing, but I think it makes the meaning clearer.
>UNIX folk will, of course, object that this notation clashes with
>redirection, but I doubt if that's relevant in 370-style filespec's.
>Note that the separator between nnn and mmm can be any non-numeric
>Does anyone have any further limitations to offer or any strong
>preferences. I'd be particularly interested in limitations imposed by
>the file name syntax of systems other than CMS, MVS/TSO, and MUSIC.
VMS uses angle brackets as aliases for square brackets in filespecs
when a directory must be specified. I'm not sure if it's relevant, but
there it is.
-- Herb
From VVVCU@cuvmb.cc.columbia.edu Tue May 2 12:17:33 1989
Return-Path: <VVVCU@cuvmb.cc.columbia.edu>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA21380; Tue, 2 May 89 12:17:33 EDT
From: VVVCU@cuvmb.cc.columbia.edu
Message-Id: <8905021617.AA21380@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA20666; Tue, 2 May 89 12:15:13 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8719; Tue, 02 May 89 12:17:27 EDT
Received: by CUVMB (Mailer R2.03B) id 1008; Tue, 02 May 89 12:17:26 EDT
Date: Tue, 2 May 89 12:17 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
Cc: Vace Kundakci Columbia U CMS <VVVCU@cuvmb.cc.columbia.edu>
Subject: Re: Sending partial files; "John F. Chandler" <PEPMNT@CFAAMP>
In-Reply-To: Your msg of : Mon, 1 May 89 21:48:43 EDT
I would vote for "additional syntax" format following the filespec
and not necessarily immediately following the last char of the file.
for example, send profile exec "start 1 end 22 future options" ...
/Vace
From @cuvmb.cc.columbia.edu:RAF@NIHCU.BITNET Tue May 2 12:47:55 1989
Return-Path: <@cuvmb.cc.columbia.edu:RAF@NIHCU.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA21644; Tue, 2 May 89 12:47:55 EDT
Message-Id: <8905021647.AA21644@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA23452; Tue, 2 May 89 12:45:36 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8745; Tue, 02 May 89 12:47:50 EDT
Received: from NIHCU.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 1188; Tue, 02 May 89 12:47:48 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: "Roger Fajman" <RAF%NIHCU@cuvmb.cc.columbia.edu>
Date: Tue, 02 May 89 12:45:48 EDT
Subject: Re: Sending partial files
& is used in WYLBUR, although only at the start of a dsname.
~ ^ ` have translation problems too, but translation problems have
be dealt with in order for Kermit to work anyway.
; is used as a command delimiter in NIH TSO Kermit and in some WYLBURs.
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Tue May 2 12:55:43 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA21754; Tue, 2 May 89 12:55:43 EDT
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA24168; Tue, 2 May 89 12:53:24 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8752; Tue, 02 May 89 12:55:40 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B)
with BSMTP id 1321; Tue, 02 May 89 12:55:38 EDT
Date: Tue, 1989 May 2 12:09:04 EDT
From: (John F. Chandler) PEPMNT@cfaamp.bitnet
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Sending partial files
In-Reply-To: XRHAH%SCFVM@CUVMB.CC.COLUMBIA.EDU message of Tue, 2 May 89 11:36:36
EDT
Message-Id: <PEPMNT.890502.120904.C0@CFAAMP.BITNET>
> VMS uses angle brackets as aliases for square brackets in filespecs
> when a directory must be specified. I'm not sure if it's relevant, but
> there it is.
I HOPE it's not relevant. The point is that the syntactical extension
would appear only for filespec's on the 370 system, so that any other
Kermit should transmit the filespec "as is". The only exceptions might
be special delimiter characters with higher precedence than blanks and
commas. In any case, this transparency to other Kermits is the main
reason I'm inclined to favor a filespec extension for specifying line
numbers. That reminds me of a potential problem: the transparency is
theoretically there, but what about the maximum length of a filespec
string for other Kermits? For example, specifying a member of a
fully-qualified, password-protected PDS under TSO could take 65 bytes,
and tacking on line numbers could add several more -- does anybody have
an idea of what the typical string size limits are?
Be that as it may, the systems where closest attention must be paid
to reserved characters are those where there is not now, but might
someday be, an implementation of Kermit-370, i.e., CICS, COMPOSE,
DOS/VSE, GUTS, MTS, ROSCOE, WYLBUR, and possibly others I haven't heard
of.
John
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Tue May 2 14:09:44 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA22454; Tue, 2 May 89 14:09:44 EDT
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA00748; Tue, 2 May 89 14:07:22 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8809; Tue, 02 May 89 14:09:39 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B)
with BSMTP id 1614; Tue, 02 May 89 14:09:38 EDT
Date: Tue, 1989 May 2 13:45:36 EDT
From: (John F. Chandler) PEPMNT@cfaamp.bitnet
To: IBM-KERMIT@cunixc.cc.columbia.edu
Subject: Re: Sending partial files
In-Reply-To: RAF%NIHCU@CUVMB.CC.COLUMBIA.EDU message of Tue, 2 May 89 12:45:48
EDT
Message-Id: <PEPMNT.890502.134536.C0@CFAAMP.BITNET>
> & is used in WYLBUR, although only at the start of a dsname.
Oh, well. Probably scratch that one.
> ~ ^ ` have translation problems too,
Not the same kind of problems. Brackets shouldn't be used except in
pairs, lest they be confusing. It would be awkward to choose an EBCDIC
character which some people interpret as a bracket and some don't. The
same applies to parentheses and braces. As far as I can tell, there's
no such problem with the tilde, carat, or grave accent. Note that what
I call the carat is really an EBCDIC "not" sign. Someday, that might
become a problem in itself, just as the backslash/centsign translation
is now for users of the Yale ASCII package and workalikes. However, I
think tradition will likely prevail and keep all three characters
available on ASCII (i.e., Kermitable) keyboards and translatable as now.
> ; is used as a command delimiter in NIH TSO Kermit and in some WYLBURs.
Does that mean that other WYLBURs use other characters as delimiters??
John
From @cuvmb.cc.columbia.edu:RAF@NIHCU.BITNET Tue May 2 15:15:28 1989
Return-Path: <@cuvmb.cc.columbia.edu:RAF@NIHCU.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA23174; Tue, 2 May 89 15:15:28 EDT
Message-Id: <8905021915.AA23174@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA06625; Tue, 2 May 89 15:13:01 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8874; Tue, 02 May 89 15:15:17 EDT
Received: from NIHCU.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 2042; Tue, 02 May 89 15:15:16 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: "Roger Fajman" <RAF%NIHCU@cuvmb.cc.columbia.edu>
Date: Tue, 02 May 89 15:14:23 EDT
Subject: Re: Sending partial files
> > ~ ^ ` have translation problems too,
>
> Not the same kind of problems. Brackets shouldn't be used except in
> pairs, lest they be confusing. It would be awkward to choose an EBCDIC
> character which some people interpret as a bracket and some don't. The
> same applies to parentheses and braces. As far as I can tell, there's
> no such problem with the tilde, carat, or grave accent. Note that what
> I call the carat is really an EBCDIC "not" sign. Someday, that might
> become a problem in itself, just as the backslash/centsign translation
> is now for users of the Yale ASCII package and workalikes. However, I
> think tradition will likely prevail and keep all three characters
> available on ASCII (i.e., Kermitable) keyboards and translatable as now.
Our host printers have both a not sign and a caret (circumflex). It's
true that they don't have the pairing problem, but not everyone agrees
on what EBCDIC codes they should be. Some people translate tilde into
EBCDIC not sign, for example. I think I've heard of people translating
accent grave into cent sign. This sort of thing could be awkward if
dsnames are translated to EBCDIC before being scanned.
> > ; is used as a command delimiter in NIH TSO Kermit and in some WYLBURs.
>
> Does that mean that other WYLBURs use other characters as delimiters??
As far as I know, all WYLBURs that allow multiple commands per line use
semicolon as the separator. I'm just not certain if all current
versions allow it.
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Tue May 30 17:26:14 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA09311; Tue, 30 May 89 17:26:14 EDT
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA09806; Tue, 30 May 89 17:25:18 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 0645; Tue, 30 May 89 17:25:19 EDT
Received: from CFAAMP.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B) with
BSMTP id 5094; Tue, 30 May 89 17:25:18 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer R2.03B) with
BSMTP id 0172; Tue, 30 May 89 17:24:39 EDT
Date: Tue, 1989 May 30 17:14 EDT
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@cuvmb.cc.columbia.edu>
To: IBM-KERMIT <IBM-KERMIT@cunixc.cc.columbia.edu>,
Pete Gifford <PETE@allegvm.bitnet>
Subject: Re: Kermit through 3174 AEA
In-Reply-To: PETE@ALLEGVM message of Tue, 30 May 89 16:06:36 GMT
Message-Id: <PEPMNT.890530.171419.C0@CFAAMP.BITNET>
> Does anyone have Kermit 4.1 file transfer for CMS or MUSIC working
> through a local 3174 with the Asynchronous Emulation Adapter (AEA)?
The latest word on the 3174 is that there is no means of transparent
throughput at present. However, IBM has indicated there will be some
such capability fairly soon (as of a month ago, the microcode upgrade
was due in about 6 months). It presumably won't be long after that
before Kermit will be able to do file transfers through the 3174.
John
From @cuvmb.cc.columbia.edu:TERRAIN@FRSAC11.BITNET Wed May 31 04:55:17 1989
Return-Path: <@cuvmb.cc.columbia.edu:TERRAIN@FRSAC11.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA14328; Wed, 31 May 89 04:55:17 EDT
Message-Id: <8905310855.AA14328@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA11868; Wed, 31 May 89 04:54:22 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 0809; Wed, 31 May 89 04:54:23 EDT
Received: from FRSAC11.BITNET (TERRAIN) by CUVMB.CC.COLUMBIA.EDU (Mailer
R2.03B) with BSMTP id 5774; Wed, 31 May 89 04:54:22 EDT
Date: Wed, 31 May 89 10:55:12 GMT
To: ibm-kermit@cunixc.cc.columbia.edu
From: TERRAIN%FRSAC11.BITNET@cuvmb.cc.columbia.edu
Comment: CROSSNET mail via MAILER@CUVMA
Comment: File KERMIT MESSAGE A
Subject: Kermit and VM/XA SP2
Hello,
If anybody knows a solution to run KERMIT-CMS under VM/XA, I am
very interested. Thanks in advance for reply.
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Wed May 31 09:08:33 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA15797; Wed, 31 May 89 09:08:33 EDT
Message-Id: <8905311308.AA15797@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA28685; Wed, 31 May 89 09:07:37 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 0856; Wed, 31 May 89 09:07:38 EDT
Received: from TUCC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 6068; Wed, 31 May 89 09:07:37 EDT
Date: Wed, 31 May 89 01:22 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Kermit through 3174 AEA
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS1967-1967; 21 LINES); Tue, 30 May 89 16:14:05 EDT
Received: by CUVMB (Mailer R2.03B) id 4855; Tue, 30 May 89 16:11:49 EDT
Date: Tue, 30 May 89 16:06:36 GMT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: Pete Gifford <PETE@ALLEGVM>
Subject: Kermit through 3174 AEA
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
Does anyone have Kermit 4.1 file transfer for CMS or MUSIC working
through a local 3174 with the Asynchronous Emulation Adapter (AEA)?
We are using ProComm+ for terminal emulation (VT102) and ProComm+'s
Kermit file transfer option and are not able to get the two to
communicate.
Any help will be greatly appreciated.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Wed May 31 09:08:45 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA15800; Wed, 31 May 89 09:08:45 EDT
Message-Id: <8905311308.AA15800@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA28693; Wed, 31 May 89 09:07:42 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 0857; Wed, 31 May 89 09:07:43 EDT
Received: from TUCC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 6070; Wed, 31 May 89 09:07:42 EDT
Date: Wed, 31 May 89 01:22 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Re: Kermit through 3174 AEA
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS2328-2328; 20 LINES); Tue, 30 May 89 17:30:10 EDT
Received: by CUVMB (Mailer R2.03B) id 5150; Tue, 30 May 89 17:27:24 EDT
Date: Tue, 30 May 89 17:26:47 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@CUVMB.CC.COLUMBIA.EDU>
Subject: Re: Kermit through 3174 AEA
Comments: To: IBM-KERMIT <IBM-KERMIT@cunixc.cc.columbia.edu>,
Pete Gifford <PETE@allegvm>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
In-Reply-To: PETE@ALLEGVM message of Tue, 30 May 89 16:06:36 GMT
> Does anyone have Kermit 4.1 file transfer for CMS or MUSIC working
> through a local 3174 with the Asynchronous Emulation Adapter (AEA)?
The latest word on the 3174 is that there is no means of transparent
throughput at present. However, IBM has indicated there will be some
such capability fairly soon (as of a month ago, the microcode upgrade
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Wed May 31 13:23:07 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA17854; Wed, 31 May 89 13:23:07 EDT
Message-Id: <8905311723.AA17854@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA14152; Wed, 31 May 89 13:22:06 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 1023; Wed, 31 May 89 13:22:09 EDT
Received: from TUCC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 6629; Wed, 31 May 89 13:22:08 EDT
Date: Wed, 31 May 89 12:23 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Kermit and VM/XA SP2
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS3727-3727; 14 LINES); Wed, 31 May 89 04:58:05 EDT
Received: by CUVMB (Mailer R2.03B) id 5828; Wed, 31 May 89 04:55:45 EDT
Date: Wed, 31 May 89 10:55:12 GMT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
Comments: CROSSNET mail via MAILER@CUVMA
Comments: File KERMIT MESSAGE A
From: TERRAIN%FRSAC11.BITNET@CUVMB.CC.COLUMBIA.EDU
Subject: Kermit and VM/XA SP2
Comments: To: ibm-kermit@cunixc.cc.columbia.edu
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
Hello,
If anybody knows a solution to run KERMIT-CMS under VM/XA, I am
very interested. Thanks in advance for reply.
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Thu Jun 1 14:58:12 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA29312; Thu, 1 Jun 89 14:58:12 EDT
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA22430; Thu, 1 Jun 89 14:57:02 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 1680; Thu, 01 Jun 89 14:57:15 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B)
with BSMTP id 8839; Thu, 01 Jun 89 14:57:14 EDT
Date: Thu, 1989 Jun 1 14:32 EDT
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@cuvmb.cc.columbia.edu>
To: IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
Subject: GRAPH controllers
Message-Id: <PEPMNT.890601.143242.C0@CFAAMP.BITNET>
I have an update for CMS Kermit that appears to make Kermit work
(finally) with GRPAPHICS-type protocol converters. In addition, it
works fine through my 4994 and through a 7171 elsewhere. However, I got
a report of problems uploading large packets through a PCI 276 with the
new code (the limit reported was 255 bytes). This sounds like the old
VTAM problem rearing its ugly head again, but it could be something
specific to the PCI 276.
1. Can anyone report on success or failure of uploading long packets
through a PCI 276 connected through VTAM under TSO? Specifically,
do packets larger than VTAM's buffer size cause problems?
2. Will someone volunteer to test the update on CMS Kermit through
VTAM and a SERIES1-type converter?
John
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Fri Jun 2 01:32:10 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA04474; Fri, 2 Jun 89 01:32:10 EDT
Message-Id: <8906020532.AA04474@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA16182; Fri, 2 Jun 89 01:31:00 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 1987; Fri, 02 Jun 89 01:31:12 EDT
Received: from TUCC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 0009; Fri, 02 Jun 89 01:31:11 EDT
Date: Fri, 02 Jun 89 01:32 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: GRAPH controllers
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS9819-9819; 24 LINES); Thu, 01 Jun 89 15:04:28 EDT
Received: by CUVMB (Mailer R2.03B) id 8891; Thu, 01 Jun 89 14:59:46 EDT
Date: Thu, 1 Jun 89 14:59:11 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@CUVMB.CC.COLUMBIA.EDU>
Subject: GRAPH controllers
Comments: To: IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
I have an update for CMS Kermit that appears to make Kermit work
(finally) with GRPAPHICS-type protocol converters. In addition, it
works fine through my 4994 and through a 7171 elsewhere. However, I got
a report of problems uploading large packets through a PCI 276 with the
new code (the limit reported was 255 bytes). This sounds like the old
VTAM problem rearing its ugly head again, but it could be something
specific to the PCI 276.
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Sat Jun 17 01:26:03 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA27876; Sat, 17 Jun 89 01:26:03 EDT
Message-Id: <8906170526.AA27876@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA19933; Sat, 17 Jun 89 01:25:21 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 9081; Sat, 17 Jun 89 01:24:36 EDT
Received: from TUCC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 6404; Sat, 17 Jun 89 01:24:35 EDT
Date: Sat, 17 Jun 89 01:23 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Need OS/2 kermit.
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS7751-7751; 15 LINES); Fri, 16 Jun 89 22:29:07 EDT
Received: by CUVMB (Mailer R2.03B) id 6205; Fri, 16 Jun 89 22:25:16 EDT
Date: Fri, 16 Jun 89 21:15:15 CDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: Ken Jeffreys <KWJ199F@SMSVMA>
Subject: Need OS/2 kermit.
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
I've been running Kermit under DOS for many years and have receintly
installed OS/2. The version of Kermit I have won't run under OS/2,
however, and I have to use the DOS box. Does anyone know where I can
find an OS/2 version of Kermit so that I may utilize my OS/2 environment
while up/down-loading files.
Thanks in advance, Ken.
From @cuvmb.cc.columbia.edu:DEDOUREK@UNB.CA Mon Jul 31 15:13:05 1989
Return-Path: <@cuvmb.cc.columbia.edu:DEDOUREK@UNB.CA>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA15567; Mon, 31 Jul 89 15:13:05 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA04819; Mon, 31 Jul 89 15:12:23 EDT
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 8084; Mon, 31 Jul 89 15:13:50 EDT
Received: from UNB.CA by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id 5338;
Mon, 31 Jul 89 15:10:38 EDT
Received: by UNBMVS1 (Mailer 11.11) id 7822; Mon, 31 Jul 89 16:08:31 ADT
Date: Mon, 31 Jul 89 16:08:31 ADT
To: ibm-kermit@cunixc.cc.columbia.edu
Cc: "David G. Macneil UNB CS" <dgm@unb.ca>, bpc@unb.ca
Subject: mail for TSO (etc.) Kermit
From: DEDOUREK%UNB.CA@cuvmb.cc.columbia.edu
Message-Id: <ID0117.D890731.T160832.DEDOUREK@UNB.CA>
Has anyone done any work on implementing the mail disposition
for Kermit on TSO (Music, etc.)?
[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
John DeDourek, Professor
School of Computer Science
University of New Brunswick
Fredericton, N. B. CANADA
E3B 5A3
dedourek@unb.ca -- Registered Domain Name
DEDOUREK@UNB -- BITNET / NETNORTH (Canada)
dedourek@unb.bitnet -- For mailers which only know how to get to
bitnet this way.
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Tue Aug 1 01:23:53 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA21719; Tue, 1 Aug 89 01:23:53 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA15663; Tue, 1 Aug 89 01:23:11 EDT
Message-Id: <8908010523.AA15663@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 8248; Tue, 01 Aug 89 01:24:42 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
6190; Tue, 01 Aug 89 01:23:41 EDT
Date: Tue, 01 Aug 89 01:23 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: mail for TSO (etc.) Kermit
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS0815-0815; 26 LINES); Mon, 31 Jul 89 17:59:52 EDT
Received: by CUVMB (Mailer R2.03B) id 5426; Mon, 31 Jul 89 15:22:54 EDT
Date: Mon, 31 Jul 89 16:08:31 ADT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: DEDOUREK%UNB.CA@CUVMB.CC.COLUMBIA.EDU
Subject: mail for TSO (etc.) Kermit
Comments: To: ibm-kermit@cunixc.cc.columbia.edu
Comments: cc: "David G. Macneil UNB CS" <dgm@unb.ca>, bpc@unb.ca
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
Has anyone done any work on implementing the mail disposition
for Kermit on TSO (Music, etc.)?
[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
John DeDourek, Professor
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Thu Aug 3 11:24:42 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA25825; Thu, 3 Aug 89 11:24:42 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA11444; Thu, 3 Aug 89 11:24:00 EDT
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 9477; Thu, 03 Aug 89 11:25:04 EDT
Received: from CFAAMP.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 0662; Thu, 03 Aug 89 11:25:03 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer R2.03B) with
BSMTP id 1084; Thu, 03 Aug 89 11:16:28 EDT
Date: Thu, 1989 Aug 3 11:06 EDT
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@cuvmb.cc.columbia.edu>
To: IBM-KERMIT <IBM-KERMIT@cunixc.cc.columbia.edu>,
DEDOUREK <DEDOUREK@unb.ca>
Subject: Re: mail for TSO (etc.) Kermit
In-Reply-To: DEDOUREK@UNB.CA message of Mon, 31 Jul 89 16:08:31 ADT
Message-Id: <PEPMNT.890803.110613.C0@CFAAMP.BITNET>
> Has anyone done any work on implementing the mail disposition
> for Kermit on TSO (Music, etc.)?
No one has come forward with the ambition to do so. All in all, it
might be easier to invent a CLIST that receives a file and sends it off
as mail using the relevant local mail processor. The problem, as I see
it, is that there is no single standard mechanism of mail delivery built
into TSO (or CMS, for that matter).
John
From @cuvmb.cc.columbia.edu:XRHAH@SCFVM.BITNET Thu Aug 3 12:13:36 1989
Return-Path: <@cuvmb.cc.columbia.edu:XRHAH@SCFVM.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA26326; Thu, 3 Aug 89 12:13:36 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA14639; Thu, 3 Aug 89 12:12:55 EDT
Message-Id: <8908031612.AA14639@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 9520; Thu, 03 Aug 89 12:13:58 EDT
Received: from SCFVM.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
0958; Thu, 03 Aug 89 12:13:57 EDT
Received: by SCFVM (Mailer R2.03B) id 6832; Thu, 03 Aug 89 12:03:02 EDT
Date: Thu, 03 Aug 89 11:39:42 EDT
From: "Herbert A. Huston" <XRHAH%SCFVM@cuvmb.cc.columbia.edu>
Subject: Re: mail for TSO (etc.) Kermit
To: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Thu, 3 Aug 89 11:26:34 EDT from
<PEPMNT%CFAAMP.BITNET@CUVMB.CC.COLUMBIA.EDU>
>> Has anyone done any work on implementing the mail disposition
>> for Kermit on TSO (Music, etc.)?
>
>No one has come forward with the ambition to do so. All in all, it
>might be easier to invent a CLIST that receives a file and sends it off
>as mail using the relevant local mail processor. The problem, as I see
>it, is that there is no single standard mechanism of mail delivery built
>into TSO (or CMS, for that matter).
I've started thinking about it along these lines:
SET MAILCMD mailcmd_template
This would appear in an initialization file. If the value is null, an error
message would be generated if an attempt were made to send mail; otherwise
the mail command would be built and executed. The template would have to
provide substitution variables for network address and filespec. Some
examples:
CMS (vanilla): SET MAILCMD SENDFILE &filespec TO &address (NOTE
CMS with RiceMAIL: SET MAILCMD MAIL &address (NOEDIT FILE &filespec
TSO/E (vanilla): SET MAILCMD TRANSMIT &address DA(&filespec)
TSO/E (with UCLA/Mail): SET MAILCMD MAIL SEND &address FROM(&filespec)
I'll leave further refinements and eventual codings to others.
-- Herb
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Thu Aug 3 12:25:38 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA26454; Thu, 3 Aug 89 12:25:38 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA15292; Thu, 3 Aug 89 12:24:56 EDT
Message-Id: <8908031624.AA15292@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 9548; Thu, 03 Aug 89 12:26:00 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
1176; Thu, 03 Aug 89 12:25:59 EDT
Date: Thu, 03 Aug 89 12:22 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Re: mail for TSO (etc.) Kermit
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS2165-2165; 20 LINES); Thu, 03 Aug 89 11:27:04 EDT
Received: by CUVMB (Mailer R2.03B) id 0719; Thu, 03 Aug 89 11:27:13 EDT
Date: Thu, 3 Aug 89 11:26:34 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@CUVMB.CC.COLUMBIA.EDU>
Subject: Re: mail for TSO (etc.) Kermit
Comments: To: IBM-KERMIT <IBM-KERMIT@cunixc.cc.columbia.edu>,
DEDOUREK <DEDOUREK@unb.ca>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
In-Reply-To: DEDOUREK@UNB.CA message of Mon, 31 Jul 89 16:08:31 ADT
> Has anyone done any work on implementing the mail disposition
> for Kermit on TSO (Music, etc.)?
No one has come forward with the ambition to do so. All in all, it
might be easier to invent a CLIST that receives a file and sends it off
as mail using the relevant local mail processor. The problem, as I see
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Thu Aug 3 12:25:43 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA26457; Thu, 3 Aug 89 12:25:43 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA15297; Thu, 3 Aug 89 12:25:00 EDT
Message-Id: <8908031625.AA15297@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 9549; Thu, 03 Aug 89 12:26:04 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
1178; Thu, 03 Aug 89 12:26:03 EDT
Date: Thu, 03 Aug 89 12:22 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Re: mail for TSO (etc.) Kermit
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS2497-2497; 42 LINES); Thu, 03 Aug 89 12:17:40 EDT
Received: by CUVMB (Mailer R2.03B) id 1048; Thu, 03 Aug 89 12:15:20 EDT
Date: Thu, 3 Aug 89 11:39:42 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "Herbert A. Huston" <XRHAH%SCFVM@CUVMB.CC.COLUMBIA.EDU>
Subject: Re: mail for TSO (etc.) Kermit
Comments: To: IBM-KERMIT@cunixc.cc.columbia.edu
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
In-Reply-To: Message of Thu,
3 Aug 89 11:26:34 EDT from
<PEPMNT%CFAAMP.BITNET@CUVMB.CC.COLUMBIA.EDU>
>> Has anyone done any work on implementing the mail disposition
>> for Kermit on TSO (Music, etc.)?
>
>No one has come forward with the ambition to do so. All in all, it
>might be easier to invent a CLIST that receives a file and sends it off
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Thu Sep 7 10:08:21 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA00979; Thu, 7 Sep 89 10:08:21 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA14330; Wed, 6 Sep 89 21:04:30 EDT
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 2956; Wed, 06 Sep 89 21:03:32 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CUVMB.COLUMBIA.EDU (Mailer R2.03B)
with BSMTP id 9210; Wed, 06 Sep 89 21:03:31 EDT
Date: Wed, 1989 Sep 6 18:36 EDT
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@cuvmb.cc.columbia.edu>
To: IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
Subject: Character translations
Message-Id: <PEPMNT.890906.183643.C0@CFAAMP.BITNET>
I have resolved to implement the new Kermit transfer syntax extension
(at level 1) now being developed at Columbia (see file T:ISOK4.TXT on
KERMSRV for the latest draft of the documentation). For those who
haven't been following the development, the next paragraph summarizes
the parts relevant to the questions I wish to pose.
The level-1 extended transfer syntax entails defining a transfer
character set (selected from the ISO registry) which both Kermits
can "understand". Each Kermit is responsible, then, for translating
the file between its storage form and the transfer form, and this now
involves not just inserting/stripping CRLF's between records, but also
translating the text. Each Kermit, in fact, must either deduce or be
told by the user what character set is used for storing the file on
disk. Character-set translations in general will require converting
one or more characters at a time of the original text into one or more
(but not necessarily the same number of) output characters. For example,
representing the THETA from the Latin/Greek set ISO 8859/7 in ISO 8859/1
might best be done by "T" + "H".
Here's the problem. As you know, the IBM 370 instruction set includes
the TR instruction for very convenient 1-for-1 character translation.
IBM mainframe Kermits have always, in fact, had to perform ASCII-to-
EBCDIC translations, and most, if not all, have made use of the TR
instruction for this purpose. Migration to 8-bit "extended ASCII" in
recent times has resulted in a number of mappings of full 8-bit ASCII-
like codes into 8-bit extended EBCDIC-like codes, and these invertible
mappings can still be done with a simple TR. However, the new transfer
syntax includes the old 7-bit ASCII as one possible transfer character
set, and there lies the difficulty: how do we translated an extended
EBCDIC text into 7-bit ASCII? Do we
a) keep the present scheme of translating all undefined characters
as NUL,
b) ignore the distinction between ASCII and the 8-bit extended sets
and simply perform the full one-to-one mapping anyway,
c) honor the principal of 7-bit transfer codes and simply select the
"nearest" equivalent for each extended EBCDIC character,
d) adopt a one-to-multi-character translation scheme, or
e) do something else?
Let me sum up the arguments pro and con:
a) If a file comes through with lots of NULs, you can quickly tell
something is missing. Also, this option happens to match what
Kermit-370 presently does. However, this option entails severe
information loss in the transmission.
b) This option preserves information, but it represents a violent
departure from present Kermit-370 default behavior (although the
SET ETOA command allows the user to choose this option even now).
c) This option preserves some, though not all of the information. It
is therefore likely to produce at least a "legible" copy on a
system without extended fonts. However, the very attempt at
*preserving* information may conceal the fact of the *loss* of
some of it. Moreover, choosing the "nearest" equivalents is often
a tricky business.
d) This option preserves more information than (c), though still not
all. However, (1) there is an obvious and large increase in
complication, (2) a buffer full of text can no longer be
translated in place, (3) throughput might be significantly
degraded, and (4) such mappings are not generally invertible.
e) ?
I am inclined to favor option (c), but I'm not exactly happy with it.
Any comments (pro or con) on any of these options? Any ideas for (e)?
One possibility for keeping users aware of information loss in options
(a), (c), and (d) would be to adopt a standard definition of what
constitutes such loss and issuing a conditional error message whenever
it occurs. In case (a), the definition could be fairly simple (e.g.,
translating non-NUL into NUL), but the other two are much more difficult.
John
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Thu Sep 7 12:22:16 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA02101; Thu, 7 Sep 89 12:22:16 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA26735; Thu, 7 Sep 89 12:21:48 EDT
Message-Id: <8909071621.AA26735@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 2215; Thu, 07 Sep 89 12:20:50 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
6143; Thu, 07 Sep 89 12:20:49 EDT
Date: Thu, 07 Sep 89 12:21 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Character translations
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS9448-9448; 87 LINES); Thu, 07 Sep 89 10:13:16 EDT
Received: by CUVMB (Mailer R2.03B) id 5742; Thu, 07 Sep 89 10:08:43 EDT
Date: Thu, 7 Sep 89 10:08:02 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@CUVMB.CC.COLUMBIA.EDU>
Subject: Character translations
Comments: To: IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
I have resolved to implement the new Kermit transfer syntax extension
(at level 1) now being developed at Columbia (see file T:ISOK4.TXT on
KERMSRV for the latest draft of the documentation). For those who
haven't been following the development, the next paragraph summarizes
the parts relevant to the questions I wish to pose.
The level-1 extended transfer syntax entails defining a transfer
character set (selected from the ISO registry) which both Kermits
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Mon Sep 18 15:13:18 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA28884; Mon, 18 Sep 89 15:13:18 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA02068; Mon, 18 Sep 89 15:09:30 EDT
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7060; Mon, 18 Sep 89 15:11:30 EDT
Received: from CFAAMP.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 3775; Mon, 18 Sep 89 15:11:29 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer R2.03B) with
BSMTP id 2680; Mon, 18 Sep 89 14:47:49 EDT
Date: Mon, 1989 Sep 18 14:39 EDT
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@cuvmb.cc.columbia.edu>
To: Knut Winsnes <SYS85001@nobivm.bitnet>,
IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
Subject: Re: Search for info: COMMTEX CX-80, 370KERMIT for CMS and VTAM
In-Reply-To: SYS85001@NOBIVM message of Mon, 18 Sep 89 11:57:04 CET
Message-Id: <PEPMNT.890918.143928.C0@CFAAMP.BITNET>
> I am in search for info concerning 370KERMIT(CMS) and COMMTEX CX-80
> via VTAM.
The primary hint you need is that the Cx-80 appears to Kermit as a
Graphics-type front end, but works like a Series/1-type front end.
Very likely, that's all you need to know. The comments in IKCKER.BWR
concerning VTAM and the automatic detection of terminal controller type
may also be pertinent. "It's in there."
John
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Tue Sep 19 01:22:51 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA04354; Tue, 19 Sep 89 01:22:51 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA16416; Tue, 19 Sep 89 01:17:48 EDT
Message-Id: <8909190517.AA16416@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7334; Tue, 19 Sep 89 01:20:51 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
4996; Tue, 19 Sep 89 01:20:50 EDT
Date: Tue, 19 Sep 89 01:22 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Re: Search for info: COMMTEX CX-80, 370KERMIT for CMS and VTAM
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS2694-2694; 20 LINES); Mon, 18 Sep 89 15:19:29 EDT
Received: by CUVMB (Mailer R2.03B) id 3833; Mon, 18 Sep 89 15:13:09 EDT
Date: Mon, 18 Sep 89 15:12:24 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@CUVMB.CC.COLUMBIA.EDU>
Subject: Re: Search for info: COMMTEX CX-80, 370KERMIT for CMS and VTAM
Comments: To: Knut Winsnes <SYS85001@nobivm>,
IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
In-Reply-To: SYS85001@NOBIVM message of Mon, 18 Sep 89 11:57:04 CET
> I am in search for info concerning 370KERMIT(CMS) and COMMTEX CX-80
> via VTAM.
The primary hint you need is that the Cx-80 appears to Kermit as a
Graphics-type front end, but works like a Series/1-type front end.
Very likely, that's all you need to know. The comments in IKCKER.BWR
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Tue Sep 19 01:22:53 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA04355; Tue, 19 Sep 89 01:22:53 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA16422; Tue, 19 Sep 89 01:17:50 EDT
Message-Id: <8909190517.AA16422@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7335; Tue, 19 Sep 89 01:21:02 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
4998; Tue, 19 Sep 89 01:21:01 EDT
Date: Tue, 19 Sep 89 01:22 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: removal from list
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS3429-3429; 11 LINES); Mon, 18 Sep 89 17:09:30 EDT
Received: by CUVMB (Mailer R2.03B) id 4208; Mon, 18 Sep 89 17:07:07 EDT
Date: Mon, 18 Sep 89 16:42:01 ADT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: The Super User <iisat!root@UUNET.UU.NET>
Subject: removal from list
Comments: To: IBM-KERM%CUVMA@cuvmb.cc.columbia.edu
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
Please remove everett@iisat.UUCP from this list.
The account has been suspended.
From @cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET Tue Sep 19 09:39:58 1989
Return-Path: <@cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA07784; Tue, 19 Sep 89 09:39:58 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA10497; Tue, 19 Sep 89 09:33:14 EDT
Message-Id: <8909191333.AA10497@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7423; Tue, 19 Sep 89 09:38:09 EDT
Received: from VM1.EARN-ULG.AC.BE by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with
BSMTP id 5289; Tue, 19 Sep 89 09:38:08 EDT
Received: by BLIULG11 (Mailer R2.03B) id 8072; Tue, 19 Sep 89 15:39:03 +0200
Date: Tue, 19 Sep 89 15:15:40 +0200
From: Andr'e PIRARD <A-PIRARD%BLIULG11@cuvmb.cc.columbia.edu>
Subject: Streams and records
To: IBM mainframes Kermit <IBM-KERMIT@cunixc.cc.columbia.edu>
Quote from SC09-1264 "IBM C/370 User's Guide" p 92:
> For variable or undefined length records, empty lines are padded with a blank
> character on output. On input, a record containing a single space character
> is interpreted as an empty line.
> [and things like reading back a \n one never wrote to the end of a file]
In fact, the whole chapter "Input and Output" is interesting to see
how they tweaked the C library to conciliate data streams with records,
filenames and ddnames and all sorts of things.
And amusing how it looks like the IK documentation, to the point I wonder
if it's not John's favourite book.
I just wonder about creating empty CMS files. That's probably getting the \n.
Not talking of character codes, of course (a thing to read for DBCS, Frank).
And btw, they've got a long way, apparently:
> ASA files may be updated as well. The control characters may be updated as if
> they were ordinary characters, using C character manipulation routines. For
> example, '\n\n\n' at the beginning [? *] of a line may be updated to '\n'
> and vice versa.
[? *]: probably owing to the ASA characters being paper controls used as
line prefixes.
Strangely enough, one notes that *the* system having a true 'newline'
character is not using it in its files.
Their conclusion is in the introduction of "IBM C/370 General Information":
> IBM C/370 extends the emerging ANSI definition of C, taking advantage of
> features of the MVS and VM/CMS operating systems.
Mine is: C programmers, in addition to ANSI C, be aware and beware of SAA.
Getting it work on OS/2 is no guarantee for IBM mainframes.
They're just a little bit incompatible.
Andr).
From fdc Tue Sep 19 10:27:35 1989
Return-Path: <fdc>
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA08437; Tue, 19 Sep 89 10:27:35 EDT
Date: Tue, 19 Sep 89 10:27:34 EDT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
To: ibm-kermit
Subject: Let's start over
Message-Id: <CMM.0.88.622218454.fdc@watsun.cc.columbia.edu>
The IBM-Kermit mailing list is hopelessly messed up. Somehow, some part of
it found its way into the LISTSERV world, and many invalid subscriptions
were entered, so that every time someone sends mail to IBM-Kermit, I get
about 75 error messages back from LISTSERVers all over the place. So I would
like to make a new mailing list. If you want to be on it, please send a
message directly to me at the "From" address above, or to FDCCU@CUVMA.BITNET.
Thanks. - Frank
From phil@wubios.wustl.edu Tue Sep 19 11:09:14 1989
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA09089; Tue, 19 Sep 89 11:09:14 EDT
Received: from wucs1.wustl.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA17825; Tue, 19 Sep 89 11:02:22 EDT
Received: from wubios.wustl.edu by wucs1.wustl.edu
(5.59/1.35); id AA17612; Tue, 19 Sep 89 10:09:17 CDT
Return-Path: <phil@wubios.WUstl.EDU>
Received: by wubios.WUstl.EDU (4.0/Sun UNIX 4.0); Tue, 19 Sep 89 10:09:05 CDT
From: phil@wubios.wustl.edu (J. Philip Miller)
Message-Id: <8909191509.AA05514@wubios.WUstl.EDU>
Subject: Re: Let's start over
To: IBM-KERMIT@cunixc.cc.columbia.edu
Date: Tue, 19 Sep 89 10:09:04 CDT
In-Reply-To: <8909191440.AA15990@wugate.wustl.edu>; from "Frank da Cruz" at Sep 19, 89 10:27 am
X-Mailer: ELM [version 2.2 PL10]
> The IBM-Kermit mailing list is hopelessly messed up. Somehow, some part of
> it found its way into the LISTSERV world, and many invalid subscriptions
> were entered, so that every time someone sends mail to IBM-Kermit, I get
> about 75 error messages back from LISTSERVers all over the place. So I would
> like to make a new mailing list. If you want to be on it, please send a
> message directly to me at the "From" address above, or to FDCCU@CUVMA.BITNET.
> Thanks. - Frank
>
count me in!
--
J. Philip Miller, Professor, Division of Biostatistics, Box 8067
Washington University Medical School, St. Louis MO 63110
phil@wubios.WUstl.edu - Internet (314) 362-3617 phil@wubios.wustl - bitnet
uunet!wucs1!wubios!phil - UUCP C90562JM@WUVMD - alternate bitnet
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Tue Sep 19 12:22:23 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA09908; Tue, 19 Sep 89 12:22:23 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA24012; Tue, 19 Sep 89 12:15:32 EDT
Message-Id: <8909191615.AA24012@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7559; Tue, 19 Sep 89 12:20:34 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
6075; Tue, 19 Sep 89 12:20:33 EDT
Date: Tue, 19 Sep 89 12:21 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Streams and records
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS6205-6205; 43 LINES); Tue, 19 Sep 89 09:44:30 EDT
Received: by CUVMB (Mailer R2.03B) id 5348; Tue, 19 Sep 89 09:40:24 EDT
Date: Tue, 19 Sep 89 15:15:40 +0200
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: Andr'e PIRARD <A-PIRARD%BLIULG11@CUVMB.CC.COLUMBIA.EDU>
Subject: Streams and records
Comments: To: IBM mainframes Kermit <IBM-KERMIT@cunixc.cc.columbia.edu>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
Quote from SC09-1264 "IBM C/370 User's Guide" p 92:
> For variable or undefined length records, empty lines are padded with a blank
> character on output. On input, a record containing a single space character
> is interpreted as an empty line.
> [and things like reading back a \n one never wrote to the end of a file]
In fact, the whole chapter "Input and Output" is interesting to see
how they tweaked the C library to conciliate data streams with records,
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.HARVARD.EDU Fri Sep 22 10:58:12 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.HARVARD.EDU>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA14515; Fri, 22 Sep 89 10:58:12 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA03594; Fri, 22 Sep 89 10:57:10 EDT
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 9622; Fri, 22 Sep 89 10:56:16 EDT
Received: from CFAAMP.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 2913; Fri, 22 Sep 89 10:56:14 EDT
Received: from CFAAMP.HARVARD.EDU (PEPMNT) by CFAAMP.BITNET (Mailer R2.03B)
with BSMTP id 3726; Fri, 22 Sep 89 10:55:27 EDT
Date: Fri, 1989 Sep 22 10:55 EDT
From: "John F. Chandler" <PEPMNT%CFAAMP.HARVARD.EDU@cuvmb.cc.columbia.edu>
To: IBM-KERMIT <IBM-KERMIT@cunixc.cc.columbia.edu>,
Knut Winsnes <SYS85001@nobivm.bitnet>
Subject: Re: 370KERMIT(CMS) and Remote Commtex CX80 via VTAM
In-Reply-To: SYS85001@NOBIVM message of Fri, 22 Sep 89 12:47:52 CET
Message-Id: <PEPMNT.890922.105522.C0@CFAAMP.HARVARD.EDU>
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Fri Sep 22 11:43:41 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA14887; Fri, 22 Sep 89 11:43:41 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA08447; Fri, 22 Sep 89 11:42:37 EDT
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 9718; Fri, 22 Sep 89 11:34:57 EDT
Received: from CFAAMP.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 3198; Fri, 22 Sep 89 11:34:55 EDT
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer R2.03B) with
BSMTP id 0035; Fri, 22 Sep 89 11:33:58 EDT
Date: Fri, 1989 Sep 22 11:26 EDT
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@cuvmb.cc.columbia.edu>
To: IBM-KERMIT <IBM-KERMIT@cunixc.cc.columbia.edu>,
Knut Winsnes <SYS85001@nobivm.bitnet>
Subject: Re: 370KERMIT(CMS) and Remote Commtex CX80 via VTAM
In-Reply-To: SYS85001@NOBIVM message of Fri, 22 Sep 89 12:47:52 CET
Message-Id: <PEPMNT.890922.112602.C0@CFAAMP.BITNET>
How about another experiment. Try running CMS Kermit in LOCAL mode:
Cx-80 terminal Other terminal
1. log on and start CMS Kermit
2. CP DEF GRAF 555
3. connect
4. DIAL SYS85001 555
5. KERMIT SET LINE 555
6. KERMIT SET CONT SERIES1
7. KERMIT SEND ...
This will use slightly different I/O and might possibly work where
the other tests failed.
John
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Fri Sep 22 12:25:11 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA15415; Fri, 22 Sep 89 12:25:11 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA12104; Fri, 22 Sep 89 12:24:08 EDT
Message-Id: <8909221624.AA12104@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 9755; Fri, 22 Sep 89 12:23:16 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
3447; Fri, 22 Sep 89 12:23:15 EDT
Date: Fri, 22 Sep 89 12:21 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: 370KERMIT(CMS) and Remote Commtex CX80 via VTAM
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS2127-2127; 45 LINES); Fri, 22 Sep 89 08:28:33 EDT
Received: by CUVMB (Mailer R2.03B) id 2313; Fri, 22 Sep 89 07:32:52 EDT
Date: Fri, 22 Sep 89 12:47:52 CET
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: Knut Winsnes <SYS85001@NOBIVM>
Subject: 370KERMIT(CMS) and Remote Commtex CX80 via VTAM
Comments: To: IBM KERMIT developers <IBM-KERM@CUVMA>,
IBM Mainframe Discussion List <IBM-MAIN@DEARN>,
VM VTAM discussions <VMVTAM-L@UIUCVMD>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
Hi, I need some help. I am participating in a test with the following
configuration:
VM/SP-CMS(Rel 4)-370KERMIT(4.1.005)
VTAM
NCP
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Fri Sep 22 12:25:17 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA15418; Fri, 22 Sep 89 12:25:17 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA12111; Fri, 22 Sep 89 12:24:12 EDT
Message-Id: <8909221624.AA12111@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 9756; Fri, 22 Sep 89 12:23:20 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
3449; Fri, 22 Sep 89 12:23:19 EDT
Date: Fri, 22 Sep 89 12:21 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Re: 370KERMIT(CMS) and Remote Commtex CX80 via VTAM
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS3197-3197; 26 LINES); Fri, 22 Sep 89 11:49:13 EDT
Received: by CUVMB (Mailer R2.03B) id 3268; Fri, 22 Sep 89 11:43:10 EDT
Date: Fri, 22 Sep 89 11:42:18 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@CUVMB.CC.COLUMBIA.EDU>
Subject: Re: 370KERMIT(CMS) and Remote Commtex CX80 via VTAM
Comments: To: IBM-KERMIT <IBM-KERMIT@cunixc.cc.columbia.edu>,
Knut Winsnes <SYS85001@nobivm>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
In-Reply-To: SYS85001@NOBIVM message of Fri, 22 Sep 89 12:47:52 CET
How about another experiment. Try running CMS Kermit in LOCAL mode:
Cx-80 terminal Other terminal
1. log on and start CMS Kermit
2. CP DEF GRAF 555
From @cuvmb.cc.columbia.edu:JGTKRAT@CALSTATE.BITNET Wed Oct 4 13:00:07 1989
Return-Path: <@cuvmb.cc.columbia.edu:JGTKRAT@CALSTATE.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA03133; Wed, 4 Oct 89 13:00:07 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA24267; Wed, 4 Oct 89 12:59:28 EDT
Message-Id: <8910041659.AA24267@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 6165; Wed, 04 Oct 89 12:21:40 EDT
Received: from CALSTATE.BITNET (JGTKRAT) by CUVMB.COLUMBIA.EDU (Mailer R2.03B)
with BSMTP id 2037; Wed, 04 Oct 89 00:42:21 EDT
Received: by CCS.CSUSCC.CALSTATE.EDU from Mail by CSUMailer (1.3);
Tue, 3 Oct 89 21:33:38 PDT
Date: Tue, 03 Oct 89 21:32:14 PDT
From: JGTKRAT%CALSTATE.BITNET@cuvmb.cc.columbia.edu
Subject: IBM-KERM
To: IBM-KERMIT@cunixc.cc.columbia.edu
Cc: <FDCCU@cuvma.bitnet>
Please continue my subscription to IBM-KERM. If possible, please
send it both to this address (as I know it works) and to
sandhoff@csus.edu (which should now work but who knows...).
As we're just now installing a real IBM, I suspect that I'm going
to need all the help I can get. When is Joe going to port MS-Kermit
onto MVS? (and a version for VAX/VMS) [Yes, I'm just kidding. I
wouldn't do that to Joe]
John F. Sandhoff, Systems Support, CSU Sacramento
A loyal Kermit fan since the beginning of time (I still have my 1984
release tape, and a running copy of MS-Kermit 1.20. Convinced?)
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Thu Oct 5 01:26:26 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA09204; Thu, 5 Oct 89 01:26:26 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA25759; Thu, 5 Oct 89 01:25:42 EDT
Message-Id: <8910050525.AA25759@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 8300; Thu, 05 Oct 89 01:24:03 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
7631; Thu, 05 Oct 89 01:24:02 EDT
Date: Thu, 05 Oct 89 01:23 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: IBM-KERM
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS4214-4214; 22 LINES); Wed, 04 Oct 89 13:03:04 EDT
Received: by CUVMB (Mailer R2.03B) id 5704; Wed, 04 Oct 89 12:59:20 EDT
Date: Tue, 3 Oct 89 21:32:14 PDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: JGTKRAT%CALSTATE.BITNET@CUVMB.CC.COLUMBIA.EDU
Subject: IBM-KERM
Comments: To: IBM-KERMIT@cunixc.cc.columbia.edu
Comments: cc: FDCCU@cuvma.BITNET
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
Please continue my subscription to IBM-KERM. If possible, please
send it both to this address (as I know it works) and to
sandhoff@csus.edu (which should now work but who knows...).
As we're just now installing a real IBM, I suspect that I'm going
to need all the help I can get. When is Joe going to port MS-Kermit
onto MVS? (and a version for VAX/VMS) [Yes, I'm just kidding. I
wouldn't do that to Joe]
From PEPMNT@cfaamp.harvard.edu Fri Oct 6 16:39:48 1989
Return-Path: <PEPMNT@cfaamp.harvard.edu>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA17532; Fri, 6 Oct 89 16:39:48 EDT
Received: from [128.103.40.61] by cunixc.cc.columbia.edu (5.59/FCB)
id AA23139; Fri, 6 Oct 89 16:38:54 EDT
Received: from CFAAMP.HARVARD.EDU by CFAAMP.HARVARD.EDU (IBM VM SMTP R1.2.1) with BSMTP id 2846; Fri, 06 Oct 89 16:38:28 EDT
Date: Fri, 1989 Oct 6 15:54 EDT
From: "John F. Chandler" <PEPMNT@cfaamp.harvard.edu>
To: IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
Subject: Switching transfer alphabets
Message-Id: <PEPMNT.891006.155440.C0@CFAAMP.HARVARD.EDU>
Well, I didn't get much response to my question about whether and how
to deal with the nominally 128-character ASCII codes in the new
256-character environment, but here's another, simpler question.
Let's suppose there is a mechanism for the sending Kermit to tell
the receiver what 256-character set is being used in the transfer,
and the user has a way of selecting which one *should* be used.
Suppose the user specifies SET TRANSFER CHAR LATIN1 to Kermit "A",
and then tells "A" to receive a file, which comes in carrying an
attribute saying the character set is GREEK. Should Kermit "A" then
continue to assume transfers will be in GREEK, even when sending? Or
should it try to remember and obey what the user said before? This
issue is similar to that of user-settable file attributes, which can
(in principle, but not yet in practice in Kermit-370) be superseded by
information in A-packets. However, the transfer character set has
nothing to with the representation of the file on either end (in
principle, anyway), so any mutually acceptable alphabet should continue
to be acceptable "forever". The difficulty is that some character sets
may be poorly matched to the underlying graphic set used in files. One
way of side-stepping this question is to split the specification into
SEND and RECEIVE options, just like EOL, packet-size, etc. How does
that grab you?
John
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Sat Oct 7 01:28:42 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA21848; Sat, 7 Oct 89 01:28:42 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA09079; Sat, 7 Oct 89 01:28:38 EDT
Message-Id: <8910070528.AA09079@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 0320; Sat, 07 Oct 89 01:26:20 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
3774; Sat, 07 Oct 89 01:26:19 EDT
Date: Sat, 07 Oct 89 01:26 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Switching transfer alphabets
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS6965-6965; 31 LINES); Fri, 06 Oct 89 16:47:47 EDT
Received: by CUVMB (Mailer R2.03B) id 2332; Fri, 06 Oct 89 16:39:40 EDT
Date: Fri, 6 Oct 89 16:38:55 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "John F. Chandler" <PEPMNT@CFAAMP.HARVARD.EDU>
Subject: Switching transfer alphabets
Comments: To: IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
Well, I didn't get much response to my question about whether and how
to deal with the nominally 128-character ASCII codes in the new
256-character environment, but here's another, simpler question.
Let's suppose there is a mechanism for the sending Kermit to tell
the receiver what 256-character set is being used in the transfer,
and the user has a way of selecting which one *should* be used.
Suppose the user specifies SET TRANSFER CHAR LATIN1 to Kermit "A",
and then tells "A" to receive a file, which comes in carrying an
From PEPMNT@cfaamp.harvard.edu Thu Oct 12 23:14:33 1989
Return-Path: <PEPMNT@cfaamp.harvard.edu>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA29257; Thu, 12 Oct 89 23:14:33 EDT
Received: from [128.103.40.61] by cunixc.cc.columbia.edu (5.59/FCB)
id AA16791; Thu, 12 Oct 89 23:14:05 EDT
Received: from CFAAMP.HARVARD.EDU by CFAAMP.HARVARD.EDU (IBM VM SMTP R1.2.1) with BSMTP id 4141; Thu, 12 Oct 89 23:13:08 EDT
Date: Thu, 1989 Oct 12 22:45 EDT
From: "John F. Chandler" <PEPMNT@cfaamp.harvard.edu>
To: IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
Subject: New subcommand proposal
Message-Id: <PEPMNT.891012.224537.C0@CFAAMP.HARVARD.EDU>
There has been a suggestion to add a new option to Kermit for uploading
a new file with the same name as an old one when WARNING is OFF.
Currently, when that happens, the new file gets written with attributes
determined by Kermit, more or less as if the old file had never existed.
However, there might be circumstances when the user would prefer not to
use the Kermit defaults and would also prefer not to have to type in the
desired attributes. In that case, the new option would cause Kermit to
remember the attributes of the old file and reuse them for the new one.
This would be pretty generic, although it was suggested first for TSO.
The question is: how should the option be specified? One possibility
is to create a new ON/OFF switch with the command syntax
SET FILE SAVE-ATTRIBUTES ON|OFF
An alternative to SAVE here might be KEEP or even OLD. Since this flag
would have no meaning unless WARNING is OFF, it would be tempting to
simply modify WARNING:
SET WARNING ON|OFF|SAVE-ATTRIBUTES
The trouble with that idea is that WARNING is a misnomer in many Kermit
implementations -- WARNING ON usually means that filename collisions
are automatically avoided, and there is usually no special warning of
the change in name. As a result, putting the new option in with
WARNING would probably make it harder to explain and to remember.
Any ideas? Comments? Votes?
John
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Fri Oct 13 01:39:33 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA00559; Fri, 13 Oct 89 01:39:33 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA22250; Fri, 13 Oct 89 01:38:46 EDT
Message-Id: <8910130538.AA22250@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 4962; Fri, 13 Oct 89 01:36:57 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
7176; Fri, 13 Oct 89 01:36:56 EDT
Date: Fri, 13 Oct 89 01:22 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: New subcommand proposal
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS5926-5926; 36 LINES); Thu, 12 Oct 89 23:53:54 EDT
Received: by CUVMB (Mailer R2.03B) id 6968; Thu, 12 Oct 89 23:14:43 EDT
Date: Thu, 12 Oct 89 23:14:04 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "John F. Chandler" <PEPMNT@CFAAMP.HARVARD.EDU>
Subject: New subcommand proposal
Comments: To: IBM-Kermit <IBM-Kermit@cunixc.cc.columbia.edu>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
There has been a suggestion to add a new option to Kermit for uploading
a new file with the same name as an old one when WARNING is OFF.
Currently, when that happens, the new file gets written with attributes
determined by Kermit, more or less as if the old file had never existed.
However, there might be circumstances when the user would prefer not to
use the Kermit defaults and would also prefer not to have to type in the
desired attributes. In that case, the new option would cause Kermit to
remember the attributes of the old file and reuse them for the new one.
From @cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET Fri Oct 13 06:27:49 1989
Return-Path: <@cuvmb.cc.columbia.edu:A-PIRARD@BLIULG11.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA02296; Fri, 13 Oct 89 06:27:49 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA10088; Fri, 13 Oct 89 06:26:54 EDT
Message-Id: <8910131026.AA10088@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 5003; Fri, 13 Oct 89 06:25:13 EDT
Received: from VM1.EARN-ULG.AC.BE by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with
BSMTP id 7319; Fri, 13 Oct 89 06:25:12 EDT
Received: by BLIULG11 (Mailer R2.03B) id 4802; Fri, 13 Oct 89 11:27:37 +0100
Date: Fri, 13 Oct 89 10:55:03 +0100
From: Andr'e PIRARD <A-PIRARD%BLIULG11@cuvmb.cc.columbia.edu>
Subject: Re: New subcommand proposal
To: IBM mainframes Kermit <IBM-KERMIT@cunixc.cc.columbia.edu>
In-Reply-To: Message of Thu, 12 Oct 89 23:14:04 EDT from
<PEPMNT@CFAAMP.HARVARD.EDU>
We could extend the idea to copying the attributes of any
file taken as a model, with the attractive syntax:
SET FILE ATTRIBUTES LIKE [filename]
UNLIKE (the default)
LIKE alone would mean "filename" is the one coming in, whether actually
renamed or not (irrespectively of SET WARNING).
My suggestion depends on how easily of the present code can be changed, viz
if keeping the same attributes is looking at them, erasing then creating
a new file.
But this syntax might be felt open-ended anyway.
Andr).
From @cuvmb.cc.columbia.edu:U8803KT@DOECX.BITNET Fri Oct 13 09:20:01 1989
Return-Path: <@cuvmb.cc.columbia.edu:U8803KT@DOECX.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA03496; Fri, 13 Oct 89 09:20:01 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA17472; Fri, 13 Oct 89 09:19:04 EDT
Message-Id: <8910131319.AA17472@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 5063; Fri, 13 Oct 89 09:17:22 EDT
X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender.
Received: from DOEVM.BITNET (MAILER) by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with
BSMTP id 7629; Fri, 13 Oct 89 09:17:21 EDT
Received: by DOEVM (Mailer R2.04) id 1791; Fri, 13 Oct 89 09:20:19 EDT
Date: Fri, 13 Oct 89 09:20:15 EDT
From: "Thomas L. Kern" <U8803KT%DOECX@cuvmb.cc.columbia.edu>
Subject: New subcommand proposal
In-Reply-To: note of 10/12/89 23:53
To: "IBM-KERMIT" <IBM-KERMIT@cunixc.cc.columbia.edu>
I vote for the SET FILE SAVE-ATTRIBUTES ON|OFF syntax. This is more
descriptive of what it is really trying to do than the SET WARNING syntax.
From @cuvmb.cc.columbia.edu:MAINT@UQAM.BITNET Fri Oct 13 11:41:34 1989
Return-Path: <@cuvmb.cc.columbia.edu:MAINT@UQAM.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA05305; Fri, 13 Oct 89 11:41:34 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA29721; Fri, 13 Oct 89 11:40:38 EDT
Message-Id: <8910131540.AA29721@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 5205; Fri, 13 Oct 89 11:38:56 EDT
Received: from UQAM.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
8139; Fri, 13 Oct 89 11:38:55 EDT
Received: by UQAM (Mailer R2.03B) id 9231; Fri, 13 Oct 89 11:35:16 EDT
Date: Fri, 13 Oct 89 10:51:48 EDT
From: Peter Jones <MAINT%UQAM@cuvmb.cc.columbia.edu>
Subject: Re: New subcommand proposal
To: IBM-KERMIT@cunixc.cc.columbia.edu
In-Reply-To: Message of Thu, 12 Oct 89 23:14:04 EDT from
<PEPMNT@CFAAMP.HARVARD.EDU>
I feel it would be useful to be able to transfer a series of files, but
skip those already transferred. For example, I have a series of .ARC files
on CMS, some of which have been transferred. I'd like to be able to
transfer only those that are missing on the PC.
After mulling this idea overnight, I took out the VAX/VMS user manual, and
took a look at the options available with the BACKUP command. In a way,
transferring files is a bit like doing a restore. Some relevant switches
that could be considered in KERMIT transfers are:
1) Time-sensitive switches: /BEFORE, /SINCE
2) /COMPARE: compare without destroying file at destination
3) /CONFIRM: ask user about each file
4) /DELETE: delete after successful transfer (maybe construct a batch file to
delete all the files at once, after all transfers are complete
5) /EXCLUDE: prevent certain files from being transferred
6) /MODIFIED: allow transfer only if newer version
7) /OVERLAY: rewrite over same file space
8) /REPLACE: replace file of same name
9) /VERIFY: verify after transfer (only practical if high-speed link between
machines
This is a rather ambitious proposal, I admit. Basically, what I'd like to do
is to get away from the norrow view of SET FILE WARNING to switches that would
tell KERMIT what to do in case of filename collisions.
On KERMIT370, and other non-ASCII versions, I'd like to see SET FILE TEXT/BIN
selected on the basis of the extension, if the user wishes. TEXT would be the
default; the user could specify SET FILETYPE-DEFAULT BIN (COM EXE ARC ...) for
the IBM PC, for example.
Peter Jones MAINT@UQAM (514)-987-3542
"Life's too short to try and fill up every minute of it" :-)
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Fri Oct 13 12:22:50 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA05709; Fri, 13 Oct 89 12:22:50 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA04070; Fri, 13 Oct 89 12:21:53 EDT
Message-Id: <8910131621.AA04070@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 5246; Fri, 13 Oct 89 12:20:12 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
8385; Fri, 13 Oct 89 12:20:11 EDT
Date: Fri, 13 Oct 89 12:21 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: New subcommand proposal
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS7344-7344; 12 LINES); Fri, 13 Oct 89 09:23:31 EDT
Received: by CUVMB (Mailer R2.03B) id 7687; Fri, 13 Oct 89 09:18:38 EDT
Date: Fri, 13 Oct 89 09:20:15 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: "Thomas L. Kern" <U8803KT%DOECX@CUVMB.CC.COLUMBIA.EDU>
Subject: New subcommand proposal
Comments: To: IBM-KERMIT <IBM-KERMIT@cunixc.cc.columbia.edu>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
In-Reply-To: note of 10/12/89 23:53
I vote for the SET FILE SAVE-ATTRIBUTES ON|OFF syntax. This is more
descriptive of what it is really trying to do than the SET WARNING syntax.
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Fri Oct 13 12:22:57 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA05712; Fri, 13 Oct 89 12:22:57 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA04077; Fri, 13 Oct 89 12:21:59 EDT
Message-Id: <8910131621.AA04077@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 5247; Fri, 13 Oct 89 12:20:18 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
8387; Fri, 13 Oct 89 12:20:16 EDT
Date: Fri, 13 Oct 89 12:21 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Re: New subcommand proposal
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS6695-6695; 23 LINES); Fri, 13 Oct 89 06:31:17 EDT
Received: by CUVMB (Mailer R2.03B) id 7377; Fri, 13 Oct 89 06:28:09 EDT
Date: Fri, 13 Oct 89 10:55:03 +0100
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: Andr'e PIRARD <A-PIRARD%BLIULG11@CUVMB.CC.COLUMBIA.EDU>
Subject: Re: New subcommand proposal
Comments: To: IBM mainframes Kermit <IBM-KERMIT@cunixc.cc.columbia.edu>
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
In-Reply-To: Message of Thu,
12 Oct 89 23:14:04 EDT from <PEPMNT@CFAAMP.HARVARD.EDU>
We could extend the idea to copying the attributes of any
file taken as a model, with the attractive syntax:
SET FILE ATTRIBUTES LIKE [filename]
UNLIKE (the default)
LIKE alone would mean "filename" is the one coming in, whether actually
renamed or not (irrespectively of SET WARNING).
From @cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET Fri Oct 13 12:23:01 1989
Return-Path: <@cuvmb.cc.columbia.edu:TUCJFWS@TUCC.BITNET>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA05720; Fri, 13 Oct 89 12:23:01 EDT
Received: from cuvmb.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
id AA04088; Fri, 13 Oct 89 12:22:04 EDT
Message-Id: <8910131622.AA04088@cunixc.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 5249; Fri, 13 Oct 89 12:20:21 EDT
Received: from TUCC.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP id
8389; Fri, 13 Oct 89 12:20:20 EDT
Date: Fri, 13 Oct 89 12:21 EDT
To: IBM-KERMIT@cunixc.cc.columbia.edu
From: Postmaster <TUCJFWS%TUCC.BITNET@cuvmb.cc.columbia.edu>
Subject: Re: Re: New subcommand proposal
You recently sent mail to TUCSEB@TUCC. The E-Mail
address for TUCSEB has been changed to:
tuchjac
Your mail was automatically forwarded to TUCSEB
at the new address. Please use tuchjac
when sending mail to TUCSEB in the future.
The forwarded mail began:
---------------------------- Original mail ------------------------------
Received: (from MAILER@CUVMA for TUCSEB@TUCC via NJE)
(RSCS8483-8483; 52 LINES); Fri, 13 Oct 89 11:44:02 EDT
Received: by CUVMB (Mailer R2.03B) id 8200; Fri, 13 Oct 89 11:40:27 EDT
Date: Fri, 13 Oct 89 10:51:48 EDT
Reply-To: IBM-KERMIT@CU20B.COLUMBIA.EDU
Sender: IBM KERMIT developers <IBM-KERM@CUVMA>
From: Peter Jones <MAINT%UQAM@CUVMB.CC.COLUMBIA.EDU>
Subject: Re: New subcommand proposal
Comments: To: IBM-KERMIT@cunixc.cc.columbia.edu
To: "Steve Blankinship, Triangle Univ CC (TSO" <TUCSEB>
In-Reply-To: Message of Thu,
12 Oct 89 23:14:04 EDT from <PEPMNT@CFAAMP.HARVARD.EDU>
I feel it would be useful to be able to transfer a series of files, but
skip those already transferred. For example, I have a series of .ARC files
on CMS, some of which have been transferred. I'd like to be able to
transfer only those that are missing on the PC.
After mulling this idea overnight, I took out the VAX/VMS user manual, and
From fdc Tue Oct 31 14:01:36 1989
Return-Path: <fdc>
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA25627; Tue, 31 Oct 89 14:01:36 EST
Date: Tue, 31 Oct 89 14:01:36 EST
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Subject: [Charles Becker <CHARLES%ETSUACAD@cuvmb.cc.columbia.edu>: What
happened to the IBM-Kermit discussion list?]
To: ibm-kermit@watsun.cc.columbia.edu
Message-Id: <CMM.0.88.625863696.fdc@watsun.cc.columbia.edu>
I'm forwarding the following message to the new, improved IBM-Kermit list,
IBM-Kermit@watsun.cc.columbia.edu. I hope you all get it. The old
LISTSERV address, IBM-KERM@CUVMA, is supposed to forward to the new
address, but this hasn't been tested yet. - Frank
---------------
Date: Sat, 28 Oct 89 00:55:50 CST
From: Charles Becker <CHARLES%ETSUACAD@cuvmb.cc.columbia.edu>
Subject: What happened to the IBM-Kermit discussion list?
To: Frank da Cruz <FDCCU@cuvmb.cc.columbia.edu>
What is the status of the IBM-KERM list? The last mailing I received
I received from it was dated Fri, 13 Oct 89 (!!!). I reviewed the
list and found that nobody was subscribed anymore. I tried to re-
subscribe and it said my request would be forwarded to the list owner
(you). I have a very troublesome problem with Kermit-CMS that I
would like to post a question about, but I have no idea where to
post it. Since I have no one else to send it to, I'll include it
here. If there is a proper person or place to send postings to,
please let me know.
MANY thanks.
Charles Becker
(frustrated) VM Systems Programmer
East Texas State University
CHARLES@ETSUACAD.BITNET
Original posting follows:
...............................................................................
Date: Thu, 26 Oct 89 01:51:01 CST
From: Charles Becker <CHARLES@ETSUACAD>
Subject: KERMIT SEND failure from VM/SP6 SFS directory
To: IBM S/370 Kermit Discussion List <IBM-KERM@CUVMA>
Whenever we try to send a file from a directory in SP6's Shared File
System, we get a "File not found" message. Does anybody know of a fix
or of plans for a fix for this problem? I've just installed the latest
update file (CMS Kermit Ver 4.1.005) and the problem has not disappeared.
Right now, I'm having our users create a T-Disk, copy their files to it,
and download from there, but this is an annoying process to have to go
through (as well as explain).
Thanks in advance for any info or help.
Charles Becker
VM Systems Programmer
East Texas State University
CHARLES@ETSUACAD.BITNET
From @cuvmb.cc.columbia.edu:LISTSERV@CUVMA.BITNET Tue Oct 31 16:00:14 1989
Return-Path: <@cuvmb.cc.columbia.edu:LISTSERV@CUVMA.BITNET>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA26994; Tue, 31 Oct 89 16:00:14 EST
Message-Id: <8910312100.AA26994@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7007; Tue, 31 Oct 89 16:00:12 EST
Received: by CUVMB (Mailer R2.03B) id 4276; Tue, 31 Oct 89 16:00:10 EST
Date: Tue, 31 Oct 89 16:00:03 EST
From: Revised List Processor (1.6c) <LISTSERV%CUVMA@cuvmb.cc.columbia.edu>
Subject: Request for subscription to list IBM-KERM
To: FDC@watsun.cc.columbia.edu, FDCCU@cuvma.bitnet, CMG@watsun.cc.columbia.edu
Cc: IBM-KERMIT@watsun.cc.columbia.edu
Dear list owner,
A request for subscription to your distribution list IBM-KERM (IBM KERMIT
developers) has been received on Tuesday, October the 31st of 1989 from
IBM-KERMIT LIST <IBM-KERMIT@WATSUN.CC.COLUMBIA.EDU>.
You can, at your discretion, issue the following command to LISTSERV@CUVMA to
add this person to the list: ADD IBM-KERM IBM-KERMIT@WATSUN.CC.COLUMBIA.EDU
IBM-KERMIT LIST
Virtually,
The LISTSERV management
From @cuvmb.cc.columbia.edu:LISTSERV@CUVMA.BITNET Tue Oct 31 15:59:56 1989
Return-Path: <@cuvmb.cc.columbia.edu:LISTSERV@CUVMA.BITNET>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA26973; Tue, 31 Oct 89 15:59:56 EST
Message-Id: <8910312059.AA26973@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7003; Tue, 31 Oct 89 15:59:54 EST
Received: by CUVMB (Mailer R2.03B) id 4271; Tue, 31 Oct 89 15:59:53 EST
Date: Tue, 31 Oct 89 15:59:52 EST
From: Revised List Processor (1.6c) <LISTSERV%CUVMA@cuvmb.cc.columbia.edu>
Subject: Output of job "" from IBM-KERMIT@WATSUN.CC.COLUMBIA.EDU
To: IBM-KERMIT@watsun.cc.columbia.edu
Your name is unknown to this LISTSERV. You must specify it, for example: SUB
IBM-KERM John A. Doe.
From @cuvmb.cc.columbia.edu:LISTSERV@CUVMA.BITNET Tue Oct 31 16:00:59 1989
Return-Path: <@cuvmb.cc.columbia.edu:LISTSERV@CUVMA.BITNET>
Received: from wubios.wustl.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AB26994; Tue, 31 Oct 89 16:00:59 EST
Message-Id: <8910312100.AB26994@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7008; Tue, 31 Oct 89 16:00:13 EST
Received: by CUVMB (Mailer R2.03B) id 4277; Tue, 31 Oct 89 16:00:11 EST
Date: Tue, 31 Oct 89 16:00:04 EST
From: Revised List Processor (1.6c) <LISTSERV%CUVMA@cuvmb.cc.columbia.edu>
Subject: Output of job "" from IBM-KERMIT@WATSUN.CC.COLUMBIA.EDU
To: IBM-KERMIT@watsun.cc.columbia.edu
List IBM-KERM is not open for automatic subscription.
Your request has been forwarded to the list owner(s):
FDC@WATSUN.CC.COLUMBIA.EDU
Frank da Cruz <FDCCU@CUVMA>
CMG@WATSUN.CC.COLUMBIA.EDU
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Tue Oct 31 16:18:09 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA27133; Tue, 31 Oct 89 16:18:09 EST
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7036; Tue, 31 Oct 89 16:18:07 EST
Received: from CFAAMP.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 4438; Tue, 31 Oct 89 16:18:06 EST
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer R2.03B) with
BSMTP id 6970; Tue, 31 Oct 89 16:15:26 EST
Date: Tue, 1989 Oct 31 15:16 EST
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@cuvmb.cc.columbia.edu>
To: ibm-kermit <ibm-kermit@watsun.cc.columbia.edu>,
Charles Becker <CHARLES@etsuacad.bitnet>
Subject: Re: [Charles Becker <CHARLES%ETSUACAD@cuvmb.cc.columbia.edu>: What
happened to the IBM-Kermit discussion list?]
In-Reply-To: fdc@watsun.cc.columbia.edu message
<CMM.0.88.625863696.fdc@watsun.cc.columbia.edu> of Tue, 31 Oct 89 14:01:36 EST
Message-Id: <PEPMNT.891031.151658.C0@CFAAMP.BITNET>
> Whenever we try to send a file from a directory in SP6's Shared File
> System, we get a "File not found" message. Does anybody know of a fix
> or of plans for a fix for this problem?
I can't say I'm surprised that there is a problem with the new Shared
File System. It's obviously an all-new, incompatible file system and
will require a whole new application interface. Also, obviously, that
interface will have to be worked out and tested at a site running CMS 6.
I welcome any suggestions/contributions on this score. For comparison,
the traditional interface steps through the directory blocks in virtual
storage looking for whole or partial matches to the requested file name.
It will be necessary to be able to search the Shared File System in a
similar, quiet fashion such that the system search order is duplicated
within Kermit. (By "quiet", I mean that there must be no error message
from the system if Kermit tries to find a name and gets no match.)
John
From @cuvmb.cc.columbia.edu:IBM-KERM@CUVMA.BITNET Wed Nov 1 10:42:47 1989
Return-Path: <@cuvmb.cc.columbia.edu:IBM-KERM@CUVMA.BITNET>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA06467; Wed, 1 Nov 89 10:42:47 EST
Message-Id: <8911011542.AA06467@watsun.cc.columbia.edu>
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7695; Wed, 01 Nov 89 10:42:44 EST
Received: by CUVMB (Mailer R2.03B) id 6596; Wed, 01 Nov 89 10:42:43 EST
Date: Wed, 1 Nov 89 10:41:30 EST
Reply-To: IBM-KERMIT%WATSUN.CC.COLUMBIA.EDU@cuvmb.cc.columbia.edu
Sender: IBM KERMIT developers <IBM-KERM%CUVMA@cuvmb.cc.columbia.edu>
From: Frank da Cruz <fdc%WATSUN.CC.COLUMBIA.EDU@cuvmb.cc.columbia.edu>
Subject: This is a test
Comments: To: IBM-KERM@cuvmb.cc.columbia.edu
To: IBM-KERMIT list <IBM-KERMIT@watsun.cc.columbia.edu>
This is a test to see if mail to IBM-KERM@CUVMA is properly forwarded
to ibm-kermit@watsun.cc.columbia.edu.
From PEPMNT@cfaamp.harvard.edu Wed Nov 1 15:17:21 1989
Return-Path: <PEPMNT@cfaamp.harvard.edu>
Received: from CFAAMP.HARVARD.EDU ([128.103.40.61]) by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA09072; Wed, 1 Nov 89 15:17:21 EST
Received: from CFAAMP.HARVARD.EDU by CFAAMP.HARVARD.EDU (IBM VM SMTP R1.2.1) with BSMTP id 7618; Wed, 01 Nov 89 15:15:26 EDT
Date: Wed, 1989 Nov 1 15:04 EST
From: "John F. Chandler" <PEPMNT@cfaamp.harvard.edu>
To: IBM-Kermit <IBM-Kermit@watsun.cc.columbia.edu>
Subject: ASCII characters
Message-Id: <PEPMNT.891101.150401.C0@CFAAMP.HARVARD.EDU>
In traditional IBM Kermits, the A-to-E table consisted of two
identical copies of the 7-bit table, thereby avoiding the question
of parity. I find, in fact, that the logic that strips out CRLF
line delimiters works with the EBCDIC versions of the latest and next-
latest characters, presumably to avoid the parity-bit ambiguity.
Does it make any sense at all to treat x'8D' as CR and x'8A' as LF?
Remember that the parity can't be ignored if the checksum is to
come out right.
John
From fdc Sat Nov 4 17:16:47 1989
Return-Path: <fdc>
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA13004; Sat, 4 Nov 89 17:16:47 EST
Date: Sat, 4 Nov 89 17:16:46 EST
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
To: "John F. Chandler" <PEPMNT@cfaamp.harvard.edu>
Cc: IBM-Kermit <IBM-Kermit@watsun.cc.columbia.edu>
Subject: Re: ASCII characters
In-Reply-To: Your message of Wed, 1989 Nov 1 15:04 EST
Message-Id: <CMM.0.88.626221006.fdc@watsun.cc.columbia.edu>
Regarding treatment of CR and LF in ASCII-to-EBCDIC translation...
Are you talking about the A-to-E translation that happens when a packet
arrives on a linemode connection (PC sends ASCII, 37x5 translates to
EBCDIC, Kermit-370 translates back to ASCII to check the checksum)?
Or are you talking about the A-to-E translation that happens when Kermit-370
is about to send a packet (it has just constructed the packet in ASCII, and
then translates it into EBCDIC so that the 37x5 can translate it back to
ASCII)?
Presumably, it is the former case, because that's the only one in which you
strip out CRLFs. There is no problem in the full-screen environment, because
the front end is in transparent or graphics mode, so there is no A/E
translation in the communication path (only between Kermit-370's packets and
Kermit-370's disk, right?).
If IBM mainframe Kermit always runs in the 7-bit environment (as through a
3705), then the high order bit will always have been stripped before the
"presentation layer" (or for that matter, even the "datalink layer") has a
chance to look at the characters, right? So you'll never get x'8D' or x'8A'.
If you do find x'8D' or x'8A' in an incoming text-mode packet, it is either
because you actually have an 8-bit-wide connection (maybe some kind of
X.25/SNA/VTAM thing does this???), or else it is the result of Kermit's
8th-bit prefixing. In either case, these bytes must have been sent
deliberately.
In text mode, the only way these bytes can occur in a packet is if an 8-bit
character set, such as ISO Latin 1, is being used as the transfer character
set. In any standard 8-bit character set ("standard" meaning ISO-compliant as
to C0/G0/C1/G1 layout), bytes in the range x'80' thru x'9F' are C1 control
characters, which have different meanings from their counterparts in the x'00'
thru x'1F' range, depending on which control character set is invoked to C1.
Normally it would be the ISO 6429 set (a variation of which is used by DEC
terminals with the Latin-1 alphabet), in which x'8A' is HTJ (Horizontal
Tabbing with Justification) and x'8D' is RI (Reverse Index).
So in short, it probably does not make sense to treat these characters as
CR and LF.
- Frank
From RAF@cu.nih.gov Sun Nov 5 12:00:07 1989
Return-Path: <RAF@cu.nih.gov>
Received: from alw.nih.gov by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA20382; Sun, 5 Nov 89 12:00:07 EST
Received: from cu.nih.gov by alw.nih.gov (5.61/alw-1.1m)
id AA10706; Sun, 5 Nov 89 11:58:54 -0500
Message-Id: <8911051658.AA10706@alw.nih.gov>
To: fdc@watsun.cc.columbia.edu, PEPMNT@cfaamp.harvard.edu
Cc: IBM-Kermit@watsun.cc.columbia.edu
From: "Roger Fajman" <RAF@cu.nih.gov>
Date: Sun, 05 Nov 89 12:00:27 EST
Subject: Re: ASCII characters
> If you do find x'8D' or x'8A' in an incoming text-mode packet, it is either
> because you actually have an 8-bit-wide connection (maybe some kind of
> X.25/SNA/VTAM thing does this???), or else it is the result of Kermit's
> 8th-bit prefixing. In either case, these bytes must have been sent
> deliberately.
>
> In text mode, the only way these bytes can occur in a packet is if an 8-bit
> character set, such as ISO Latin 1, is being used as the transfer character
> set. In any standard 8-bit character set ("standard" meaning ISO-compliant as
> to C0/G0/C1/G1 layout), bytes in the range x'80' thru x'9F' are C1 control
> characters, which have different meanings from their counterparts in the x'00'
> thru x'1F' range, depending on which control character set is invoked to C1.
> Normally it would be the ISO 6429 set (a variation of which is used by DEC
> terminals with the Latin-1 alphabet), in which x'8A' is HTJ (Horizontal
> Tabbing with Justification) and x'8D' is RI (Reverse Index).
>
> So in short, it probably does not make sense to treat these characters as
> CR and LF.
>
> - Frank
You are right if a true 8-bit character set is involved. However, in
the 7 bit character set environment it's a nice simple rule to say that
the 8th bit is ignored. This should apply to CR and LF too. On the
PC, some programs (WordStar comes to mind) use the 8th bit for their
own purposes.
Roger
From @cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET Mon Nov 6 11:57:46 1989
Return-Path: <@cuvmb.cc.columbia.edu:PEPMNT@CFAAMP.BITNET>
Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by watsun.cc.columbia.edu (4.0/SMI-4.0)
id AA00396; Mon, 6 Nov 89 11:57:46 EST
Received: from CUVMB.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2.1) with BSMTP id 0770; Mon, 06 Nov 89 11:57:29 EST
Received: from CFAAMP.BITNET by CUVMB.COLUMBIA.EDU (Mailer R2.03B) with BSMTP
id 6114; Mon, 06 Nov 89 11:57:28 EST
Received: from CFAAMP.BITNET (PEPMNT) by CFAAMP.BITNET (Mailer R2.03B) with
BSMTP id 8820; Mon, 06 Nov 89 11:53:32 EST
Date: Mon, 1989 Nov 6 11:38 EST
From: "John F. Chandler" <PEPMNT%CFAAMP.BITNET@cuvmb.cc.columbia.edu>
To: IBM-Kermit <IBM-Kermit@watsun.cc.columbia.edu>
Subject: Re: ASCII characters
In-Reply-To: fdc@watsun.cc.columbia.edu message
<CMM.0.88.626221006.fdc@watsun.cc.columbia.edu> of Sat, 4 Nov 89 17:16:46 EST
Message-Id: <PEPMNT.891106.113857.C0@CFAAMP.BITNET>
> Are you talking about the A-to-E translation that happens when a packet
> arrives on a linemode connection (PC sends ASCII, 37x5 translates to
> EBCDIC, Kermit-370 translates back to ASCII to check the checksum)?
No, it's the next A-to-E translation of the received data bytes that
I'm thinking about. At present, I know of no 8-bit-wide channels into
an IBM mainframe that Kermit can use, so I'm not particularly worried
about unfiltered parity bits -- especially since the checksum is supposed
to protect against that sort of misinterpretation. What concerns me is
the micro Kermit that might intentionally transmit bytes with the 8th
bit set, presumably through 8th-bit quoting. At present, the user is
protected from such folly (but at a cost in program logic). Is this
protection a good idea?
John