Hi Amy

Darrens response was:

"DBSLREF from my recollection is a DeBugSuperLayerReference bootstrap file. It is populated at gen time by the SuperLayer pre-gen process but I also recall that there is a 'debug' switch (maybe set as an evironment variable) that controls if the debug files get built as part of the pre-gen/gen. A quick check of the docs should answer that one. I would guess that if this is turned on then this file may have maxed out on it's size. ischk the file for corruption and then I think you are safe to actually clear it iscr -e "

If it IS a debug reference file and it IS populated during the pre-gen superlayer process, then maybe you CAN re-create the file (since it appears to be a workfile). And if you are not using the de-bug feature then switch it off (as Darren indicated) so that the file is not used. This may speed up your genning process. Maybe someone who is experienced in Superlayer (like Darren) can confirm all this.

As for Pro IV internal housekeeping - what you need to do depends on your installation. Pro IV/Northgate should be able to recommend an appropriate procedure. I would make sure that absolutely no-one is using Pro IV or has been logged on and left sessions running during the time you're optimising the system - even you.

My protocol involves (for Pro IV):

ISARCH - "check" first then "pack" on all boots directories and all data directories for all the Pro IV environments, development and test

For more efficient file sizing use ISOUT and ISIN on files that don't change much

In August genning in VIP was crashing my Pro IV and it was very sluggish. After the housekeeping it was much improved.

Hope that helps

Donald

But remember - no-one should be using Pro IV whilst the ISARCH is in progress.

Hi Amy

Darrens response was:

"DBSLREF from my recollection is a DeBugSuperLayerReference bootstrap file. It is populated at gen time by the SuperLayer pre-gen process but I also recall that there is a 'debug' switch (maybe set as an evironment variable) that controls if the debug files get built as part of the pre-gen/gen. A quick check of the docs should answer that one. I would guess that if this is turned on then this file may have maxed out on it's size. ischk the file for corruption and then I think you are safe to actually clear it iscr -e "

If it IS a debug reference file and it IS populated during the pre-gen superlayer process, then maybe you CAN re-create the file (since it appears to be a workfile). And if you are not using the de-bug feature then switch it off (as Darren indicated) so that the file is not used. This may speed up your genning process. Maybe someone who is experienced in Superlayer (like Darren) can confirm all this.

As for Pro IV internal housekeeping and yes it is for optimising the *.pro bootstraps and *.pro data files - what you need to do depends on your installation. Pro IV/Northgate should be able to recommend an appropriate procedure. I would make sure that absolutely no-one is using Pro IV or has been logged on and left sessions running during the time you're optimising the system - even you.

My protocol involves (for Pro IV):

ISARCH - "check" first then "pack" on all boots directories and all data directories for all the Pro IV environments, development and test

For more efficient file sizing use ISOUT and ISIN on files that don't change much

In August genning in VIP was crashing my Pro IV and it was very sluggish. After the housekeeping it was much improved.

Hope that helps

Donald

But remember - no-one should be using Pro IV whilst the ISARCH is in progress.

Thanks Donald! - Amy

Any .pro file with a size around 32MB, 64MB or 192 MB is suspicious.
Depending on the 'page size' of the file it can take up data up to this limit.
A page size of 512 points to a max of 32Mb, 1024 to 64 MB and 3072 to 192Mb.
If you can find the ISCHK.EXE utility on your system, you check it using the -v parameter.
From the command prompt (CMD) you type:
[path]ischk -v [path]dbslref.pro

It shows you then the info.

Another method is to check the record length with iskeys32.exe
A record length of 250 points to a file max of 32Mb , 506 to 64Mb and 1530 to 192Mb
In this case the command will be
[path]iskeys32 -n -sz [path]dbslref.pro

I have also an application running under XP. My DBSLREF.PRO has 0 records and a record length of 192.

So first do the visual check of any bootstrap file. Is it near 32, 64 of 192 Mb? If so than check e.g. the record length of that file to see if it is really in the critical area.
If that is the case, your 'housekeeping' will be
1. ISCHK the file. If you encounter any corruption, do not fix the file and reply No to every question of fixing (see Rob's post) In this case you need plan B.
2. ISPACK the file. That might give the file some air to breath.
3. If the size tends to move repeatedly to the max file size, you might consider to enlarge the file size yourself.
If have experience to do that with data files, but not with bootstraps, although I guess that it's not much of a difference. It is nothing more that extract the data from the existing file with ISOUT32, recreate the file with a larger size using ISCR32.exe with the parameters of key length and record size. For a file with a total key length of 10 you can stretch it to 192Mb to define the record size to 1530 (and on versions later than 4,0 even to 384Mb using a record length of 3000 !) the command would be:
(iscr32 -k10 -r1500 newfile.pro )
Then ISIN32 the out file.
Off course 'newfile.pro' should have the same name as the file you extract the data from with ISOUT32.EXE

Furthermore, I am curious which P4 version you are working with. I know of earlier than 4.6 versions that consume lots of CPU time, ending in an almost frozen environment. I believe that with 4.6 this problem has become history.

Last another, maybe simple, idea. Are you sure, the freeze of the system is not caused by a record lock of a data file?

Hope this might help you a bit.
Richard