18 replies to this topic

[Amy]

Hi.

I was just making a simple change to a function that seems to have corrupted a file called DBSLREF.

Does anyone know how I can fix this quickly? I can not gen the file. I have checked other functions using the file and they seem okay. I have gotten in the habit of copying my prodata & prodev directories when ever I have a system problem I can't explain and the copy usually fixes the problem. This time it didn't.

I am using SL version 5.5 version 3.2.5

Thanks for your help... quickly, if possible!!

- Amy

[Rob Donovan]

Hi Amy,

It sounds like the file dbslref is corrupt.

Firstly, I would be very careful in what you are doing with 'copying' your system like you say.

Copying your system to fix errors, is simply hiding the problem, and may well be causing bigger problems for you in the future. It almost certainly is not 'fixing' the problem, and I would not recommend doing that.

You should never copy a file (or dir), when someone else has it open, as it can corrupt the copy of the file.

You should make sure that there is no one accessing ProIV first, by checking with the 'ps' command for any 'pro' sessions.

Once you are 100% sure there is no one in ProIV, you should run an ischk *.pro in your prodev & prodata dirs.

This will check to see if there are any corrupt files.

You should NOT use ischk to fix the problem (say no to any fix questions), as ischk can lose data and make the file worse.

If you find any corrupt files, you need to decide what to do on a file by file basis, some files maybe you can remove and physically create because they are just workfiles.

Files that are not workfiles need to be either restored from a backup, or you can try to 'salvage' the data by writing updates to copy the data out.

You could list any corrupt files here, and I can possibly help you with fixing them if you want, but only the prodev files.

HTHs a bit,

[DARREN]

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

[Amy]

Hi Amy,

It sounds like the file dbslref is corrupt.

Firstly, I would be very careful in what you are doing with 'copying' your system like you say.

Copying your system to fix errors, is simply hiding the problem, and may well be causing bigger problems for you in the future. It almost certainly is not 'fixing' the problem, and I would not recommend doing that.

You should never copy a file (or dir), when someone else has it open, as it can corrupt the copy of the file.

You should make sure that there is no one accessing ProIV first, by checking with the 'ps' command for any 'pro' sessions.

Once you are 100% sure there is no one in ProIV, you should run an ischk *.pro in your prodev & prodata dirs.

This will check to see if there are any corrupt files.

You should NOT use ischk to fix the problem (say no to any fix questions), as ischk can lose data and make the file worse.

If you find any corrupt files, you need to decide what to do on a file by file basis, some files maybe you can remove and physically create because they are just workfiles.

Files that are not workfiles need to be either restored from a backup, or you can try to 'salvage' the data by writing updates to copy the data out.

You could list any corrupt files here, and I can possibly help you with fixing them if you want, but only the prodev files.

HTHs a bit,

[Amy]

Hi Rob,

In response to your concern about copying directories... I have had an on-going problem that I have looked for help with and still have no answer. On occasion my system locks up. When this occurs my users cannot work. I work alone and tried to find the causes - I believe there are few things that cause this to happen but have not been able to eliminate the problem. I had many calls with PROIV and wrote in here a few times but nothing has helped. I have seen two posts with the same problem - one turned out to be symantic security software causing the exact same problem - this helped me discover that my server has a program called livesystem by iomega that completely freezes my PROIV application - I do not have to "fix" or "copy" my directories when the system freezes for this reason. Another time I thought I found the problem - I had left a period in function code (I believe someone else later had the same problem). I currently "blow-up" the system if I gen a function that references a file with a propath set that doesn't exist. If I accidently don't catch this my system locks up and the users can't work. I then must log off all users, stop Proiv, copy prodev and prodata, modify pro4.ini to point to new files, restart proiv and everything is fine.(users lose 15 minutes) I don't want to do this and sometimes I go months without having to but then there are times when I am making lots of changes and it might happen every week. I work in fear of locking up the system... my customers can't work without their system. The copy works, Milo talked me through ISCHECK etc but nothing ever fixed the problem - only the copy. If you can tell me how to prevent the system from locking up I would really appreciate it!

When I say lock up - there is a delay of minutes with every thing or we all just get locked and if I abort myself my users start to get in their functions. If the lock up is a result of something I genned I quickly abort myself and wait to see if they are very slow, if they are I copy the directories and we all can work again.

Just wanted to make it clear that copying was the only thing I can find that works...

Thanks for any insight, Amy

PROIV superlayer 5.5 version 513

[Rob Donovan]

Hi Amy,

What O/S are you working on?

Rob.

[Amy]

Hi Amy,

What O/S are you working on?

Rob.

Hi

my O/S is Windows XP

Amy

[Donald Miller]

Hi Amy

You said " I currently "blow-up" the system if I gen a function that references a file with a propath set that doesn't exist"

I appreciate that people work in many different ways but is there a reason why your files need an alternate path name?
Why can the ".pro" files not all exist in the same directory and therefore not require the use of an alternate name (if the PRODATA is set in the pro4.ini file)?

Or have I misunderstood the problem?

Donald

[Amy]

