>> 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.
Indeed, indexing by record. So when the file is sitting on a CMS minidisk, it sounds like we have decent solutions for index-by-record when dealing with both RECFM F and RECFM V provided the new record is shorter. For RECFM F when new record is longer shouldn't be a problem unless longer than file's LRECL, and there are known methods for dealing with that situation already (e.g. split it, truncate it, etc). For RECFM V when new record is longer and it would be preferable to avoid truncation, then there does not appear to be a "pretty" solution short of re-platforming (e.g. "go use SFS", etc). Attempted to use VSAM under CMS, but the CMS VSAM handling code appears to be significantly older than the z/OS counterparts. Other than just using SFS, not sure if re-platforming to either BFS or CMS OpenEditions might solve. --Shawn S. -----Original Message----- From: CMSTSO Pipelines Discussion List <CMS-PIPELINES@VM.MARIST.EDU> On Behalf Of Alan Altmark Sent: Saturday, September 12, 2020 12:07 PM To: CMS-PIPELINES@VM.MARIST.EDU Subject: Re: [CMS-PIPELINES] Replace single record in file 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, 40+ 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 >
