Columbia Kermit

home *** CD-ROM | disk | FTP | other *** search

/ Columbia Kermit / kermit.zip / e / 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#D&#B&#J&#E&#W&#I&#K&#T&#A&#D&#C&#H&#L&#S&#V &#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"D&#B&#J&#E&#W&#I&#K&#T&#A&#D&#C&#H&#L&#S&#V &#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