Removable Media Frequently Asked Questions List

By Leon Grossman‎, Claus Boerschig and Bruce Boschek

NEWS AND IMPORTANT NOTES
After; a longer period of silence IBM has released now a driver who supports ATAPI devices like Iomega's ATAPI-ZIP and the LS-120 drive. Together with the NewDasd package it will now allow SCSI and IDE/ATAPI removable media drive users (of all sorts) to gain HPFS removability, speed, and just overall native support for HPFS without requiring special drivers. These drivers will be folded into the base OS at some later date but you can get them now. See also the new ATAPI PAGE for more information.

NewDasd; becomes now older and out: IBM provides a complete support of removable media in the newest FIXPACKS, FP 35 for Warp 3 / Warp LAN Server and FP 6 for Warp 4, respectively. Don't worry about the missing support of optical disks, set simply the wellknown /of parm behind the basedev=os2dasd.dmd statement into your config.sys file and enjoy furthermore on opticals.

There; is now also an official support from IBM for HPFS386 on removable media. It works great !! Special thanks to Sam.

There is a release of new device drivers ( still BETA code) available supporting 1024 and 2048 bytes/sector optical media. A more detailed description will maybe follow into the next revision of this FAQ. Please, send us your experience you made.

Note for PP Zip drive users: You are the only ones left out here (SyQuest has an .ADD driver for their PP drives) but if you can talk Iomega into creating an .ADD driver for your PP drive the new OS2DASD.DMD will support the PP ZIP drive too! I have emailed Iomega on this several times, only to be completely ignored. I emailed them upon learning about the new drivers by IBM and they have ignored me. Let's start an email campaign and make them listen. Read in sections 2 and 3 for more information.

NewDasd is officially available from IBM's OS/2 Device Driver Pak On Line. Furthermore, you find a good collection of removable media support, often directly from the different programmers, and more OS/2 software on our anonymous FTP sites namely
 * in USA: Anyone is interested in providing the FAQ?
 * in Europe: http://rheooptik.fmf.uni-freiburg.de/pub/os2/drivers/removables/00-index.html

There have been a lot of questions about removable media and OS/2 lately. Especially the Zip and EZ drives. Unfortunately, IBM elected not to provide removable drive support in OS/2 Warp v4. This means that you have to find your own drivers for your drive and HPFS was not modified to accommodate removable media. This FAQ is an attempt to answer some of those questions. Note: some of this information was gleaned from the Usenet over a period of months and some of it (some of the Zip drive info) is from my personal experience. I welcome comments, suggestions, techniques, useful hints, corrections, etc. Please send comments to lgrossm@ceatlabs.okstate.edu, clabo@fmf.uni-freiburg.de , Bruce.Boschek@viro.med.uni-giessen.de.

The latest version of this FAQ ( ASCII format) can always be obtained by:
 * Email: to lgrossm@ceatlabs.okstate.edu with "Send me the Zip-FAQ" in the subject line (without the quotes).
 * ftp: by ftp://rheooptik.fmf.uni-freiburg.de/pub/os2/drivers/removables/remove.zip
 * WWW: http://www.txdirect.net/users/teej/remmedia.htm European users can take advantage of our site at http://rheooptik.fmf.uni-freiburg.de/www/faq/remmedia.htm

Should I buy the EZ, the Zip, or some other drive?
To answer this question, you must first decide what you are going to do with your drive. What are your primary concerns? There are several factors which should be considered in your decision:
 * Portability
 * Price
 * Storage capacity
 * Speed
 * Compatibility
 * Data Security


 * Portability: For portability, the Zip is the winner. It is small, lightweight, and durable. Durability is the biggest key to the Zip drive's portability. The media in a Zip disk is flexible and can withstand the shock of being dropped repeatedly. Dropping disks is not something you *want* to do but it happens, especially when you are travelling. Size wise, my parallel port Zip drive fits nicely in the briefcase with my notebook computer. One portability complaint people have voiced is a lack of battery support for this drive. There is now a company which makes a battery pack for this drive. No other drive matches the Zip in portability. The EZ is the closest thing to the Zip but it is heavier, bulkier, and much more fragile.
 * Price: The EZ drive has now been discontinued, leaving the Zip drive as the only alternative under $200. Hopefully, Iomega will keep the price under $150 for their drives.
 * Storage Capacity: If the capacity is your driving force and you have the money to spend, one of the large capacity optical drives would be a good choice. Perhaps a PD drive would be a good price/capacity compromise. Cartridges for this drive can be purchased for ~$50 for a 650MB cartridge ($0.07/MB). For me, the price was the deciding factor. If I could have afforded one of the larger MO drives, I wouldn't have even considered a Zip drive.
 * Speed: This is probably the Zip drives biggest weakness. It is advertised as being as fast as a hard drive but in most cases it is too slow to be used as one. Here is where Syquest's drives shine. They have fast access times (approximately half that of the Zip drive) and has transfer rates at least twice that of the Zip drive (numbers anyone?). The speed is due to Syquest using a rigid disk in their cartridges instead of a flexible one like Iomega used. Iomega has achieved 10ms access times and 3MB/s transfer rates for the JAZ, making it a nice performer.
 * Compatibility: The Zip drive has the upper hand here. It was out for months and had the chance to become a pseudo standard before the EZ hit the shelf. Essentially, you are more likely to find someone else who has a Zip drive than you are to find someone with an EZ or other drive. The Zip disks are easier to find, as well. I can buy Zip disks at Wal-Mart here if I'm desperate. The EZ isn't quite so pervasive. Unless you are very lucky, any other drive is going to be relegated to mail order for cartridge purchases.
 * Data Security: The true nature of removable media is such that the cartridges are removed, transported, and ultimately read on different drives. The questions arise: How safe is the construction of the cartridge? How will it react to shocks and vibrations. How sensitive is it to any changes in temperature, light and dust? How reliable are the corresponding drives? How well do the cartridges and the drives work together?

A comparison of the Iomega ZIP 100 and SyQuest 3270 Types quickly shows the differences: The ZIP disk is enclosed in a massive and relatively robust diskette. The corresponding drive is built on the Bernoulli principle so that dreaded head crashes are not possible and the data on the medium is therefore relatively safe. The media are small and easily transportable. The SyQuest is of a bulky, semitransparent design which to begin with would not fit in anyone's pocket (which certainly would not be advisable in any case since doing so would assure the creation of defective sectors!!). The drive functions in an analogous manner to a hard disk so that it is by nature sensitive to shock and vibration during use. From my own experience I can say that a SyQuest is not suitable for long-term storage of important data because of an unusually high rate of defects in both, the drives and the cartridges. As a result of large construction tolerances there is also a high degree of incompatibility between drives and new cartridges. If one should come up with the idea of reading cartridges with different drives one will certainly be rewarded by numerous unreadable sectors.

I have experienced 4 MB defective sectors on disks of 250 MB total capacity. This applies to all drives of the type 3270. I do not know to what extent this relates to the EZ, but caution seems to be advisable. The only advantage of these drives is their higher performance.If, however, you need this you should consider the JAZ and forget SyQuest.


 * A quick summary is: If you need durability, portability, and compatibility then the Zip is a safe choice. If you need speed and price, the EZ is a good choice. If you need raw storage power, speed and capacity try the IOMEGA JAZ or go somewhere else.

Should I buy the SCSI or the Parallel Port version?
This one is easy. If you need portability between machines then you need to get the parallel port version, unless all of the computers you work with use SCSI. If you need speed, the SCSI or IDE version will be faster in most cases. Under OS/2, SCSI devices are well supported and there are many options for drivers. Parallel port drives are at the mercy of the drive manufacturer. In the case of the Zip drive, the difference in speed between a Zip hooked up to an enhanced parallel port and one hooked up to SCSI or IDE is not that great. Accessing my parallel port Zip drive on my P5-100 "eats up" all of the CPU power,though. My 486 with the SCSI Zip drive only uses about 50% of the CPU while accessing the drive and I expect the same from an IDE drive. EZ users will quickly find out that many of the speed benefits of their drives are cancelled out by the speed limitations of the parallel port. If you intend to buy an EZ drive, you should really buy the SCSI version if you want to use it to its full potential.

Introduction
The easiest way to use a removable drive for HPFS is to install it as "non removable" that is as a hard disk. This does not require the use of a special driver. The only requirement for SCSI drives is that the SCSI host adapter provides "IntH13" support for removable drives. This is provided by some but not all adapters. In order to access the drive one only need replace the native SCSI driver with the ibmint13.i13 driver that is included with OS/2. Since the removable drive is used as a hard disk HPFS can be used without any problem. This holds as long as the disk is not removed and to be on the safe side it is better not to even try to remove the it. An unpleasant side effect of this method is that by using the i13 driver only BIOS-supported devices can be accessed. Any CD-ROMs or scanners that are attached to the system are thus lost. In addition, the advantages of the SCSI bus are also lost! Examples of host adapters that provide i13 support are all NCR810, Adaptec (Ctrl-A for SCSI-adapter setup and "Support removable drives as fixed disk=on") and Tekram. Future domain adapters do not provide i13 support and this method will therefore not work with this brand.

The principle is the same for support of IDE drives. After registering the drive parameters with the BIOS the drive appears as a hard disk and can be accessed using the ibm1s506.add driver. Both methods are quite simple but it is important to note that exchanging of media is not supported since an attempt to remove the media results in a controller error. New media will then not be seen by OS/2 and the system will need to be restarted in order to access the drive.

OS/2 is very divided in its treatment of removable devices. Real Hard disks identify themselves as Device-Type 00 during the SCSI bus initialization. Removable drives identify themselves always differently, according to the fundamental technology upon which they are based. If OS/2 recognizes now a drive as removable ( and in addition to the type bit, there is a 2nd bit for removable or not ) then only the "superfloppy" mode is available, which rules out using partition table, caching or HPFS unless special drivers permit it. Iomega's OAD drivers are a good example of this. Hard disks, on the other hand, are partitioned and cached. Here again, the same limitations apply to the IDE bus; if a drive is not registered in the BIOS and is managed by a driver as an ATAPI device, only the superfloppy mode is possible since OS/2 knows the real nature of the device.

Parallel-port devices present a similar situation. A driver is used to control the device and registers it with the OS/2 DASD manager. If the driver indicates that the drive is a removable device, only super-floppy mode can be used. It must be noted that the driver is manufacturer specific, not generic. If a driver is not available for a parallel-port device it cannot be presently used with OS/2, a limitation that quickly reduces the attractiveness of this type of drive.

The superfloppy technique is basically a catastrophe for the OS/2 user. On the one hand, caching (independent of file system used) and HPFS are ruled out, making removable drives painfully slow. The worst part is the loss of the DOS compatibility, however, since DOS does not recognize unpartitioned superfloppies without special drivers that are as good as unavailable. This has forced OS/2 users to search for and find some interesting alternative solutions to these problems and finally in IBM reacting by publishing a new solution for support of removable devices.

