Good Morning, FOCUS Nation:

We opened a case with IBI because we found this FOCERRNUM appearing in our logs: FOCERRNUM 348.
I checked through Focal Point and IBI Tech Support but could not find this error described.
The initial IBI suggestion is that there are EDATEMP storage issues and we are researching further. Meanwhile, please let us know if you have seen this error message and solutions you may have taken.

All the best for the holidays.

This message has been edited. Last edited by: S.J. Kadish,

Happy Holidays Sandy!

? 348
-EXIT
(FOC348) ERROR WRITING HOLD FILE DESCRIPTION TO HOLD MASTER
An I/O error has prevented the HOLD MASTER from being written.
Check to see that adequate file space is available.

Do you have APP HOLD command in your code?

Hey, Tom:
Thanks for the best way to find a Focus error. We are currently researching the EDATEMP storage issues.

This message has been edited. Last edited by: S.J. Kadish,

BabakNYC - To answer your question we do not have an APP HOLD command in the code. Are there any advantages or disadvantages for adding an APP HOLD command?

APP commands redirect and/or change the location mapping of where WebFOCUS will read or write. There isn't any benefit to using them. The reason I asked was to find out if your code might be redirecting the HOLD MASTER to a directory you may not have write access to.

Reaching out again to see if anybody else has seen a (FOC348) or (FOC0348) appearing anywhere. On our side three Report Caster jobs failed at exactly the same time in production. While the error appears to indicate an EDATEMP issue we have not seen this error anywhere else.

Thanks as always.

Sandy-

EDATEMP lives under a folder structure something like this:

\\myservername\ibi_parent\srv81\wfs\edatemp 

This UNC would map to a physical drive.

Have you checked with your admin folks to make sure there is plenty of space available on that drive, at the time the 348's are encountered?

Our understanding from the server team is that there is adequate space in EDATEMP

Sandy --

My recollections is that the Hold MASTER file gets written and closed before the Table process starts pumping rows into the corresponding data file. Normally (unless you direct otherwise with APP commands), the hold mfd and hold data target to the same temp directory.

Given that mfd's are pretty minuscule, a foc348 "ERROR WRITING HOLD FILE DESCRIPTION TO HOLD MASTER" would indicate an immediate i/o failure (such as a permissions issue), not a space issue.

Is this the first Hold that the report performs?

I concur with Jack although, if you have several subprocesses building data throughout your job, it could be that the available space is used before the point at which your MFD is being written.

e.g. table file abc hold as hold1; table file xyz hold as hold2; If hold 1 used all availale space, then writing hold2.mas could fail.

So you need to know at what point the process is failing.

Also, EDATEMP might be adequately sized as far as your systems bods are concerned but, as all temporary files are deleted on this type of job failure, the space should become free again after failure. Best to monitor EDATEMP as the failing process runs to see how things fare.

I have seen situations where this has occured and the root cause has very often been an almost complete dump of data into a hold file to be manipulated rather than passing as much processing to the RDBMS. The solution was to interogate the SQL from the processes to ensure all predicates etc. were being passed to the SQL. Especially important around datetime selections as one of the most common issues in poor SQL seems to be selections on timestamps.

T

I sincerely want to thank everybody for their kind and sage advice. The 348 issue ocurred on one day with three jobs that failed at the same exact time. We are installing EUM which should help us better monitor these EDATEMP situations.