Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!olivea!decwrl!pa.dec.com!shlump.nac.dec.com!jareth.enet.dec.com!edp
From: edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.))
Newsgroups: comp.sys.handhelds
Subject: RE: Help on file transfer
Message-ID: <18850@shlump.nac.dec.com>
Date: 11 Jan 91 18:59:00 GMT
References: <21CC6A4E2000279A@gacvx2.gac.edu>
Sender: newsdaemon@shlump.nac.dec.com
Reply-To: edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.))
Organization: Digital Equipment Corporation
Lines: 23

Well, instead of arguing, I tried an experiment.  I tried two archives, both
with the HP-48 set to space parity and VMS Kermit set to space parity, file-type
binary.  I did one archive with the HP-48 set to ASCII and one with it set to
binary.  I got two different files on the VMS system, with these different
record characteristics:

		HP-48 in binary		HP-48 in ASCII
	format	variable length,		variable length,
		maximum 510 bytes	maximum 3786 bytes
    attributes	none			carriage return carriage control

Furthermore, the file created by the ASCII transfer could not be successfully
transferred back to the HP-48, with either the original settings or with both
sides set to binary.  (The transfer always yielded a string rather than a backup
object.)  Therefore, it is important to set the file transfer mode on the HP-48
when doing an archive; the archive does not automatically override the setting
and force a binary transfer (at least not a proper binary transfer as VMS Kermit
requires it).


				-- edp (Eric Postpischil)
				"Always mount a scratch monkey."
				edp@jareth.enet.dec.com