Hi Donald -

I do not need the propath set - I am modifying old code that used alternative files for master files that many accounts shared... right or wrong, the propath is set and I haven't caught them all. I can open every single file but I haven't. I didn't realize that it would cause such problems - I thought it was faster to just gen the function, try to run it and correct problems that I found .

My problem isn't so much that I have these alt files causing the system to lock -because other things have caused the same result. I don't know what is happening within PROIV to fix the situation...that's my problem. I understand that copying seems like a strange way to fix the situation but I have users that can't work if I don't make the copy and I work in fear of locking up their system.

Thanks for any help, Amy

[Donald Miller]

Hi Amy

From what you've said it sounds like you're changing the code in the same environment the users are operating in. Is there no "development" environment?

If there is really only one environment then generating a proper development environment completely separated from your users should mean that you can change and gen what you like without affecting your users (in most cases - it's hard to be precise without knowing more about your hardware and Pro IV set up)

Then when you are happy with the performance of the functionality that you've changed, you can export/import it into the users environment using the appropriate Pro IV feature.

Or are you in this position because there is inadequate room for a duplicate environment?

[Rob Donovan]

Amy,

If you want to, create a prx (or slx, but prx would be better) of a function & filedef that locks up your system, and email it to me (rob@proivrc.com)

I will see if it locks up my system...

Rob.

[Amy]

Donald, I am working in a test environment most of the time. When I have the problem - my live system locks up too! I have two seperate prodev and prodata directories.... can you tell me - when I am in a function (SLFUNS) and I attempt to open a logic it appears to freeze and if I wait (no users working) eventually the code appears .... what is going on during the lapse of time? In my mind PROIV got it's directions mixed up and is running around looking for my code. I think the copy resets the links to find my logic and stops the system from dragging because it is no longer frantically looking for my code.

Rob - I will try to send you an export file to see if you can help - thanks so much for your help.

Thanks again, Amy

Amy,

If you want to, create a prx (or slx, but prx would be better) of a function & filedef that locks up your system, and email it to me (rob@proivrc.com)

I will see if it locks up my system...

Rob.

[Rob Donovan]

ok...

To be honest, it sounds like the ProISAM system is getting its self in a mess, and therefor all ProISAM access is causing problems.

That would be my first thought... but I need to think of a few things to check out.

Most of my exp. 'problem' sovling with ProIV is on Unix systems. I dont run ProIV much on Windows, apart from testing...

Rob.

[Donald Miller]

Hi Amy

It sounds like Darren's answer might solve your problem - did you re-create the file as he suggested or did the manual indicate otherwise?

I don't use Superlayer but if a file it's accessing is fragmented because it's overfilled then it will be all over the place trying to get the records which of course will take longer than usual. The fact that it does eventually get the records strongly suggests that excessive numbers of records for the current file size(s) could be your problem.

When was the last time you did some "housekeeping" within Pro IV?

Pro IV recommend on Windows environments that this is carried out regularly. One of my customers had a problem many years ago (with 1.5 I think) because of this. Once the housekeeping was done (and repeated) the problem didn't re-occur. The procedure varies a little from site to site and between operating systems but, in general, once a month should help.

In the "old days" of Pro IV it was more necessary (mainly because disks weren't so large and processors so powerful). Once the routine had been completed the improvement in perfomance was amazing. But we're talking a 286 12 MHz processor with 10 Mb total disk space, 8 were used and Pro IV occupied about 1.5 Mb (the whole system including data).

It was simpler then......

Donald

[Amy]

Hi Donald - that's a new thought - could I be maxing out on regens? when you say housekeeping are you talking about within PROIV files (not my customer data.pro files but the filedef.pro, functdef.pro, slfun.pro...files)? My system is not large - but sometimes I might gen the same function every couple of minutes...or I might be genning many functions quickly then all of a sudden I'll gen something and cause the freeze.... oh - I feel like you might be on to something! The only thing is, I never had this problem in the past but I was just programming and knew nothing about any behind the sceenes maintenance ... I only took care of cleaning up users data

Amy

Hi Amy

It sounds like Darren's answer might solve your problem - did you re-create the file as he suggested or did the manual indicate otherwise?

I don't use Superlayer but if a file it's accessing is fragmented because it's overfilled then it will be all over the place trying to get the records which of course will take longer than usual. The fact that it does eventually get the records strongly suggests that excessive numbers of records for the current file size(s) could be your problem.

When was the last time you did some "housekeeping" within Pro IV?

Pro IV recommend on Windows environments that this is carried out regularly. One of my customers had a problem many years ago (with 1.5 I think) because of this. Once the housekeeping was done (and repeated) the problem didn't re-occur. The procedure varies a little from site to site and between operating systems but, in general, once a month should help.

In the "old days" of Pro IV it was more necessary (mainly because disks weren't so large and processors so powerful). Once the routine had been completed the improvement in perfomance was amazing. But we're talking a 286 12 MHz processor with 10 Mb total disk space, 8 were used and Pro IV occupied about 1.5 Mb (the whole system including data).

It was simpler then......

Donald