Updated May 18, 1997
It seems like the market has exploded recently with low-cost removable disk drives like the EZ Drive and the ZIP drive from Iomega. We chose the EZ Drive over the ZIP drive for the following reasons:
We realize that 135Mb might not be enough for some users, so if you have a removable drive that you'd like us to support in the future, drop a line to firstname.lastname@example.org.
When an EZ Drive cartridge is formatted for use with EZD, a total of 262,000 blocks are available. If you convert this to bytes and then to megabytes, you end up with:
262,000 * 512 = 134,144,000 bytes
134,144,000 / 1024 /1024 = 127.92 Mbytes
What happened is that the SyQuest marketing department "redefined" the meaning of a megabyte (most disk drive manufacturers do this) to be a thousand kilobytes and a kilobyte to be a thousand bytes. Therefore using their math you end up with:
134,144,000 / 1000 / 1000 = 134.14 Mbytes
Still quite not there as far as 135 Mbytes. This is because a track is reserved for use by AMOS for diagnostic purposes. This is the space that gets used when you use self test and the read/write test gets executed. If you add in the space used by this extra track, you end up with (just) 135 Mbytes using SyQuest's "new" definition of a megabyte.
We decided to stick with the 135Mb because it's written all over the cartridges and the drive and figured this would add even more confusion - despite the fact that a kilobyte is still 1024 bytes!
EZD fully supports extended logicals on AMOS 2.x systems. If EZD encounters an extended logical on an AMOS 1.4 system, you'll see an error message for that logical telling you that it's extended format and cannot be accessed by this version of AMOS.
Additionally, when you unmount an EZD cartridge with the EZD/U command, on AMOS 2.x systems EZD will re-sort the order of the PPNs on the cartridge if the format is traditional. This is because AMOS 1.4 systems cannot read traditional disks that don't have PPNs in numerical order, which is the way in which AMOS 2.x systems write them.
There are really none. On most systems there is only about a ½ second delay between the time applications write a block to the disk and the time that the disk driver gets around to writing it. As a result, the driver is able to determine if any other blocks can be written with only one write command which can speed disk writing throughput by a factor of ten.
Of course, should the media become unavailable during this ½ second delay, pending writes will be lost. To guard against such data losses, keep in mind the following:
You don't need to worry about the MONTST program - it automatically flushes the write-behind cache on all drives before rebooting the system.
Like all software, there are things that can go wrong. The EZD program is very stable and reliable, however, there are two things that we know of that will cause your system to crash. So rather than let you find it out, we thought we'd tell you.
You cannot boot a system directly from EZD. This would require a change in the boot PROM code and the source code to the boot PROMs are not available.
EZD works just fine with a warm boot however. In fact, a great way to use EZD is to make a backup of your DSK0: onto an EZD cartridge from time to time (in addition to the backups you usually make of course) and should your system fail to boot because DSK0: got wiped out, warm boot from a tape and then run the EZD program. You can then copy DSK0: back from the EZ Drive and get your system back up and running in no time.
To make EZD compatible with warm booting, you need to include the following programs (put them all into shareable or system memory with WRMGEN):
EZD.LIT from [1,4]
EZD.DVR from [1,6]
Plus the base disk driver for your SCSI interface, i.e.:
SCZDVR.DVR for non SCSI-2 systems
SCZ190.DVR for AM-4000 and SCSI-2 AM-3000M systems
SCZRR.DVR for Roadrunners and Eagles
SCZPC.DVR for Falcons
The EZD program needs 20K. Additionally, the EZD driver uses 50K. This
driver must be loaded into memory at all times. If it's not loaded into
system memory, it remains loaded in the memory partition of the job that
ran EZD, meaning that that job will have 50K less until EZD is uninstalled
Because EZD uses some very sophisticated techniques to install a read/write disk driver without rebooting the system, one thing it must do is to exit to AMOS and restart itself. Normally this happens so quickly that you don't notice it but if you're running EZD from within a command file, the next command in the command file will be executed before EZD gets a second chance to run, which will cause problems. Whenever you use EZD from a command file, you must follow it with a :K. This causes the command file processor to pause and allows EZD to restart itself.
For example, to backup your DSK0: with a command file to EZD, you'd use:
:<Backup of DSK0: complete>
Because the system initialization command file is a command file, the same warnings apply as with command files. Additionally, because the MEMORY 0 statement in your INI file changes the memory partition, you must execute the EZD command after the MEMORY 0 statement. You can do this by using the FORCE program to force the boot job to execute EZD when the MEMORY 0 command has completed. For example:
If you want to run other commands in addition to EZD, you can force the boot job to run a command file:
POSTBT.CMD would contain: