🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #33512

(none)

#33512
From: SCHRIMPF
Date: Mon, 08 Aug 1988 08:23
54 lines
3777 bytes
Date: 08 August 1988, 10:23:02 CET
From: AG Nukleare Festkoerperph 06421-284155         SCHRIMPF at DMRHRZ11
To:   INFO-ATARI16@SCORE.STANFO
Problems with program-server.

Hi Atarians,
   I just got to know about Atari program servers two weeks ago.
   Though I am new in that business I am quite familar with BITNET-ing
   messages and computering in general. I seem to have a lot of trouble
   with the servers and I don't know whether thats a general trouble or
   just something I am doing wrong.
   Almost half of the programs,listings,... that I got are extremly
   erroneous. The crazy thing is, some files come along perfectly and
   some don't. There seem to be at least two different errors.
   First of all some of the text-files, like ARBACK.C or SPEAK.C
   are not complete. That is the most stupid thing in the world, if
   somebody transmitts program sources to a server, which just end
   right in the middle of the program. They can be deARCED and UUDECODEd
   correctly, so the transmission to my userid seems to be okay and it
   must be the case that come crazy guys are putting incomplete stuff into
   the servers archive.
   The next error is that the files can be UUDECODEd but deARCing shows
   a CRC error. This happens with GULAMDOC.ARC, MORE14.ARC, SPEAK.ARC,
   HDSCAN13.ARC and with all (!!!) the files form the new server at SSYX.
   To me that is not a problem of the IBM 4831 ( where I am receiving the
   files ) but a problem of the files in the program servers archive, too.
   I got send the files from the new server at SSYX but accident more than
   20 times ( in words: twenty !!!, though I just ordered them once ) and I
   checked a couple of the files. They are all identical, that means it is
   not a problem of transmitting the files. It must be that the original
   files are just not okay.
   So my questions is: Why is somebody organizing a program-server with
   wrong, erroneous and incomplete files ?
   I have a bit of experience in the IBM-PC world ( and a lot with ATARI-ST),
   but I have never had such problems with any PC-program server.
   There is another strange thing. The PC-servers that I know use just
   binary file transfer, that means the transmit 8 bits and not 7. Their
   files are not (!!!) UUENCODED. That has a tremendous advantage ( or I
   should say UUENCODing causes additional trouble, where you need a wizzard,
   as some computer folks would say ). Using UUENCODE means, using a certain
   text-notation ( ASCII ). But the IBM uses EBCDIC-code and not ASCII-code.
   The problems arrises because, there are no equivalent characters for the
   square brackets in the EBCDIC-code. The IBM realizes the problem and
   has a biult in UUDECODing feature, so that I can decode the files there and
   then transfer them in a binary mode down to my ST. If I would transfer
   the files directly with a 7-bit transfer ( KERMIT in TEXT-mode ) the files
   would be damaged. The same thing is happening to program sources, if
   they are not ARCed. Once they are in a TEXT-mode on the IBM I cannot get
   the square brackets down to any other computer. They are lost.
   Why in the hole world are the Atari-freaks doing things so extrem
   dangerous ( for the files ) and complicated ( for the users ) ???

   Andreas Schrimpf, Renthof 5, D-3550 Marburg, FRG
   SCHRIMPF@DMRHRZ11.BITNET
Technical Details
Message-ID: <8808080823.AA04365@ucbvax.berkeley.edu>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!rutgers!ucsd!ucbvax!DMRHRZ11.BITNET!SCHRIMPF

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!rutgers!ucsd!ucbvax!DMRHRZ11.BITNET!SCHRIMPF
From: SCHRIMPF@DMRHRZ11.BITNET
Newsgroups: comp.sys.atari.st
Subject: (none)
Message-ID: <8808080823.AA04365@ucbvax.berkeley.edu>
Date: 8 Aug 88 08:23:30 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 54
X-Unparsable-Date: Mon, 08 Aug 88 10:23:19 CET