AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (03/03/89)
>Date: Tue, 28 Feb 89 21:39:00 EST >From: "Andy Tefft (814) 862-6728" <ART100%PSUVM.BITNET@CUNYVM.CUNY.EDU> >Subject: single-drive programs >[...] How hard is it to make a program say "volume not found. please >insert correct disk or press <esc> to exit" and wait for your answer, >INSTEAD of just saying "Volume not found" and ending!!? It's a little trickier than you might think, but it isn't all that bad. I'm talking about programs under ProDOS, by the way, not DOS 3.3. When a program does file operations through ProDOS or GS/OS, it does things like OPEN, READ, WRITE, and CLOSE. (I'm talking about OS-level commands here, but when you do them from BASIC.SYSTEM there is a fairly direct correspondence.) A file must be OPENed before it can be read from or written to. ProDOS does _not_ expect a disk to be removed while their are open files on it, and it will _not_ look in that drive for other volumes. So a program that needs to support disk swapping needs to CLOSE all open files after remembering where it was in each one (by doing GET_MARKs, perhaps), and later it needs to re-open the files and SET_MARK back to where it left off. Not a major pain, but not completely trivial, either. >Andy >art100@psuvm.bitnet / a1t@ecl.psu.edu --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons
neighbor@csd4.milw.wisc.edu (Jeffrey Alan Ding) (03/04/89)
In article <8903022345.aa13273@SMOKE.BRL.MIL> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes: >>From: "Andy Tefft (814) 862-6728" <ART100%PSUVM.BITNET@CUNYVM.CUNY.EDU> >>Subject: single-drive programs > >>[...] How hard is it to make a program say "volume not found. please >>insert correct disk or press <esc> to exit" and wait for your answer, >>INSTEAD of just saying "Volume not found" and ending!!? > >A file must be OPENed before it can be read from or written to. >ProDOS does _not_ expect a disk to be removed while their are open >files on it, and it will _not_ look in that drive for other volumes. >So a program that needs to support disk swapping needs to CLOSE all >open files after remembering where it was in each one (by doing >GET_MARKs, perhaps), and later it needs to re-open the files and >SET_MARK back to where it left off. Not a major pain, but not >completely trivial, either. Not necessary. All one has to do is an ONLINE call to make sure the correct volume is in the drive. The requirements are that you know the volumes of both disks, the SOURCE disk and the TARGET disk. Get the volume of the SOURCE disk, OPEN input file, READ from that file and perform any operations on the data. Then do an ONLINE call, prompt user to insert TARGET disk if not online, OPEN output file and WRITE out data. Then do another ONLINE call, prompt user to insert SOURCE disk if not online, READ from input file and perform any operations on the data. Do an ONLINE call, prompt user to insert TARGET disk...... and so forth. This routine can be built into the same code as the non disk swapping code. Do an online before you open any files to make sure the SOURCE disk and TARGET disk are online. If they are, then no swapping will take place and the ONLINE calls are unecessary. If both volumes are not online, then you make the ONLINE calls each time you move between reading and writting. As for the comment on not enough memory to support swapping - nonsense! Adding this code would take less than 1/4K of memory. >>Andy >>art100@psuvm.bitnet / a1t@ecl.psu.edu > > --David A. Lyons bitnet: awcttypa@uiamvs neighbor@csd4.milw.wisc.edu
phaedrus@blake.acs.washington.edu (the Wanderer) (03/04/89)
In article <1423@csd4.milw.wisc.edu> neighbor@csd4.milw.wisc.edu (Jeffrey Alan Ding) writes: >In article <8903022345.aa13273@SMOKE.BRL.MIL> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes: >>>From: "Andy Tefft (814) 862-6728" <ART100%PSUVM.BITNET@CUNYVM.CUNY.EDU> >>>Subject: single-drive programs >> >>>[...] How hard is it to make a program say "volume not found. please >>>insert correct disk or press <esc> to exit" and wait for your answer, >>>INSTEAD of just saying "Volume not found" and ending!!? >> >>[description of technique involving GET_MARK and CLOSE followed by >> OPEN and GET_MARK] > >Not necessary. All one has to do is an ONLINE call to make sure the correct >volume is in the drive. The requirements are that you know the volumes of >both disks, the SOURCE disk and the TARGET disk. > >Get the volume of the SOURCE disk, OPEN input file, READ from that file and >perform any operations on the data. Then do an ONLINE call, prompt user >to insert TARGET disk if not online, OPEN output file and WRITE out data. > >Then do another ONLINE call, prompt user to insert SOURCE disk if not >online, READ from input file and perform any operations on the data. >Do an ONLINE call, prompt user to insert TARGET disk...... and so forth. > >This routine can be built into the same code as the non disk swapping >code. Do an online before you open any files to make sure the SOURCE >disk and TARGET disk are online. If they are, then no swapping will take >place and the ONLINE calls are unecessary. If both volumes are not online, >then you make the ONLINE calls each time you move between reading and writting. > >As for the comment on not enough memory to support swapping - nonsense! >Adding this code would take less than 1/4K of memory. > I'm not sure that I follow the logic of this. The ONLINE call at the very beginning makes good sense; and, as you say, if both volumes are on-line, nothing further need be done. If they are not, and unless the machine spontaneously sprouts another drive during the process, it seems unnecessary to do an ONLINE between each read and write; you just got done reading from, say, the source disk, so you *know* that the destination disk isn't going to be there. In fact, in this situation, the sensible time to do the ONLINE call is *after* you have prompted the user to change disks and the user has pressed a key to continue--so that you know that the user has put the proper disk in the drive. Also, in this situation, the program should *definitely* remember its position in the file and close the file when it is not actually being read from or written to, as David Lyons described. Any time a user is changing disks during a process, the number of things that can go wrong boggles the mind... and keeping the file on the removed disk closed minimizes the risk that such a mistake will trash the directory of the destination disk or do something equally nasty. Oh, yes; when using an ONLINE call for this sort of purpose, always use the form of the call that checks a specific slot and drive, not the form that scans all slots and drives in the system. The most annoying form of program in existence has got to be a certain utility I have (which shall remain nameless), which copies files in exactly the manner described, and constantly... makes...that annoying...grinding...noise...on every... 5.25" floppy... drive in... the system... while it satisfies... itself... that neither... of the disks... you're using... have moved... lately. (I'm sure that someone out there will recognize the program... :) ) -- Mark VanWinkle Computer Science Hopeful, University of Washington INTERNET: phaedrus@blake.acs.washington.edu DISCLAIMER: Whatever it was, I was nowhere near it at the time.
Jerry.Kindall@f10.n226.z1.FIDONET.ORG (Jerry Kindall) (03/06/89)
The only problem with the ONLINE call is that if you make it on a device
which has open files, and someone has switched the disk, ONLINE will
return an error. This means that it's no good to have files open while
supporting one drive, and using ONLINE to do it.
I did manage to do it, though, with a GET_FILE_INFO call on the volume
directory of the disks, instead of using ONLINE. The program I wrote is
in BASIC (using MicroDot to do the reading, writing, etc.) but the &.F
command is basically equivalent to GET_FILE_INFO.
- Jerry Kindall
Send mail to: jerryk%pro-beagle.cts.com@nosc.mil
crash!pnet01!pro-beagle!jerryk
jerryk@pro-beagle.cts.com
GEnie: J.KINDALL
Alink: JKindall
--
Jerry Kindall via cmhGate - Net 226 fido<=>uucp gateway Col, OH
UUCP: ...!osu-cis!n8emr!cmhgate!10!Jerry.Kindall