Unless /corrected/ the STROBJCVN still does effectively OPNDBF
against every member of a file for the named library [list]. Quite
pointless for most systems and even quite irritating for its effect of
updating the /last used/ information.
There is unlikely any reason to /convert/ any [part of any database]
*FILE objects [esp. when coming from v5r4]. Note that all *FILE objects
on the system will be faulted irrespective that large numbers of file
objects [device files like PRTF and DSPF] are not _database_ *FILE
objects yet they are *FILE objects. What database conversions are
required of late, will be best effected by DSPLIB for every library and
no /last use/ information updated by that action; assumption being, that
STROBJCVN in v6r1 still uses [an effective] OPNDBF to force its database
file.member conversions... and _that_ type of conversion is *very*
unlikely to be required on any system since v5r1 I think -- but I think
it will also effect the same conversions to the database *FILE
[composite pieces] as will the DSPLIB.
Regards, Chuck
rob@xxxxxxxxx wrote:
What does the conversion process do on files? If I fail to run STROBJCVN
against the files will that slow down the open of them?
As an Amazon Associate we earn from qualifying purchases.
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.