D3 likes to log certain system operations like clear-file foofile in
attributes 18 through 20 of the relevant file-of-files item.
That log is only 'cleared' by the next system reload -- is there any great
risk to nuking those entries manually,
either with a basic program or an ED session? I was contemplating doing
this while system was up and running,
all users in their data entry screens, but everybody's hands off the
keyboard, as during lunch time...

Here is a program I run from my file resizing program. We occasionally run
the resize program even though we may not do a save and restore and have
experienced no known problems clearing those attributes.

SUBROUTINE SR.UT.CLEAR.FOF
**********************************
* PROGRAM TO CLEAR FLAGS IN THE
* FOF FILE.
*
*
* (c) Copyright 1991 - 2002, Key Data Systems Group
* All rights reserved. 559-432-3832 USA
* JEK 11/12/2002
**********************************
COMMON /KDS01/ FILES(300),KDS01.INIT
COMMON /KDS02/ KPRMS(300),KDS02.INIT
PROMPT ""
OPEN "DM,FILE-OF-FILES," TO FOF ELSE GOTO 999
PRINT ; PRINT "NOW CLEARING FILE-OF-FILES FLAGS..."
LINE='SELECT FOF WITH FILECODE # "" AND WITH MD = "KEY]"'
EXECUTE LINE
EOL=0
LOOP
READNEXT ID ELSE EOL=1
UNTIL EOL=1 DO
READ FREC FROM FOF,ID THEN
FREC<18>=""
FREC<19>=""
FREC<20>=""
WRITE FREC ON FOF,ID
END
REPEAT
*
* EXIT PROGRAM
*
999 RETURN
*
END


"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

We used to have to do this a lot - with no ill effects. Normally, we just
selected the items that were over 1500 bytes in size to delete.

We used to use a screen generator (called Screen-Gen) that had its own work
files that it did lots of clear-files on. After a while the screens would
really slow down. Running a similar program sped them right back up.

hth
Colin Alfke

"Jeffrey Kaufman" wrote