ndd@duke.UUCP (09/20/83)
I was interested to see Dave Seaman's list of points about Apple Pascal, and felt that I had to make a comment. I think that letting the DOS remember which disk drives are associated with specific volume names is a very bad idea. If one has an application that requires switching diskettes in and out while a program is running, and if you try to do your own I/O error checking, that feature will bite you. If you start out with volumes FOO: and BAR: in the drives, remove BAR: and insert JUNK:, and then attempt to reset JUNK:temp, the system generally says that the file wasn't found, because DOS doesn't check the diskette directory (this assumes no file BAR:temp). If one leaves JUNK: out when resetting JUNK:temp, the error indicates that the file isn't found, when it should say that the proper volume wasn't found. Another cute thing happens when you have two volumes named FOO: which have different directories; if you start with one FOO: and then switch to the other and try a write, the first FOO:'s directory will be written over that of the second. Of course, one can argue that anyone who has two different disks with the same name deserves what he gets, but I would prefer sacrificing some speed for a more reliable scheme. The only sure way that I have found to get around this is to always reset using the device number and then UNITREAD the directory to get the volume name. If I am missing something, I would certainly love for someone to straighten me out; if not, I would argue that this 'feature' is not one that Apple P-system users can be proud of. Ned Danieley duke!ndd
CSvax:Pucc-H:ags@pur-ee.UUCP (09/29/83)
Ned Danieley has raised some interesting questions concerning the way Apple Pascal remembers volume names. The system is reasonably intelligent, but it is not foolproof. I will paraphrase: Q. Suppose I have two volumes on line (FOO: and BAR:). While my program is running, I remove BAR: and insert JUNK:. If my program now tries to reset JUNK:TEMP, will it succeed? A. If TEMP exists on the volume JUNK:, the system will find it. It will try all the drives, if it has to. If JUNK: is on line, but there is no file TEMP, your program (assuming it does its own checking) will get an ioresult of 10, which means "No such file on specified volume." Q. If JUNK: is not on line, can my program correctly determine the reason for failure? A. If the system fails to find JUNK: in any of the drives, your program will get an ioresult of 9, meaning "No device -- volume is not on line." You may then take appropriate action (such as pausing to remind the user to "Put in JUNK:"). Q. Suppose the file I want to open is BAR:TEMP, and that I have just removed BAR: and put in JUNK:. The system still has the directory for BAR: in memory. Won't this cause trouble? A. You're right. In this case the system does not double-check. On the other hand, if you ask for #5:TEMP (assuming BAR: was last seen in drive #5), then the system does re-read the directory before proceeding. (What can I say? I have been using Apple Pascal for two years and this has never happened -- even though when I first started I had only one drive and I had to put in a new disk every 3.8 seconds.) Probably the best defensive measure is to do a unitclear on each drive before you start opening files. I now have three drives and I don't often swap disks anymore except to make backups, so I'm not particularly worried. This is the only thing resembling a serious problem that I have ever found in the system (I know of two minor bugs in addition to this). I only wish that VSOS 2.1 (the operating system for the Control Data Cyber 205) were as stable and bug-free as Apple Pascal 1.1. Incidentally, Apple has announced that version 1.2 will be available in the fourth quarter of 1983, with full support for all features of the //e, including 128K bank-switched memory and double-density graphics, as well as hard disk support. Q. What if I put two volumes named FOO: on line with different directories? A. The manual specifically warns against doing th. An important special case is making backups -- you put the original and the backup (both named FOO:) on line and specify the copy in terms of unit numbers rather than volume names. The system makes the copy and then reminds you that you have two volumes with the same name. It keeps reminding you, if necessary, on every command until it notices that you have removed one. The manual also points out that you should not replace a disk by another having the same name, for obvious reasons. Since my backup disks all live across the room from the computer, and nothing else has the same name, I don't worry about this restriction. This has gotten too long. Dave Seaman Purdue University User Services Pucc-H:ags