Well...
Where's the question?
EF is nothing new - I can say that for feature which is 10+ years old.
No "gotchas" are secret. No exotics.
It's good way to avoid x37 abends, especially when used with some
DATACLASS features like DVC, Reduce Space Allocation, etc.
--
Radoslaw Skorupka
Lodz, Poland
Jack Kelly wrote:
We're always behind the curve, so I'm just using extended format(EF). I'm
trying to replace the Stop x37/DIF methodology with EF. I'm using EF for
x37 reasons, not striping or greater than 4GB, and access is via QSAM.
Other than the candidate entries for each dataset is there any major draw
backs, eg HSM, FTP'ing, restoring? And will an EF mutivolume dataset be
restored to a single volume if it's copied or HSM recalled?
Doing some testing, I did find one thing that has me puzzled. I created a
trk=(1,1) EF dataset and the EOV routine got control after 149 extents on
two volumes. It allocates the 123 extents on one volume and then 26 on the
second volume, there was plenty of room on the second volume as the next
test indicated. I removed the EOV exit and it wrote 123 extent on each of
the three volumes.
Jack Kelly
202-502-2390 (Office)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi
118.642.672 zote i zosta w caoci wpacony.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
