On Sat, 8 Jan 2011 08:22:33 -0500, Bob Rutledge wrote: > >Try it. > >Or search the archives of ISPF-L where you will find... > >"The amount of storage required by the ISPF editor approximates to the >following equation: > >(Number of records * (40 + record length)) > >Note that sites can limit the amount of storage available to ISPF edit/view >users through the MAXIMUM_STORAGE_ALLOWED_FOR_EDIT setting in the ISPF >configuration table. The default for this setting is 0, which allows edit >to use as much storage as is available. > >Regards, Peter > >Peter Van Dyke >ISPF" > Ah, so it hasn't changed in a couple decades. I was beginning to fear that IBM would discover some new techniques and my experience would become outdated. (Well, The LRECL limit has been relaxed.)
This demonstrates only that ISPF is brain-dead. It could readily, on encountering the storage limit, reformat the data in a B-tree with varying record lengths. This would degrade performance for some operations while greatly improving performance for operations such as record insertion and deletion. Perhaps even resort to RLE compression to gain comparable benefit for RECFM=FB. (But is the format of in-storage data GUPI, thus immutable?) XEDIT is no better, IIRC. But XEDIT lets you change RECFM and LRECL dynamically. -- gil ---------------------------------------------------------------------- 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