How to format removable disks as HPFS and HPFS386
One of the worst properties that OS/2 inherited from IBM is the totally in-adequate support of removable media. As a consequence it was necessary to find solutions that side-step this weakness. HPFS was once created as an alternative to the DOS file system FAT. It was designed to provide fast and efficient access and excellent security for data. In addition to allowing use of long file names and maintaining large or small case it allows direct attachment of the extended attributes used under OS/2. What is more, HPFS was designed for use with large-capacity storage systems which makes it optimal for present-day dimensions. However, the use of HPFS demands a partitioned medium. This alone is the reason that floppy disks cannot be formatted with HPFS. Since a "superfloppy" also can not be partitioned, and partitioned removable drives are not supported, use of HPFS is not possible with removable drives as long as only standard OS/2 on-board support is used. In principle, however, there is no reason that HPFS cannot be used with removable media of high capacity available today. HPFS was conceived for hard disks. When the system starts, the IFS driver opens the file system (dirty bit) and very efficiently manages it with the help of an integrated cache. At shutdown the cache is emptied and the file system is placed into a logically consistent state. Finally, the dirty bit is deleted. If the system finds this bit on startup it assumes that the system crashed and the file system is checked for logical consistency by the CHKDSK program.

Implementation of HPFS on removable drives must take this technical require ment into consideration. Before every shutdown the file system must be properly closed so that access is possible after remounting. This would take place during a normal shutdown, however the medium could not be changed while the system is still running, i.e. without shutdown and restarting. To deal with this problem, a number of "flush tools" have been developed that force a "local" shutdown of a drive by use of elementary system calls. These tools are implemented on a purely logical level and are applications. The most prominent is without a doubt HPFSRem from Jeff Jackowski which will be described in detail later. All that remains is the question of how to coerce OS/2 into accepting HPFS on removable devices. This is not trivial because, as noted above, a partitioned medium is prerequisite. Also as mentioned above, the individual devices identify themselves with a typical device number on the bus during startup. This number is then transmitted by the device driver and presented to the central OS2DASD.DMD, which in turn decides upon how the drive is to be treated thereafter.

The same can be said for HPFS386, the file system included in Warp LAN Server Advanced. Additionally to 'simple' HPFS it supports a greater cache, file- and directory owners and DASD limits (='Quota'). The problem has always been to exchange a HPFS/HPFS386 formatted media on the fly. The IFS driver allowed to eject a media but refused, due to a bug, to remount a new one. As a result no access on the new media was possible without reboot. It worked only successful with FAT formatted media in the past. According to IBM, this horrible bug is now fixed in ip_8508 for Warp Server as I could still test with an early Alpha version. Note: If the local security function is installed, you must have administrator privileges to eject and remount successfully any HPFS386 formatted removable media. Normal users are not allowed to change anything on the drives configuration.

The simplest way to deal with this is to deceive OS2DASD.DMD about the true nature of the device and instead of presenting the correct drive type just register an additional hard drive. By this misrepresentation of the device type the removable drive is now accepted as a hard disk and can,and in fact *MUST* be partitioned. In order to change the disk it is only necessary to use one of the flush tools which represents nothing more or less than removing the storage medium "behind the back" of the running operating system.

Yet another possibility is to patch the OS2DASD manager, changing the rules of the game by which the OS deals with removable devices. This is much more complicated, but if it can be achieved, it provides a very attractive and practical solution to the problem. Of course, the two methods shown can be combined,still resulting in an uncomplicated software with a high degree of operational security.

The main reason for updating the FAQ-list so soon again is the result of a sudden and unexpected "enlightenment" on the part of IBM in regard to the need for a revised DASD management. Shortly after the last revision of this FAQ-list on 25/26 October we received an alpha version of a new driver packager for removable devices from IBM. Since we were given adequate time to test this package - and for that we would like to express our gratitude to IBM here - we can provide a description of its most important features and help spread word about it around the OS/2 community. We want to note that this DASD manager will be an integral part of future OS/2 versions (not, however, Version 4 "Merlin"). When that finally takes place, the problems with removable media will finally be swept away, making this FAQ-list, for the most part, a thing of the past.

The core of the package is a new DASD manager that manages removable media using new rules. Instead of limiting removable drives to the role of super floppies it now allows partitioning and HPFS formatting. The drives are locked at boot up and, regardless of whether the disk has been partitioned as primary or extended/logical, it is always assigned a drive letter after the last hard drive. Changing media that have different partition sizes and changing from primary to extended/logical partitioned disks is possible without problem. Thus, the potential partitioning headaches that are always a possibility with "device deceivers" are ruled out from the beginning. It is amusing to observe the way FDISK sees these devices, namely with drive letters assigned according to the old rules. This is, however, only an artefact in FDISK and has no practical consequences. This effect shows the way the operating system is being fooled and what is possible with this type of deception, if only one is willing to make the effort.

To change HPFS formatted media, it is always necessary to perform a LOCAL shutdown of the file system. On the command line level this is performed by a flusher that closes the file system, unlocks the drive and even ejects the disk. On the level of the WPS, this function has been integrated into a DLL so that only a secondary (right) mouse click and selection of "Eject disk" is required (In all seriousness, friends!). All that remains is to note that it works perfectly and to ask why this took so long to achieve (Hello, IBM?). Since we only had an alpha version of the software we cannot yet report on the installation instructions. I can only say that I slept well the night after installing the package. A notable feature is the possibility of inserting a medium AFTER booting, thereby alleviating the need to remember to have a medium in the drive before boot up. It should, however, be noted that some drivers and SCSI BIOSes do not handle the absence of media in the drive at boot up well. OS2CAM.ADD traps and ADAPTEC pauses interminably before continuing so that it is certainly advisable to have a disk at hand.

An; important note for users of optical disk drives: In the past, only disks with 512 bytes per sector have been supported. There is now a new device driver package who allows to format media with 1024 and 2048 bytes/sector HPFS. The media are exchangeable on the fly. In combination with NewDasd, even Media of different partition size and different sector size can be exchanged. Drivers such as OPTICAL.SYS and OPTICAL.DMD are now completely unnecessary and must be removed before installation of the new IBM package. Optical disks can also be partitioned and HPFS formatted. Superfloppy mode is still possible (by use of a switch after the OS2DASD.DMD statement in the Config.Sys); however, use of these drives as super floppies can only be recommended for use in saving data from previously floppy formatted disks before partitioning and reformatting for use in the new mode. This change over and the inherent copying of large amounts of data requires some effort, however it is well worth the effort since it offers much greater flexibility, DOS compatibility or the inherent advantages of HPFS.

The following is a (partly historical) review of known methods for the use of removable media under OS/2, according to device and bus type. I would like to note here that much of this information is now out of date as a result of the new driver package from IBM. It may still be of use, however, in order to allow comparisons to be made of the various options available and for an occasional practical solution in borderline and exceptional cases.

Presentation and discussion of general methods
For the user, practical questions immediately arise: Which possibilities are there for the use of removable devices under OS/2, what are the resulting requirements and, most importantly, what are the limitations that I will have to live with? Following is a list of all of the solutions and methods that are known to the authors together with their advantages and disadvantages.

IBMINT13.I13 Driver
The simplest route is to take advantage of the i13 support by the host-adapter BIOS if available,and installation of the ibmint13.i13 driver. The removable disk is thereby irreversibly bound to the system as a hard disk. In spite of the use of flush tools, trying to change media is destined to failure since it will in general result in a bus error that can only be corrected by shutting down and restarting the system. (As the exception that proves the rule,I have succeeded in changing disks with NCR adapters, but not with any others.) This route is always available if a native SCSI driver does not exist for the adapter being used. This way should, under normal circumstances, be only considered of historical interest, particularly in light of the inherent disadvantages; CD-ROMs, scanners, tape drives etc. attached to the SCSI host are no longer accessible, and the SCSI host adapter MUST support i13 for the removable media. There may be specialized applications in which it might find use but it cannot be considered.
 * Requirements: The driver IBMINT13.I13 (included in OS/2), i13 BIOS
 * Supported Drives: Any SCSI drive.

LOCKDRV.FLT
A number of years ago IBM introduced the driver LOCKDRV.FLT which still serves as the foundation for all other drivers. This "filter-driver" is an example of a typical "device-twister" that misrepresents a removable drive as a hard drive to the DASD Manager. As the name implies, however, the drive is locked at startup, preventing disk change during operation. To circumvent this problem Jeff Jackowski wrote a utility, HPFSRem, that performs a local shutdown on the removable drive and then sends to it a lock / unlock command. In some cases this works and so it is possible to remove the media however in many instances the drive does not accept the unlock command and a change cannot be performed. Especially older devices may not accept the unlock request, because an industry standard does not seem to exist. This solution cannot really be recommended because it is too much a matter of luck whether or not it will work.
 * Requirements:
 * lockdrv.zip (LockDrive filter from IBM/Adaptec)
 * HPFSRem.zip (Flush and Lock/Unlock tool)
 * emxdll09.zip necessary DLL files for HPFSRem
 * Supported Drives: Most newer SCSI Drives

Syquest-hpfs.zip
Another possibility is the free package "syquest-hpfs.zip". In addition to detailed installation instructions, this package also contains an "flt" driver and a flush utility. This driver also deceives OS2DASD about the true nature of the removable device, emulating a hard drive. The ejection button is, however, not locked so that, after flushing, the medium can be replaced. An advantage of this package is its almost universal applicability since any device that even smells like a removable drive is supported. Tests have shown that removable magnetic disks, magneto-optical devices (MODs) and even PD combination drives can be HPFS formatted and the disks changed in "mid-stream," i.e. without shutting down and restarting.

A prerequisite for use of this system is a correctly installed SCSI device. In addition, a native OS/2 SCSI driver must be loaded since the flt driver slips in between this and the OS2DASD. In principle, the driver works with all SCSI adapters. I only know of one problem case and this could easily be remedied by a long-overdue device driver update. Although this system otherwise has so many advantages, one important thing must be noted: The driver emulates a hard disk and therefore the removable disks MUST be partitioned. Disks can only be exchanged if both are identically partitioned, i.e. have the same geometry. If partitioning is changed, it is quite necessary to shut down and reboot. Another word of warning: OS/2 is often installed in extended partitions. If this is the case and a removable disk that contains a primary partition is inserted, the computer will not boot (...can not find country.sys...) because the drive letters are shifted. The only solution is to delete the primary partition on the removable disk and repartition as extended/logical.This problem accounts for the majority of boot failures.

