8 replies to this topic

[mikelandl]

Hi all,

I want to write a small shell script to monitor the integrity of all the ProIsam files on a server. What exactly should I be looking at with respect to each file? File size? Paging size? Load factor? A combination of some or all of those?

Thanks in advance.

[Kevin Bruss]

I recall an issue with a pro-isam file being over 2GB on a unix box faces corruption..
I wrote a script that looked for size of 1.5GB and over; it performed an ischk, then if errors, would issue an email for further review.
This was done during off-hours.
To fix, we'd use the isout, clear the file, then do an isin.

[mikelandl]

Thanks Kevin,

How was your script checking for error messages from ischk? I've run ischk before on some pro files that I purposely corrupted (adding and deleting characters in a test editor) and some error messages were sent to stdout and some to stderr.

[Joseph Bove]

Mike,

You can search this board for a number of posts about this.

Basically, you want to look for corrupt or rebuild. If folks are guaranteed off the system,ischk -y *.pro with redirected output is quite helpful.

The other thing to look out for is the max file size. Even though 2 Gig is now the max file size, it does not mean that all files will automatically grow to 2 gig.

Below is a Unix script we use to check file sizes.

hth,

Joseph

# This script informs the user of the maximum file size allowed for a ProISAM
# file

currentsize=`ls -l $1 | awk '{print $5}'`
maxfilesize=`/atc/proiv/iskeys -n -sz $1 | awk '{print $7}'`
keysize=`/atc/proiv/iskeys -n -sz $1 | awk '{print $4}'`

case $maxfilesize in
   1024) maxsize=64000000;;
   1000) maxsize=64000000;;
   1536) maxsize=192000000;;
   1530) maxsize=192000000;;
   1500) maxsize=192000000;;
   3000) maxsize=384000000;;
      *) maxsize=32000000;;
esac


percent=`echo $(($currentsize / ($maxsize / 100)))`
#percent=`expr $currentsize \* 100 / $maxsize`

echo $1 key: $keysize size: $currentsize of $maxsize Usage: $percent%

[mikelandl]

Thanks Joseph, I think that might just do it.

[Kevin Bruss]

Hi Mike,

Well first, I'd use the 2>&1 so that stdout and err get written to the same temp log; something like this:
ischk -s -n tmpdesc.pro >$mylog 2>&1

In testing, I made corrupt file (echoing "testing" to a bogus .pro file, then cat'ing a real .pro file to it)

> ischk -s -n fdesc.pro >mylog 2>&1
(in log) fdesc.pro: 70785 records

> ischk -s -n kdesc.pro >mylog 2>&1
(in log) kdesc.pro: 101 - Corrupted isam file.

I don't have the original script at my disposal, but it was pretty basic to put together; as in above, I might check for a condition of 'corrupt' or just 'records', presuming that an error condition would not report this.

[Chi Sum Cheung]

Please correct me if I'm wrong, but I had the understanding that PRO-isam files (not C-isam) is limited to 384 megs on a unix system (at least thats what the "Environment Guide 55r300.pdf" says... chapter 7, page 91).

I've done some brief testing (with v55 r323) a fair while ago now (and it's not conclusive in any way). I noticed that upon hitting the limit (somewhere between 380meg and 400meg), records are dropped (not written) into the file yet pro4 continues on processing.

Has this changed? (is there new doco somewhere?)

[Lewis Mccabe]

PRO-IV 5.5 rel 5.1.7 supports up to 2 gig pro-isam files. We have not performed any tests though.

Lew

[Joseph Bove]

Chi Sum Cheung,

I noticed that upon hitting the limit (somewhere between 380meg and 400meg), records are dropped (not written) into the file yet pro4 continues on processing.

From our (and our clients') experiences when a ProISAM file on Unix hits its limit, it will usually generate error in writing messages. The file nearly never rebuilds nor is capable of isout'ing. In a pinch, you can write an update to read from the old file def and post to a larger file size.

In Windows, the file will stop posting, but no errors will occur. The file does not corrupt, it simply stop growing.

I'm not sure that there is any hard and fast rule about what is supposed to happen...

That's just what we've seen over the years.

hth,

Joseph