SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (03/06/86)
Info-Kermit Digest Wed, 5 Mar 1986 Volume 4 : Number 15 Departments: ANNOUNCEMENTS - Kermit for Gould/SEL 32/8750 with MPX 3.2A New os9 Kermit (68000 and 6809) C-KERMIT - Kermit for Ultrix-11? Pixel Support for C-Kermit C-Kermit and TACs MS-DOS KERMIT - Tektronix Emulator in QK-Kermit Re: Tektronix Emulator in QK-Kermit PCjr w/Tecmar memory vs 2.28/jrd Kermit-MS MISCELLANY - Minor Problem with VMS Kermit (BLISS/MACRO) V3.1.066: ---------------------------------------------------------------------- Date: Wed 5 Mar 86 09:50:14-EST From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU> Subject: Kermit for Gould/SEL 32/8750 with MPX 3.2A Announcing SEL-Kermit Version 1.0 for the Gould/SEL Concept 32/8750 with MPX 3.2A, written in Fortran-77+ by Marlon Gordon and Dave Durand, Singer/Link Houston. According to the documentation, it works in both remote and local mode, and can run as a Kermit server. The file arrived on some crazy kind of tape, which we read the best way we could. It all seems to be intact. The files are in KER:GM1*.* on CU20B, available as usual via anonymous FTP on the Internet, and also via KERMSRV at CUVMA on BITNET. ------------------------------ Date: Fri 28 Feb 86 18:04:22-PST From: Bob Larson <BLARSON%ECLD@usc-ecl.arpa> Subject: New os9 Kermit (68000 and 6809) Since someone finally confirmed that I didn't break the 6809 support when I added 68000 support to kermit, the new version should be made standard. (Thanks Mark Sunderlin, scsnet!sunder.) The new version is on usc-eclb.arpa as ps:<blarson.os9>os9*.* . The files that have changed are second generation, so os9*.*.2 will get you only the new files. The only real changes for 6809 users are in the .hlp and .bwr files and some code to make connect mode on a bit-banger port easier to implement. (A special device driver is needed, any volunteers?) Bob Larson <Blarson@Usc-Ecl.Arpa> Uucp: ihnp4!sdcrdcf!oberon!blarson [Ed. - Thanks! The new files are in KER:OS9*.* on CU20B, and in OS* * on KERMSRV at CUVMA.] ------------------------------ Date: Fri, 28 Feb 86 10:44 EST From: Mark Katsouros <KATSOURO@UMDD.BITNET> Subject: Kermit for Ultrix-11? I've had no luck in getting Kermit working on our Ultrix-11 system. Tried making several different versions, and fooled around with mixing up the flags, but was unsuccessful in coming up with anything even close. If you happen to hear of a way to get what I have (ck*.*) made for Ultrix-11, please let me know. Also, I'd really appreciate it if you would let me know if you hear of anyone else on the net using Ultrix-11. (Perhaps they have some sort of Kermit protocol.) Thank you for your time, Mark Katsouros University of Maryland, College Park [Ed. - Does anybody have any hints about making C-Kermit work in Ultrix-11? What is Ultrix-11, anyway? A 2.9 derivative? A version 7 derivative? Venix in disguise?] ------------------------------ Date: Fri 28 Feb 86 11:15:39-EST From: Chris Lent <OC.PEDHEM@CU20B.COLUMBIA.EDU> Subject: Pixel Support for C-Kermit Just put C-kermit on a Pixel 1000 which is a 68000 based Berkley Unix box. Make bsd almost works but it seems the getppid() function which is used to determine the parent process id of the shell running C-kermit is missing from the run-time library. So I made a change to ckufio.c adding an #ifdef PIXEL and substituted a kill(0,9) for kill(getppid(),1). The unix diffs of the current version of ckufio.c and ckuker.mak follow: $ diff ckufio.c ckufiopix.c 198a199,201 > #ifdef PIXEL > return(kill(0,9)); > #else 199a203 > #endif $ diff ckuker.mak ckukerpix.mak 174a175,179 > #Pixel 1000 (Almost) Berkeley Unix 4.1 or 4.2 (and presumably also 4.3) > #Pixel 1000 V2.1 (Has no getppid() function) > pixel: > make wermit "CFLAGS= -DBSD4 -DDEBUG -DTLOG -DPIXEL" > ------------------------------ Date: 2 Mar 1986 12:26:45 EST Subject: C-Kermit and TACs From: Glen Foster <GFoster@USC-ISI.ARPA> Has anybody set up C-Kermit on a VAX running Unix (4.2bsd in this case) to get it to perform the proper Telnet protocol negotiations with a TAC so the TAC doesn't interfere with a file transfer? I know what Telnet sequence to send, I'm just not familiar enough with C-Kermit and Unix to know how to do it. I'm sure it could be done relatively easy with a Kermit script file, perhaps someone has done something a little fancier with a shell script the "knows" whether the remote is coming through a TAC or not and sets binary mode if it is. The Tops-20 Kermit at ISI does this, surely C-Kermit and Unix must have this capability! Thanks in advance. Glen Foster - GFOSTER@USC-ISI.ARPA [Ed. - There is no code in C-Kermit to put TACs in binary mode, though there is no reason why it couldn't be added. For now, just use TAC commands like @b i s and @b o s.] ------------------------------ Date: 26 Feb 86 06:50:00 PST From: ALEX WOO <wu@ames-aero> Subject: Tektronix Emulator in QK-Kermit Has anyone got the tek4014 emulator in qk-kermit to work? I don't have a Zenith but a Hercules card so I tried to recompile the relevant modules. Here is a summary of my failed efforts. 1. It was necessary to overlay the source. I chose to overlay the local and definewords procedures since they are not critical for terminal emulation. 2. There was a definite error in the DefineWorld(1,0,779,1023,0) call. I changed it to either DefineWorld(1,0,0,779,1023) or DefineWorld(1,0,0,3120,4095) depending on which tektronix driver I'm using on the mainframe. After fixing these errors, I find that when the terminal goes into tektronix mode the screen blanks out. It recovers correctly but nothing is ever painted to the screen. It almosts looks as if the vectors are drawn on a RAM screen (but I set that boolean to be false). Any suggestions? Alex. P.S. I was surprised that turbo-pascal could drive the serial ports at 19,200 baud. ------------------------------ Date: Tue, 4 Mar 86 11:03 EST From: VIC@QUCDN Subject: Re: Tektronix Emulator in QK-Kermit Since we don't have the Hercules board, I can only guess at what your problems might be. Here are some possibilities to consider: 1. QK-KERMIT emulates a TEK4010 which is slightly different from a TEK4014 terminals. You maybe sending TEK4014 sequences that are not interpetted the same on a TEK4010. 2. Make sure that you are using the Hercules routines from the Turbo tool box. 3. Do not change the DefineWorld definition. Although it appears to be backwards it is fixed up with some other code. ( Two wrongs make it right?) 4. Try leaving the RamScreen definition unchanged. We changed it to false to reduce the amount of memory used. I am not sure how this affects the Hercules routines so you may leave it alone. 5. Are you running at 19.2 baud? I have never tested it out at that rate. May I suggest you run your test at a lower baud rate to insure that your problem is not a baud rate problem. ------------------------------ FROM: EGRJN@TUCC Date: Tue, 04 Mar 86 08:52 EST Subject: PCjr w/Tecmar memory vs 2.28/jrd Kermit-MS I got version 2.28 of the IBM PC Kermit from KERMSRV and I discovered a problem that few others may have found, and which I hope you can report to the right folks. I have a PCjr with TECMAR memory which brings my system memory to 640K. When I run KERMIT 2.28, the program bombs with a message indicating "insufficient memory". If I disable the TECMAR memory, the program runs fine. Version 2.27 runs fine in either case. Something was done to 2.28 which creates this incompat- ibility with my system. Disabling the extra memory is inconvenient because it prevents me from using RAM disks or programs like Sidekick. Perhaps if they knew of it, the KERMIT wizards could avoid this improvement in future versions. [Ed. - Has anyone else experienced this problem? If so, did it go away when you tried jrd/2 or later? Joe Doupnik found some problems with the dynamic memory allocation and fixed them.] ------------------------------ Date: Fri 28 Feb 86 11:15:39-EST From: Chris Lent <OC.PEDHEM@CU20B.COLUMBIA.EDU> Subject: Minor Problem with VMS Kermit (BLISS/MACRO) V3.1.066: If you didn't recompile KERMIT under VAX/VMS 4.X from the MACRO (or BLISS I assume) a version compiled under VAX/VMS 3.2 to 3.7 may stall in what looks like a CTRL/S-CTRL/S (XOFF-XOFF) standoff when using DEC's VT220 terminals. I assume the terminal sends a CTRL/S between the time you type the escape character and the time you type the C to close a CONNECT session. It might also be that PASSALL mode (rather than VMS 4.X PASTHRU) mode is used and the terminal's incessant CTRL-S/CTRL-Q sequences eventually lock up KERMIT. Recompiling under VAX/VMS 4.X seems to solve thsi problem. Note that this hangup problem did NOT occur on VT100's or IBM-PC's using KERMIT to be terminals. To determine what version your kermit was linked under do a $ ANALYZE/IMAGE SYS$SYSTEM:KERMIT.EXE and look at the linker identification under the heading Image Identification Information. If the string starts with a 3 you probably should rebuild your KERMIT.EXE. Chris Lent The Cooper Union for the Advancement of Science and Art. ihnp4!allegra!phri!cooper!chris or care of: OC.PEDHEM@CU20B.COLUMBIA.EDU ------------------------------ End of Info-Kermit Digest ************************* -------