For preparation of the first repartitioned media, a properly prepared boot disk, i.e. with installed flt driver, is required for deleting the primary partition on the removable media then and creating an extended and logical partitions. Alternatively, a so-called low level format of the media can be performed which checks also the surface for defective sectors at the same time. Warning: All data will be lost when partitioning and formatting operations are performed!
 * Requirements: syquest-hpfs.zip (generic SCSI driver for removable media)
 * Supported Drives: All SCSI drives with 512 bytes/sector

Iomega device drivers
These drivers are discussed above in regard to the topic ZIP Drives. In my eyes these drivers are unusable, an opinion that is supported by the many e-mails I have received. From my own experience I must say that even the DOS drivers are catastrophic and so I recommend to find a different, better working combination. Regarding Iomega, one can only say "Good hardware but bad drivers that are only useable with Iomega hardware." A good description is given in the next chapter.
 * Requirements:
 * iomega234.zip orig. IOMEGA drivers (includes OAD driver)
 * HPFSRem.zip (Flush and Lock/Unlock tool)
 * emxdll09.zip necessary DLL files for HPFSRem
 * Supported Drives: All Iomega removable drives. SCSI and PP devices.

SyQuest device drivers
These represent currently the best drivers available for removable media. An "flt" device driver and a patched OS2DASD.DMD file are installed that together completely change the rules of the game on the system level. HPFS can be applied to removable media. Exchanging media works without a hitch. Even dissimilarly partitioned media can be exchanged. The SyQuest package itself only supports exchange of FAT formatted media, however, HPFSRem can be used to exchange HPFS-formatted media and even the Lock/Unlock feature can be taken advantage of since the SyQuest driver provides excellent support for the HPFSRem tool. Worth mentioning is the possibility to unlock the drive by a right mouse-button click on the drive icon. My own experiments show that these drivers also support Iomega's ZIP drive. In all likelihood, the Jaz, or more accurately all magnetic removable devices, will probably be useable. According to B. Boschek, tests with MODs and this system were not successful, which is not surprising since this is a completely different type of device. For all these drives it will be necessary to return to the syquest-hpfs.zip package.
 * Requirement:
 * os2s349.zip SyQuest SCSI device drivers v3.49
 * HPFSRem.zip (Flush and Lock/Unlock tool)
 * hpfspm12.zip PM-GUI for the HPFSRem tool
 * emxdll09.zip necessary DLL files for HPFSRem
 * Supported Drives: Syquest drives, Some SCSI Iomega drives, Other magnetic media removable drives.

The (new) IBM driver package
Only a quick description is necessary. After replacing the original OS2DASD.DMD with the new file of the same name, copying a few files and DELETING all references to device-deceiving drivers used in the past, after rebooting the removable devices is directly available. The only requirement is a correctly installed device driver. Anyone with experience using CD-ROM drives under OS/2 is familiar with the use of the secondary (right) mouse button. Nothing more really needs to be said about this, except perhaps to note that the WPS now copies rather than moving objects as it did with syquest-hpfs.zip, showing that OS/2 is quite familiar with this device type.
 * Requirement: newdasd.zip The new IBM driver package
 * Supported drives: Any drive that has an .ADD driver for it. IDE drives, SCSI drives, some (SyQuest) parallel port devices

IDE and ATAPI Drives
ATAPI is an enhancement (a set of additional commands) of the IDE interface. It is more useful to realize removable devices as ATAPI devices, so the known problems with the BIOS can be avoided. The first drives who appeared on the market were the Iomega ATAPI-ZIP and the LS-120 drive. To have access on these drives you NEED a special driver (There is no way without!). As ATAPI becomes a new de facto standard now, we created a new ATAPI PAGE which is easier to maintain and which will be updated regulary. At present I am only away of 2 operational modes for IDE drives; the first is registering the device with the system BIOS and addressing it as a hard disk. This way is not particularly attractive.

Alternatively, the SyQuest IDE drivers bring some light into this otherwise gloomy area. By use of a patched ibm1s506.add and os2dasd.dmd, the SyQuests IDE drivers provide excellent service. I have not tried IDE ZIP drives. In spite of all its advantages, the driver has a bug that SyQuest needs to quickly take care of. Any other ATAPI devices, such as a CD-ROMs, are lost to the operating system when the driver is installed.


 * Requirements:
 * os2i350.zip SyQuest IDE device drivers v3.50
 * HPFSRem.zip (Flush and Lock/Unlock tool)
 * hpfspm12.zip PM-GUI for the HPFSRem tool
 * emxdll09.zip necessary DLL files for HPFSRem

Supported Drives: IDE drives, drivers seem to be generic.

The new IBM drivers
We recently learned from IBM that they are working on a new version of the general device driver for the IDE bus, ibm1s506.add and that it will be included in the final release of the driver package.

I personally imagine that this new driver will be similar to the SyQuest package,with a fix for the ATAPI bug. The error that is registered by the IDE-BUS when the medium is changed will be handled by the driver so that a new medium can be inserted without problem. Together with the new OS/2 DASD this should result in simple and safe handling for the user. In regard to the IDE bus in general I would like here to make a personal remark: IDE is very CPU intensive and poses a serious obstacle to all multi-tasking systems. Anyone facing a decision about what to buy should chose SCSI since it is the more "intelligent" bus system and does not put as nearly as much stress on the CPU as does IDE. As most of us are aware of, whatever saves wear and tear on the CPU saves ware and tear on the nerves of the user. What is more, SCSI can be set up without a great deal of fumbling around whereas IDE can result in a lot of gray hair...


 * Requirement:
 * newdasd.zip The new IBM driver package
 * removdsk.zip The new IBM ATAPI Enhancement

Supported Drives: All IDE and ATAPI removable drives

Parallel-Port Drives
I have no personal experience with these devices. HPFS formatting will probably be impossible, or at least will rule out changing disks without rebooting. This technology is not advisable for OS/2. A portable SCSI adapter and SCSI driver are certainly better alternatives.

