Columbia Kermit/kermit.zip/protocol/retrieve.txt

Text File | 2020-01-01 | 9KB | 180 lines

18-Aug-96  0:38:17-GMT,1885;000000000001
Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id UAA17051; Sat, 17 Aug 1996 20:38:14 -0400 (EDT)
Date: Sat, 17 Aug 1996 20:38:14 -0400 (EDT)
From: Frank da Cruz <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: New Kermit protocol thing

As you know, C-Kermit has a MOVE command, which is just like SEND except
it deletes the source file(s) if and only if they are sent successfully.
This turns out to be very useful to a lot of our more serious users --
companies that use Kermit for real transaction processing, etc, because it's
atomic.

MOVE is trivial to implement -- it calls the SEND parsing routine and then
just sets a flag; the routine that closes the input file checks to see if the
flag is set, and if so, and the file was sent successfully, it deletes the
file.  Takes about 5 minutes to implement.

Now it seems some of these same users need the same thing in the opposite
direction: they want the client to tell the server to send files and then
delete them iff they were sent ok.  This requires addition of a new packet
type -- I chose "H" -- and a new top-level command.  There's no good word for
this, so I chose RETRIEVE.

On the client side, RETRIEVE calls the same parsing routine as GET and REGET,
but it invokes the protocol module in such a way as to let it know that it
should send an H packet, rather than an R or J packet (all three of these have
the same format).

On the server side, when the server gets an H packet, it does exactly what it
does when it gets an R packet, except it sets the very same flag that is used
when the MOVE command is given -- "I should delete each file after I send, iff
it was sent successfully".  And obviously, it must remember to RESET this flag
after each transaction.

That's about it...

- Frank

20-Aug-96  0:05:34-GMT,2052;000000000011
Received: from CUVMB.CC.COLUMBIA.EDU (cuvmb.cc.columbia.edu [128.59.40.129]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with SMTP id UAA17973; Mon, 19 Aug 1996 20:05:33 -0400 (EDT)
Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP V2R1)
   with BSMTP id 5221; Mon, 19 Aug 96 20:05:09 EDT
Date: Mon, 19 Aug 1996   20:04 EDT
From: "John F. Chandler"   <[e-mail]>
To: Frank da Cruz   <[e-mail]>
cc: Joe Doupnik   <[e-mail]>
Subject: Re: New Kermit protocol thing
In-reply-to: [e-mail] message
   <[e-mail]> of Sat, 17 Aug 96 20:40:30
   EDT
Message-id: <[e-mail]>

Frank,

> As you know, C-Kermit has a MOVE command, ...
> This turns out to be very useful to a lot of our more serious users --
> companies that use Kermit for real transaction processing, etc, because it's
> atomic.

While I can see how this is useful, I also cringe at the thought of using
it -- deciding what is a successful transfer is not a purely objective
thing.  I guess the IBM mainframe world has more avenues to misleadingly
"successful" transfers, so I'm especially sentitive to this.  Things like
the LONGLINE setting, which permits the user to choose whether to fold
lines that are too long for the available LRECL, or to (gasp!) truncate,
as well as to halt.  In fact, truncate is the default!  Then, too, there
is the RECFM issue, not to mention the possibility of inappropriate
character translations for text files.  I really wonder if it would ever
be a good idea to implement MOVE in K370.

>  This requires addition of a new packet
> type -- I chose "H" -- and a new top-level command.  There's no good word for
> this, so I chose RETRIEVE.

How about SEIZE or STEAL, or even CONFISCATE?  Surely, you can do better
than to use a word that is more-or-less synonymous with GET.  Of course,
if TAKE weren't already in use, it would be ideal...

                                                 John

