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?
This mailing list archive is Copyright 1997-2026 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.