For the sake of completeness, the SyQuest parallel port drivers as well as those from Iomega should be mentioned. The device drivers are not generic. [Leon's note: HPFS is supported for the Iomega Zip PP drive and works quite well with HPFSRem.]


 * Requirements:
 * os2p349.zip SyQuest PPort device drivers v3.49
 * iomega234.zip orig. IOMEGA drivers (includes OAD driver)
 * HPFSRem.zip (Flush and Lock/Unlock tool)
 * hpfspm12.zip PM-GUI for the HPFSRem tool
 * emxdll09.zip necessary DLL files for HPFSRem
 * Supported Drives: EZ, Zip, any PP drive that has specific PP drivers.

From the above description it is evident that there is quite a selection of methods for use of removable drives under OS/2. The user will certainly achieve the best results with SCSI devices because support is by far the best for this equipment. Without a doubt, the best solution for removable devices is the new IBM driver package. Alternatively, the syquest-hpfs.zip package can be used, although it is somewhat limited by the requirement for identically partitioned drives when exchanging the media. At the same time, this system offers considerable flexibility, supporting every available SCSI removable device as a hard disk. Still an important note at this point: The question was already raised as to the possibility of exchanging the flushing executable files into the different packages. I want to warn against this! Using syquest.exe or iomega.exe from the syquest-hpfs.zip package with the IBM drivers leads down a blind alley since these flushers do not even attempt to unlock the drive. The flush is carried out but the drive remains locked. Conversely, trying to use HPFSRem.exe or eject.exe with syquest.flt results in sending a lock/unlock command to the drive, but since the driver does not support this command it returns an error message and the flush is not carried out (...could not prepare disk for removal..). It would be most unfortunate if this message was to go unnoticed (!) and the eject button pressed anyway...

Flushers and drivers must be conform to one another and support each others function. Flushing is, however, a function that is independent of the file system used. FAT formatted media, now equally cached by the system, must principally also be flushed before the medium is removed, although failure to do so does not result in such dramatic consequences, would occur with HPFS formatted media. HPFSRem and eject.exe include an integrated lock/unlock function and can replace each another. which however only works if the driver below it supports this call. The nature of this call is, in fact, not dependent upon the currently formatted file system.

Support of multiple devices and the use of CheckDisk after a crash.
As soon as a device is installed and functioning properly, one quickly begins to wish for support and use of multiple devices of different types. The drivers themselves are easily capable of this. A ZipDrive and SyQuest drive can coexist with the syquest-hpfs.zip package as well as with the original SyQuest drivers or the IBM package. Mixing drivers, on the other hand,is critical as they tend to interfere with one another. The IBM package will be considered in all circumstances because it provides the best support available at this time.

Alternatively, If only magnetic media are being used and the IBM drivers are not available I would recommend the SyQuest drivers. If magneto-optical devices are added, syquest-hpfs is a good choice. When multiple devices are used, a leveling effect becomes apparent, A SyQuest and a ZIP drive/media relate to one another at a ratio of 2.5:1, i.e. 2.5x larger and 2.5x faster.That is the only difference visibly for the user. Manufacturer-specific drivers are often the cause of problems,whereby special functions such as password protection,etc. as well as all of the pretty icons of the various window(s) managers unfortunately become unusable since one was forced to turn to a generic driver.

In cases of installation problems it is important to determine whether there is competition between different drivers. All base drivers presented here are installed via BASEDEV statements in the config.sys. It is well known that all BASEDEV assignments are carried out before CHKDSK is initiated,so that any removable drive will be checked after a system crash. It is therefore important that the hpfs.ifs autocheck statement in the config.sys be appended to include the removable drives. The fact that device drivers are loaded after CHKDSK has run applies, as been reported, to Iomegas drivers but neither to the SyQuest original driver package nor to syquest-hpfs.zip or even the IBM package.

Note: Such a masked removable media can be used as swapdisk or to store the OS/2 INI files. But in these cases all removability will be definitively lost!!

Booting from Removable Drives
By being a little sly it is even possible to boot from removable devices. To achieve this, however, i13 support on the part of the SCSI BIOS and a pre-installed OS/2 Boot Manager are required!! It is then necessary to make the removable disk bootable. One way to achieve this is to first copy SYSINSTX from the first OS/2 diskette to \OS2 and then to run this utility. After that the complete contents of the boot partition are copied (xcopy /h/t/r/s/e/v) to the removable disk.

Hint: This is best accomplished from a boot diskette or service partition to avoid problems with locked .DLLs.

After this is finished all that remains is to correct the paths in the config.sys. After adding the drive to the Boot Manager as a startable partition it should now be possible to boot from the drive. Alternatively, it is possible to carry out a new installation on the removable disk, or one can use the elegant EWS program BOOTOS2.EXE.If you want to boot from a removable disk, it is important that the system does not get "wind" of the true nature of the drive.

I have successfully booted using ibmint13.i13, syquest.flt and lockdrv.flt as well as the IDE ibm1s506.add driver with an IDE SyQuest device. This is possible because these drivers emulate hard disks. Attempting to use any other drivers will probably cause problems and end in a system crash. In any case it should be evident to note that the disk from which the system booted cannot be removed or exchanged, even if the drive is not locked.

Note: It is NOT possible to boot from removable media using the new IBM driver package. OS/2 knows in this case the true nature of the device and it refuses generally to be booted from removable media. It is necessary to mask the drive by use of a "device twister" like the syquest.flt filter driver.

This driver is the best choice of all because a second removable device can be changed when booted from the first as I tried out successfully. Booting from removable devices can spare a service partition on a built-in hard disk. In case there are more than one computer this effect is evident.

Questions
The information formerly available here about HPOFS and drawbacks to HPFS can be found on a separated page now.

Where can I get the drivers and utilities?
ALL of the device drivers described above can be found on the usual FTP servers as well as on the European FTP site rheooptik.fmf.uni-freiburg.de or the American FTP site ladybug.cheng.okstate.edu. Choose the faster connection for download. The new IBM driver package can also be obtained from IBM's servers.

Obtaining the drivers
The latest drivers for the Iomega drives can be obtained from the Iomega web site at http://www.Iomega.com. Alternatively there is a copy of the drivers on the Device Driver CD-Rom that comes with OS/2 Warp v4. I have to complain about Iomega here. They have a 100MB disk to put drivers on and they couldn't manage to put two floppy disks worth of data on the drive. Instead they want you to pay an outrageous amount of money to have the OS/2 drivers sent to you on floppy disks.

If you have a SCSI Zip drive, don't even bother downloading these drivers. IBM has released much better support for these drives (see 3.2.3). If you have a PP Zip drive, you will still have to download the Iomega drivers but you will want to pester Iomega into writing an .ADD driver for their PPA3 SCSI adapter (the one built into the PP Zip) because then you could use the new IBM removability drivers as well.

Choosing between the .FLT and OAD drivers
Iomega didn't make things simple for those of us with Zip drives. They originally only provided the OAD drivers which only worked with Iomega SCSI adapters and the Parallel Port version of the Zip drive. Everybody else was relegated to using the SCSI drivers for their SCSI card and treating their Zip disks as large floppy disks. Needless to say, the large floppy treatment was unbearably slow. So much so that I purchased a Zip Zoom card as soon as I could. Iomega made an attempt to rectify the situation by releasing the .FLT drivers. Both drivers badly in need of an update and are obsolete now that IBM has released the NEWDASD.EXE driver package. Unfortunately, the OAD drivers are still needed for the PP Zip drive users, until we can find someone who is willing to hold an Iomega developer hostage long enough to develop an .ADD driver for the PPA3 adapter.

The OAD drivers
These drivers only work for Iomega SCSI adapters and the Parallel Port version of the Zip drive. If I am not mistaken, an Iomega SCSI adapter includes the Adaptec 1502 SCSI card (which is what Iomega sells as the Zip Zoom SCSI card) and maybe the Adaptec 1522 SCSI card.


 * Advantages:
 * Fast without requiring the disk to be locked into the drive as a fixed disk.
 * Compatible with the format that the disks come with from the factory.
 * I, personally, have experience using these drivers with HPFS so I know it works.


 * Currently the only option for PP drive users.


 * Disadvantages:
 * Doesn't work with non-Iomega SCSI adapters.
 * Only allows one device to be attached to your SCSI adapter.
 * There have been reports of problems copying files that have large EAs and these drivers. I have not experienced this problem so I can't verify it's existence. (Anybody like to provide details?)
 * Drivers must be placed in a subdirectory named x:\oad on the boot drive.
 * Needs HPFSRem to gain HPFS removability support.

The .FLT drivers
There is no longer any reason to use these drivers unless you need to use the protect utility to password protect your disks. Iomega is supposed to be writing code to make protect work with the NEWDASD drivers.

Advantages:
 * Works with any OS/2 supported SCSI card.
 * Allows you to use multiple SCSI devices on your SCSI card.
 * Compatible with the format that the disks come with from the factory (in non-fixed mode).

Disadvantages:
 * Slow, unless you use fixed mode.
 * Fixed mode must be partitioned and, as such, all cartridges must be partitioned and will no longer work with DOS, Windows, or OS/2 not running with fixed mode drivers (See section two for problems with changing drive letters).
 * In fixed mode, disks have to be unmounted and remounted using a utility before they can be ejected and after they have been reinserted.
 * Needs HPFSRem to gain HPFS removability support.

IBM's (new) drivers
These are the drivers that removable media drives have been waiting for. They work with almost any drive, can handle HPFS removability, etc... All you have to do is download the drivers. They are available on my FTP server as well as on the IBM device driver pack online.

Advantages:
 * Extremely fast
 * Works with any OS/2 supported SCSI card
 * Allows you to use multiple SCSI devices on your SCSI card
 * Compatible with the Zip disk factory format
 * Future versions of the OS will have this support natively
 * No extra utility required to have removable HPFS support
 * Works with the Jaz drive
 * Primary partitions are placed at the end of the drive chain (no more changing drive letters resulting in inability to boot)
 * No more superfloppy... ever

Disadvantages:
 * Doesn't currently work with Iomega's protect utility

Why is my Zip Drive so slow?
There are two reasons your zip drive might be slow:

With a Parallel Port drive using the OAD drivers.
The OAD driver defaults to nibble mode for compatibility with the largest number of parallel ports. If you have an enhanced parallel port, you can speed up your zip drive by adding the following to the os2.sys driver in your config.sys. This does not work with all chipsets. See the OADMAN for more information. Apparently I was wrong with the previous statement. I finally did some testing of my PP zip drive and no amount of playing with switches changes anything. I am now under the impression that the drivers autodetect your PP and set themselves to the highest speed. In any case, I was wrong with the location of the switches. You add the switches using the genoad utility to "modify adapter data". The manuals were very unclear on this but it doesn't appear to matter anyway. You are welcome to try if you think it would help.

Essentially the answer to this question is: Because you are using a slow parallel port. (My enhanced PP only gets .26MB/s as apposed to the .56MB/s for my SCSI zip drive.) Those of you without enhanced PP are in really bad shape. Perhaps setting the /IRQ switch on print0x.sys will speed things up and lower the CPU load? (I'd like to hear experiences on this.)

With the .FLT driver or no driver other than the driver for your specific SCSI card.
Floppy disks are not cached under OS/2 and if you are not using the .FLT drivers in fixed mode or you are not using the .FLT drivers you will experience some of the most agonizing file operations of your entire life with your Zip drive. This is due to OS/2's treatment of removable media as large floppy disks. [It's also due to the fact that OS/2's FAT implementation was designed for stability at the expense of speed; and that shows up very clearly with Zip drives. (It also shows up on floppies, but one *rarely* copies as much data to a floppy as to a Zip drive.)] When not in fixed mode the only thing the .FLT drivers do is allow you to read factory formatted cartridges. Significant speed improvements can be made by adding the /fixed option to the .FLT driver line in your config.sys (see the online manual for specifics on syntax. I don't use these drivers so I'll be happy to hear info on this) Adding the fixed parameter should bring the speed of your Zip drive up to comparable performance with a drive using the OAD drivers.

Now that IBM has released the new OS2DASD, there is no reason to use the Iomega .FLT drivers unless you use the protect utility.

The portion in brackets was written by Brandon S. Allbery.

Will the IDE Zip Drive work with OS/2?
In a word, yes. The drive will be automatically recognized by the new IBM1S506.ADD driver (part of NEWDASD.EXE) which is available on the IBM device driver pack online. You will even get HPFS removability support.

Can I format my Zip cartridge as HPFS
- (See Section 2) In a word, yes. All that is required is the ability to lock the disk into the drive. Various drivers have different ways of doing this. The methods are all rather simple and relatively intuitive. If the drive won't let you format as HPFS, try locking the drive into place (can be done from the drives object).

Why can't I format my Jaz drive as HPFS?
Iomega's drivers don't work properly for this drive. Fortunately, syquest-hpfs and the new OS2DASD.DMD from IBM work with this drive. See sections 2 and 3.2 for more information.

Introduction
The removable-media market was long dominated by Syquest, the company to first develop useable removable-disk systems. The 44 and 88 MB disks deserve special mention since they quickly became a standard, particularly among DTP users. The 3270 drive with 270 MB capacity followed and quickly became a hit as a result of their increased capacity and high speed. Due to enormous technical problems that SyQuest openly admitted, the EZ-Flyer generation with 200 and 230 MB and an improved 3270 series were manufactured. To gain presence in the important sector of extremely large capacities, SyQuest has now announced the forthcoming SyJet drive with 1.3 GB capacity. By the time this part of the FAQ becomes available the SyJet should be on the market. For the sake of thoroughness, it must be mentioned that the Iomega Jaz is already available, very popular and presents considerable competition for the SyJet drive.

Technical Information
All SyQuest drives are based on the same technology as hard disks, namely a ferromagnetic platter rotating at high speed. The read and write head floats at a very small distance (a few microns) above the spinning platter. As a result of the high rotational speed, an air cushion builds up which serves to prevent physical contact between the head and the platter. If, as a result of a malfunction, the head does touch the medium it is referred to as a head crash which may completely destroy the head and in any case renders the medium unusable at that point. The very small separation between head and medium allows for close spacing of the lanes and therefore a large capacity in small physical dimensions. In addition, this principle guarantees excellent transfer rates, i.e. rapid reading and writing of data.

Two serious problems are associated with this technique, sensitivity to dust and to external shocks. Hard disks are encapsulated so that dust problems after manufacture do not present a problem. Removable disks are, in contrast, more or less open to the external environment and are therefore susceptible to this problem. As a result of the minute distance between head and platter, if a dust particle finds its way between them, the head can actually strike the medium, which makes itself quickly noticeable by the occurrence of defective sectors. It is therefore essential to take as good care as possible of the disks.

By the nature of the construction, external shocks present a severe problem. As a consequence, it is advisable not to operate a Syquest drive at a disco party, much less strike the case of the computer or drive, otherwise one may well be rewarded with bad sectors on the medium. Implementation: The heads are built into all SyQuest drives. The rotating medium is encased in and somewhat protected by a semi-transparent plastic exchangeable cassette with a slit through which the head enters to approach the disk. When the eject button is pressed, the head is retracted, the disk spun down and finally the whole cassette is ejected from the drive. All SyQuest products are also equipped with an emergency ejector that should only be used in a real emergency, i.e. a jammed mechanism or disk, since it is possible to destroy the head and the medium by this method. Obviously, this emergency ejector is purely a hardware mechanism and if it is used while the drive is running the disk will be immediately rendered worthless.

Personal Experience: The technical requirement of dust-proofing and the desire for removability are really mutually exclusive. SyQuest has only partially achieved a satisfactory compromise. The product of this effort is a relatively fast system that has its drawbacks. I have used all types of SyQuest 3270 systems for about 2 years and can personally testify that with increasing age of the media an increasingly large number of defective sectors occur, resulting in the danger massive data loss on the one hand, and questionable interoperability i.e. use of the same media in different drives on the other. I will go into this in more detail below.

Drives: The construction of the drives is very delicate. Driven by the wish for a 3-1/2 inch construction it was necessary to save in many places. The inside of the drive is protected from dust by a small plastic flap that is guaranteed not to last long. During operation the system is dust tight, which means that the tolerances have to be kept at a minimum. Unfortunately, SyQuest has not been very reliable in this area so that it is altogether possible that a particular drive cannot spin up a particular disk that works fine in another drive. This behavior is often quite bizarre. In general, all that can be recommended here is to treat the drives with kid gloves and be very careful. They are not suitable for those with a forceful nature. Also noticeable is the fact that drives with different firmware revisions ( different construction series ) may treat one and the same disk in a very different manner: Formatting with one drive may result in a number of defective sectors, whereas formatting the same disk in another drive will show it error free. It is not difficult to imagine the results when the opposite of this example occurs, particularly when the disk already contains data! Generally speaking, SyQuest SCSI drives demand particular attention, although the potential danger is of a different nature: We have experienced a drive going up in smoke although it was correctly attached to the system. Upon questioning a number of retailers we learned that this occurs commonly. What is more, SyQuest takes the drives back and repairs them without further question. The question remains unanswered as to who pays for the dead SCSI host controller and mother board that needed to be replaced after this drama.

Media: The media consist of a solid steel platter with a magnetic surface and a golden-colored glimmer. It is contained within a plastic cassette that appears somewhat bulky and shapeless. If one carefully shakes the cassette it rattles in a manner that is not exactly reassuring and one immediately wonders whether this cannot already result in a damaged surface. These concerns quickly prove to be all-too-real. Simply placing the cassette in it’s protective slip case into a back pack and riding a bike over a cobble stone road results in defective sectors on the disk. The media are really quite fragile and it is highly recommended that they always be stored in their protective case. Rough handling or transport is to be avoided at all costs. I have also noticed that it is necessary to allow the disk to attain at least room temperature before inserting it into the drive. The tolerances are so small that a disk that is too cold may not be able to be spun up by the drive. In addition, the cassettes should never be subjected to temperature extremes or shocks such as direct sun or cold winter weather.

Use and Suitability of the 3270 Hardware: The experience that I have shared above leaves a rather bleak outlook. To be more objective however, I would like to point out that the Syquest drives are very fast, competing with many hard drives in this regard. Nonetheless, their use as removable systems is severely limited by the weaknesses mentioned here. Whether or not they are suitable for a given application depends directly upon the demands made on them. If one needs storage media for archive purposes, saving data that only occasionally needs to be retrieved, and not needing to often transport the media from one geographic point to another, SyQuest drives offer an inexpensive and very fast system. Prerequisites for this are stable storage conditions and a need for only few different drives to be interchanged. If, on the other hand, one has large amounts of data that must often be safely transported from one place to another and need to be read from or be written to on a number of different drives, one cannot in good conscience recommend the 3270 series as they could quickly lead one into deep water. The drives are fragile and require careful handling. If one is fortunate and does not get a lemon in the beginning they can, in fact, have quite a long lifetime. You may or may not have problems, but rough treatment will not be forgiven. In order to avoid media problems from the very beginning, each disk should be low level formatted by means of the BIOS formatting utility. If defective sectors are found the disk should immediately be exchanged as it is incompatible with the drive. When performing the final format operation, quick formatting should not be chosen. Under OS/2 the format switch /L should be used. If the media are to be used under DOS, Scandisk can be recommended. ( A question addressed to IBM: Why is it not possible to include a surface-testing program such as Scandisk in an otherwise excellent operating system such as OS/2?) Using the protocol mentioned here provides a reasonable guarantee that the data will still be readable after a year. Thus, the need for removability is only partially satisfied.

Finally, I would like to note that users of the older 44 and 88 MB drives will not share these views. These systems appear to have been designed much better than the later products. In the meantime, SyQuest has stopped producing the 3270 series in favor of the EZ-Flyers. These latter drives have also generally enjoyed a much better reputation, at least in magazine tests. The above difficulties must, therefore, not apply to newer SyQuest generations. If anyone has more experience in this area they are welcome to send it to me for insertion here. I personally have not been able to gain any experience with the EZ-Flyer since I have jumped ship to Iomegas ZIP Drive, which is much slower and smaller, but for all that is also very robust and guarantees true removable service.

Types of Devices.
Syquest offers the 3270 Series in three basic variants:

Devices with an IDE interface. My first experience with this kind of drive was beset with a certain amount of frustration, due to the classical IDE problems with primary/secondary and master/slave. Since this is no different than the situation with hard disks one cannot criticize Syquest for these problems. When these initial problems are solved, this setup proves to be quite stable. It is important that the device is registered with the BIOS, otherwise it will be necessary to have a disk in the drive at boot-up. A drive should be used in any case because only by this means will disk changing be possible. There is a small hitch in the setup that should be mentioned. The SyQuest documentation contains an error in the jumper diagram: Firstly, the picture of the jumpers is inverted (mirror image) and secondly, the jumper positions are wrong anyway. Therefore it is necessary to find the right settings by trial and error. The rest of the documentation is clear and accurate.

Devices with SCSI interface are, of course, the least difficult to install. Termination is passive, by a series of resistors that are easy to remove if the device is not to be terminated. It is possible to use all SCSI IDs with the drive so it is possible to connect the SyQuest to any SCSI bus without having to change the other device IDs. The documentation is clear and most importantly, accurate.

The Parallel-Port Versions. There is not much to say about these devices. They are connected to the LPT port, if a printer is to be use it is connected to the printer port on the drive. Finally, the power cable is attached to the drive. That is all there is to it. The number of difficulties encountered depend upon the parallel port used. These drives cannot be accessed with a special device driver, however. SyQuest is well aware of this and therefore provide good drivers for almost all operating systems. There will more to say about that later. The parallel port is not really suitable for removable disk drives since it is too slow and cannot take advantage of certain inherent characteristics of these devices. These devices were not particularly easy to install on OS/2 systems before the development of IBMs NewDasd package and they are still not particularly well adapted. The parallel port must be considered an emergency solution under circumstances in which the removable drive is to be attached to a number of different computers.

Operation with various operating systems.
Although the topic of this FAQ-List is the use of removable drives with OS/2, I would like to make a few comments about the use of various 3270 drives with DOS, Windows 3.x and Windows 95. If the information in the FAQ does not answer a particular question, the news group comp.os.os2.setup.storage can be recommended. It should be possible there to receive information on other systems as well.


 * Using the 3270 drives with DOS and Windows 3.x.


 * All operating systems require a special device driver in order to use removable disk drives. Most operating systems are in the rule quite inflexible about not allowing a drive that was registered upon initialization to be removed from the system. Mounting and unmounting file systems as per Unix or Linux systems is not implemented in DOS/Windows or OS/2. Thus, real removability under these operating systems is only possible using special device drivers. As noted above, SyQuest clearly recognizes this problem and is one of the only companies in the branch that provide excellent driver support for the use of their drives under various operating systems. This is certainly an argument for using them.


 * Use of the various drives under DOS and Windows 3.x is quite straightforward. Drivers are available from SyQuest and are both useable and regularly updated. Under DOS, disks are generally not locked in the drives and are removed by pressing the eject button. Alternatively, locking utilities can be applied to avoid unwanted disk removal. Since the drives are generally controlled by drivers and not be I13, DOS FDISK does not recognize them. In order to allow the user flexibility in setting up the drives, special utilities are available, for example the program SQPREP which allows partitioning and formatting of SyQuest (and unfortunately only SyQuest) disks. Starting up Windows loads a 16 bit protected mode device driver and the drive is locked since the rudimentary multitasking capability of this system no longer tolerates simply removing and replacing disks. Disk removal is implemented by a special Windows software that unlocks the drive. Installation of this system is uncomplicated using the INSTALL (DOS) or SETUP (Windows) program provided. The newest driver versions are readily available on the Internet. At present these are Version 3.45 for IDE, 3.48 for SCSI devices, and 3.41 for parallel-port drives. The drivers can be obtained from ftp.syquest.com (USA) or at rheooptik.fmf.uni-freiburg.de (Europe).


 * The use of SyQuest Drives with Windows 95:


 * At present, the situation with Win 95 is difficult at best. As far as I know there are no custom drivers available. Windows 95 provides generic support for SCSI devices without special drivers so that there is no problem here, however IDE devices are handled by Win95s own IDE driver and since this driver knows nothing about on-the-fly removability, the drives can only be used as non-removable media. In order to change disks the system first needs to be stopped, or the 16-bit DOS/WIN 3.x driver must be install, which involves using some tricks because of the version number. This forces the system into compatibility modus, which is, however, unstable and results in system crashes. it remains to be seen how SyQuest plans to deal with this problem. At this time, only SCSI devices can really be recommended. Anyone who knows more and feels free to write a few words about?


 * Device usage under OS/2


 * SyQuest was the first company to make available useable OS/2 drivers that allowed removability. Due to the problems resulting from partitioning, a good deal of patchwork was involved, using commercial drivers and shareware tools. Anyone interested in further details is invited to read Chapter 2 which describes the system problems encountered with OS/2 and how to slip around them. For the IDE and SCSI versions of the 3270 series, it is only necessary to download the NEWDASD package from IBM. Support of SCSI and IDE equipment is generic, but in the meantime is excellent. Under certain circumstances it may be advantageous to use the SYQEST-HPFS.ZIP package for SCSI equipment. For parallel-port drives it is necessary to obtain SyQuests own OS2P341.ZIP in addition to IBMs NEWDASD.ZIP. The driver ESPA.ADD from the SyQuest package is used in combination with the NEWDASD driver. These drivers can be obtained from IBM and SyQuest.


 * The sources can be found in Chapter 2 which also provides detailed instructions and descriptions. The installation of the IBM packages as well as SyQuest-hpfs.zip is described in detail in Chapter 5, dealing with Other Drives. The description there also applies to SyQuest drives without revision. In addition, it is obviously advisable to read the readme files provided with the packages.

Interoperability
In using removable media, one may find oneself in the situation in which one and the same disk needs to be accessed by different operating systems, or on altogether different platforms. The problems involving this situation will be the subject of this last section. According to Microsoft specifications, with DOS/Win 3.x, Win 95 and Win NT removable media are to be treated as partitioned media. A prerequisite for use under DOS and therefore also under Windows 3.x, is a defined partition. Windows 95 and NT also treat removable media as partitioned drives and can neither write to nor read from OS/2 superfloppy format.

On the other hand, using OS/2 (including Warp 4) out of the box and without additional drivers, a removable drive can be treated as a superfloppy (IBM specification for removable media) and cannot be partitioned. An exchange would therefore appear to be very difficult at best. In fact, however, there a number of alternative solutions to this problem:

The first involves using the OS/2 Superfloppy format, which is possible with all systems except DOS (and is even possible there with the help of special drivers). The files system of choice is FAT since it is accessible to all operating systems. Although this solution may not provide satisfactory transfer rates (see Chapter 2), it does work.

With the appearance first of SyQuest-hpfs.zip and now of NEWDASD.ZIP, OS/2 understands the Microsoft specification, and partitioned removable media have (finally) become a reality. An exchange of data on removable disks across platforms is now a simple matter, and if 16-bit FAT alone is used as the file system format and the appropriate drivers are installed, the disks can be read by all systems. This is certainly the method of choice since it imposes the least problems. Superfloppies are out, which should be reason enough to celebrate, especially for anyone working with DTP under Win-OS/2.

The only difficulties that remain occur with the use of various file systems. Using DOS/Win 3.x there is really no problem since the only file system that can be used is 16-bit FAT. Windows 95, in the most recent revision (OEM version) can work with 32-bit FAT in addition to 16-bit FAT. Whatever opinion one has of this solution, Win 95 is the only operating system that can read this format so that it can be ignored from the standpoint of interchangability. Both OS/2 and NT can work with 16-bit FAT file system and can share data on this basis. NT can also use NTFS which cannot be read by any other system. NT 3.51 still supported HPFS, but NT4.0 no longer has this capability; to be certain, Win 95 and DOS also not. The safest file format therefore is 16-bit FAT, which can be read by all systems (including Linux and MAC).

If the demand is for a more sophisticated system (including for instance long file names), OS/2 HPFS is available. By using special drivers it is possible to read from and write to HPFS under DOS. By use of the package hpfsnt.zip from Chris Behnken, and assuming one has pinball.sys from Windows NT 3.51, Win NT 4.0 can be taught to understand HPFS, once again allowing an interchange of disks. This can be highly recommended since the lack of HPFS support under NT 4 is the result of politics and not a technical issue. The quality of the file system is enormously superior to that of FAT. Linux can read HPFS but not write to it. Many OS/2 users are flirting with Linux because it already has a number of capabilities (Security, Multi-user capability...) that OS/2 should be able to do much better (IBM, do you hear me ??). Data exchange via removable media is implemented by the IFS driver package ext2_240.zip that was written by W. Mathieu. This package gives OS/2 the capability to read from and write to the Linux EXT2FS file system, obviating the need to use FAT.

Other Removable drives
A very very important note at the beginning: A new BETA driver package who supports 1024 b/s and even 2048 b/s media has become available. A more detailed description will follow at the next update of this chapter. Download the new package now and test it. Please send us the experience you made with.

Can I use an Optical Disk Drive with OS/2?
Yes. SCSI optical Disk Drives or Magneto Optical Devices (MOs) that accept media with 512 Bytes/Sector can be used. At present only 512 byte/sector media can be used. These usually have a capacity of 600 MB per side so that two-sided disks have a total capacity of 1.2 GB. Media with 1024 or 2048 byte per sector (650 MB, 1.3 or 2.6 GB) are not supported and according to the experts, probably will not be in the (near) future. Some drives from Hewlett Packard and Fuji, for example, can read from and write to disks of both sector sizes. Others, such as Hitachi are designed for disks with 1024 or 2048 byte per sector but disks with 512 can be read from but not written to. There have been occasional reports that 1024 byte per sector disks can be used, but in numerous attempts I have been unable to repeat these.

Obviously, the drive must be properly installed in the system and attached to the SCSI bus with a unique SCSI ID. The OS/2 SCSI driver that is appropriate for the host adapter being used must be installed and functioning correctly (NOTE: This is not true for non-removable service as discussed in section "b" below where the host adapter driver is replaced with ibmint13.i13). For external drives it is important to keep in mind that external SCSI cables can be very touchy. If you are having difficulties with an external device, try borrowing a good cable for testing purposes. The SCSI bus must be terminated at both ends (only!). Also, if you plan to boot from your MO you will need to tell your SCSI host adapter BIOS about your plans. This in turn may mean that trying to boot without a disk in the MO drive fails or takes an excessive amount of time (up to 5 minutes with some Adaptec adapters). If you have chosen this option, make sure you have an MO disk handy when you want to boot your computer. For help with SCSI problems, check the News Group comp.periphs.scsi.

PD drives (so-called "phase-change devices" designed for use as combination MO and CD-ROM drives, sold under the Panasonic, Matshita or other names) can be treated exactly as other MOs and work very well with OS/2. These drives function as SCSI embedded targets and your host adapter driver will need to be informed about this (for Adaptec: /ET switch after the driver statement in the Config.Sys, i.e. BASEDEV=AIC7800.ADD /ET - for other adapters, check your handbook) in order to use both MO and CD-ROM features.

MO drives can be used in a number of different configurations with OS/2. We will consider them individually on the basis of user need and from a historical standpoint. In fact, with the recent turn of events (new support from IBM), the first solution is usually adequate and preferable. For the sake of completeness and to clarify contradictory appearing recommendations elsewhere I will, however, present all of the possibilities with which I am familiar.

How to set up an MO drive for use with OS/2
I just bought a compatible SCSI Optical Disk drive. I don't care about the background or use in special situations. I just want to get the best performance out of my new drive for data transfer, archive and backup use. What is the fastest way to get up and running?

Obtain either the driver package syquest-hpfs.zip (sometimes found as syhpfs.zip) or IBM's new driver package newdasd.zip and unpack them. Shut down, connect your MO drive, turn it on and insert an MO disk. Restart your computer, follow the installation procedure with the package (reviewed below) and reboot. Click on the "Drives" icon with the secondary mouse button and select "Create a Partition." You should now see a new drive (the last one on the list), which you can select. Mark the partition shown and delete it (after making absolutely certain that you are really looking at the MO and not your last HD!) Then select "Create a New Partition," chose logical and OK. You will then need to reboot so the new partition is recognized by the OS.

When the system is running again you will have a new drive letter (after your last HD but before your CD-ROM). Click on it with the secondary mouse button and select "Format Drive" (again making certain that this is really the MO!). Chose HPFS (or FAT if you must), give the volume a label, if you like, and press OK. Share and enjoy! For more details and possible pitfalls, see below.

Background
MOs as exchangeable, partitionable drives: This is what removable drives are supposed to be all about and what most people imagine them to be. In fact, however, this has only recently become a possibility. In this mode, the optical disk is treated as a hard disk when it is in the drive, but it can be deregistered with the operating system and removed and replaced by another disk. Since it is treated like a hard disk it can (must) be partitioned, formatted with HPFS (or FAT, of course) and, as we will see, can even serve as a boot device.

This answer to every MO owners prayer came in the form of the package syquest-hpfs.zip, which first allowed the possibility of partitioning and HPFS, combined with disk removability. As noted in Section 2, this wonder was achieved by the use of a "device deceiver," that misrepresents the removable drive to the OS/2 device manager, registering it as a hard drive. By use of a small program, a flusher, that empties the cache (regardless of file system) and performs a local shutdown on the drive, it became possible to remove the disk and replace it with an identically partitioned (note!) disk. To avoid the pesky problem of shifting drive letters, the disk can be partitioned as extended and logical rather than primary.

As noted in detail above, IBM recently recognized the need for better support of removable media and created a driver package that provides almost optimal usage of MO drives. Disks with different partition sizes can be interchanged, the drive is locked so that loss of data cannot occur if one inadvertently tries to eject by physically pushing the eject button, and an "Eject Disk" item is found on the popup menu of the drive object. Multiple partitions can be created, however, the disk can then only be exchanged by rebooting. Installation of the two packages, syquest-hpfs.zip and newdasd.zip will be described below. Before beginning, however, a note on logistics is in order. Both of these packages are superior in all ways to previous methods available, including optical.sys or optical.dmd. With thes appearance of these new packages it is no longer necessary to treat an MO disk as a large floppy disk. BUT, if you have been using your MO as a "superfloppy" drive and you have a number of MO disks that contain data, it is best to back up that data BEFORE you change constellation to the new drive support system. The MO disks will need to be partitioned and formatted, destroying all data on them. You can then copy the saved data back to the MO for use with the new support system. Of course you can also just switch back to optical.dmd to access your old disks, leaving them unpartitioned, but this can only be considered an alternative if you want to buy new disks for new work AND only very rarely need the data off your old disks (archives). If you have a new drive and only new disks without data you can just ignore this warning.

Installation of the syquest-hpfs.zip package
Note: This part is mostly taken from the "readme.os2" file that accompanies the syquest-hpfs.zip package.

In order not to offend or confuse users of either brand of hardware, the filter driver and flusher were included twice in the package, once with the Iomega name and once with the SyQuest name. Besides for their names, the files are identical and for use with non-SyQuest, non-Iomega equipment (MO-drives) you can use either one ( but not both! ) or rename the files as you like. For the sake of clarity I will just call the files syquest.flt and syquest.exe. In practice I usually rename the .flt driver "modisk.flt" and the flusher "newdisk.exe."

The installation is simple and straightforward:


 * 1) Read the README.OS2 file.
 * 2) Make certain your OS/2 SCSI-adapter driver is correctly installed and loaded from the Config.Sys.
 * 3) Edit the Config.Sys to include the line basedev=syquest.flt /unit=0,..,.. where unit means the number of the drive(s) to support. Note: Unit does not mean the device LUN or SCSI - ID. The devices (MO-drives only) are numbered starting with the first found removable unit. i.e. 1 MO-drive => /unit=0 2 MO-drives => /unit=0,1 . 1 MO, 1 Zip, 1 SyQuest and 1 Jazz => /unit=0,1,2,3
 * 4) Copy the syquest.flt driver to \os2\boot (OS/2-Warp) or to \os2 (OS/2 V 2.x) and syquest.exe file into your \os2 directory. Restart the system. The removable drive will now be recognized as a hard disk.
 * 5) Shutdown and reboot.
 * 6) Use FDISK (or PMFDISK) and FORMAT to prepare your removable drives. Note: In case you previously used your disks as large floppies (i.e. with optical.sys or optical.dmd), a drive letter may not be assigned to the drive at this time. Start FDISK, partition your media and reboot again. A drive letter will now have been assigned to the removable disk. You can only change from one medium to another without rebooting if both media are partitioned identically.
 * 7) To change disks, make certain there are no open files or running programs on the drive. To unmount a disk, enter on OS/2 command line: "syquest drive:" where 'drive:' is the letter of your drive as established by OS/2. i.e. syquest f: Now you can change the disk. After the change you will need to remount the drive by retyping the "syquest" at the prompt. You can then continue to work. Changing between FAT and HPFS file systems while the system is running is also supported. In case you get the error: DosDevIOCtl LOCK error: return code = 108 DosDevIOCtl FSD error: return code = 033 there are open files or running programs on your removable drive. Close the file(s) or program(s) and retry. Important! If you use a removable drive for your swap file you must not change the disk!

