Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL ("Info-IBMPC Digest") (09/23/96)
Info-IBMPC Digest Mon, 23 Sep 96 Volume 90 : Issue 151
Today's Editor:
Gregory Hicks - Rota Spain <GHICKS@WSMR-Simtel20.Army.Mil>
Today's Topics:
Defective Hard Disk
File transfer from Mainframe to PC via Modem (2 msgs)
386 & 486 Towers (2 msgs)
IBMPC Digest SIMTEL Archives
Today's Queries:
IEEE-488 bus card for IBM PC's
Re: JTFAX 9600 board in a 386DX25 CompuAdd
Italic font for Proprinter
New Uploads:
4DOS v 3.02 uploaded to SIMTEL20
Borland's patch fixes for Turbo C++ 1.0
Improved conferencing/mail door for RBBS uploaded to SIMTEL20
UNzip for VMS
UUPC version 1.08a now available
Send Replies or notes for publication to:
<INFO-IBMPC@WSMR-SIMTEL20.ARMY.MIL>
Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to:
<INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
Archives of past issues of the Info-IBMPC Digest are available by FTP
only from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.
----------------------------------------------------------------------
Date: Sun, 16 Sep 90 19:58:43 GMT
From: mathrich@mthvax.cs.miami.edu (Rich Winkel)
Subject: Defective Hard Disk
In digest Info-IBMPC@WSMR-SIMTEL20.ARMY.mil writes:
> I had that same problem a few weeks ago when my Hard Drive started
>to suddenly give "General Read Failure" errors on several of my
>programs. All that was required was a low-level format, and everything
>was back to normal. With no bad sectors reported.
> Apparently, sometimes DOS "misplaces" a track by a few micrometers.
>Subsequent reads and writes serves to propigate the problem until DOS
>finally deems that the track is bad. A low-level format (And sometimes
>a simple format) will re-organize the tracks.
I always thought it was a progressive weakening of the magnetic fields
on the disk. I've had to LL format my hard disk twice since I bought
it in 1985, each time after having run it in a hot environment (in the
summer) for several days. I've seen the same thing happen at work in
poorly air-conditioned offices in the summer. Furthermore, by lowering
the temperature before doing a backup (prior to reformatting) I've
managed to avoid losing any data, and if I run a disk verifier on the
disk it confirms that the number of errors decreases greatly with lower
temperatures. Magnets don't like high temperatures, it leads to a
progessive degradation of the magnetic field (i.e. the field strength
decreases with increasing temperature, and the strength at a given
(lower) temperature decreases after chronic exposure to high
temperatures)
Also, the fact that the errors always seem to be on a particular side
of a particular platter in my HD unit (presumably an area where the
oxide coating is thin) would seem to rule out seek errors, since all
heads seek together. Doing a LL format is the only way to refresh
certain information in the sector header, such as the sector ID, which
is left untouched during normal disk write operations. Afterwards the
disk is good for another few years. Of course, I could be wrong, but
this seems the most likely explanation to me.
Rich
------------------------------
Date: Fri, 14 Sep 90 15:42:39 EST
From: <POSTMASTER%TREARN.BITNET@uga.cc.uga.edu>
Subject: File transfer from IBM mainfr. to home over teleph.
A couple of people have mentioned YTERM (Yale Terminal emulator) as a
solution to this problem. I have used this product for years over the
telephone, though a 7171 converter. Downloading and uploading have
worked fine.
There is a YTERM-L list. To subscribe (from a BITNET node), type
TELL LISTSERV AT YALEVM SUB YTERM-L your name
You might also want to sign up for TPRINT-L (YTerms local print
feature) and PCTRANS-L (data transfer feature), with similar commands.
You can also get a list of YTERM files available from the server by
typing
TELL LISTSERV AT YALEVM GET YTERM-L FILELIST
There also are PCTRANS-L FILELIST and TPRINT-L FILELIST Look at the
list(s), identify files you are interested in, (probably you will want
to see YTERM GENLINFO), and use the above command format to GET them.
Mark Keintz PHONE: 215/898-6713
Computer Group Mgr BITNET: MKEINTZ@PENNSAS or KEINTZ@PENNDRLS
Population Studies Ctr. INTERNET: MKEINTZ@PENNSAS.UPENN.EDU
Univ of Penn/6298 KEINTZ@PENNDRLS.UPENN.EDU
3718 Locust Walk
Philadelphia, PA 19104-6290
------------------------------
Date: Fri, 14 Sep 90 16:09:25 EDT
From: Tom Reid x4505 <reid%CTC.CONTEL.COM@uga.cc.uga.edu>
Subject: File transfer from IBM mainfr. to home over teleph.
>
> I'm looking for good suggestions for making it possible for me to
>transfer files from our IBM 43xx mainframe over telephone to my 386x
>home pc.
> ... have been done with a kermit program but without succes. (Kermit
>does not recognize the protocol convertor as an ascii device (no 7171))
I am surprised because kermit was designed to transfer data using only
pure ascii (3 bytes split over 4 bytes with top two bits masked). Get
the OLDEST kermit you can find. Maybe the new ones have forgotten
their heritage.
I have used Procomm and kermit many times to go over LANs (which don't
like non-ascii either) but it has been several years since the host was
an IBM mainframe.
Tom.
Thomas F. Reid, Ph. D. (703)818-4505 (work)
Contel Technology Center (703)742-8720 (home)
15000 Conference Center Drive Net: reid@ctc.contel.com
P.O. Box 10814
Chantilly, Va. 22021-3808
------------------------------
Date: Sun, 16 Sep 90 11:01:45 CDT
From: Tony Phillips <S102066@UMRVMA.UMR.EDU>
Subject: 386 & 486 Towers
On Sun, 16 Sep 90 01:30:06 +0200 <55srwlgs@sacemnet.af.mil> Frank Starr
asked about 386 & 486 Towers...
>... Just what is a "tower", and what advantages does it have to
>standard PC's. From the ads I've seen, it looks to be nothing more than
>a CPU made to stand on end, rather than sitting flat like standard PC
>CPUs.
Basically, you're correct in saying that it's nothing more than a CPU
made to stand on end. But, that's where all of its intrensic
advantages come in. A tower box usually is made to hold several more
devices than a flat (or "Baby") cpu case is. For example, our RISC
systems in our UNIX labs have 8 device bays, as compared to a standard
AT's 5. Consequently, a tower usually has a much larger power supply
to run those extra devices (250-300 watts.) The physical architectures
of these computers also lend themselves to better ventalation in most
cases. And the best advantage of them all: you can put them on the
floor where they are out of the way.
Tony Phillips
President- A.C.M. Rolla Chapter
Student of Computer Science
University of Missouri, Rolla
Reply Addresses
BITNET: S102066@UMRVMA
INTERNET: S102066@UMRVMA.UMR.EDU
-or- TONYP@CS.UMR.EDU
------------------------------
Date: 16 Sep 90 14:32:00 CDT
From: "55SRWLGS" <55srwlgs@sacemnet.af.mil>
Subject: 386 & 486 Towers
Thanx to all those who elaborated on the subject of Towers
CPU's. I don't expect I'll personally need to buy one, but if I have to
advise an office, I'll know when they need one, and try to help them
avoid the temptation to buy just because it's something new.
Frank Starr
55srwlgs@sacemnet.af.mil
------------------------------
Date: Mon, 3 Sep 90 16:10:07 MDT
From: Gregory Hicks <GHICKS@WSMR-SIMTEL20.ARMY.MIL>
Subject: IBMPC Digest SIMTEL Archives
<dix@clinet.fi> asked where the Digests were archived. I tried to send
him a reply, but my mailer couldn't connect to his host. Since the
reply might be of interest to the readership as a whole, ...
Old Digests are archived in directory PD2:<archives.ibmpc> as
YYMM.x-TXT-Z where YY ==> Year, MM ==> month, and x ==> 1 or 2
depending on the number of issues sent out that month.
Current year issues are YYMM.x-TXT. Current issues are in
IBMPC-ARCHIV.TXT. Files are generally 50-75 TOPS-20 pages in length.
(56 pages = 112K 8 bit bytes)) Files are COMPRESSed as in Un*x.
Hope this helps.
Regards,
Gregory Hicks
------------------------------
Date: Fri, 14 Sep 90 18:45:40 MEZ
From: Enrico Giakas <GKS93660%DOSUNI1@pucc.PRINCETON.EDU>
Subject: IEEE-488 bus card for IBM PC's
Who knows further distributers or better producers of 'IEEE-bus cards'
(IEEE Standard 488.1-1987) for a slot of IBM XT personal computer. One
distributer in Germany is: Meilhaus; Fischerstr. 2; D-8039 Puchheim. A
producer of such a adapter card is Keithley. It would be helpful, if
the hardware is supported by a software that allows to use HPGL.
With the hope of a lot replies
E. G.
------------------------------
Date: Mon, 17 Sep 90 00:36:53 -0400
From: aa381@cleveland.Freenet.Edu (Jeffry Gerber)
Subject: Re: JTFAX 9600 board in a 386DX25 CompuAdd
This thing just wont' work. Would anyone kindly have an answer? It
often gives interference, resulting a a screen message:
NON-DOS DISK, or
CANNOT RECOGNIZE DISK DRIVE A: OR C: OR B:
I have an Award BIOS, Phoenix is about to be swapped in. JTFAX's
manual gives lists of all available memory addresses, settable by DIP
switches on the fax board. None works.
Often the machine will boot, but then be unable to recognize, or to
find the fax board... or sometimes (depending on DIP settings for
memory location) just won't load the JTFAX software, Version 2.00. I'm
using MSDOS 4.01
I've read ALL the docs for the computer and fax hardware and software,
and tried MANIFEST. MANIFEST shows the memory area E000-EFFF is
vacant, non-accessed, but the DIP switches can't reach that area; only
C000 through DFFF, I believe.
Techie help would be much appreciated.
Thank you each and all in advance!
Jeff Gerber, lawyer/sysop aa381@cleveland.freenet.edu
5010 Mayfield Rd.
Cleveland OH 44124 USA
voice 216-291-1262
fax 291-1263
------------------------------
Date: Sun, 16 Sep 90 03:22:00 PDT
From: Franks@SSC.SSCNET.UCLA.EDU
Subject: Italic font for Proprinter
Is there any reasonable way to get a IBM proprinter to print in
italics? I.e., is there a font set available with italics for
downloading to the proprinter (model x24)?
Thanks,
Mike Franks Internet: franks@ssc.sscnet.ucla.edu
Social Sciences Computing
UCLA
------------------------------
Date: Thu, 13 Sep 90 23:17:27 PDT
From: sidney@saturn.ucsc.edu (Sidney Markowitz )
Subject: 4DOS v 3.02 uploaded to SIMTEL20
I have uploaded to SIMTEL20:
pd1:<msdos.sysutl>
4DOS302.ZIP 4DOS v 3.02, enhanced COMMAND.COM replacement
4DOS, a shareware COMMAND.COM replacement, includes aliases, history
list, command line editing, extended commands and batch language, and
more, while swapping to disk, EMS or XMS memory as available to reduce
low memory requirements to less than COMMAND.COM's.
This file replaces PD1:<MSDOS.SYSUTL>4DOS301A.ZIP
-- sidney markowitz <sidney@saturn.ucsc.edu>
------------------------------
Date: Sat, 8 Sep 90 18:38:46 PDT
From: sidney@saturn.ucsc.edu (Sidney Markowitz )
Subject: Borland's patch fixes for Turbo C++ 1.0
I have uploaded to SIMTEL20:
pd1:<msdos.turbo-c>
TCPPT1.ZIP First bug fixes for Turbo C++, from Borland
Borland's patches and replacement files for Turbo C++ 1.0, as posted by
Borland in their tech support forum on Compuserve. The announcement on
Compuserve dated 9/6/90 referred to these as "the first set of
patches".
Sidney Markowitz <sidney@saturn.ucsc.edu>
------------------------------
Date: Fri, 14 Sep 90 22:09:29 EDT
From: Scott Barnes <sba8_ltd@uhura.cc.rochester.edu>
Subject: Improved conferencing/mail door for RBBS uploaded to SIMTEL20
I have uploaded these files to SIMTEL20:
pd2:<msdos2.rbbs-pc>
GC101-1.ZIP Conference/mail door for RBBS systems (1 of 3)
GC101-2.ZIP Conference/mail door for RBBS systems (2 of 3)
GC101-3.ZIP Conference/mail door for RBBS systems (3 of 3)
GC-DESC.ZIP Describes GC101 conference/mail door for RBBS
Long description:
GRAND CENTRAL MESSAGE SYSTEM 1.01 - GC is a high-performance door which
replaces the native conference and mail functions of the RBBS program.
It features a full-screen user interface, a topic-based message system,
a powerful editor, and more.
------------------------------
Date: Sat, 15 Sep 1990 09:38 MDT
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: UNzip for VMS
UNzip for VMS has been available from SIMTEL20 for some time. It's in
the PD3:<MISC.VAXVMS> directory.
Directory for VMSUNZIP.ARC
Name Length Stowage SF Size now Date Time CRC
============ ======== ======== ==== ======== ========= ====== ====
CRC32.C 8672 Crunched 52% 4163 5 Feb 90 4;53a 249D
CRC32.H 160 Crunched 15% 136 5 Feb 90 4;54a 9DB9
README.1ST 1671 Crunched 26% 1242 7 Feb 90 2;41p 58CB
UNZIP.C 35656 Crunched 55% 16250 5 Feb 90 4;53a 4A0A
UNZIP.DOC 1405 Crunched 26% 1044 5 Feb 90 5;07a 864B
UNZIP.EXE 15422 Crunched 25% 11598 5 Feb 90 4;56a 8117
VMSUNZIP.EXE 81182 Squeezed 21% 64922 5 Feb 90 5;38a 6094
==== ======== ==== ========
Total 7 144168 32% 99355
Keith Petersen
Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.mil
BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
------------------------------
Date: Mon, 10 Sep 90 21:40:51 EDT
From: Drew Derbyshire <ahd@kendra.kew.com>
Subject: UUPC version 1.08a now available
UUPC/Extended version 1.08a is now available for the public. This
package is a small but *free* UUCP based mailer for connecting an
MS-DOS based PC to another PC or UNIX system.
The original authors of UUPC in Vancouver have moved onto other
projects and blessed (cursed?) my efforts of updating UUPC; thus,
version 1.08a is a replacement for both the interim release of UUPC and
UUPC/Extended 1.07j.
UUPC/extended 1.08a can be retrieved via anonymous FTP from
clutx.clarkson.edu, directory pub/uupc, and from the Clarkson CUHUG
BBS, telephone 315-268-6667, file area 4. The file names are:
UUPC08AU.ZIP (Executables and documents)
UUPC08AS.ZIP (Source files)
It has also been uploaded to WSMR-SIMTEL20.ARMY.MIL, directory
PD2:<MSDOS2.UUCP>.
Major changes for this release include:
Users can include messages from the mailbox when replying to mail,
and issue other commands when sending mail.
File name collisions when receiving files with mixed case names from
UNIX hosts are now avoided.
Full host names (greater than six characters) are sent to remote
hosts.
UUPC/extended now understands daylight savings time, and
automatically changes the name of the time zone twice a year.
Additional status messages if UUIO fails when connecting to the
remote system.
Modified packet machine to count errors on a per packet basis; this
means that a file transfer will not fail because of errors which slow
but do not halt the transfer, but a file transfer which is hung on a
single bad packet will fail after MAXERR retries.
The source files have been reorganized, and now compile under Turbo
C++ 1.0 or Microsoft 6.0 C. Turbo C 2.0 is no longer supported because
of MAKEFILE changes.
Appending the signature file is now controlled by a new option flag,
"autosign".
The help files have be externalized.
NOTE: Because some of the changes require changes in UUPC/extended
setup, the documentation files, especially CHANGES.DOC, should be
reviewed before using the new release.
My thanks to Keith Petersen and Russ Nelson for help in loading
UUPC/extended to various places.
Please direct all questions on UUPC or UUPC/extended to
help@kendra.kew.com.
Drew Derbyshire
Internet: ahd@kendra.kew.com U.S. Mail: 108 Decatur St, Apt 9
Voice: 617-641-3739 Arlington, MA 02174
------------------------------
End of Info-IBMPC Digest V90 #151
*********************************
-------