files with deleted records - flag ?

Exists there a flag (or somthing else) to  identify files with  deleted records ?
DSPRFD with (*MBR) is little bit too expensive . . .
asdf13Asked:
Who is Participating?
 
tliottaCommented:
asdf13:

I'm not sure why DSPFD *MBR to an *OUTFILE would be too expensive, but the various file APIs are the general alternative.

1. Create a list of the files you want to check.
2. For each file:
3. Call QUSLMBR to list the files members in a user space.
4.    For each member:
5.     Call QUSRMBRD with format MBRD0200
6.     Check number of deleted records in positions 145-148 for a zero/non-zero 32-bit binary number.

If you only want to check a single file, you don't need to create a list of files. And if the file only has a single member, you don't have to create a list of members.

In fact, if it's a single file with a single member, you can retrieve the value directly with QUSRMBRD. The API essentially does just the same as the RTVMBRD command that Dave suggested.

The QUSLOBJ API can be used to create a list of *FILE objects. If the list cannot be filtered to a small enough number to fit in a user space, the QGYOLOBJ API can supply the list dynamically.

Please elaborate on why DSPFD *MBR is too expensive. There might be ways to use it that can help.

Tom
0
 
daveslaterCommented:
Hi
you can use the RTVMBRD with the NBRDLTRCD parm

Dave
0
 
asdf13Author Commented:
Hello,
thanks for recommendation.
My intention was,  to save systemresources (performance).
Big libraries, with many files   and up to 32.000 members, takes a lot of processing time with DSPFD or RTVMBRD.  ("too expensive . . . ")
Now i  got the information, that  in former releases (<V5), a "inofficial" API  delivered the flag "contains deleted records". But this API doesn't exits yet.
 
0
 
tliottaCommented:
asdf13:

Ouch.

So many members... some ERP or similar app creating them?

Unusual elements get involved when member counts start to grow. One example is that authorities get stored with _each_ member. This is because members are actually objects themselves although we don't program for that -- we program as if the *FILE is the object. You can see this in action when you do something like CHGOBJAUT for a *FILE with many members; it can take a long time for the command to complete as each member gets touched behind the scenes.

That kind of overhead can drain a system (as you probably experience at times). Elimination of excess members can really pay off.

Good luck.

Tom
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.