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



Rob,

The trick with your /server/logs directory is to set the objects inside the directory as ALWSAV(*NO) but leave the directories themselves *YES. Now in the event of a full recovery, the directory structure will be on the tape.

One could create a back up list (you use BRMS) to backup the directory structure only and not all the object inside the directories to get around that issue as well.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 7/29/2013 7:35 AM, rob@xxxxxxxxx wrote:
I have used both the CHGATR method and the omit from the BRMS backup. Both
have their place. If I always want it omitted from the backup, even a
dedicated full system save, then I'll use the CHGATR method. If I just
want it omitted from nightly backups, but want it in my dedicated full
system saves then I'll use an ignore list in BRMS and when I do my full
system saves I'll use
STRBKUBRM CTLGRP(DTFULL) SBMJOB(*NO) OMITS(*IGNORE)
The key thing being the OMITS(*IGNORE)

Something to consider: If you were to do an unload/reload to a new system
would you really want to skip that directory? Will you remember to change
the attribute back?
If you had to restore a completely fried system would it work without that
entire directory not being there? For example, if I have a directory
called /server/logs it may create files in the logs directory as it needs
them. And they're most likely to be locked on a nightly basis and not
really cared about. But if I had to restore to a new system and did not
even have the logs directory would the application start or would it
complain about a missing directory? Is it application dependent?

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 From: Alan Shore <ashore@xxxxxxxx> To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>, Date: 07/25/2013 01:11 PM Subject: RE: locking an ifs directory Sent by: midrange-l-bounces@xxxxxxxxxxxx Thanks for the response Jim, but I am going to test with the CHGATR from Paul Alan Shore E-mail : ASHORE@xxxxxxxx Phone [O] : (631) 200-5019 Phone [C] : (631) 880-8640 -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [ mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer Sent: Thursday, July 25, 2013 11:21 AM To: Midrange Systems Technical Discussion Subject: Re: locking an ifs directory Alan, Have them exclude that directory from the backup. It's transient data that can be recovered without the tape anyway so it's not needed for a recovery. Now you can just forget about all the locking etc. Have Tom call me if he needs help doing that. Jim Oberholtzer Chief Technical Architect Agile Technology Architects On 7/25/2013 10:00 AM, Alan Shore wrote:
> Hi everyone
> Before I forget (which is not unusual for me) we are on V5r4
>
> We have been testing a process of placing files in a directory on the
ifs, and processing these files from this directory.
> The night before last, we started this process to run overnight, but
have since discovered that not all the files that were transmitted to this
directory made it there, even though there was no error captured at the
origination.
> My investigation shows that a backup was running at that time, and I was
wondering if the backup locked the directory in the ifs.
> The question is - is there a way that I can lock that same directory
without running the backup?
> As always, all responses gratefully accepted.
>
> Alan Shore
> E-mail :ASHORE@xxxxxxxx
> Phone [O] : (631) 200-5019
> Phone [C] : (631) 880-8640
--

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.