Remember: If you partition the MO as primary the drive letters will be shifted. For example, if you have one physical hard disk with one primary partition C: and three logical partitions D: E: and F:, after creating a primary partition on your MO and rebooting, the MO will be D: and the logical HD partitions will be E: F: and G:. In general there is no reason to make the MO partition primary. When you create the partition FDISK will ask whether it should be primary or logical.

Installation of the new IBM driver package
Note: This part is mostly taken from the "readme.txt" file included with the package.


 * 1) Read the file readme.txt included with the package.
 * 2) Rename OS2\BOOT\OS2DASD.DMD to OS2\BOOT\OS2DASD.ORG
 * 3) Copy OS2DASD.DMD from this package to OS2\BOOT\
 * 4) Rename OS2/PMFORMAT.EXE to OS2\PMFORMAT.ORG
 * 5) Copy PMFORMAT.EXE from this package to OS2\
 * 6) Copy NEWDISK.DLL to OS2\DLL
 * 7) Run REGDLL.EXE from an OS2 Command Line. You should see: register successful replace successful
 * 8) Edit the Config.Sys as follows: Find the line: BASEDEV=OS2DASD.DMD Add the /of (optical to fixed) parameter to OS2DASD.DMD. NOTE: You MUST use small letters. /OF will not work! The line should now read: BASEDEV=OS2DASD.DMD /of
 * 9) Shutdown and Reboot.


 * Very important note: The switches /of or /rf for the new os2dasd.dmd are case sensitive. These switches in upper case will not work !!!

