cloos@acsu.buffalo.edu (James H. Cloos) (10/11/90)
I've found that compressing files that have been trasnfered from hp48's to sun's will corrupt them; trying to trasnfer the uncompressed file back to the hp results in nothing more than a string "HPHP48-"etc. This also occurs when transfering a file to the 48 that has been trasnfered between computers with image mode ftp. (As I understand it, Inamge mode is used between differing types of systems when bin mode is requested. Bin mode itself is used only between identical types of systems (ie., a pair of sun4's, etc.).) I have been able to repeatedly acomplish this "destruction." As far as I can tell, though, the uncompressed a/o ftp'ed file looks OK on the computer. ??? Any comments of differing results are gladly accepted. Well, maybe not GLADLY, as that means I lost files using utilities that should have left my stuff OK. :-( -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@acsu.buffalo.edu Snail: PersonalZipCode: 14048-0772, USA rutgers!ub!cloos
bgribble@jarthur.Claremont.EDU (Bill Gribble) (10/11/90)
In article <40142@eerie.acsu.Buffalo.EDU> cloos@acsu.buffalo.edu (James H. Cloos) writes: >I've found that compressing files that have been trasnfered from >hp48's to sun's will corrupt them; trying to trasnfer the uncompressed >file back to the hp results in nothing more than a string >"HPHP48-"etc. This also occurs when transfering a file to the 48 that >has been trasnfered between computers with image mode ftp. (As I >understand it, Inamge mode is used between differing types of systems >when bin mode is requested. Bin mode itself is used only between >identical types of systems (ie., a pair of sun4's, etc.).) I don't want to flame you, but I *do* want to cut off this type of silliness before a bunch of hp owners who don't know a whole lot about the net get upset. FTP AND COMPRESS AREN'T DOING ANYTHING BAD TO YOUR FILES. If there is a problem with file transfers, mos tlikely the problem is yours: you forgot to set file type binary on either the sending kermit or on your hp. Think about it for a minute - if image ftp and compress couldn't deal with binary files they wouldn't be in use today. What makes HP binaries any different from IBM binaries in the eyes of a UNIX system? They're both just gibberish binary files. Calm down a bit and try again. >James H. Cloos, Jr. Phone: +1 716 673-1250 ***************************************************************************** ** Bill Gribble Harvey Mudd College, Claremont, CA ** ** bgribble@jarthur.claremont.edu Never heard of it? You're stupid. ** *****************************************************************************
cloos@acsu.buffalo.edu (James H. Cloos) (10/15/90)
I have to reply to this. The files that got corupted worked before they were compressed/uncompressed and, wrt those that were ftp'ed, before they were ftp'ed. Given that, I can only assume that the problem happened at the stages I said. I have repeated this. -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@acsu.buffalo.edu Snail: PersonalZipCode: 14048-0772, USA rutgers!ub!cloos
madler@piglet.caltech.edu (Mark Adler) (10/16/90)
I suggest that readers ignore the postings about ftp and compress corrupting HP-48 files (as if they're "more" binary than other files). I've used them (and most every other scheme for moving and compressing binary files that you can think of) with nary a problem. It does take a little care to make sure you do it right and request that ftp and kermit deal with binary files, but it does work. This fellow has a very common syndrome among computer users, which is to assume anything possible before assuming that oneself is doing something wrong. Of course, that is the FIRST thing that should be assumed---I know I do. If I could have one cent for every "compiler bug" that has been claimed, I would make Trump look like a pauper. Mark Adler madler@piglet.caltech.edu
cloos@acsu.buffalo.edu (James H. Cloos) (10/16/90)
In article <1990Oct15.170509.9366@nntp-server.caltech.edu> madler@piglet.caltech.edu (Mark Adler) writes: > > This fellow has a very common syndrome among computer >users, which is to assume anything possible before assuming that oneself is >doing something wrong. Of course, that is the FIRST thing that should be >assumed---I know I do. Given that this was posted, so is this: I must object to Mark's characterization of me wrt asuuming something else is at fault before assumeing I am. In general AND IN THIS SPECIFIC CASE, I did quite the opposite. In fact, I first started noticing these problems a few weeks back, but waited so long to post because I was trying various things to prevent/correct the symptoms. None of these succeeded. *SOMETHING* is going wrong, that is certain. Multiple tests usw have led me to the opinions expressed in my first posting. I also seriously feel that the above quoted comment was not called for, I so mauch as told him that in a mail file earlier today (in response to a reply by Mark to my 1st post). {If nothing else, leaving that comment out would have reduced badwidth usage, but as much as I hate to see flames in c.s.h, I do not enjoy public attacks either. Comments like that belong only in the mail.} -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@acsu.buffalo.edu Snail: PersonalZipCode: 14048-0772, USA rutgers!ub!cloos
byu@csri.toronto.edu (Benjamin Yu) (10/16/90)
In article <40831@eerie.acsu.Buffalo.EDU> cloos@acsu.buffalo.edu (James H. Cloos) writes: # In article <1990Oct15.170509.9366@nntp-server.caltech.edu> madler@piglet.caltech.edu (Mark Adler) writes: # > # > This fellow has a very common syndrome among computer # >users, which is to assume anything possible before assuming that oneself is # >doing something wrong. Of course, that is the FIRST thing that should be # >assumed---I know I do. # # Given that this was posted, so is this: # # I must object to Mark's characterization of me wrt asuuming something else # is at fault before assumeing I am. In general AND IN THIS SPECIFIC CASE, # I did quite the opposite. In fact, I first started noticing these problems # a few weeks back, but waited so long to post because I was trying various # things to prevent/correct the symptoms. None of these succeeded. # # *SOMETHING* is going wrong, that is certain. Multiple tests usw have led # me to the opinions expressed in my first posting. # # I also seriously feel that the above quoted comment was not called for, I # so mauch as told him that in a mail file earlier today (in response to a # reply by Mark to my 1st post). # # {If nothing else, leaving that comment out would have reduced badwidth # usage, but as much as I hate to see flames in c.s.h, I do not enjoy # public attacks either. Comments like that belong only in the mail.} # # -JimC # -- # James H. Cloos, Jr. Phone: +1 716 673-1250 # cloos@acsu.buffalo.edu Snail: PersonalZipCode: 14048-0772, USA # rutgers!ub!cloos Well, call me whatever you like, but I experienced different output from different FTP and UUDECODE programs (ALL FLAGS SET THE SAME!!). I have tried ftp once to get an uuencoded file from a site, downloaded to my PC for uudecode and then to my 48, and nothing worked. But if I uudecoded the file on my Unix box and then uuencoded it again and then download it to my PC, uudecoded it and then to my 48, it works. So, unless everyone has the same ftp, uudecode, uuencode, compress, etc. functioning the same in all platform, I would hesitate to say outright that the problem is simply setting BINARY in the file transfer!!! Benjamin Yu byu@csri.toronto.edu
madler@piglet.caltech.edu (Mark Adler) (10/16/90)
I apologize if I offended James Cloos with my comments about assumptions where the fault may lay. In this case, I'M the one who made a bad assumption about how he came to his conclusions. I have assisted quite a few people over email in doing these kind of transfers, and, so far, it has been resolved each time by having the user do the right thing. Also, I made that posting the same time I sent mail to James suggesting things to try to get it to work, so his reply came long after that first posting. (Newsgroup posting tends to be rather slower than email.) It certainly is tricky to get it to work, especially since some machines don't like to have arbitrary length files. Binary transfers require care and attention to spot problems along the way to aid in debugging the entire link. Again, I apologize to James and to the net for this additional, but appropriate bandwidth noise. Mark Adler madler@piglet.caltech.edu
avenger@wpi.WPI.EDU (Samuel Joseph Pullara) (10/16/90)
In article <40717@eerie.acsu.Buffalo.EDU> cloos@acsu.buffalo.edu (James H. Cloos) writes: >I have to reply to this. The files that got corupted worked before they >were compressed/uncompressed and, wrt those that were ftp'ed, before they >were ftp'ed. Given that, I can only assume that the problem happened >at the stages I said. I have repeated this. >-JimC >-- >James H. Cloos, Jr. Phone: +1 716 673-1250 >cloos@acsu.buffalo.edu Snail: PersonalZipCode: 14048-0772, USA >rutgers!ub!cloos The most obvious reason for this is that when you FTPed the files you had it set to ascii and not binary, if compression doesn't mess up normal computer files it certainly won't mess up files for the 48sx.... -- /------------------------------------------------------------------------\ | Sam Pullara, Undergraduate Physics Worcester Polytechnic Institute | | avenger@wpi.wpi.edu (c) 1990 Avenger Publications | |______________-All my opinions were expressed or implied.-______________|
darrylo@hpnmdla.HP.COM (Darryl Okahata) (10/17/90)
In comp.sys.handhelds, cloos@acsu.buffalo.edu (James H. Cloos) writes: > I have to reply to this. The files that got corupted worked before they > were compressed/uncompressed and, wrt those that were ftp'ed, before they > were ftp'ed. Given that, I can only assume that the problem happened > at the stages I said. I have repeated this. Perhaps, if you posted a very detailed, nitty-gritty, step-by-step, description of *everything* that you did, we could figure out what is happening. At the Unix end, use the script(1) command and post the output here. -- Darryl ("I don't believe it.") Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@hp-sde.sde.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.
cloos@acsu.buffalo.edu (James H. Cloos) (10/17/90)
In article <1990Oct15.220403.15473@nntp-server.caltech.edu> madler@piglet.caltech.edu (Mark Adler) writes: >Also, I made that posting the same time I sent mail to James suggesting >things to try to get it to work, so his reply came long after that first >posting. (Newsgroup posting tends to be rather slower than email.) Looks like the keyword is getting more and more to the point. I did see the news followup well after the mail reply, and so my appologies to Mark for suggesting that his statement wrt assumptions was made after he had a chance to see the mail I sent him. Now, before we have to rename c.s.h into alt.assumption, lets get back to the FUN stuff that goes on here. & remember, I did say CAN & not WILL corrupt. -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@acsu.buffalo.edu Snail: PersonalZipCode: 14048-0772, USA
rrd@hpfcso.HP.COM (Ray Depew) (10/17/90)
/ hpfcso:comp.sys.handhelds / madler@piglet.caltech.edu (Mark Adler) / 11:05 am Oct 15, 1990 / I suggest that readers ignore the postings about ftp and compress corrupting HP-48 files (as if they're "more" binary than other files). I've used them (and most every other scheme for moving and compressing binary files that you can think of) with nary a problem. It does take a little care to make sure you do it right and request that ftp and kermit deal with binary files, but it does work. This fellow has a very common syndrome among computer users, which is to assume anything possible before assuming that oneself is doing something wrong. Of course, that is the FIRST thing that should be assumed---I know I do. If I could have one cent for every "compiler bug" that has been claimed, I would make Trump look like a pauper. Mark Adler madler@piglet.caltech.edu ----------
rrd@hpfcso.HP.COM (Ray Depew) (10/17/90)
> If I could have one cent for ... > .., I would make Trump look like a pauper. Isn't he already? (Or at least trying to convince his creditors that he is?) Ray IC's by Bill and Dave rrd@hpfitst1.hp.com (I know, it belongs in alt.alex.p.keaton, but I couldn't resist! :-)
khbsnsr@nmt.edu (Kenneth Brunell) (10/19/90)
OK, I seem to have this problem too. Although I just think that there
is something that I am overlooking. I have tried to download several
machine code objects into my 48. including HP's stpwatch.lib, usag,
and some others. What I get in the resulting variable is a string:
"HPHP48-A[binary data. . .]"
What does this mean? Does it have anything to do with the translation
code (SETUP), though I thought that that was just for ASCII up/downloads
to take care of all the special characters. Or, is there another program
floating around out there that I need to convert this thing into a
system object?
-------------------------------------------------------------------------------
| _ , __ _ _ | "It's green . . ." |
| ' ) / / ) // // | Mr. Scott |
| /-< _ ____ /--< __ . . ____ _ // // | |
| / ) </_/ / <_ /___/_/ (_(_/_/ / <_</_</_</_ | Loooove that .sig |
| <khbsnsr@jupiter.nmt.edu> | |
===============================================================================khbsnsr@nmt.edu (Kenneth Brunell) (10/22/90)
Ok folks. I have found MY problems! In order to the assembly programs from ftp sites, first, makesure that you set the transfer type to Image, with the binary command in ftp. Then, make sure that when you kermit it to your HP, and if you use kermit to get onto your PC, to use IMAGE mode, switch i. On top of this, you may have to make sure that the file is the proper length before sending it to the HP. OH, and the HP must be set to binary, in the setup menu. This worked for me. -Ken ------------------------------------------------------------------------------- | _ , __ _ _ | "It's green . . ." | | ' ) / / ) // // | Mr. Scott | | /-< _ ____ /--< __ . . ____ _ // // | | | / ) </_/ / <_ /___/_/ (_(_/_/ / <_</_</_</_ | Loooove that .sig | | <khbsnsr@jupiter.nmt.edu> | | ===============================================================================