FOCSORT Problems: I semi-regularly have Mainframe Production Job Abends. This doesn't happen every day (the job runs daily), but does occur every week or so. I can re-run the job under my UserID without a problem. The initial message below is from 2/17/2011. The second message is from 2/12/2011. It appears that sometimes there is sufficient FOCSORT space available, and sometimes not. Is anyone aware of a setting that will ensure sufficient FOCSORT space? The problem does generally happen during a MATCH FILE process. The first error message below occurred during a MATCH of 3584116 records with 7452667 records, attempting to HOLD OLD-OR-NEW, with 3 sort fields.



(FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR READING FOCSORT
, PAGE 19016, CODE 0xaa000107
(FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR WRITING
FOCSORT ,PAGE 295213 ,CODE=AA000005
xxxxxxxxx

Following is the ABEND message from 2/12

(FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR WRITING
FOCSORT ,PAGE 197473 ,CODE=AA000107
(FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR WRITING FOCSORT
, PAGE 197729, CODE 0x0000cac0
(FOC198) FATAL ERROR IN DATABASE I/O. FOCUS TERMINATING ERROR WRITING
FOCSORT ,PAGE 197473 ,CODE=AA000005

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

I know that in the latest releases of WebFocus the limit in size of focsort has been removed. It can grow to several gigs large. I do not know if that is also the case for mainframe focus. If so, you need to be sure that these amounts of data can be written. If not, then you still need space enough for the max 2 gig that the focsort can grow to.

Could this be relat3ed to avaialable resources ?

Running out of space for the focsort allocation ?

Hi, both of the questions are really valid. In WEBFOCUS and FOCUS for Z/OS, FOCSORT is "theoretically" unlimited in release 7.6 or higher (in earlier releases it was limited to 2 gig). It looks as if you are in (or at least are testing in ) 765 or higher, so the unlimited FOCSORT is most likely OK. So, then we get into the issue of machine resources. FOCUS can't keep terabytes of information in memory, so at some point, what we have been collecting is dumped to a ddname of FOCSORT which is a 4K LRECL file. Like any other dataset in MVS/ZOS, that has to fit in the allocation . One thing I have seen, is that I may allocate 100 cylinders primary and 200 secondary and expect therefore to get 100 + 15(200) cylinders because of the secondary extents. However, if going to a work disk that is very fragmented, it might take 14 tries to get the original 100 cylinders and then we run out of secondary extents. Normally in the world outside of FOCUS that would give a B37 abend. FOCUS of course, tries to catch that and give you a FOC198 with a different error to be a little more specific. For instance FOC198 WITH RC AA000003 indicates no more room on the disk, and AA000004 means more than 16 extents would be required. However, many big companies have STOPX37 or an equivalent software package that says "in no more room on this disk, I'll just put it on another" .

iF SO, FOCUS would have to know that this dataset (FOCSORT) was on different volumes, so try this:
If this is batch:
//FOCSORT DD UNIT=(type,n),…

WHERE type is the type of unit, and n the maximum NUMBER of units . There is also a member in your ERRORS PDS called IBITABLA which contains the default allocation for FOCSORT (among others), including number of volumes. In a TABLE, we can avoid FOCSORT with EXTSORT, SAVEMATRIX, but in MATCH file , we make a complete reporting pass against the 1st file, then against the 2nd, then merge the two outputs together...

Also, if you don't have STOPX37, I like to allocate my primary allocation as very small , and my secondary very large. This way, we will spill to the secondary very quickly and if there isn't STOPX37, or there is no other work area available, when the os goes to get the 1st of the secondarys, it will blow up right then, and not 45 minutes into the job when it finally gets too big.

Noreen Redden (sorry to be so long-winded)