If you previously used the disk as a large floppy ("Superfloppy") you will need to partition and format as described above. You can, however, remove the "/of" switch from the os2dasd.dmd line in your Config.Sys and use optical.dmd to read your old "superfloppy" disks and retrieve information from them before destroying the data by partitioning and formatting. The MO will be locked in the drive. You MUST use the EJECT command, or the WPS menu function to eject the media. If you do successfully "trick" the drive into letting you eject the disk without doing this you can also kiss your data good-bye. We discoverd that the argument of eject.exe is also case sensitive. The command eject E: will cause an error, use always eject e: instead !

Note: Using this new code has a few limitations (taken from the readme.txt file):


 * 1) FDISK does not display the correct drive letters if a primary partition is in the removable drive. This is cosmetic only and will not cause any problems in the use of applications other than FDISK. The drive letters will follow the rules stated above.
 * 2) Media remains locked in drive after shutdown.
 * Workaround: power the drive off/on, eject, power off, or eject before shutdown if not HPFS. (see 3)


 * 1) Occasionally shutdown doesn't complete when HPFS formatted media is removed prior to the shutdown request.
 * Workaround: before shutdown, insert media, access by issuing a DIR or some other command, then shutdown. Media will be locked in drive, use procedure above to get the media out.


 * 1) Trap on Trantor T128/T13b adapters, externally attached. The device driver associated with these adapters are the T128SCSI.ADD and the T13BSCSI.ADD. No fix available at this time.
 * 2) The switches /of and /rf and the argument of eject.exe are case sensitive. Type always the arguments in lower case.

