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 Message-Id: <199608180038.UAA17051@watsun.cc.columbia.edu> To: jrd@cc.usu.edu cc: peprbv@cuvmb.cc.columbia.edu 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" To: Frank da Cruz cc: Joe Doupnik Subject: Re: New Kermit protocol thing In-reply-to: fdc@watsun.cc.columbia.edu message of Sat, 17 Aug 96 20:40:30 EDT Message-id: 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" To: "John F. Chandler" Cc: jrd@watsun.cc.columbia.edu, fdc@watsun.cc.columbia.edu Subject: Re: New Kermit protocol thing In-Reply-To: Your message of Mon, 19 Aug 1996 20:04 EDT Message-ID: 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" To: fdc@watsun.cc.columbia.edu Cc: jrd@watsun.cc.columbia.edu Subject: MSK 3.15 again Message-ID: 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 To: "John F. Chandler" Cc: Joe Doupnik Subject: Re: New Kermit protocol thing In-Reply-To: Your message of Mon, 19 Aug 1996 20:04 EDT Message-ID: > 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 To: "Joe R. Doupnik" Subject: Re: New Kermit protocol thing In-Reply-To: Your message of Mon, 19 Aug 96 20:12:13 EDT Cc: John Chandler Message-ID: > 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