harish wrote:
> Hi guys,
>
> T24 Release: G14.0.07
>
> Jbase Release: Major 4.1 , Minor 5.7
>
> AIX Release: 5.3.0.0
>
>
> Query1:
> **********
>
> A file namely LIMIT.PARAMETER(j4) got corrupted.
>
> Hence when we try to login into globus we get an OPF error 'MISSING
> File LIMIT.PARAMTER'.
>
> On checking the physical file,the file shows a value of ZERO
> bytes!!!!!!
>
> FBNK.LIMIT.PARAMETER
> 001 F
> 002 ../bnk.data/li/FBNK.LIMI015
> 003 ../bnk.dict/F.LIMIT018]D
> As per the last update date time
>
> $ ls -l *LIMI*15
> -rwxrwx---   1 xxxx globus            0 Mar 31 14:02 FBNK.LIMI015
>
> We are sure that COB was not running during that period.
>
> On checking the PROTOCOL ,this file was not modified that day.
>
> question:
> ***********
>
> In order to  drill down to the root cause of the problem ,we will have
> to look into this issue in different dimensions. Therefore could you
> guys evaluate the different cirsumstances under which a size of a J4
> file can become 0 all of a sudden.
>
> Additional clarification:
> ***************************
>
> Could you guys give me the steps to intentionally corrupt J4 a file.
> (this would be really usefull in simualating such scenarios for our
> testing)
>
>   
Well if a program crashes, or someone uses kill -9, then all sorts of 
things can happen and working out why is not easy. First though to get 
the last modified time and not the create time, you want:

ls -lc *LIMI*15

The create time will not change once the file is created ;-)

Next, you want to take out the kill command from your system by changing 
the permissions so it can only be run by the root user, then installing 
the sudo command (all sites should install sudo). You could also replace 
it with a script that allows kill INTR and so on but does NOT allow kill -9.

When a program is killed (with -9) or aborts (segmentation violation 
etc), the if it was in the middle of file modifications it can leave the 
filesystem journal in strange states. When the filesystem comes to apply 
changes from the journal it can only deal with what is there. Sometimes 
it ends up just blanking the file.

To find out if you had core dumps, you need to first make sure that your 
AIX system is configured to allow core dump files to be created (it 
always should be). If it is not, then you will not get much further. If 
it is, then you need to look for core dumps and when they were created:

find / -name "core*" | xargs ls -lc

If you find any core dumps that were created by someone that was using 
T24, then send them to TEMENOS for analysis. If you know how to use dbx 
with a core file, then this can also help you to see where the program 
that dumped core, crashed.

Other possibilities include the fact that a poorly written/tested 
program can blank out a file. Something that ends up doing:

EXECUTE "blah blah blah >FBNK.LIMI015"

because it was building a command and got it wrong for instance.

You can also vi a file or jed it and end up writing it as empty:

vi FBNK.LIMI015
dd
:w

When a file is 0 bytes, this is a likely candidate, but so is OPENSEQ 
opening the wrong file, and any other stupid possibilities.

To guard against this, you need to be running transaction journaling of 
course, so you can load the file from a backup snapshot and replay the 
journal.

To corrupt, well do any of the above; write a program that is writing 
lots of things to the file in  a loop and kill -9 it, and so on.

It has been a very long time since there were any bugs in J4 files, and 
unless jBASE is crashing because of some rogue command or running out of 
memory, then I would look to your procedures and programs for the 
culprit (mostly).

Jim






--~--~---------~--~----~------------~-------~--~----~
Please read the posting guidelines at: 
http://groups.google.com/group/jBASE/web/Posting%20Guidelines

IMPORTANT: Type T24: at the start of the subject line for questions specific to 
Globus/T24

To post, send email to [email protected]
To unsubscribe, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to