RE: RSTLIB problem

Owner and authorities are the same on both systems.  The file changes work
fine on the development system. The change management system is the one
doing the savlib, sndnetf, and rstlib commands.  I haven't been able to try
the ALWOBJDIF parm yet because it requires *ALLOBJ authority.  I've asked
our security officer to try that, but even if it works, I doubt the vendor
will want to change their command. They claim it's an IBM problem.  

Any TurnOver users out there run into this?

> -----Original Message-----
> From: rob@dekko.com [SMTP:rob@dekko.com]
> Sent: Friday, August 10, 2001 1:20 PM
> To:   midrange-l@midrange.com
> Subject:      Re: RSTLIB problem
> 
> 
> I suspect that the RSTLIB command is not really working.  Check out the
> change and create dates of the file.  They may have different owners on
> each system.  For example
> MBROPT(*ALL) ALWOBJDIF(*ALL)
> with the proper security may improve the restore.  But you may be better
> served by getting the owners right on both machines and doing that sort of
> change, in the future, with your change management software.
> 
> Common problem here is that developers have one user profile with *ALLOBJ
> for special purposes, on the development machine.  Once they have this
> they
> no longer use the appropriate user profiles on the development machine for
> general purposes.  After all, who needs to test?  That's what users are
> for.  Result is that object ownership is all messed up.
> 
> Rob Berendt
> 
> ==================
> A smart person learns from their mistakes,
> but a wise person learns from OTHER peoples mistakes.
> 
> 
>  
> 
>                     "Smith, Nelson"
> 
>                     <NSmith@lincare.com       To:
> MIDRANGE-L@midrange.com                                           
>                     >                         cc:
> 
>                     Sent by:                  Subject:     RSTLIB problem
> 
>                     midrange-l-admin@mi
> 
>                     drange.com
> 
>  
> 
>  
> 
>                     08/10/2001 11:13 AM
> 
>                     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
> 
> 
> 
> 
> _______________________________________________
> MIDRANGE-L mailing list
> MIDRANGE-L@midrange.com
> http://lists.midrange.com/cgi-bin/listinfo/midrange-l