dbTalk Databases Forums  

Strange File conundrum

comp.databases.pick comp.databases.pick


Discuss Strange File conundrum in the comp.databases.pick forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Steve Douglas
 
Posts: n/a

Default Strange File conundrum - 03-30-2011 , 11:06 AM






Anybody ever seen this message? It's a new one on me. When we try to access this particular file it returns this message. There are no processes running that could be actually deleting this file. The POVF is not changing.The Base Frame MD item for the file is still there as is the DICT RANDOM.FILE.NAME RANDOM.FILE.NAME item that defines the data area. This is on D3 7.5.1/Linux.

[160] File 'RANDOM.FILE.NAME' in the process of being deleted.

Evidently there's a flag set somewhere that says this file is being deletedbut I don't know where. I don't see anything in locks or anywhere I'm familiar with.

Thanks,
Steve

Reply With Quote
  #2  
Old   
Tony Gravagno
 
Posts: n/a

Default Re: Strange File conundrum - 03-31-2011 , 03:24 AM






Steve, I have seen that message and I believe you're right. That
message is the result of a bit set in the File Control Block, which is
a frame appended to the back end of all files for such housekeeping.
If you have a file with a mod of 1, there are two frames, the data
frame and the FCB. If the FCB is corrupted, someone in TL support can
use the debugger to reset the bit for you with the debugger. If the
problem is more serious, like a seriously corrupted FCB, then they
will probably recommend copying the data to a new file, deleting or
zapping this file, then renaming the new file to the current name,
thus shuffling your data back into place.

So I think this can be resolved with a call to TL.

HTH
T

Steve Douglas wrote:

Quote:
Anybody ever seen this message? It's a new one on me.
When we try to access this particular file it returns
this message. There are no processes running that
could be actually deleting this file. The POVF is not
changing. The Base Frame MD item for the file is still
there as is the DICT RANDOM.FILE.NAME RANDOM.FILE.NAME
item that defines the data area. This is on D3 7.5.1/Linux.

[160] File 'RANDOM.FILE.NAME' in the process of being deleted.

Evidently there's a flag set somewhere that says this
file is being deleted but I don't know where. I don't
see anything in locks or anywhere I'm familiar with.

Thanks,
Steve

Reply With Quote
  #3  
Old   
Steve Douglas
 
Posts: n/a

Default Re: Strange File conundrum - 03-31-2011 , 07:53 AM



Tony,

Thanks for the detail. I was waiting on a callback from Zumasys (who holdsthe support contract on that box & TL on it but I thought I'd ask while I was waiting. Sorry for the wasted effort there. TL zapped the file definitions and we'll recreate it later today. We lost the frames until the next restore but that's not a biggy. Luckily it was in a "rebuildable" file.

Steve

Reply With Quote
  #4  
Old   
Frank Winans
 
Posts: n/a

Default Re: Strange File conundrum - 03-31-2011 , 11:29 AM



I'd be delighted if TL ever puts out a verb that lets end-users
discard a file and all its frames on their own; detected gfe's
just give me the willies, and migrating the problem file to
a DX'd 'trashcan' account just doesn't seem satisfying enough.
{Maybe restraining it so it doesn't kick in until next time you bring
up D3 would make it easier to design and test...}

Reply With Quote
  #5  
Old   
Tony Gravagno
 
Posts: n/a

Default Re: Strange File conundrum - 03-31-2011 , 01:43 PM



"Frank Winans" wrote:

Quote:
I'd be delighted if TL ever puts out a verb that lets end-users
discard a file and all its frames on their own; detected gfe's
just give me the willies, and migrating the problem file to
a DX'd 'trashcan' account just doesn't seem satisfying enough.
{Maybe restraining it so it doesn't kick in until next time you bring
up D3 would make it easier to design and test...}
I can write a utility to do that. No one has ever asked for it
before. Of course anything I come up with wouldn't be free. So would
your delight be predicate on whether that functionality was free?

T

Reply With Quote
  #6  
Old   
Frank Winans
 
Posts: n/a

Default Re: Strange File conundrum - 03-31-2011 , 04:50 PM



"Tony Gravagno" wrote
Quote:
"Frank Winans" wrote:

I'd be delighted if TL ever puts out a verb that lets end-users
discard a file and all its frames on their own.

I can write a utility to do that. No one has ever asked for it
before. Of course anything I come up with wouldn't be free. So would
your delight be predicate on whether that functionality was free?

T
I can but ask my boss; we're a D3 shop but I myself don't own d3 or
anything like it. I presume it would take a different copy of the utility
for d3/nt since other platforms (still) have no fsi: , and I live in hope
that it would still work on near-future releases of same-platform d3...

Reply With Quote
  #7  
Old   
Tony Gravagno
 
Posts: n/a

Default Re: Strange File conundrum - 04-01-2011 , 06:37 PM



"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote:

Quote:
"Tony Gravagno" wrote
"Frank Winans" wrote:

I'd be delighted if TL ever puts out a verb that lets end-users
discard a file and all its frames on their own.

I can write a utility to do that. No one has ever asked for it
before. Of course anything I come up with wouldn't be free. So would
your delight be predicate on whether that functionality was free?

T
I can but ask my boss; we're a D3 shop but I myself don't own d3 or
anything like it. I presume it would take a different copy of the utility
for d3/nt since other platforms (still) have no fsi: , and I live in hope
that it would still work on near-future releases of same-platform d3...
What I have in mind would work in VME only but for all D3 platforms.

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.