Pecas - roll and warm questions

D

dacust

New Member
First, I know nothing about Progress (or Pecas for that matter), and I'm far from being a Unix expert. We have an HP UX system running Pecas that came with a company we bought. We are phasing it out.

I'm having disk space problems, and it seems that either the "roll" or the "warm" procedures are doing that. Since this system will only be used for history after this weekend, can I turn those functions off? My guess is that it is a database re-org.

I didn't want to clutter up this post with lots of useless details, but I can find out anything you need.

From what I see, the "roll" function is a Progress deal. Not sure about the "warm" stuff.

-dan

My programs don't have bugs, they just develop random features.
 
Just guessing, since I don't know what pecas is, but in the generic Progress world "roll" and "warm" would probably refer to a "roll forward" process on a "warm spare" database.

You would find evidence of this in the .lg files of the source and target databases. Messages about switching ai files and applying ai files should be present. You would also have after-image extents defined for the database.

If no such evidence exists stop reading.

In such a scenario the disk space usage is probably coming from archived after-image extents. If you can find those and purge them you can probably not worry about it.

If that is the process being described and if there really are no updates to the database and if you have a good backup or just don't care if you lose everything then yes, you could, disable the process. At least in theory...

The gory details could get messy. There are a lot of ways to actually set this up and I can't think of a generic way to explain selectively shutting it off in a neat and clean manner. (The ugly way would be to disable after-imaging -- but that might result in a lot of annoying errors that you'll need to get used to ignoring...) If you're willing to dig through scripts you would want to look for "rfutil" (or "_rfutil") commands. They are closely associated with after-imaging.
 
Thanks for the ultra-quick rely!

Hmmm. That kinda fits, but not quite to my satisfaction.

There is a .lg file, but only 8344 bytes.

The database directory:
Code: 
-rw-rw-rw- 1 root root      17767 May 14 00:31 OLDgscust1.log
-rw-rw-r-- 1 root sys      131072 May 14 16:40 gscust1.a1
-rw-rw-r-- 1 root sys      131072 May 14 15:40 gscust1.a2
-rw-rw-r-- 1 root sys      131072 May 14 16:40 gscust1.a3
-rw-rw-r-- 1 root sys     5144576 May 14 01:14 gscust1.b1
-rw-rw-r-- 1 root sys     5144576 May 14 01:15 gscust1.b2
-rw-rw-r-- 1 root sys    85327872 May 14 16:40 gscust1.b3
-rw-rw-r-- 1 root sys    51249152 May 14 16:40 gscust1.d1
-rw-rw-r-- 1 root sys    51249152 May 14 01:14 gscust1.d2
-rw-rw-r-- 1 root sys    51249152 May 14 01:14 gscust1.d3
-rw-rw-r-- 1 root sys    51249152 May 14 01:14 gscust1.d4
-rw-rw-r-- 1 root sys    51249152 May 14 01:14 gscust1.d5
-rw-rw-r-- 1 root sys    51249152 May 14 01:14 gscust1.d6
-rw-rw-r-- 1 root sys  1324515328 May 14 01:15 gscust1.d7
-rw-rw-r-- 1 root sys       32768 May 14 01:14 gscust1.db
-rw-rw-rw- 1 root sys        1644 Feb 21 2004  gscust1.ds
-rw-rw-rw- 1 root root       8344 May 14 17:12 gscust1.lg
-r--r--r-- 1 root sys      847934 May 14 17:00 gscust1.lic
-r--r--r-- 1 root root         38 May 14 01:15 gscust1.lk
-rw-rw-rw- 1 root sys          73 Mar  9 2003  gscust1.pf
-rw-rw-rw- 1 root sys         660 Jan 21 2005  gscust1.st
-rw-rw-r-- 1 root sys          84 Mar  8 2003  gscust1.v8pf
-rw-rw-rw- 1 root sys        1191 Nov  4 2000  owner.out
The gscust1.d7 is what's growing. It grows whether people are using the system or not.

crontab has these entries, if this helps:
Code: 
30 23 * * * /usr/local/bin/update_warmdb.wrapper #PECAS warm database update
40 1-22 * * * /usr/local/bin/roll_forward_db.wrapper #PECAS roll forward databa
I was thinking of commenting the above entries out.
 
It is possible that something is truncating the .lg file.

Commenting out the cron entries would stop some roll forward process. But I cannot tell from looking at what you've provided if the roll forward target is gscust1 or some completely different database. You'll have to look through those scripts to determine that.

In any case... for the database to be growing there must be a source of data that is still active. Rolling forward "nothing" results in zero database growth. So somewhere there is a source of transactions that are creating records in your database (or databases).
 
OK, thanks for your help. I was looking for an easy fix.. yeah, right.

The developer says nothing is running to create anything. But this is the same developer that maintains the production directory with ~1200 objects, 974 of which are dated copies, but can't clean them up because they don't know which ones "might be important"....

Oh, well. Production will be off of it after this weekend (was supposed to be last October). I can probably keep it running another coupla months by scrounging for stuff to delete. After that, if it crashes, we can just send it back to the leasing company.

Anyway, thanks again. At least I have something to tell my boss.

-dan
 
You must log in or register to reply here.
Back
Top