Re: Looking for binary file xfer from TRSDOS6/LSDOS6



Perhaps, try ARCHIVE4 or some other Model 4 compression program. If the archive shell has a few extra bytes, those will be likely be moot. This solution may also allow you to transfer 1 file instead of many.

Frank Durda IV wrote:
Well to follow-up on this thread, here are my encounters with
the YMODEM programs that I located and tried. The findings may
be of interest:

y-modem_1991_richard_vanhouten_cmd aka YMODEM6/CMD

I found that YMODEM6/CMD would refuse to do anything, simply
redisplaying the usage menu without any explanation of what might
be wrong with the command line parameters. Even the sample send
commands shown in the YMODEM/DOC file failed. It also acts like it
might have code issues as it dumps you back to the SYS1 command
interpreter with the prompt in some place other than column 1.
If someone knows how to actually get it to send anything under
LS-DOS 6, do speak up. I tried both batch and non-batch and it returns
the same "here are my commands" answer without doing anything useful.


yakety_yak_ymodem_transfer_v1.2_19xx_mike_bailey_cmd aka YAK/CMD

Moving on, I found that YAK (aka Yakety-Yak...) won't do batch. It
doesn't appear to have been written to have that option, so that's
out. It may transfer individual files just fine, but I have too many
to do in such a manual way. If it could be operated entirely from
the command line (one file per command) I could still manage that,
but it appears to not accept command line parameters to control the copy.


fastterm-zip.zip aka FTII/CMD

Next, I tried FTII/CMD (FastTerm), which exhibited two problems.
First, when given a list of test files to copy (about 200 filenames), it
aborts after moving the 14th file, regardless of how many are in the
batch file list. It claims that the 15th file is not found, but the
file is right there, is a plain text file with no password or any
other issues. By deleting a few lines from the start of the batch file,
FTII will eventually reach and transfer the files it just claimed were
missing and allows you through a few more files roughly to the number
you deleted from the start of the file. Then FTII stops again,
claiming another file was not found that really is there.
(All filenames in the batch file were of the form name/ext:5 and were
auto-generated from directory output using "ls -1d/ > batchfile/txt")

I suspect FTII has a fixed size buffer or something that it pre-loads
the transfer list into, and my list is longer than the buffer can handle.
It's also possible there are memory leaks, buffer/block spanning,
buffer overrrun or stack imbalances causing this behavior.

Well, being able to only move 14 files at a time is annoying but I
was willing to live with it, considering that after numerous tests,
FTII did copy a smaller set of large test files consistently,
and the files that reached the UNIX system on the other end all
compared.

However, nearly every file FTII copied has an apparently random amount
of junk characters (usually NULLs) beyond the stated size of the file
that is also copied, although the amount is consistent for each copy
of that given file. I have determined this extra material is being
transmitted from the Model 4 and does not appear to be introduced on
the by the receiving "lrz --ymodem" program that I am using.

As many of these files that I am trying to move are binary files,
I can't have any extra or missing (or different) bytes anywhere, nor
do I want to hand-trim some varying amount of excess bytes. If the
file is 19,897 bytes on the Model 4, the transferred file needs to be
19,897 bytes long too and contain the same information as was there on
the Model 4. So, FTII/CMD appears to be also unacceptable as a
trustworthy method to move files off the Model 4/4D/4P platform.


Those were the three programs suggested that I was able to find that
claim to do YMODEM batch transfers.


Are there any other options anyone can suggest to transfer a bunch of
files from a Model 4 to DOS, Windows, or BSD/UNIX/UNIX-like INTACT,
remembering that some of the files in question are larger than the
biggest floppy media?

Right now it appears that I have no choice but to write something
to perform this transfer task, since no existing tool seems to get it
right reliably. It just seems incredible that no one has a reliable
file transfer program already.


Frank Durda IV - send mail to this address and remove the "LOSE":
<uhclemLOSE.feb09%nemesis.lonestar.org> http://nemesis.lonestar.org
Copyright 2009, ask before reprinting.

.



Relevant Pages

  • Re: Looking for binary file xfer from TRSDOS6/LSDOS6
    ... the YMODEM programs that I located and tried. ... be wrong with the command line parameters. ... By deleting a few lines from the start of the batch file, ... FTII will eventually reach and transfer the files it just claimed were ...
    (comp.sys.tandy)
  • Re: log off command
    ... I simply execute the batch file and let them play... ... If it's by the hour you don't need a script. ... You can logoff a sessionname or a session ID in each case you have to ... Is it possible to issue the command from user1's logon to logoff ...
    (microsoft.public.windowsxp.basics)
  • Re: log off command
    ... I simply execute the batch file and let them play... ... If it's by the hour you don't need a script. ... You can logoff a sessionname or a session ID in each case you have to ... Is it possible to issue the command from user1's logon to logoff ...
    (microsoft.public.windowsxp.basics)
  • Re: log off command
    ... SOON 3600 LOGOFF %ID2% ... If it doesn't work please post what the "at" command returns if you run it ... after the batch file and please again describe when it does not work. ... Matija Hrovat ...
    (microsoft.public.windowsxp.basics)
  • Re: problem with a batch file wkgrp parameter
    ... The short answer is you're using the wrong syntax in your batch file. ... that isn't the secured workgroup information file used to secure the database, ... permission to open this secured database. ... You need to remove the "START /MAX" command, but even then it won't work ...
    (microsoft.public.access.security)