× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 06-Mar-2014 13:45 -0800, John McKee wrote:
I got curious about the disk usage, so submitted RTVDSKINF. Just
guessing, but it may not have been run in a very long time. QAEZDISK
in QUSRSYS was created 12/09/92 10:34:25 at system level V2R2M0.

Is there a page somewhere that would show what has been added by
release?

For this scenario at least, the DSPFFD QUSRSYS/QAEZDISK compared to DSPFFD QSYS/QAEZDISK will reveal the specific difference; i.e. to reveal what data is /truncated/ or otherwise would be lost, if the new model file is not used to create a new output file.

The QAEZDISK in QSYS was created 06/06/05 22:09:08.

CPI802 says to delete the file in QUSRSYS.

That would be msg CPI9802 "Record format for file &1 in &2 does not match model file." The model file is in QSYS, like other OS-provided model output files.

Would it be typical to delete the QUSRSYS file during an upgrade?

Although starting with a 'Q', the file is a user file in that quasi-user library [also with 'Q' prefix]. The user has control over the output file in the same sense that they would with any DSPOBJD or DSPFD output file.

Unlike other output files however, the general model-outfile concept is somewhat debased in this particular scenario. Instead of allowing any user-chosen and named output file, the Retrieve Disk Information (RTVDSKINF) had supported only using the statically defined output file QUSRSYS/QAEZDISK.QCURRENT [where the additional dot-naming shown here, is the member name QCURRENT, although I do not recall if the feature might use *FIRST instead, or explicitly QCURRENT]. To maintain the effect of multiple sets of output, either different member names of that file must be used or different named files are used; e.g. per Rename Member (RNMM) to rename the member [though if *FIRST is utilized by the feature, then the member data must be copied to a new member name versus simply the member being renamed] or per Rename Object (RNMOBJ) to rename the file.

Any reason to not delete it?

Except to have the old data available, probably no reason not to delete the user file; just as alluded in the recovery.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.