I'm pretty stuck at the moment and it's an urgent matter, so any help would be very much appreciated!
I need to copy two files (1.03MB and 450KB) from an old computer with "SCO Unix SVR 3.2" operating system - i.e. command "uname -a" returned "scosysv scosysv 3.2 2 i386" so I think I got the OS right.
Here are the logistics:
I have root access to it.
Computer has 3.5" and 5.25" floppy drives and a tape drive, but I only have 3.5" floppies (FAT formatted) available and I could get a magnetic tape.
It has a modem but I presume to connect it to a network would be very hard having in mind the scarce online documentation and my inexperience in that regard.
Every attempt in mounting or any formatting (with "format" and "dosformat") the various floppy disks at "/dev/fd0" resulted in floppy drive accessing the floppy disk and after several seconds displaying similar message:
"WARNING: floppy: Read error on dev 2/60, block= cmd=0x status=0x01" with an additional "can't read DOS boot sector off /dev/fd0" or similar messages.
BUT I DID manage to do listing of floppy disk files with "dosls /dev/fd0" command and even to copy a small .txt file to a floppy disk with the "doscp test.txt /dev/fd0" command. But the same "doscp" command on a 450KB file returned an error that there is no more free space on the floppy drive although there was.
Any ideas how to successfully mount a "DOS floppy" or do a UNIX format of a floppy disk and then copy a file to floppy drive? Any floppy file system format would do!
Welcome to the forum - we hope you find this to be a friendly and helpful place, and that you enjoy your time here !
One possibility here, if you have an appropriate serial cable, would be to transfer the files over a serial link to a modern system using Kermit or ZModem or something similar. This might be the least painful way, if you have a compatible cable, and a compatible serial port on the destination system.
Failing that, the tape drive might also work, if you have another tape drive on the destination system that can read the tapes (or if the tape drive can be moved from the SCO box to the destination system, assuming the destination system can use that tape drive, of course).
It sounds as though the 3.5" floppy drive might be having problems, if you've tried multiple floppy disks and gotten the same results. Finding still-usable blank 5.25" floppies might be a challenge these days to be sure, but as a last resort this might be worth looking into (though you'd still need a destination system with a 5.25" drive, which could be an even bigger challenge still).
Lastly, if this version of SCO has support for TCP/IP, you could try to get an old ISA network card that's compatible with the OS installed, and then transfer the files via FTP or an NFS mount, or something similar
Anyway, good luck - hope some of this helps ! If not, let us know, and either myself or others might be able to chime in with some more suggestions.
Regarding the floppy disk.
The dos* commands work with not mounted floppys.
Maybe the doscp command expects a 720k DD not a 1.44M HD?
Consult its man page man doscp
If it works with small files, make a copy with cp and compress it with compress .
Later a gunzip should uncompress it.
The dd command can copy a portion of a file. The portions can be assembled again with a simple cat
My first question is whether this SCO machine is a production box? Does it have a backup? Could you recover it if it goes wrong?
A SCO Unix box of this vintage does not support DOS by default. DOS support needs to be installed using:
# mkdev dos
but this involves re-linking the kernel and rebooting the system. That should work if all the necessary files are still present on the system but also could go wrong if they're not.
Also, 3.5" floppies become unusable after a number of years so it would be well worth validating one or more on another system to ensure format, write and read functionality.
A 1.44MB floppy on SCO would be device /dev/fd0135ds18 and, of course, to format the raw device would be /dev/rfd0135ds18
Thank you for the quick reply!
You know, after I posted the question last night the serial cable idea came to my mind also it really would bypass any floppy disk/tape malfunctions and library install problems. I googled last night and it looked to me like a simple port configuration and a "cat" command on the sender's computer, and a simple custom app on a receiver's end, would do the trick? The file data is in ASCII format so I'm a bit more hopeful that "cat" command wouldn't mess up the data during the sending.
As for Kermit and ZModem, do you think one of them would come preinstalled with that OS or they would need to be installed? I'm asking you this because this is a client's Unix computer we are talking about so I can't check these things promptly.
Thank you for the clarification of the purpose of the "dos*" commands!
The file sizes I mentioned are after I compressed the files with the "compress -H " argument so unfortunately I think they are as compressed as they can be. Thank you for the quick reply and all of the ideas, but I am suspecting that all of those floppy disks are more or less corrupted and can't be used in full capacity - I will test them more thoroughly when I would have a chance. So I think that, apart from the experimenting with the serial communication, the best option I have is to split the files into smaller chunks on multiple floppies and hope that they wouldn't land on bad sectors
Thank you for the quick reply!
Yes, the SCO machine is a production machine, and I did try to follow that tutorial you mentioned but restrained myself from pressing Enter after the command "mkdev dos" for the similar reasons you mentioned
Thank you also for the clarification of the proper naming of the floppy devices - I will try the commands the next time.
Yes, if these are simple ASCII files and if the serial ports are set up identically at both ends (and if you have the right kind of cable), then a plain cat might well be enough to do the trick, if all goes well.
As to whether or not SCO SVR3.2 would have Kermit or ZModem utilities - sorry, I have no idea offhand, you'd have to check on the system itself to see if binaries such as sz and kermit are there.
Assuming that the floppy drive actually works, do not try to format a diskette, just use tar.
As root:
tar ctvf /dev/rfd0135ds18 file_name # if the 3.5 diskette is drive A
tar ctvf /dev/rfd1135ds18 file_name # if drive B
edit: corrected the line above was rfd1135ds17
tar.exe is a program on Windows 10 build 1903 and later.
If this does not work:
cat /etc/inittab # to determine if tty1A or tty2A has 'respawn' on its line.
if so, you can log into the system using another modem, use putty to cat the files to the screen, and log all the output, afterwards, you can use notepad++ to convert the files from lf to crlf, if necessary.
If you do not have a modem, build a null modem serial cable on 25 pin, 2->3, 3->2 and 7 straight.
Modify /etc/inittab so that tty1A or 2A is changed to 1a or 2a.
Set the baud rate to whatever is listed in inittab, probably m=9600, n=19200
It is highly unlikely that you have TCP if there is not a network card in the system as TCP was sold as a separate product. Kermit was available from Columbia University and may have been downloaded. uucp is a standard product, as is cu if you have another system that has a serial port enabled; uucp is available for Linux systems.
I am a bit puzzled because I have no idea how I can help, I have the complete ATT i386 SYSV 3.2 in my library but my wife made my life complicated having stored a mountain of stuff in front... My set is from what was at the time considered as a mini (a PRIME box, elsewhere we had prime-os boxes)... a tower with a i386/33 , but in the classroom we were 20 connected to it via wise terminals and writing/compiling COBOL programs... Now what I remember: all the diskettes of the OS were 5"1/4 Hi density, and the tower had internal 5"1/4 drive and a QIQ tape drive and an external 3"1/2 drive, this is where it gets tricky: if for 5"1/4 floppies you had almost a common standard, at the time it was not the case of 3"1/2 as Mac had theirs, commodore also, I had a brother machine that had his: 200K etc, and most important, I am not sure at all unless you had extra updates that you had High density, well we did not and the OS was of 87-88... the tape was used for the backups, and the floppyB (3"1/4) for our use, which only very few used, I had no computer at the time except a Synclair QL so no hope for me... but having a friend at university I did copies with dd, because at university they had all sorts of fancy machines on top of PCs..
All this to say as suggested MIG it is possible that your drive/OS does not support 1.44 Mb format but just 720Kb, I remembered using the split command to split the file in portions mostly for testing, but cannot remember how to reconstitute the file after ( I am quite sure the was a command but my memory is serving me at the moment...)
You would have to try... I remember seeing students struggling between their terminal and the floppy, I don't know what was the command they used ( as I did not do like them having no equipment) I wonder if it was not just tar, but when the floppy was full it displayed "full, please put a new diskette and press Enter", most unix at the time if offered that option, would be with backup commands.
And maybe more important: I don't know how close the SCO is of the original, I believe it would have extra stuff, user-friendly utilities etc for the vendor to attract clients
I think it was made clear that you need the
/dev/fd0135ds18 or /dev/rfd0135ds18 device for a 1.44M HD floppy.
The /dev/fd0135ds18 block device is for use with a file system (e.g. FAT) for either mount and copying with cp or copying with dos* commands.
The /dev/rfd0135ds18 raw device can be used for sequential data like a tape: tar cvf /dev/rfd0135ds18 file_name
(no t of course)
and will destroy a file system.
Internet resource: https://www.scosales.com/ta/kb/107195.html
Portions of files created by dd skip=n count=m ... can later be concatenated in one go by cat part1 part2 part3 ... > filename
http://osr600doc.sco.com/en/manC/tar.C.html
talks of one function(operation mode) that is either c(create and write) or u(rewrite and update) or t(read and list) or x(read and extract).
All tar versions are like this.
The C and r functions are specific to SCO tar.
And all tar versions have (at least) the function modifiers f(archive filename follows) and v(verbose).
Most tar versions allow a leading dash to make it compliant with standard Unix options.
Sorry to bother you again! I tried everything today to send text (via echo) and files (via cat) via ttyS0 or ttyS1 (from the PC that has two RS232 9-pin ports) and failed miserably
Here is the chronology of commands I tried today:
cat /proc/tty/driver/serial # <-- returned '/proc does not exist'.
dmesg | grep tty # <-- returned nothing.
grep -i 'tty' /var/log/dmesg # <-- returned "...can't open /var/log/dmesg".
setserial # <--- returned "not found".
stty 9600 cs8 -parenb -ixon -ixoff -cstopb >/dev/ttyS0 # <--- returned nothing on other devices also.
echo 'testing' >/dev/ttyS0 # <-- my receiving-end laptop didn't receive anything although I configured the receiving end with the same baud rate (and other configurations) and serial communication with other Windows computers works flawlessly. echo 'testing' >/dev/ttyS1 # <-- my receiving-end laptop didn't receive anything. echo 'testing' >/dev/ttyBLAH # <-- nothing happened and my receiving-end laptop didn't receive anything.
Same happened when I tried cat test.txt >/dev/ttyS0 and with other devices.
ls -l /dev/tty* # <-- showed that all above devices (i.e. ttyS0, ttyS1 and ttyBLAH) are in the list, with '4th column' saying "other" although the same column for other devices (like /dev/tty1A, tty1a, tty2A...) said "bin". So I suspect that ttyS0 and ttyS1 were created AFTER I ran commands in 4).
By the way I totally forgot to try your cat /etc/inittab and so sorry for that! I will try it tomorrow.
So, what am I missing here? Is it safe and should I run mkdev serial to configure serial devices although in documentation it says that "The device files for the first and second ports already exist.".
Command tar ctvf /dev/rfd0135ds18 file_name was also a "disaster" and returned: "floppy: Read error on dev 2/60, block=0 cmd=0x01 status=0x01" on all floppy disks that I've tried although I tested every sector of those floppy disks, so I suppose that floppy drive is probably busted.
I will return tomorrow to the client to test all the commands again on other PC (I will first list the tty* devices prior to everything else) so I would very much appreciate a prompt response
The device names on SCO are not the same as Linux.
COM1 is tty1a with a direct connection, or tty1A with a modem connection
COM2 is tty2a and tty2A.
If either or the comp ports is not enabled, build a crossover cable and connect a PC.
then:
enable tty1a (or tty2a)
edit /etc/inittab, find the line with that tty## and set the last character on the line to 'm' for 9600 baud.
you may have to disable and enable the line if you made a change ( I think the default was 9600).
#disable tty1a
#enable tty1a
You should now be able to login from the pc using putty with the appropriate serial settings using xon/xoff protocol.
Turn on logging in putty and cat the file.
Edit the received log file to remove the lines prior to the first line of the file.
Thank you very much for your quick reply!
I think I didn't try with tty1a but I tried with tty1A instead and it didn't work - I will definitely try tty1a tomorrow.
So, I am only interested in sending data from Unix PC via serial port, so I have a cable fit to do that one way transmission since in my testing environment I managed to read the input very fast and didn't need to respond with XOFF/XON for the flow control.
So, are you saying that it is not enough to configure tty1a with a command line like stty 9600 cs8 -parenb -ixon -ixoff -cstopb -echo >/dev/tty1a and I should do that inittab editing AS WELL or INSTEAD of stty command?
When you say ...set the last character on the line to 'm' for 9600 baud. do you mean to REPLACE the last character with 'm' or to ADD 'm' at the end of the line? Sorry for asking for this level of detail but I haven't found any usable examples of /etc/inittab file online.
You need to enable the line in order to log in. the last field on the inittab line is the baud rate and char setting.
m is 9600baud 8n1
n is 19200 baud 8n1
I don't remember any others, and I no longer have access to any systems with serial ports.
If your found ttyS?? ports in /dev then it is likely that there is/was a multi port serial card installed at some time. The naming convention for these ports varied by manufacturer.
You should not need to use stty to define the port if it is enabled, as getty will take care of that based on the data in inittab.
Rather than try to send the data using
cat file_name >/dev/tty1a
I would log in from tty1a, then turn on logging and:
Thank you very much for your prompt and useful replies! Finally, I established the connection today and transmitted all the necessary files! The port tty1a was initially disabled so your command enable tty1a did the trick. In /etc/inittab port tty1a was configured with m at the end of the line so I configured the receiving software with that 9600 baud rate and 8n1, extra tightened the screws on the ancient loosely rs232 port and thereafter everything went smoothly! Thank you and God bless you!
By the way, for anybody who will maybe struggle with transfer of files from Unix SCO: to minimize the file size I used compress -H file_name and then uncompressed the file on Windows OS with Deark software.
