I've had a PC on a primarily SGI network since 1990. During that time, I've assembled some information and software to make the PC a more useful tool in that environment. The key is to make it easy to exchange and share data between your PC and SGI workstation. This can range from the old standby floppy disks and tapes, to serial communication all the way to high-speed networking and NFS.
Assuming you have a SCSI floppy or floptical diskette drive in your SGI
workstation, you can exchange data with PCs and Macs via low and high
density floppy disks (and with 21MB floptical disks if your PC is
similarly equipped). The SGI workstation will automatically recognize
the floppy format and mount it with the proper file system at
The MS-DOS file system on IRIX will "do the right things" to files put on the floppy. These include:
So, to avoid surprises, achieve faster transfer speed to/from the floppy, and stuff more data on a floppy, I'd recommend that you use some form of archive and/or compression tool when reading/writing the floppy disk on both the PC and IRIX side. Writing many individual files to a floppy from IRIX and be somewhat slow due the the MS-DOS file system translations. A single file archive can be written to and read from the floppy much faster. Also, you can "hide" long file names, mixed-case file names, and IRIX permissions inside the archive.
If you have the luxury of more than one system with floptical drives, by all means get ahold of some floptical diskettes. I personally use the "3M Floptical Diskettes". They come 5 to a box (which unfortunately runs ~US$70).
As far as compression and archive tools go:
pkzip and winzip.
For density, speed, and cost you'll be hard pressed to beat magnetic tapes for data archive and interchange. To take advantage of this method, you'll need:
The SCSI host adapter must be ASPI-compliant and you'll need a tape form factor that matches the one in your workstation.
Here's some tape drives, host adapters and ASPI drivers I have used successfully (I've never found a tape/controller combination that didn't work):
PUT.BAT) that are used to read and write data from and to the tape. You'll need to use compatible tar options on the IRIX side. Here are matching IRIX shell scripts to read and write DOS-TAR compatible tapes:
get" and "
chmod +x get put
PUT.BAT) the try to read them on IRIX with
get. If it works, GREAT! Then try writing files on IRIX with
putand try to read them on the PC with
GET.BAT. If this works, you are done. If not, read on for trouble-shooting tips.
Below are some tips for troubleshooting problems with tape data interchange as well as some handy tips and tricks for using DOS-TAR more effectively:
What follows is a historical account of the IRIX SCSI tape driver for those interested in the reasoning behind its current complexity.
/dev/rmt/tpsXdYs) and non-byte swapped devices (
/dev/rmt/tpsXdYns) were maintained for compatibility reasons. On these newer tape devices I recommend that you not use either the swap or non-swap devices because I've never really figured out which does what and I usually guess wrong at least half the time :-)
/dev/rmt/tpsXdYv) and hardware compression (
/dev/rmt/tpsXdYc). The GNU tar source code base upon which DOS-TAR was built variable block size, period. Regarding hardware compression, unless both of your tape devices support the same compression algorithm, you'll probably be better off not using this feature either, at least until you verify everything else is working.
tarwith its default device parameter which is either the value of the environment variable
/dev/tapeif that is not specified. The
/dev/tapepseudo device is created by the
/dev/MAKEDEVscript at boot-up time and is set to point to a default tape device, which is the first SCSI tape device found (with various device options as appropriate for that tape drive). If you have multiple tape drives, or drives with features like variable block size, or ones with byte-swapping issues, the default tape device may not work for you.
/dev/ = Irix DEVice directory
rmt/ = Removable Magnetic Tape directory
tps = TaPe Scsi device
C = SCSI controller, usually 0 for internal, 1 for external SCSI bus
d = d?
I = SCSI ID of the tape device, usually [1..7] for SCSI-I&II or [1..15] for wide SCSI-III. In IRIX, SCSI-ID#0 is reserved for the host adapter(s) in the workstation.
nr = Non-Rewind device, tape does not rewind after writing, default is to rewind.
ns = Non-byte Swapping device
s = byte Swapping device
v = Variable block size option, default is fixed block size
c = enable hardware data Compression, default is no hardware data compression
tar: this appears to be a byte-swapped archive
Most likely, you are using a quarter inch cartridge (QIC) tape
drive and you'll need to deal with the default byte-swapping behavior
of the IRIX SCSI tape driver. Alternately, your default tape
device may have been manually configured for a byte-swapping driver.
The best way to override this without affecting other
users/applications, is to set the environment variable,
scripts to point to the non-swapped tape device. For example if your
tape is on the internal SCSI controller (0) at SCSI ID #4, then the
default tape device is:
and the non-swapped device is:
So, to change the default, use:
Alternately, you can use the non-swapped tape device link (if it exists; e.g QIC drives):
in the get and put shell scripts; for example in put:
Note: On DAT and 8mm tapes, this is not applicable.
DOS-TAR does support variable block sizes.
aspiread: errno -25
This is most likely the result of using the variable block size tape device. The way to tell what device is being used as the default tar tape device is as follows:
> ls -l /dev/tape
crw-rw-rw- 2 root sys 144,70 /dev/tape
> ls -l /dev/rmt
crw-rw-rw- 1 root sys 144, 66 tps0d4
crw-rw-rw- 1 root sys 144, 67 tps0d4nr
crw-rw-rw- 1 root sys 144, 67 tps0d4nrns
crw-rw-rw- 1 root sys 144, 71 tps0d4nrnsv
crw-rw-rw- 1 root sys 144, 65 tps0d4nrs
crw-rw-rw- 1 root sys 144, 69 tps0d4nrsv
crw-rw-rw- 1 root sys 144, 71 tps0d4nrv
crw-rw-rw- 1 root sys 144, 66 tps0d4ns
crw-rw-rw- 1 root sys 144, 70 tps0d4nsv
crw-rw-rw- 1 root sys 144, 64 tps0d4s
crw-rw-rw- 1 root sys 152, 67 tps0d4stat
crw-rw-rw- 1 root sys 144, 68 tps0d4sv
crw-rw-rw- 1 root sys 144, 70 tps0d4v
/dev/tape(144 and 70 respectively in this example) with the same fields for the
tpsdevices. The one(s) that match show you which one is being used as the default device. In this example (a DDS1 DAT tape on SCSI controller 0, SCSI ID 4) you can see
/dev/tapeis using the
tps0d4vdevice (as well as
tps04dnsv) meaning that it is non-byte swapped, variable block size by default. Non-byte swapped is good, but variable block size is bad for DOS-TAR. To fix this, you'll need to set the
setenv TAPE /dev/rmt/tps0d4
tps0d4nsare the same major and minor numbers they are the same device.
DOS-TAR is built in the medium DOS memory model, which limits it memory requirements, but also limits it in certain aspects. The major limitation is on the tar blocking factor (or number of 512-byte disk blocks to buffer at any time).
tar uses the "b" argument as the blocking factor for tape records. The default is to use the results of the MTIOCGETBLKSIZE ioctl for tape when creating a tape (and for reading on fixed blocksize devices, such as QIC) and to determine the blocksize (for variable blocksize devices) when reading. See the output of
for this information; the "recommended" default for SCSI tape devices is set in /var/sysgen/master.d/tpsc. This default blocking factor may be large enough that some non-SGI systems will either not be able to determine the blocking factor automatically when reading the tape, (thus requiring the b option be specified when reading the tape), or in rare cases, to not be able to read the tape at all. In the latter case, the b option with a smaller value must be specified when writing the tape.
A blocking factor of 1 is normally used with standard input and standard output, and 20 for files or devices not supporting the ioctl (such as remote tape). If the tape was written with a blocking factor that does not exceed the limit for that device, the block size is determined automatically when reading a tape for devices with variable block size.
When reading from fixed blocksize devices, tar cannot determine the blocking factor used when the tape was created. This may lead to tar incorrectly deciding that the tape is a multi-volume tape, if the blocking factor when reading is not an integral divisor of the block size used when the tape was written. If this occurs on tapes that you believe are not multi-volume, simply press RETURN at the "change tape" prompt, and tar will complete normally.
The IRIX version of tar is by default POSIX-compliant, allowing up to 255 character long file names, while DOS-TAR is based on the older non-POSIX naming convention with a 100 character file name limit.
So, when writing tapes on IRIX that are to be read with DOS-TAR,
O" option must be used. This is done for you in the
SCSICODE, you can see this is a "medium
error". This can be caused by using improper medium (i.e. tape) in
the drive. Certain types of medium are interchangeable (physically)
between tape drives. However, using non-standard medium on different
brands of tapes drives may or may not work. For example, using:
You may find that you can read and write the non-standard medium with the same brand tape drive but have trouble when going to a different brand drive. Bottom line is to find and use a tape medium that works in all the tape drives you'll be using. Just because it works in one system doesn't mean it is correct.
If you continue to have trouble on the PC side reading (or writing) tar archives to tape, you can try the following debugging approaches:
SCSICODE program from Adaptec is included in
the DOS-TAR distribution.
MT -scommand will tell you about the SCSI tape drive on your PC, similar to the
mt statuscommand in IRIX. Tt will display tape drive information, SCSI driver versions, etc.
SCSICODEwill assist in decoding SCSI errors reported by the various DOS programs when the
DEBUGenvironment variable is set (i.e.
SET DEBUG=1). Here is a typical error output and debug session in DOS:
> SET DEBUG=1
> TAR xvb 20
SCSIRead(10240) <--(Trying to read 10240 = 20*512 bytes)
ASPI status= 4 <--(this is the SCSICODE sense key)
Adapter status= 0 <--(the host adapter has no error)
Target status= 2 <--(this is the SCSICODE error code)
- sense=F0 00 20 00 00 00 14 12 00 00 00 00 00 00
aspiread: errno: -25 <--(ASPI error code is -25)> SCSICODE /e:2 /s:4 Sense Key 4 - Hardware error Error Code 2 - No seek complete
"Use the source, Luke!"
CVto debug it. If you find and fix any bugs in it, please let me know and I'll add the changes to my version.
Now that you've (finally) got DOS-TAR working, here are some tips to extend its usefulness:
PUT.BATto write to the non-rewinding tape device (
/dev/nrtape) and then use a series of call to
PUT.BAT, once for each drive letter.
MT.EXE -p nto position the tape to the desired volume prior to extracting the files.
Instead of physically connecting a tape drive to your PeeCee, why not let the network do the connecting. Here is the Windows version of GNU tar with makes use of the WinSock networking interface to blast archive bits over the wire. In the distribution are full documentation files, but the quick start guide is:
WIN-TAR/BINdirectory on your system and edit
WTAR.INIto suite your needs.
rsh PeeCee "tar cvf - C:/" | dd -bs=10240 of=/dev/tape
This will back up the C: file system on machine PC.
Many PC networking software packages are now including more of the TCP/IP networking tools common on Unix workstations for decades. Among these tools, telnet can be used for workstation <-> PC access for command-line operations. All SGI workstations include a telnet daemon (telnetd) that can accept telnet connections. Many PC networking packages also include such a feature, usually implemented as a Terminate and Stay Resident (TSR) or Dynamic Link Library (DLL). If your PC is so equipped, you'll need a few simple components to make a telnet link:
And to prove it works, here's a screen shot from my Indy workstation connected to my lowly 386 running Sun's PC-NFS Pro. It looks and feels just like MS-DOS.
If you need to connect 2 systems via 10baseT Ethernet (RJ45 connectors) you can make a cable that can be used between the two machines without the need for a network hub. Just follow the pinouts below to reverse the normal cable assignments. Wires not listed here (4 of them) are not used. You can also purchase pre-assembled PC<->PC network cables for under US$10 at computer and electronics stores.
Note: You may need a crimping tool to make the cable, and this is sometimes tricky.
This is the front view of an RJ-45 connector so that you can identify the wire numbers.
If you, like I, frequently switch between systems, making the different machines look and feel alike can be helpful. There are several things you can do to make your SGI workstation behave similar to a PeeCee.
TREEcommand for IRIX.
The X Window System has a very flexible input system. It is based on the concept of 'Window or Keyboard Focus' whereby one (and only one) window on your screen has 'focus', meaning it is receiving keyboard and pointer events. The default means of determining which window has focus is 'implicit', meaning the window that has the cursor inside of its boundaries has focus. The window with focus need not be on top of the window hierarchy, only some small portion must be visible. This is very useful, for example, in a 'cut and paste' operation. You can select some text by dragging the cursor over it in one window and then quickly paste it into another just by moving the cursor over a visible option of the other window and pressing the paste (middle) mouse button.
However, as nice as this focus policy is, in some cases, it may be desirable to adopt a different policy. The 4D Window Manager (4Dwm) offers an 'explicit' keyboard focus policy with a number of options. In explicit mode, you change window focus by some explicit action, such as clicking in the window you wish to receive focus.
When the focus policy is explicit, four resources can be set to True to allow a window to receive keyboard focus automatically at specified times:
|autoKeyFocus||When the window with focus is iconified or unmapped (gives focus to the window that last had it)|
|deiconifyKeyFocus||When the window is iconified|
|raiseKeyFocus||When the window is raised to the top of the stack|
|startupKeyFocus||When the window is mapped|
Table: 4D Window Manager resource options.
Among these, the raiseKeyFocus behavior is interesting to use with certain applications, especially when they make heavy use of dialog boxes. In this manner, whenever a dialog box appears (i.e. it is raised to the top of the stack) it automatically receives keyboard focus. Along with this option, the autoKeyFocus is useful as after the dialog is closed, focus returns to the window that last had it, namely the main application window.
The focus policy must be done on a session-wide basis as it is the window manager (4Dwm in the case of SGI workstations) that enforces the policy. This means that all windows on your workstation display will behave in the same way. The way to change these settings is through the 4D Window Manager's applications defaults file, located at:
The setting that can be changed are:
|*keyboardFocusPolicy:||pointer / explicit|
|*autoKeyFocus:||false / true|
|*deiconifyKeyFocus:||false / true|
|*raiseKeyFocus:||false / true|
|*startupKeyFocus:||false / true|
Table: 4D Window Manager resource settings.
It is recommended that you make a backup copy of this resource file, before changing it. The window manager must be stopped and restarted for any changes made to take effect. This may be accomplished from the ToolChest->System->Restart_Window_Manager menu item.