|
| -----Original Message----- | [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of | csmith@xxxxxxxxxxxxxxxxxxxx | Cause . . . . . : A problem was detected while processing the system | cross-reference files. The problem type is 2. | 2 -- An unexpected condition was encountered | Recovery . . . : If the problem type is 1, request a reclaim | storage | | (RCLSTG command specifying SELECT(*ALL) or SELECT(*DBXREF) ) Well, given this amount of help in *SECLVL msg, I would recommend: RCLSTG command specifying SELECT(*DBXREF). (The ReclaimStorage specifying SELECT(*ALL) requires a dedicated system.) Fixing the SQL X-ref files takes, oh.. I can't recall how long it took, 15 minutes on an old system?? Depends on your system CPW and how many files and such, I would guess. May not fix this problem, however. (Too bad customer's couldn't update the *SECLVL text, based on experience of whether RCLSTG fixes other problems besides 1. Well, actually they could, similar to building up an FAQ and shipping a *MSGF, but we've seen how much luck Buck and others have had building up a very-well documented FAQ from this list, so...) This would also be the (to me, obvious) DIS-advantage of adding a layer above the OS layer to catalog what is already inherent, strictly for the benefit of SQL dweebs. Been doing the 400 gig for a couple decades, and until recently getting garbage in DSPOBJD (as others have posted), had NEVER gotten ANYthing like this for DSPFD, DSPFFD, etc. Seen these kinda errors in the SQL-added layer frequently. Oh well.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.