cook@gaia.UUCP (Forrest Cook) (09/15/87)
Thanks to all of the responses to my first question about the BDOS Search for First and Search for Next commands. Most of the messages I received said that it is necessary to do the Search Next calls immediately after the Search First, and to save the filenames and/or FCBs in a buffer before doing any file operations. I have changed my code and seem to be back to square one. The procedure I am using is now as follows: Zero the lower FCB bytes and the CR byte in the FCB (as per cp/m manuals). Fill the name and extension fields with ???????? and ??? . Call Search for First with DE pointing to the FCB. Call Search for Next. (This doesn't help or hurt.) Call a routine which copies the FCB to another buffer NEWFCB. Open, Read, and Close the first file using NEWFCB, FCB is not altered. Call Search for Next. (I tried pointing DE to the FCB, no change.) The results: The search first returns with the first filename and the file is read out with no problems. The search next returns with the first filename and the read bombs out with an immediate EOF. The search for first and next both return without errors (match found). Am I missing somthing very obvious? Thanks in advance, Forrest Cook
oster@dewey.soe.berkeley.edu (David Phillip Oster) (09/16/87)
In article <330@gaia.UUCP> cook@gaia.UUCP (Forrest Cook) writes: >Am I missing something very obvious? Yes. I've seen at least four replies go by that all said: Zero the lower FCB bytes and the CR byte in the FCB (as per cp/m manuals). Fill the name and extension fields with ???????? and ??? . Call Search for First Call a routine which appends the FCB to a list of FCBs While Search for Next returns OK, DO BEGIN Call a routine which appends the FCB to a list of FCBs END When the entire list of names is built, go back, and one at a time, open, read, process, close. --- David Phillip Oster --My Good News: "I'm a perfectionist." Arpa: oster@dewey.soe.berkeley.edu --My Bad News: "I don't charge by the hour." Uucp: {seismo,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu
koko@uthub.UUCP (09/17/87)
The problem, as far as I can see, is that the BDOS has internal variables, distinct from the FCB, which are maintained in between the Search for First call and the Search for Next call, and in between successive Search for Next calls. Calls to other file functions overwrite those variables. Therefore the sequence of calls that you are using fails, since your program has no way of saving and restoring those variables -- only BDOS knows where they are stored. The most obvious, but not a very efficient, way of doing what you want to do is to maintain a count of which directory entry you are at. Each time you finish dumping a file, increment that count, then call Search for First, and then call Search for Next the number of times specified by count minus one. (The initial value for count should be one.) Don't forget to reject (and not count) entries that are not the first extension, or else a part of a file will be mistaken for a complete one. If I think of a more efficient way, then I'll post it.