Hi All,

I am extracting the data from a FOCUS DB file. It contain huge data. While extracting the data, I am facing the space abend. I allocated max number of Primary and Secondary volumes, Still facing the same abend.

Please let me know, Is there any other way to extract the data from FOCUS file.I am trying to read few numer of records by using WHERE RECORDLIMIT command and save the result by using ON TABLE HOLD AS OUTPUT1, after this how we can continue to extract the remaining data.
OUTPUT1 contain 1 to 10000
OUTPUT2 contain 10001 to 20000
OUTPUT3 contain 20001 to 30000

Thanks,
Rajesh.

Rajesh,
Are you extracting to a file?
Are you sorting?
When you say huge, is it the number of records or the length of the fields or both?
When you say you face the SPACE ABEND, is that for FOCSORT or for your extracted file?
Please also update you signature to show which version of WF or MF you are using.

Rajesh:

I have a feeling from reading your post that the FOCUS file was created from one large flat file, with with little or no data analysis or normaliztion done. if this is true, then only proper database design can save you at this point.

To describe what needs to be done would require a great deal of explaining which would be difficult to convey with postings on FOCALPoint.

If you feel this could be the problem, you can respond to this posting and maybe we can discuss by phone, email, FAX or by some combination.

Thanks,
Jim

Hi,

I am trying to extract the data from FOCUS Database file to flat file. The Database file contain huge number of records. I skiped the FOCSORT with using the TABLEF command also.

Thanks,
Rajesh.
FOCUS 7.1.1/ MF(OS/390)

This seems to me like a candidate for Pooled Table, which can run an extract once and produce multiple outputs.

However as it is probably 10 years since I have even heard it's name, perhaps someone else can remember how it works.

There are some docs on the IB Tech support site, which should start you in the right direction.

This is an attempt to answer you question about continuing a recordlimit test. This will work if there are no other screening tests and you know about how many records in total you have. Be careful where you do the define (the with real field in the define). This also assumes you not getting data from multipaths. With that said, here is an example using the car file.

Good luck.

DEFINE FILE CAR
CNTR/I9 WITH MODEL= CNTR + 1;
END
TABLEF FILE CAR
PRINT MODEL
IF CNTR LE 9
ON TABLE SAVE AS SAVE1
END
TABLEF FILE CAR
PRINT MODEL
IF CNTR GT 9
ON TABLE SAVE AS SAVE2
END

The contents of the save files:

SAVE1

* * * TOP OF FILE * * *
V12XKE AUTO
XJ12L AUTO
INTERCEPTOR III
TR7
504 4 DOOR
2000 GT VELOCE
2000 SPIDER VELOCE
2000 4 DOOR BERLINA
DORA 2 DOOR
* * * END OF FILE * * *

SAVE2

* * * TOP OF FILE * * *
B210 2 DOOR AUTO
COROLLA 4 DOOR DIX AUTO
100 LS 2 DOOR AUTO
2002 2 DOOR
2002 2 DOOR AUTO
3.0 SI 4 DOOR
3.0 SI 4 DOOR AUTO
530I 4 DOOR
530I 4 DOOR AUTO
* * * END OF FILE * * *

ET

I believe that this is exactly where pooled tables come in. If Rajesh is dealing with large amounts of data, then running through the data multiple times will be quite an overhead. Your code, with pooled tables, should result in only one pass of the data instead of two passes, and multiple outputs. Much more efficient.

The numer of records required in each output though would stil be necessary for the split.

Just as others have said about other new or added features, they sometimes don't work as good as one may like them to.

We don't have pooled tables as it is added cost option. I have played with it during an evaluation period (set pooling on)and (at least in my experience - sorry Rob Freeman if you are still at IBI)it doesn't always result in more efficiency especially if the code was not originally written with pooled tables in mind. We did not want to recode and then test thousands of focexecs to take full advantage of pooled tables. I assume you have used it previously. What is your experience with it? Did you find large performance improvements?

As you have noticed for Rajesh's problem, the flat file is not big enough to store the dump of all the data.
The code would be the same. If it is run often enough it may justify the added cost for pooled tables. If run infrequently then why bother. Pooled table or not, all I did was to supply Rajesh with a way to continue where he left off with his first recordlimit test as in his example. If he has pooled tables at his site he can run his code both ways as a test to see if in fact in his case it is more efficient. In this particular case it most likely it will be as it is just a straight dump from one Focus DB but I can't say for sure.