Comparison of the two packages
What are the advantages and disadvantages of the syquest-hpfs.zip package vs. the IBM DASD package?

The first big difference is the possibility to boot from a properly formatted and prepared MO with the SYQUEST-HPFS package. The IBM driver package, on the other hand, is easier to install and use. In addition it is more sophisticated, locking the drive so that it is impossible to remove a disk without first properly closing the file system and offering a secondary mouse button menu with an "Eject Disk" selection. Both of these methods can be recommended as "state of the art" solutions to the problem of using removable drives with OS/2.

What other modes of operation are available for using MODs with OS/2?
There are (at least) two additional possibilities for using Optical Disk Drives under OS/2:


 * 1) MODs as large floppies:
 * "Traditionally," MODs have been used under OS/2 as so-called "super floppies," treated by the operating system in the same manner as the standard floppy drives A: and B:. Since floppies are not partitioned they cannot be formatted with HPFS. Also like floppies, the disks are not locked in the drives and can be exchanged at any time. In addition to lack of partitioning and HPFS support, caching is not available and performance of these giant floppies is often maddeningly slow. With the appearance of newer support systems mentioned above there is generally no longer any reason to use this "standard" mode.
 * Required: The IBM driver, optical.sys or the newer optical.dmd. These are included with Warp 4 and are installed if you chose "Optical Drive Support" in Selective Install. As far as I know, if an OS/2 driver is packaged with the MOD it usually only supports this floppy mode and most often is IBM's own optical.sys. Until very recently, this was the only mode that IBM foresaw for use of these drives under OS/2. This has changed as mentioned above in Section 2.


 * 1) MODs as non-removable (pseudo-hard) drives:
 * MODs, like other removable drives, can most easily be installed as non- removable using interrupt 13H SCSI support instead of the normal SCSI host adapter driver as explained in section 2.3.1 above. In this mode the disk must be inserted in the drive before booting and cannot be removed until the system is shut down. The optical disk is treated exactly as a permanently installed hard disk, therefore, to change the disk the system must be shut down, the disk replaced and the system restarted. In addition to this obvious disadvantage, use of int 13 in this manner obviates use of any other SCSI devices, i.e. additional SCSI drives, CD-ROMs, scanners and the like. For these reasons this method cannot be recommended except in the most unusual of circumstances.
 * Required: A SCSI host BIOS with i13 support for removable devices (Adaptec, NCR, Tekram, but NOT Future Domain), and ibmint13.i13, which is an inherent part of the OS/2 operating system.
 * Only one line is required in the Config.Sys: Basedev=ibmint13.i13.

Conclusions
Only a year ago the use of magneto-optical devices under OS/2 was limited to treating the device as a large floppy disk with inherent slow data transfer rates, lack of HPFS data safety, long file names and partitioning. Now there are two excellent alternatives that should meet the needs of nearly all users. There are still improvements to be made, i.e. use of media with more than 512 Bytes per sector, etc. but the MO user now has the opportunity to take advantage of this excellent and timely technology under the operating system of choice.

Pinnacle Micro "Tahoe" Drive
Ted Blockley writes:


 * I have a Pinnacle Micro "Tahoe" drive. This is an external 230 MB Magneto-optical drive with SCSI interface. At the desktop, I use it with either an Adaptec SCSI (2940UW) or NCR based SCSI adapter. For portable use, it came with a Trantor (Adaptec) Parallel port adapter (used with a Thinkpad).


 * Each successive addition of Warp seems to be better at recognizing this drive.


 * Merlin that recognizes the drive automatically and enables the features such as lock and unlock. The one feature that doesn't work (and hasn't worked) is the "eject disk" menu item. IBM got a report from me during the Merlin Beta, but nothing came of it.


 * There is no support for HPFS, although there is a utility (which I haven't tried) to accomplish this.


 * Merlin seems much more tolerant than Warp3. With Version 3, it was important that a disk be present in the drive when the system booted. Merlin doesn't mind if the drive is empty at boot time.


 * The current drivers for the parallel port adapter seem to work well. This is no different than with Warp3.


 * The one problem that I have not checked for in version 4 is that OS/2 cannot read disks formatted in DOS. DOS can, however, read OS/2 format disks.


 * The only special installation procedure I followed was to enable the optical disk support manually.


 * There isn't much else to say. I use Back Again/2 for backups. When the "verify while writing" option is used, backups usually go at a rate of 30 MB per minute. When that option is disabled (separate verify), the rate drops to 20 MB per minute.

Performing a backup using your Zip drive.
This section was shamelessly stolen from:

Larry Scott scott@buffnet.net copyright 1996--distribute freely but give me credit, please

[I have not tried this method and I am providing it because it looks useful. I have received a couple of emails on this and have not had a chance to look into them or forward the mail on to the author of this section (sorry). One brings up the point that Info-Zip does not archive directory EAs, necessitating some other method of backing up the Desktop Directory. The other email has to do with RAR as a better compression tool for this job since, unlike Info-Zip. it can automatically span floppies. Anybody want to provide an RAR procedure?]

These are the steps I followed in backing up my 400 meg OS/2 boot drive onto two 100 meg disks in a parallel port Iomega Zip drive, with the solid InfoZip compression program. This assumes you already have a parallel port Iomega Zip drive operating in OS/2. The drivers for OS/2 are available at Hobbes (ftp://ftp-os2.nmsu.edu/os2/drivers) and on Pete Norloff's OS2 BBS (http://www.os2bbs.com). I think I might have gotten them from Compuserve. Mine is a FAT system, so if you're using an HPFS system you'll have to look into how that affects things. I'm not sure it does, since the centerpiece here is the Info zip utility (v. 2.0.1, file date 9-19-93), which preserves EA's inside zip files which don't themselves have EA's. Therefore I don't think you have to worry about doing a format of the Zip disk to HPFS.

ZIP and UNZIP are available at lots of places. Typing "zip" and "unzip" at the commmand line tells you their switches. I haven't yet gotten around to looking at the newer versions that were published this year.

Here goes:

libpath=.;\;a:\; and changed the set path and dpath to: set path=\;a:\; set dpath=\;a:\; I'm not sure what if any of that was necessary since my main problem in getting the Zip drive to work turned out to be trying to put the drivers in A:\ rather than in A:\OAD. But those config.sys lines are as above now, and they work.
 * 1) Make OS/2 utility (boot) diskettes. I did this by starting with the "Create Utility Diskettes" icon under the "System Setup" icon in "OS/2 System." Add to the CONFIG.SYS file on the #2 disk [officially called DISK 1] the line "DEVICE=A:\OAD\OS2.SYS" (no quotes). I also added:

In the course of experimenting to make things work I also added three other DLL files. See the complete directory listing for my customized OS/2 Utility Diskette #2 below. One or another of the added DLL's may or may not be necessary. I think I also added TEDIT and TEDIT.HLP.

And of course you need to copy ZIP.EXE and UNZIP.EXE to that disk.


 * 1) ZIP driver. Make a directory named OAD on Utility Diskette #2--the one with CMD.EXE and CONFIG.SYS on it. Don't bother trying any other directory name. There isn't room to get all of your OAD files onto the floppy disk with all the DLL files that are already there. Use a file viewer such as LIST or HYPERVIEW to look in the customized files CONFIG.OAD, GENOAD.MAP, and CONFIG.MAP in your hard drive OAD directory to help you guess which files might be necessary with your machine to make the boot disk work the Zip drive, and copy files to A:\OAD accordingly. The ones I ended up with are shown in the complete directory listing for my customized OS/2 Utility Diskette #2, below. I did not end up having to rerun GENOAD, so GENOAD.EXE is definitely not necessary even though it's on there. Obviously you're going to have to experiment with booting with these utility disks to make sure you can access your Zip drive when you use these boot diskettes.

