Re: Year end save files.

rob@xxxxxxxxx wrote:

<<SNIP>>

I am wondering if this would save significant space for those
special year end saves that you almost never use the data from
OMITOBJ((*ALL *LF))
if it was available. Apparently IBM only allows you to specify
*FILE and does not allow you to specify object "attribute".

How many would omit LF's if this capability were available?

We used to have one application that had all their LF's (and
only their LF's) begin with 'Z'.

A saved logical file is little more than its one *FILE object plus each of its *FMT [record format] and *MEM [database member] objects. The vast majority of space will almost always be in the Access Path [the *QDDSI] objects which are saved as part of the physical data members if\when the ACCPTH(*YES) is requested; i.e. those larger objects are never saved as part of SAVOBJ of the keyed LF, even though the storage for the the index is attributed to the logical file object in DSPOBJD size. As such, being able to omit the logicals would atypically offer significant value in saving space on media, instead saving mostly in the number of [small] objects. The naming convention enabling omission via the OMITOBJ or inclusion via the FILEMBR to then effect *NONE for members of the saved logicals could be used to limit the storage space requirements on the media. Depending on the complexity of the database relations, the biggest & more worthwhile saving [versus space] might be in the expense for ordering the /DBF network/ for the save; i.e. without any LFs, ordering the files on the save [dependent logical files\members after their physical data members] is essentially moot.

Rather than extending the generic save *object* feature to enable a by-attribute omission or selection, which would probably have little value outside of database *FILE object saves [probably more often to exclude non-DBF], an effective database-only save API [and/or command] would IMO be the better option. I contemplated that approach and even did some initial coding once [by using the save object API], with the intention of providing a low-storage and better selection of what was to be saved; primarily to enable a SAVDBF of a /database network/ so as to avoid the need to explain what was required to effect that. I had also made changes to the DB save to enable a no-data save [extending an OS-only DB-save feature] to get all of the definitional data for the members without actually omitting the members, but that would have needed integration into the object-save feature for the equivalent of FILEMBR((generic* *NODATA)) to activate the database-save feature. The intent was serviceability, to help get data file objects [without data; especially when considered too sensitive] from customer systems, rather than to enable some non-DR save capabilities; without that, *NONE for the physical files was done in selecting FILEMBR, so the actual member definition would not be retrieved such that ADDPFM was required in the lab.

Regards, Chuck