Hard drive problem

[Joseph Huber_1]

I have the impression, following all these analyze messages is more confusing than helpfull to You.

To really find the reason why a file is not created, look at the point where it is done:
VMS does not silently ignore an error.

Do what I said earlier : diagnose the program creating the file. If it is a DCL command (CREATE,COPY,...), You get a clear text message.
If it is an executable written in C: fopen or creat return an error code in errno, use perror() to print the associated message.

If it is created by VMS RMS functions (SYS$OPEN,SYS$CREATE) or similar, they return a VMS condition code.

[Uwe Zessin]

Yes and no ;-)

Judging from some old threads it looks like Scc deals with unreliable hardware, so a test is not too unreasonable.

On the other hand: Scc does not always tell us the full error message which makes it hard for us to help more efficient.

[Scc_3]

Hello,

Yes, I am sorry the way I asking question sometimes or most of the time I don't or I can't give out all information. I might not have all the fact in time and I keeping adding more in sprogress.

Well let me try one more time to explain the problem and go from there.

The programs that the users use here been running fine for years and years of cause there are update on that programs to fit what they need.
The last update of that program was dated 15 June 2005 and it been running fine.

2 weeks ago monday morning, at 8:00 am morning, the girl show up to work and running that program to create quotation for the customer. What my programs does is to open a input screen and let them input the customer information at a header file and then the program will create a filename call q123456.319 for items input .(example) Q = quote, 123456 is the next quote number and 319 is the date.
to create this quote number, the program sent a comment to the vax
lstatue = fil_open (filno_qlitem,filname,'new',"keyed',0,0)
filno_qlitem, preset format length of file size.
filname = q123456.319 (in this case)
new - new file
....etc.

This q123456.319 should be created before the program kicks in to next program, but that morning don't. There is no error message for the Vax, except from my program, saying
" can't not open q123456.310"
"can't find q123456.319, file not found, error 46"
error 46 inconsistend open/close file.

Since the program assume this file got to be create before but they don't. Kick the user back to main program.

I try it, same error, So I move the user to poining at dka100:[trs.data] which is a backup disk for data I backup a nite before to get information and everything work
same program just pointing at dka100: instead of dka400:

1 week past, everything still running good.
I copy all the current date from dka100: back to dka400: and let the user using the dka400: to get data or write to that directory. Everything is fine, no program.

1 week later, which is this monday, at 2:00 pm, it happen again, so I move the user back to dka100: and working find again.

Yesterday, with you people have I do a ANA/disk_structe and looking for error, not muct error there, except there is a quote number beem create twice on April 2005
Final, I delete them out the system.

But before I preform the ANA/DISK_STRUCTURE TEST. I ran into the old data directory with in dka400: and run my program and pointing at that directory for data information. And it work...lol, without doing anything to it.

So I assume there must be somewhere may be a bad block inside the drive and cause it.

I will let the users running on dka100: and see what will happen.

I will delete the dka400:[trs.data], all files and directory, since the information is no long good. And go from there.

This program been running for 15 yrs with update 5 -6 times a yrs. Never see this before.

I hope I get this a little clear. I am very happy to see so many people out their willing to help me out. I will try to get my message across more clear next time.

Thanks !

P.s : Sound like, all this problem start all because the Vax should create this file but it don't for a reason. I will look into this. And now I rewrite that program to tell me where it got kick out.

Scc

[Scc_3]

Opps,
One more testing I done on monday night.
I through o.k let me try to manually edit a file name example q999999.310
At dcl

$ edit q999999.310 (press return)
The Vax don't allow me, saying ACP file access delied.....The screen goes so quick can't catch them all, since I was dial-in at home, can't print that out.

But on tuesday I try the same process and it work.

It got to be something to do with the Vax on read or write to disk.

Scc

[Uwe Zessin]

> lstatue = fil_open (filno_qlitem,filname,'new',"keyed',0,0)

That looks like somebody might check the status value and if it indicates a failure the program just says "an error has occured", but it does not say which error :-(

[Scc_3]

Hello,
It can't happen, because that line is written inside the program. There is a good chance the girl might doing something and cause an error to the program not to create the file.

I already build a debug program and see how that program doing when it hit that area and also create an extra warning message. If something go wrong around that area. The error message will be diff than other. So I guess I can pin point better what cause that problem.

Scc

[Uwe Zessin]

For a full diagnostic you need to get at the 'status value' (STV) of the FAB (file access block). I'd take a look into the "fil_open" routine if you have not done so already. It looks like a Fortran program to me - see if the OPEN statement includes some attempt to 'catch' the error for you.

If you can remove this - the Fortran runtime will be able to create a traceback which includes the full error messages, something like:
%F...
-RMS-...
-SYSTEM-...

The last message is a translation of the STV.

[Ian Miller.]

Look at DFU
http://h71000.www7.hp.com/freeware/freeware70/dfu/
and
DFU VERIFY/LOCK/DIR/REBUILD devicename: