What happens if a ? FILE command is issue while a FOCUS database is in the process of being loaded? Will it return a value, or will it abend?

We want to use ? FILE as an alert trigger to see if a FOCUS database is ready to be read, but I don't want to get a false-positive if we get statistics back on a partially loaded table.

This message has been edited. Last edited by: Kerry,

Dave, Are you loading through SU, or directly ?

It may be an idea to set a flag somewhere by the loading program instead, then check the flag.

We are reading a FOCUS file that someone else is creating and loading. We pull an extract from the FOCUS file to use on a different server. Since we want the file as soon as it is loaded, we were going to use a RC alert... so we have no ability to set a flag. ? FILE was a way we hoped would get us there quicker, but I don't want to kick off our extract process if the file is in the process of being loaded. Unfortunately, we'll just have to schedule the job well outside of the load window if this doesn't work.

Could you have whoever is loading the focus file copy an empty trigger file like loaded.txt when their process has completed? Then you can just check for the existence of that file since it won't exist until the load has completed. You would have to be sure and delete ithe trigger file after you have done your processing.

I pretty sure that you'll get a false positive to ? FILE. The file exists so you may get statistics, even though it may still be loading

Thanks Waz and Darin - unfortunately we have no control over the group creating the file and that process won't change. I had considered the trigger file technique, but with no ability for us to change the current process, that's out.

I think I got the answer I need - barring the changes suggested, we will probably get false positives if we run a ? FILE on the database any time prior to it being completely loaded.

Thanks!

Dave,

Do you know how the other group (herein called the "untouchables" ) run the load job? If it is via RC and you have access to their RC, then looking at the RC tables might give you a possible method.

AS for ? FILE, this will update with stats as the file is loaded so you are correct not to use that method.

T

Dave I agree with Tony,

If they are running the process that creates the Focus DB under Report Caster
all you need to do is check the log.

Check if it has an END_STAMP for the date you are running and also check
the ERROR column to make sure it completed correctly.

There are plenty of posts regarding re-submitting a caster job if it's
dependencies are not ready.

Can you have their job submit your job via DSTRUN?

Another option is that generaly during a file update process the date/time is changing on the file. you could look at the maybe every 3 minutes or so and see if it has changed sence that last time you look and if it is the same you might be able to assume the update job is complete.

? FDT
will also display the 'latest update' timestamp, and (for a large Focus or Xfocus file) is considerably faster than
? FILE

Have you thought about using the last modified date of the FOC file its self.

You could use APP QUERY and check the DATE and TIME columns

Waz - that's another angle I hadn't thought of. What gets returned if we hit the file while its in the process of loading? If its the prior date, that would work. If it updates during loading, we could potentially be lead to believe the file is done.

Does the last modified date only update when the load is complete?

I gave it a quick test (In windows WF 766).

Seems the last changed does not change until the MODIFY finishes, then it gets updated.

The code below shows the process.

-* Uncomment me the first run.
-*TABLE FILE CAR
-*SUM COMPUTE
-*    CDATE/YYMD = &YYMD ;
-*BY COUNTRY
-*ON TABLE HOLD AS TESTMOD FORMAT FOCUS
-*END
-*-RUN

! dir testmod.foc
-RUN

MODIFY FILE TESTMOD

FIXFORM COUNTRY
COMPUTE CNTR/I9 = 1 ;
GOTO LOOPER

CASE LOOPER
COMPUTE CNTR = CNTR + 1 ;
IF CNTR EQ 100000000 THEN GOTO ENDCASE ;

MATCH COUNTRY
ON MATCH COMPUTE CDATE=&YYMD;
ON MATCH UPDATE CDATE
ON MATCH GOTO LOOPER
ON NOMATCH REJECT
ENDCASE
DATA
ENGLAND
END

-RUN

! dir testmod.foc
-RUN

Here is the output

 Directory of C:\ibi\DEVSTU~1\srv76\wfs\tst

18/09/2008  01:46 PM             4,096 testmod.foc
               1 File(s)          4,096 bytes
               0 Dir(s)  15,618,281,472 bytes free

 C:\ibi\DEVSTU~1\srv76\wfs\tst\testmod.foc ON 09/18/2008 AT 13.47.19

 TRANSACTIONS:         TOTAL =     1  ACCEPTED=     1  REJECTED=     0
 SEGMENTS:             INPUT =     0  UPDATED =99999998  DELETED =     0
 Volume in drive C is OS
 Volume Serial Number is 7C4E-0897

 Directory of C:\ibi\DEVSTU~1\srv76\wfs\tst

18/09/2008  01:51 PM             4,096 testmod.foc
               1 File(s)          4,096 bytes
               0 Dir(s)  15,618,215,936 bytes free

The Date Modified in Explorer stayed at 18/09/2008 01:46 until the program ended.

Waz,
In your test case indeed the file gets updated only after the program closes.
This is because you update only the one record, not causing any buffer to flush, so not needing to write to the file. If the buffer does need flushing (by either a lot of different records to update or insert), the file will get written to during the modify.
I also think that doing explicit commits will write to the file, because it is actually the same as flushing the buffers.

I would have thought that it doesn't matter if the Date Modified is updated during or after the process finishes.

A simple test if the date to see if it hasn't changed in a while would suffice.

You could use HDIFF to determine the number of seconds/minutes after the last update, then trigger the next event.

I just did a test loading a Foc file with a couple of million records.

Windows doesn't seem to record the updates against the file (Date Modified).

But Unix (Solaris) updates cosntantly, I assume with every check point.

Looks like it is OS specific.

I still believe my previous post is a good way to go.