Re: locking an ifs directory

Rob,

Having a CL program that sets all the IFS attributes is a great idea for two reasons. First it documents what changes have been made to the system. Secondly, it provides a way to unset/reset those attributes before/after save operations. Now you have complete control over what's backed up and when. Add BRMS to the mix ( or either of the other two major tape management systems ) and you have an excellent set up.

As to the network storage for hosted partitions, I have clients where it will take some time to correct the situation you found yourself in so your not alone there.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 7/30/2013 6:32 AM, rob@xxxxxxxxx wrote:

I have a long detailed script for our downtime weekends. In it I have all
of our CHGATR's and have people run them again prior to the save. It may
not make sense to run them since the attributes are most likely already
set. However, if an unload/reload is planned for that downtime (may have
some coming up...) then I want it sticking out so that I may make a
conscientious decision as I modify the script for that weekend "do I
really want to ignore this directory?". Sometimes the answer is still
yes. For example, a simple restore of /QFPNWSSTG may be a quick way to
get that guest partition restored. However if I do a more classic
unload/reload I could really enhance the performance of that guest by
having it across six storage spaces instead of just one that I created in
my early ignorance.


Rob Berendt
-- IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive Garrett, IN 46738 Ship to: Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com
--