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 interrested 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
Choosing the right drive
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 traveling. 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 cardridge ($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 acheived 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.
HPFS Support for Removable Drives
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 theSCSI 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 allways 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 privilegies to eject and remount succesfully any HPFS386 formatted removable media. Normal users are not allowd 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 artifact 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 exchangable 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.
SCSI Drives
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-Manger.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.
Iomega's Zip and Jaz drives
Obtaining the IOMEGA drivers. Choosing between the .FLT, the OAD, and IBM's (new) drivers. The OAD drivers The .FLT drivers IBM's (new) drivers Why is my Zip Drive so slow? With a Parallel Port drive using the OAD drivers. With the .FLT driver or no driver other than the driver for your specific SCSI card. Will the IDE Zip Drive work with OS/2? Can I format my Zip cartridge as HPFS? How to format successfully the JAZ HPFS
Syquest 3270 drives and media Introduction Technical information Personal experiences Drives Media Use and suitability Types of devices Operations with various operating systems Interoperability
Other Removable drives Can I use an Optical Drive with OS/2 How to set up an MO drive for use with OS/2 Background Installation of the syquest-hpfs.zip package Installation of the new IBM driver package Comparison of the two packages What other modes of operation are available for using MODs with OS/2? Conclusions Pinnacle Micro Tahoe Drive (M-O)
Performing a backup using your Zip drive.
Credits