cut- C:\OS2 C:\OS2_MOU C:\CMD C:\WP51 ---cut-- Here's how I did it:
 * 1) Directory listing. You need a file with a plain list of all the directories in your root directory looking like this:

With the #2 utility disk [officially DISK 1] in drive A, run the command: dir c:\*.* /o:g /a > a:\zipback.lst [If your OS/2 drive is some drive other than c: then substitute that letter in place of c: in the command.]

Edit a:\zipback.lst as follows:


 * Delete all lines that aren't directory names. That includes headings and all names of root directory files.
 * If there are any directory names with extensions, close up the spaces and insert the ".". Example: "SIO 153" becomes "SIO.153"
 * Delete everything after the directory name on each line. (I used a word processor macro that searched for a space, deleted the remainder of the line, moved to the beginning of the next line and repeated until there were no more spaces in the file.)
 * Add c:\ [or whatever drive] at the beginning of every line. (I used a word processor search and replace function to replace with C:\)


 * 1) Make a conservative guess as to which of your directories with their files and subdirectories will fit, zipped with the files in your root directory, on one Zip disk. Move part of your directory list from a:\zipback.lst to a:\zipback1.lst according to your guess. If you underestimate what will fit there's no problem. You can add to it. If you overestimate what will fit on the disk when you run zip I don't know what happens. I didn't do that.


 * 1) Make three batch (.cmd) files on the #2 (DISK 1) Utility disk. Each has just one line, so IGNORE ANY WRAP here, and put everything on one line with a space where the wrap occurred, for each of the three. Again, if you're doing a drive other than c:, substitute.

ZIPC.CMD a:\zip.exe -u -g -S drive-c1.zip c:\*.* -x c:\swapper.dat c:\ea?data.?sf ZIPBACK1.CMD type a:\zipback1.lst | a:\zip.exe -u -g -r -S -@ drive-c1.zip -x c:\os2\system\swapper.dat ZIPBACK2.CMD type a:\zipback2.lst | a:\zip.exe -u -g -r -S -@ drive-c2.zip -x c:\os2\system\swapper.dat

Here's the complete directory listing of what I ended up with on the #2 Utility Diskette. [There's a heretofore unmentioned file, ZIPBACK2.LST, which we'll get to.]:

The volume label in drive A is DISK 1. The Volume Serial Number is E33F:B815. Directory of A:\ ANSICALL DLL      512   9-23-94  3:31a BKSCALLS DLL      512   9-23-94  3:32a BMSCALLS DLL      512   9-23-94  3:34a BVHINIT DLL      7999  10-09-94  7:03p BVSCALLS DLL      512   9-23-94  3:30a CLOCK01 SYS      3735   9-23-94  4:17a CLOCK02 SYS      3834   9-23-94  4:17a CMD     EXE     91648   9-23-94  4:55a CONFIG  SYS       510   9-20-96  8:32p COUNTRY SYS     25610   9-23-94  4:53a DOSCALL1 DLL   137084  10-07-94 12:52p EA DATA  SF      9216   9-19-96  6:24p HARDERR EXE     14888  10-07-94 12:47p HPFS    IFS    135746   9-23-94  4:38a IBM1FLPY ADD    30994  10-05-94 10:31p IBM1S506 ADD    27104  10-06-94 10:41p IBM2ADSK ADD     9798  10-05-94 10:32p IBM2FLPY ADD    13718  10-05-94 10:31p IBM2SCSI ADD    32373  10-03-94  1:39p IBMINT13 I13     9860  10-05-94 10:32p IBMKBD  SYS      5548  10-03-94  2:21p KBDBASE SYS     27989  10-03-94  2:23p KBDCALLS DLL     1024   9-23-94  3:07a KEYBOARD DCP   137500   9-23-94  4:48a MOUCALLS DLL     1024   9-23-94  3:35a MSG     DLL       512   9-23-94  3:17a NAMPIPES DLL     1024   9-23-94  3:34a NLS     DLL       512   9-23-94  3:16a NPXEMLTR DLL    25504   9-23-94  5:07a OAD                9-20-96  6:53p OS2CHAR DLL       512   9-23-94  3:26a OS2DASD DMD     33562  10-05-94 10:30p OS2LOGO         19358  10-05-94 11:05p PRINT01 SYS     10910  10-03-94  2:38p PRINT02 SYS     10022  10-03-94  2:38p QUECALLS DLL     1024   9-23-94  3:19a RESOURCE SYS    27084  10-05-94 10:29p SCREEN01 SYS     9461  10-08-94  7:14p SCREEN02 SYS     9393  10-08-94  7:14p SESMGR  DLL      1536  10-07-94 12:54a SIPANEL1 DLL    31312  10-08-94  1:07a SYSINST1 EXE     4960  10-25-94  4:06p TEDIT   HLP     14596   9-01-94  6:52p TEDIT   EXE     10820   9-23-94  5:21a UNZIP   EXE     95795   8-29-94 11:40a VIOCALLS DLL     2048   9-23-94  3:28a VTBL850 DCP     10478   9-23-94  4:15a ZIP     EXE     93232   9-19-93  1:04p ZIPBACK LST         1   9-21-96  9:15a ZIPBACK1 CMD       92   9-22-96  2:39p ZIPBACK1 LST      670   9-21-96  9:15a ZIPBACK2 LST      322   9-21-96  1:54a ZIPBACK2 CMD       92   9-22-96  2:39p ZIPC    CMD        74   9-20-96 10:48p 54 file(s)   1144156 bytes used Directory of A:\OAD .                  9-20-96  6:53p ..                 9-20-96  6:53p CONFIG  OAD       369   2-25-96 10:24p CONFIG  MAP       199   2-25-96 10:15p CONFIG  DEV      3765  10-10-95  2:34a GENOAD  MSG      8828  10-10-95  2:34a GENOAD  HLP     15670  10-10-95  2:34a GENOAD  EXE    138101  10-10-95  2:34a IOM$ERR DAT      3119  10-10-95  2:34a IOM$MSG DAT     12416  10-10-95  2:34a NULLADP OPT       335  10-10-95  2:34a NULLADP ADP      1096  10-10-95  2:34a NULLDEV OPT       286  10-10-95  2:34a NULLDEV DEV     15489  10-10-95  2:34a OS2     SYS     10878  10-10-95  2:34a PPA     OPT       499  10-10-95  2:34a PPA     ADP      3146  10-10-95  2:34a PPA3    OPT       569  10-10-95  2:34a PPA3    ADP     10777  10-10-95  2:34a ZIP-100 OPT       436  10-10-95  2:34a ZIP-100 DEV     15489  10-10-95  2:34a 21 file(s)    241467 bytes used Total files listed: 75 file(s)   1385623 bytes used 54272 bytes free

zip -T drive-c1.zip Note that case is important with all the zip switches. You can also list the contents of the zip file with: unzip -l drive-c1.zip If you want to see the filenames in a file, use: unzip -l drive-c1.zip > c:\filelist
 * 1) Dual boot to DOS.
 * 2) Reboot with the diskettes.
 * 3) Make the Zip drive the current drive. [In other words, if it's drive E, get an [E:\] prompt.
 * 4) Run ZIPC. This starts the file DRIVE-C1.ZIP on your Zip disk with just the files from your root directory.
 * 5) Run ZIPBACK1. This will add to DRIVE-C1.ZIP the directories listed in A:\ZIPBACK1.LST, with their files and subdirectories.
 * 6) If you've got lots of room left on the first Zip disk, rename A:\ZIPBACK1.LST to something else, move some more directory names from A:\ZIPBACK.LST to a new A:\ZIPBACK1.LST, go back to the Zip drive ([E:\] prompt) and rerun ZIPBACK1. Repeat until you've got the first 100 meg disk as full as you want to try to get it. [You might want to recombine the files listing the directories you've backed up so far into A:\ZIPBACK1.LST.]
 * 7) Repeat steps 4, 10, and 11 with a fresh Zip disk, using ZIPBACK2.LST and ZIPBACK2.CMD in place of ZIPBACK1.LST and ZIPBACK1.CMD. This did it for me. Obviously you can go on to more disks if you need to.
 * 8) If you like you can verify the integrity of your zip file with:
 * 1) I have not restored and don't plan to restore my whole zip file as a test. I have, however, done restoration of a file and a directory. You can do it like this (for example):
 * Make a directory \TESTBACK on a drive with 25 megs or so of space. I'm going to assume it's drive c:
 * Insert the Zip disk on which you backed up the directory you want to test. I'm going to use the \TCPIP directory as an example and assume it was in your ZIPBACK1.LST. Change to the Zip drive as the current drive. Do:

unzip drive-c1.zip tcpip/*.* -d c:\testback
 * Note the direction of the slash in "tcpip/*.*" and note there's nothing in front of the name. Those are important.
 * If you want to see that the ea's are really there on your FAT system you can do, in c:\testback\tcpip:

dir /n
 * I leave it to you to get rid of c:\testback and all its subdirectories. Remember it has to be an OS/2 method to deal with the EA's. You might take a look at OS2-Commander.


 * 1) If you ever do need a complete restore, the first thing you'll want to do is install the same version of DOS that you're running. I think you should know where your original DOS disks are, and have diskcopies of them. Use either format c: /b or sys c: to put the DOS system files in the right spot on the hard drive. Then, boot with your OS2 utility disks and restore your zip files. The procedure for that is of course:


 * Get the [E:\] prompt [whatever the Zip drive is
 * unzip *.zip -d c:\ [or whatever your OS/2 drive is.

Remember to SAY NO to overwriting the two DOS system files. The names vary. There's IO.SYS with MSDOS.SYS, and IBMDOS.COM with IBMBIO.COM. After everything's restored you'll be in DOS mode, as you were for this backup. Dual boot back to OS/2.

Well that's all folks. If I've left something essential as well as a lot of basics, let me know. The lines of the .CMD files above are imported from the working files, so I don't think there's any mistake there. I'll answer mail, but I don't promise to solve any problems.

Credit to Duane Chamblee for the example of using zip with a directory list and the -@ switch, contained in ZIPINS.ZIP at the OS2 BBS.

Credits
This is section is to thank everyone who has helped provide me with the information in this FAQ. If I've left you out, feel free to chew me out and make me put your name in here.
 * Leon Grossman
 * T. J. Casser
 * Bruce Boschek
 * Claus Boerschig
 * Sam Detweiler