Dir function problem (AREV Specific)
At 17 NOV 2003 12:26:07PM Victor Engel wrote:
I have a program that essentially does the following:
initdir directory:'*.*'
loop
x=dirlist()Gosub sortlist (sorts X alphabetically)for i=1 to numentriesfilename=x[i]filesize=dir(directory:filename)if len(filesize) then gosub process_file_then_delete_it else* Houston, we have a problem.
debug
endnextcall delay(some_delay_time)repeat
The program goes to the debugger. When I notice Arev is in the debugger, I /filename to see what file is being processed. Then I shell to DOS to get the file size and /filesize in the debugger to set the variable then g to proceed.
It appears that only one workstation has this problem. I'm going to do a cold boot of the computer to see if that resolves the problem, but I'm wondering if anyone has an idea of what causes this.
By the way, there is also locking logic that guarantees no other workstation is attempting to work on this file. Anyway, if they did, they'd delete the file when finished. It's still there when I encounter the problem.
The puzzling thing to me is that dirlist reveals the file but dir() reveals no details about it.
At 17 NOV 2003 12:26PM Steve Smith wrote:
Check for other file attributes (system/hidden) being set, or for the file in question being open by another process (ie size appears to be 0).
What attributes does the dir function care about? I'll check this, but I don't think it is an issue.
Recall what the Netware FLAG.EXE utility shows. Novell keeps its own attribute bits ( shareable and execute only ) bits in the file allocation table next to DOS's directory / read only / system / hidden / archive / volume bits. I recall there was a $NOVATTR routine somewhere in my distant past which reported these attributes. Someone may still have a copy they'd like to send me . AREV DIR() function returns the file size data. And the only place that's kept is in the FAT entry for the file. I've seen the adjacent Novell bits being set and thus causing confusion for some DOS routines that assume these bits will be left unset. Typically this involves logical AND on the file attribute byte to check the file attributes, followed by a conditional jump. Once the "readnext file" call fails (used in the INITDIR call) on a strange file type all subsequent calls to "readnext file" may fail if the Carry Flag bit in the CPU is not cleared. I've written this bug into my Novell routine prototypes before (and had to amend those routines accordingly when I found out the hard way - your bug sounds very similar to mine). ] What does STATUS() return if you try to OSOPEN/OSDELETE? I'll add code to check that. Currently a message is displayed before an OSOPEN is attempted if the dir function returns null. My documentation shows no information for STATUS() being set for the dir function. Is this correct? Can't recall. I'm interested to see if Novell is somehow delivering a value.
I'm thinking that the problem is related more to stale connections to the server. I can't say this with absolute certainty, but it appears that only one workstation is affected. I've cold booted it and am monitoring again.
I have no idea why this might occur, but I have had some networks destroy connections in the middle of AREV sessions before. The "filesize modulo 65536=21930" problem only applies to OSREADs not immediately OSOPENed beforehand. I thought the problem may have been associated with progressive reads on a directory, and not the DIR itself. </QUOTE> —- === At 17 NOV 2003 12:26PM Steve Smith wrote: === <QUOTE>Just noticed a $NOVSPEC function which may have been written in part to cure this problem - possibly for Victor Ratnieks in Adelaide, if I recall. You can use it exactly like the DIR() syntax http://www.state-of-the-art.com.au/util26.zip I don't know if it works nowadays, but the price is right… </QUOTE> —- === At 17 NOV 2003 12:26PM ps wing wrote: === <QUOTE>You are not trying to reference long filenames are you? </QUOTE> —- === At 17 NOV 2003 12:26PM Victor Engel wrote: === <QUOTE>No. </QUOTE> —- === At 17 NOV 2003 12:26PM Victor Engel wrote: === <QUOTE>Steve, Great feedback. Before I answer the individual points, I'd like to point out that the lab has 10 identical PCs in two basic configurations doing identical things. They each poll a central pool for file existence. The pool is located in a directory on the network (Netware). Files are downloaded from the mainframe to this directory using ftp. When the ftp process is completed, an empty file of the same name is written to a separate directory whose purpose is to flag when updates to the actual file are complete. From the Arev side, the flag directory is the one being polled for the empty file (INITDIR and DIRLIST are applied to this directory). If one is found, then the data directory is checked for the file (DIR function is applied to this directory). The first thing that is done is the size of the file is read using the DIR function (for reporting purposes). Since we got here by checking the existence of the flag file, we know updates are complete. For extra measure, though, a loop (which should not be needed) is created to wait some seconds before a retry in the case that the dir function returned a null. The loop expires after 275 seconds at which point the message is displayed. I added this for diagnostic purposes when the problem surfaced a couple weeks ago. In every case where the message has appeared, when I checked for the file, it was there in good condition. This process has proceeded for well over a year now with no failure of the dir function until October of this year. ] Check for other file attributes (system/hidden) being set, or for the file in question being open by another process (ie size appears to be 0). What attributes does the dir function care about? I'll check this, but I don't think it is an issue. ] What does STATUS() return if you try to OSOPEN/OSDELETE? I'll add code to check that. Currently a message is displayed before an OSOPEN is attempted if the dir function returns null. My documentation shows no information for STATUS() being set for the dir function. Is this correct? ]Does the filename actually have a space or CHAR(255) in it? No. ]Is this a network drive or a local one? Network drive. ]Have you tried a flush ahead of each OSOPEN? This is before OSOPEN. I'm only doing a DIR at this point. ]Are you OSOPENing ahead of each OSREAD? No OSOPEN or OSREAD happens if DIR returns null. ]Is the file size /65536 give a remainder of 21930? Is this issue relevant to the DIR function? Files are always a multiple of 35000 bytes I believe. When recognized properly, they are OSBREAD in blocks that miss 21930 boundaries. ]Do you have write-behind caching enabled on the drive in question? Supposedly not, but I will double check this as well. I'm thinking that the problem is related more to stale connections to the server. I can't say this with absolute certainty, but it appears that only one workstation is affected. I've cold booted it and am monitoring again. </QUOTE> —- === At 17 NOV 2003 12:26PM Steve Smith wrote: === <QUOTE>Check for other file attributes (system/hidden) being set, or for the file in question being open by another process (ie size appears to be 0). What does STATUS() return if you try to OSOPEN/OSDELETE? Does the filename actually have a space or CHAR(255) in it? Is this a network drive or a local one? Have you tried a flush ahead of each OSOPEN? Are you OSOPENing ahead of each OSREAD? Is the file size /65536 give a remainder of 21930? Do you have write-behind caching enabled on the drive in question? Steve </QUOTE> —- === At 17 NOV 2003 12:26PM Charles Milner wrote: === <QUOTE>What's the significane of the /65536 problem in the Dir function? Is there a work around? </QUOTE> —- === At 17 NOV 2003 12:26PM Steve Smith wrote: === <QUOTE>Charles, The problem exists not on the dir() function, but the osbread statement whenever the offset mod 65536=21930 The workaround is to OSOPEN the file on the line immediately before the OSBREAD. Sorry for the confusion. Steve </QUOTE> —- === At 17 NOV 2003 12:26PM Steve Smith wrote: === <QUOTE>And I knew** I had deja vu about this
At 17 NOV 2003 12:26PM Steve Smith wrote:
At 17 NOV 2003 12:26PM Victor Engel wrote:
Enjoy conversing with yourself, Steve?