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



Hi, Joe,

Clearly, there are still plenty of way to "fool" the OS ... :-o

Renaming libraries during a restore seems to be one of them.

Did you try the (related) RSTDFROBJ command?

Also, I seem to recall that RSTOBJ was somewhat sensitive to the library list, as far as finding dependent objects ... perhaps you could create the new named library first, then set it as your *CURLIB or add it to the top of your *LIBL, prior to these restore attempts?

Otherwise, it might be worth opening a "case" (PMR) with IBM Support to see if they can shed any additional light on the situation.

Or, when all else fails, you can always just recreate those (few) join LFs from DDS source after the restore(s) are completed?


All the best,

Mark S. Waterbury

On Wednesday, January 8, 2020, 10:16:59 AM EST, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:

Well, I stopped using them 30 years ago, so I'm happy that something has
changed.

But it doesn't look like that parameter works when you change the
library names on the restore.

It just keeps telling me that DFRID REFRESH has one object remaining.


On 1/D8/2020 8:45 AM, Mark Waterbury wrote:
  Hi, Joe,

This was fixed by IBM around V5R4, IIRC ...

Prompt the RSTLIB or RSTOBJ commands, and press F10=Additional parameters, then look for the (then) "new" parameter for "Defer ID . . . "  DFRID ...

So, not a problem for 30 years, but only perhaps 20 years?  ;-)

Happy New Year!   "Welcome to the future!"

All the best,

Mark S. Waterbury

      On Wednesday, January 8, 2020, 9:21:10 AM EST, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
 
  Has anyone ever identified a process to handle either RSTLIB or
CRTDUPOBJ for cross-library logicals: those pesky logical files that
join physical files in two different libraries (they can also be created
as SQL VIEWs these days).

The problem is simple.  I can create a logical ABC1/LF over ABC1/PF and
ABC2/PF.  But if I save and restore those libraries to a different name
(say XYZ1 and XYZ2), I end up with a "broken" logical.  XYZ1/LF ends up
being created over XYZ1/PF and ABC2/PF.   The same happens if I try to
do a CRTDUPOBJ of ABC1/LF to XYZ1/LF.

I have found no way short of recreating the logical file with CRTLF (or
RUNSQLSTM for a VIEW) to link the logical correctly to both physicals.

This has been a problem for 30 years, which is why I've since avoided
them like the plague.  But I have a few of them I'm dealing with right
now and they're quite annoying, and I was hoping something had changed
over the years.  :)



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.