PC to SGI Connectivity Information

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.

[Top]

Sneaker Net:

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 /floppy (by default).

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:

[Top]

SCSI Tape Tools:

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):

16-bit Version:

Then, you'll need to grab a copy of DOS-TAR which gives your PC the ability to read and write tar tapes that are fully compatible with your SGI workstation. Here's some more information pertaining to DOS-TAR:
As you can see in the distribution, I include some DOS batch files (GET.BAT and 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:
#!/bin/csh -f
# This shell script reads files from a tar file written by DOS-TAR
# You may want to change TAPE to point to /dev/rmt/tps* if needed
setenv TAPE /dev/tape
echo "\nTar reading from tape device $TAPE..."
tar xvpb 20 $*
put:
#!/bin/csh -f
# This shell script writes files to a tar file that can be read by DOS-TAR
# You may want to change TAPE to point to /dev/rmt/tps* if needed
setenv TAPE /dev/tape
echo "\nTar writing to tape device $TAPE..."
# Write archive in non-POSIX format with blocking factor of 20.
tar cvOb 20 $*
Chances are everything will work at this point. You'll most likely want to test out both directions of the tape transfer, the it PC->IRIX and IRIX->PC. Since the IRIX tar is much more flexible and forgiving, it is best to try writing some files on the PC (using PUT.BAT) the try to read them on IRIX with get. If it works, GREAT! Then try writing files on IRIX with put and try to read them on the PC with GET.BAT. If this works, you are done. If not, read on for trouble-shooting tips.

32-bit Version:

All is not lost, there is an excellent commercial package available that has all the features of the above, plus a whole lot more. Go check out the MKS Toolkit demo here. Not only do you get tar and mt, but over 200 other Unix commands and utilities. I've used versions of the MKS Toolkit for nearly 10 years.

DOS-TAR 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:

Background:

What follows is a historical account of the IRIX SCSI tape driver for those interested in the reasoning behind its current complexity.

Back in the early days of IRIX, SGI used to have systems based on the Motorola 68K microprocessor family (IRIS terminals), which is a little-endian machine (meaning the least significant byte of data appears first in memory). Later, SGI switched over the the MIPS microprocessor (4D series) which can be either little- or big-endian (the most significant byte of data is stored first in memory). As most typical Unix systems are big-endian, it was decided to use the big-endian configuration for the MIPS CPU. In order to maintain compatibility between the older and newer systems, which both had 60 and 150 MB QIC tape drives, it was decided to make the 4D SCSI tape drivers capable of swapping bytes to allow reading and writing little-endian tapes for use on the older systems. This was made the default behavior for the QIC tapes.
Later when 8mm, DAT and DLT tapes came along, there was no need for backwards compatibility and the default setting was non-byte swapped. However the byte swapping device (/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 :-)
Anyway, to further complicate matters these newer tape devices allowed for a several newer twists, variable block size (/dev/rmt/tpsXdYv) and hardware compression (/dev/rmt/tpsXdYc). The GNU tar source code base upon which DOS-TAR was built does not support 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.
So where does this all lead? The problem comes about when you use tar with its default device parameter which is either the value of the environment variable TAPE or /dev/tape if that is not specified. The /dev/tape pseudo device is created by the /dev/MAKEDEV script 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.
Read the man-page for tps for more information on specifying tape device options, but for a quick start use the following; things you can change are bold:
/dev/rmt/tpsCdI{nr}{ns}{s}{v}{c}
/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

Byte Swapping:

Symptom:

You write a tar archive on the PC and when reading it on IRIX you get the following error:
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, TAPE, in the get and put shell 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:

Variable Block Size:

DOS-TAR does not support variable block sizes.

Symptom:

You write a tar archive on IRIX and try to read it with DOS-TAR and get the following error:
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
---------------Major--^^^..^^---Minor---
Compare the device major and minor numbers of /dev/tape (144 and 70 respectively in this example) with the same fields for the tps devices. 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/tape is using the tps0d4v device (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 TAPE variable in get and put as follows:
setenv TAPE /dev/rmt/tps0d4
Note: That since tps0d4 and tps0d4ns are the same major and minor numbers they are the same device.

Blocking Factor:

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
mt blksize
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.

POSIX Compliance:

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, the "tar O" option must be used. This is done for you in the

Type of Tape:

Symptom:

You write a tape on IRIX and read it with DOS-TAR and get the following error:
aspiread: errno: -16

Using 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.

ASPI Debugging:

If you continue to have trouble on the PC side reading (or writing) tar archives to tape, you can try the following debugging approaches:

The SCSICODE program from Adaptec is included in the DOS-TAR distribution.

Tips and Tricks

Now that you've (finally) got DOS-TAR working, here are some tips to extend its usefulness:

[Top]

Windows TAR with remote UNIX access:

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:

Run
WTAR.EXE --WAIT
on the PeeCee.
Run:
rsh PeeCee "tar cvf - C:/" | dd -bs=10240 of=/dev/tape
on the Irix system.

This will back up the C: file system on machine PC.

[Top]

Remote PC Access:

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.

[Top]

PC to SGI network cable:

Making a 10baseT cable for use between 2 machines

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.

Crossover Cable schematic

Crossover cable diagram

RJ-45 connector pinout

This is the front view of an RJ-45 connector so that you can identify the wire numbers.

[Top]

Look and Feel:

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.

[Top]

WindowFocus:

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.

Note: This is almost identical to the window focus policy used in the Microsoft Windows graphical user environments.

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:

/usr/lib/X11/app-defaults/4DWm

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.

[Top]

<e-mail the author>
Last updated: 24.AUG.1999