×
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.
midrange.com