20-Aug-96  0:12:15-GMT,800;000000000011
Received: (from jrd@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id UAA18513; Mon, 19 Aug 1996 20:12:14 -0400 (EDT)
Date: Mon, 19 Aug 96 20:12:13 EDT
From: "Joe R. Doupnik" <[e-mail]>
To: "John F. Chandler" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: New Kermit protocol thing
In-Reply-To: Your message of Mon, 19 Aug 1996 20:04 EDT
Message-ID: <[e-mail]>

John,
    Confiscate appeals to me, but we expect too many typos. So I
guess it's down to SEIZE, being politically correct. Goodness, what
would happen to our command syntax if the lawyers got involved?
    My reaction was similar to yours, but I added Move and Retrieve
to MSK 3.15. The latter is disabled by default.
    Joe D.

20-Aug-96  0:13:32-GMT,459;000000000011
Received: (from jrd@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id UAA18636; Mon, 19 Aug 1996 20:13:31 -0400 (EDT)
Date: Mon, 19 Aug 96 20:13:31 EDT
From: "Joe R. Doupnik" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: MSK 3.15 again
Message-ID: <[e-mail]>

Frank,
    I fixed INPUT/MINPUT to work again. The msk315.exe file is on
watsun as of 1800 MDT.
    Joe D.

20-Aug-96  0:14:37-GMT,2326;000000000001
Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id UAA18721; Mon, 19 Aug 1996 20:14:36 -0400 (EDT)
Date: Mon, 19 Aug 96 20:14:36 EDT
From: Frank da Cruz <[e-mail]>
To: "John F. Chandler" <[e-mail]>
Cc: Joe Doupnik <[e-mail]>
Subject: Re: New Kermit protocol thing
In-Reply-To: Your message of Mon, 19 Aug 1996 20:04 EDT
Message-ID: <[e-mail]>

> While I can see how this is useful, I also cringe at the thought of using
> it -- deciding what is a successful transfer is not a purely objective
> thing.  I guess the IBM mainframe world has more avenues to misleadingly
> "successful" transfers, so I'm especially sentitive to this.  Things like
> the LONGLINE setting, which permits the user to choose whether to fold
> lines that are too long for the available LRECL, or to (gasp!) truncate,
> as well as to halt.  In fact, truncate is the default!  Then, too, there
> is the RECFM issue, not to mention the possibility of inappropriate
> character translations for text files.  I really wonder if it would ever
> be a good idea to implement MOVE in K370.
>
Well, nobody has ever asked for it...  But they do ask for it in the other
Kermits.  It's entirely up to you whether to add it -- but obviously it's got
to be documented in such a way that they know what they are getting into.
And the server end of it should be disabled by default, so they have to ENABLE
it first (but then, DELETE was always enabled, right?)...

> How about SEIZE or STEAL, or even CONFISCATE?  Surely, you can do better
> than to use a word that is more-or-less synonymous with GET.  Of course,
> if TAKE weren't already in use, it would be ideal...
>
I know -- I thought about lots of different words, but there is no word that
means "send me your copy of the file and then delete your copy of it after
sending it to me".  So in the absence of a compelling argument against (or a
clearly superior alternative to) RETRIEVE, we might as well stick with it.

As we add more and more commands to Kermit, we just simply run out of good
words for them.  For that matter, MOVE -- although it gets the idea across --
still lacks directionality.  It could mean anything.  For that matter so
could SEND (who sends it to whom?).

- Frank

20-Aug-96  0:17:13-GMT,910;000000000001
Received: (from fdc@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id UAA18999; Mon, 19 Aug 1996 20:17:13 -0400 (EDT)
Date: Mon, 19 Aug 96 20:17:13 EDT
From: Frank da Cruz <[e-mail]>
To: "Joe R. Doupnik" <[e-mail]>
Subject: Re: New Kermit protocol thing
In-Reply-To: Your message of Mon, 19 Aug 96 20:12:13 EDT
Cc: John Chandler <[e-mail]>
Message-ID: <[e-mail]>

> Confiscate appeals to me, but we expect too many typos. So I
> guess it's down to SEIZE, being politically correct. Goodness, what
> would happen to our command syntax if the lawyers got involved?
>
Words like STEAL, SEIZE, and CONFISCATE all have emotional overtones
and connotations we should avoid.  Just like "abort" -- whatever you
think about abortion, the word "abort" simply makes some people cry.
I know, I've seen it happen.

- Frank