EDF came as an add-on to VM/370 release 6 in 1979. Along with FBA
support if memory serves.
Alan is not doing justice to the designers. Being copy-on-write, it was
the first CMS file system that had no leakage of disk blocks on crashes
or power outages. CDF had the choice of trashed files or block leakage
and clearly chose the latter, but as a consequence, you might have 10%
wasted blocks on a minidisk after a while.
On 9/12/20 19:14, Kris Buelens wrote:
Wasn't EDF new with VM/SP?
(I remember performance problems with CDF for large RECFM V files in my
first IBM years)
Kris Buelens,
--- VM/VSE consultant, Belgium ---
-----------------------------------------------------------------------
Op za 12 sep. 2020 om 19:07 schreef Alan Altmark <alan_altm...@us.ibm.com>:
The CMS EDF file system is a very lightweight file system that has survived
40+ years with this restriction. (EDF was introduced in SEPP or BSEPP, I
think.)
Back then VSAM was available to solve more complex data management issues.
Now, you re-platform.
Regards,
Alan Altmark
IBM
On Sep 12, 2020, at 12:27 PM, Paul Gilmartin <paulgboul...@aim.com>
wrote:
On 2020-09-12, at 06:18:25, Rob van der Heij wrote:
On Sat, 12 Sep 2020 at 01:18, Stanislawski, Shawn (National VM
Capability) <
shaw...@dxc.com> wrote:
Would be preferable to avoid truncation of a longer new record when
dealing with recfm=VARIABLE.
But at this point, it sounds as if there is not an elegant
resource-light
method for so doing?
Would you mind to mark the original as "deleted" and append the longer
record to the RECFM V file maybe? But I guess you were going index by
record number rather than a key.
I understand that MDFS indexes blocks (not records) in a tree.
I was disappointed that does not support "elegant resource-light"
insertion, deletion, and replacement of records. (Yes, that
would require splitting blocks when records are inserted, marking
parts of blocks as unused, and balancing the tree for performance.)
SFS is merely secret.
-- gil
