|
midrange.com
Nelson,
Basically, the problem you describe is that the changes you have made to
the file do not result in a change to the file's format level identifier.
When the file is restored on another system, the restore process sees that
the format ID is the same as an existing file so it decides to share the
format with that if the existing file. The effect is that the changes you
make are lost.
The most common type of change for which we have seen this is when the only
change made to a file is to the column headings.
The simplest way to resolve this problem is to let TurnOver send the source
for the file and compile the file out if QTEMP on the other system. This
then bypasses the problems caused by the save restore process. Compiling
the file is not significantly more "expensive" than duplicating it, and the
data has to be re-copied regardless of which method is used.
I have attached information from the OS/400 Backup and Recovery Guide that
explains what is happening during the RSTLIB process.
>>>>>>>>>>>>>
3.8.9.6 How the System Restores Files with Shared Formats
When a database file is restored and that file, before it was saved, had
shared the record format of another file, an attempt is made to find the
file whose format was shared, and re-establish the original format sharing.
The search for restoring the shared format starts in the library to which
the restored file is directed and continues in the library from which the
restored file was saved. Following are the results of the search:
If the sharing file is found and has not been changed (level check) since
the save, then no new format is created for the restored file.
If the sharing file is not found, or it is found but fails the level check,
then a new format for the restored file is created with the same definition
as the one it initially shared.
If a format sharing file has been renamed, deleted, or moved to a library
other than the save or restore library, a new format is created for the
dependent file when the dependent file is restored.
>>>>>>>>>>>>
If you have any further questions, feel free to email me off-list.
Mark Phippard
Director of Development
SoftLanding Systems
"Smith, Nelson"
<NSmith@lincare.com To: MIDRANGE-L@midrange.com
> cc:
Sent by: Subject: RSTLIB problem
midrange-l-admin@mi
drange.com
08/10/01 12:13 PM
Please respond to
midrange-l
When I make a change to a field in a physical file on my development system
that does not change the file level identifier, such as adding some
additional values to a VALUES keyword and then save that file and send it
over to my production machine and restore it, the restored copy does not
reflect those changes unless I first delete (or rename) all copies of that
file on the production system, even though the existing copies of the file
are in different libraries than the one I am restoring it to.
I am told that this is a long-standing anomaly with the RSTLIB command.
Can
anyone confirm this is an IBM problem and does anyone have a work-around
other than the prior deleting of the file method? This wrecks havoc with
my
change management system (TurnOver).
Nelson Smith, CDP
IBM Certified Specialist
AS400 RPG IV Programmer
(727) 431-8243
(800) 284-2006
************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information
which maybe confidential or privileged and is intended only for the
individual or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the
contents of this message.
All personal messages express views solely of the sender, which are not to
be attributed to Lincare Holdings Inc., and may not be copied or
distributed without this disclaimer.
If you received this message in error, please notify us immediately at
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************
_______________________________________________
MIDRANGE-L mailing list
MIDRANGE-L@midrange.com
http://lists.midrange.com/cgi-bin/listinfo/midrange-l
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.
