Hi all,

I'm having a problem with executing Reports on 1 special Masterfile.

The report often crashes with an error: "Unknown error occurred. Agent on reporting server EDASERVE may have crashed. Please investigate reporting server log."

Sometimes i get the error: (FOC198) ... ERROR
READING FOCSORT , PAGE 959657265, CODE 0xffffffff

I'm searching the forum for about a week and I don't find any solution. The FOC198 tells me, that it might be a matter of temporary space, but the Server has 11 GB of free space on the volume. That should be enough!?

I created a new MasterFile of the Table and I'm adding more and more fields as i need them in my reports. The more fields the masterfile consists of, the "agents crashed" error occurs more often. May it be a matter of the length of fields in the masterfile? Can it become to big? Is there a limit? I'm confused, because only about 10% of my requests get the described errors, the other requests are okay so far.

The CHECK MF command gives me the following output (its the german version, but I think you understand it anyway):

0(INF32075) FEHLERANZAHL= 0
(INF32076) SEGMENTANZAHL= 1 ( REAL= 1 VIRTUAL= 0 )
(INF32077) FELDANZAHL= 153 INDEXES= 0 FILES= 1
(INF32079) GESAMTLÄNGE ALLER FELDER=58680

I am thankful for every hint!

regards,
JP

This message has been edited. Last edited by: Jean-Pierre,

You might have 11 gig available but focsort has a limit of 2 gig.

I suspect that's the real issue.

And, the mmore fields you put in, the bigger the record becomes, and thus this limitof 2GB is reached earlier and earlier.
The output that you're getting, is it already sorted? Or do you just use PRINT in your request, no BY's or ACROSS's? If so, you could consider using TABLEF in stead of TABLE. The F-version does not use the internal matrix (which gets written to focsort if it becomes too big for internal memory), and is thus not limited to the 2 GB, but rather to the limit the OS imposes on filesize.

Hope this helps ...

thank you for answers so far.

I am using about 15 BY's and a SUM (no ACROSS's) in my request. Is that too much?

quote:

I am using about 15 BY's and a SUM ... Is that too much?

It depends on the effective size of the rows (data records) being assembled in the 'internal matrix'.

To determine that, add conditions to cut the answer-set down to a few thousand rows, and use HOLD FORMAT FOCUS. The resulting Focus file is essentially a copy of the internal matrix. ? FILE will list the number of segment-instances (under "COUNT"), and ? FDT the number of pages they occupy, from which you can calculate roughly how many records will fit as 500,000 * Count / Pages.

[one page = 4KB; 512K pages = 2048KKB = 2K K KB = 2GB. Hope I'm not pulling a Pelosi]

You can generally make more efficient use of the available 2GB (i.e., increase the effective row capacity of the internal matrix) by using multiple verbs, which will distribute your columns among a series of segments representing a data hierarchy.

This message has been edited. Last edited by: j.gross,

I tested these comands with a report, that caused the agents crash for several times today. That is the result:

0(INF32080) DATENSATZANZAHL IN TABELLE= 83 ZEILEN= 83
? FILE DREI
-RUN
0 STATUS OF FOCUS FILE: D:\ibi\srv76\wfs\...\drei.foc ON 02/10/2009 AT 11.04.13
0 ACTIVE DELETED DATE OF TIME OF LAST TRANS
SEGNAME COUNT COUNT LAST CHG LAST CHG NUMBER
SEG01 83 02/10/2009 11.04.13 83
0 TOTAL SEGS 83
TOTAL CHAR 129812
TOTAL PAGES 42
LAST CHANGE 02/10/2009 11.04.13 83
FILE APPEARS TO NEED THE -REBUILD- UTILITY
REORG PERCENT IS A MEASURE OF FILE DISORGANIZATION
0 PCT IS PERFECT--100 PCT IS BAD
REORG PERCENT 32.53 %


? FDT DREI
0 DIRECTORY:\ibi\srv76\wfs\edatemp\...\drei.foc ON 02/10/2009 AT 11.04.13
DATE/TIME OF LAST CHANGE: 02/10/2009 11.04.13
0 SEGNAME LENGTH PARENT START END PAGES LINKS TYPE
1 SEG01 392 1 42 42 1


I'm using 42 pages * 4 KB = 168 KB? So 42 pages and a count of 83 does not look that much. But I'm new to WebFOCUS, so hopefully someone can tell me something more interesting than I can get from these information. :-)

quote:

58680

According to some documentation I found on the tech site (Here) the max size of a segment cannot exceed 32KB.
Your size is 58 KB. I'm guessing this is the cause of the problem. Admitted, focus should have given a warning about the size of the incoming data which is way too high to handle, but that does not seem to happen.
My advice would be to decrease the number of fields so that the maximum record length stays below the 32 KB.

That hint is great! But does that only apply for the formats FOCUS and XFOCUS? Usually I'm using a statement like ON TABLE PCHOLD FORMAT '&AFORMAT' where &AFORMAT specifies the format fof the output (HTML, EXL2K, PDF).

I may be wrong here, but I think it is applicable only when you do a hold to some kind of database type.
Usually these large record sizes do not occur when doing hold in format html/pdf/excel, because most users (if not all) will not like to read a 58KB record in pdf, which may span something like 10 pages....

Jean-Pierre --

It's a bit odd that a HOLD FORMAT FOCUS would result in a disorganized Focus file:

quote:

FILE APPEARS TO NEED THE -REBUILD- UTILITY
REORG PERCENT IS A MEASURE OF FILE DISORGANIZATION
0 PCT IS PERFECT--100 PCT IS BAD
REORG PERCENT 32.53 %

If that happens to the process of accumulating the internal matrix, and you are assembling over a million rows in the result set, it can seriously degrade the performance of the Table request.

Were your "about 15 BY's" by any chance a mixture of ascending and descending sorts (BY and BY HIGHEST)?

Oh, and did you solve your original problem?

This message has been edited. Last edited by: j.gross,

thank for your answers so far! I reduced the length of all fields from 58.000 to 29.000 and I did not receive an error since then. Although the documentation tells, that this would be helpful for FOCUS and XFOCUS formats, it seems to be a solution für HTML, PDF and EXCEL also.

I mark this Thread as SOLVED.

Thank you!

This message has been edited. Last edited by: Jean-Pierre,