Rob,
I ran into a BRMS recovery issue when using OMITS with IFS
Omitted items were omitted from the Recovery report, though they existed on the Full save.
IBM recommended not use OMITS for IFS.
From an old PMR.
"BRMS doesn't keep track of omitted directories. So when directories are omitted using QLNKOMT and BRMS does a *LINK full, BRMS will conclude that it has a full backup of the IFS. Indirectly, the user does have a list of the missing/omitted directories because they can just look in the QLNKOMT list. To restore the data, the customer would need to do a WRKMEDIBRM option 7 next to the December *LINK entry and restore the omitted directories."
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Thursday, April 14, 2016 11:29 AM
To: Midrange Systems Technical Discussion
Subject: RE: Upgrading to IBM i 7.3 - CHGATR ... ATR(*ALWSAV) VALUE(*NO)
Nope Paul, you're wrong. If you want that kind of selectivity you should be using OMITs in BRMS. Then you could always use the option in BRMS to ignore omits.
STRBKUBRM ... OMITS(*IGNORE)
You're already a BRMS shop so, suck it up buttercup. :-)
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: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/14/2016 10:33 AM
Subject: RE: Upgrading to IBM i 7.3 - CHGATR ... ATR(*ALWSAV)
VALUE(*NO)
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob,
< Haven't really played much with save while active and stream files with
IBM i 7.3.
Did you mean to say 7.2?
I've been bouncing back and forth with CHGATR ... ATR(*ALWSAV) VALUE(*NO
to *YES) for various IFS dir, etc.
Years back, anything that had a lock similar to your messages below, I set
to save *NO.
This cleaned up my messages on my save.
However, when I did my P5 to P7 migration, I had some LPP that were
corrupted.
What we found out, (PMR with IBM) , was that when I changed the CHGATR ...
ATR(*ALWSAV) VALUE(*NO).
This then resulted in a system save that was not 100%.
So what we need, (I should have created a DCR), is when doing a system
save, the ATR(*ALWSAV) VALUE(*NO) should be ignored.
Only be used for non-system saves.
What are the thoughts from the group?
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Thursday, April 14, 2016 10:13 AM
To: Midrange Systems Technical Discussion
Subject: RE: Upgrading to IBM i 7.3
Haven't really played much with save while active and stream files with
IBM i 7.3.
I will say that in IBM i 7.2 IBM changed a LOT of directories with "Can be
saved" set to no.
CHGATR ... ATR(*ALWSAV) VALUE(*NO)
This results in a lot of entries in BRMS like:
Date sent Time sent Message
4/14/16 4:35:04 Starting save of list *LINK to devices TAPKVL01.
4/14/16 4:44:19 Cannot save /QOPT.
4/14/16 4:44:19 Cannot save /QIBM/ProdData/OS/SNMP.
4/14/16 4:44:19 Cannot save /QIBM/ProdData/OS/ClusterResourceServices.
4/14/16 4:44:19 Cannot save /QIBM/ProdData/OS/MRI2924.
4/14/16 4:44:19 Cannot save /QIBM/ProdData/OS/SQLLIB/bin.
4/14/16 4:44:19 Cannot save /QIBM/ProdData/OS/xlxp/lib.
4/14/16 4:44:19 Cannot save /QIBM/ProdData/OS400/DRDA/endSock.
4/14/16 4:44:20 Cannot save
/QIBM/ProdData/OS400/Servers/streamfile.end.
4/14/16 4:44:20 Cannot save /QIBM/ProdData/OS400/Servers/netprint.end.
4/14/16 4:44:20 Cannot save
/QIBM/ProdData/OS400/Servers/dataqueue.end.
...
But you still have a lot of
4/14/16 4:44:21 Cannot save /QOpenSys/var/UME/cimxml.socket.
4/14/16 4:44:21 Object in use. Object is
/QIBM/UserData/OS/ADMININST/adm
4/14/16 4:44:21 Cannot open object
/QIBM/UserData/OS/ADMININST/admin1/wlp
4/14/16 4:44:21 Object in use. Object is
/QIBM/UserData/OS/ADMININST/adm
4/14/16 4:44:21 Cannot open object
/QIBM/UserData/OS/ADMININST/admin1/wlp
4/14/16 4:44:21 Object in use. Object is
/QIBM/UserData/OS/ADMININST/adm
4/14/16 4:44:21 Cannot open object
/QIBM/UserData/OS/ADMININST/admin1/wlp
4/14/16 4:44:21 Object in use. Object is
/QIBM/UserData/OS/ADMININST/adm
4/14/16 4:44:21 Cannot open object
/QIBM/UserData/OS/ADMININST/admin2/wlp
4/14/16 4:44:21 Object in use. Object is
/QIBM/UserData/OS/ADMININST/adm
4/14/16 4:44:21 Cannot open object
/QIBM/UserData/OS/ADMININST/admin2/wlp
4/14/16 4:44:21 Object in use. Object is
/QIBM/UserData/OS/ADMININST/adm
...
Again, this is IBM i 7.2.
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: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx>
Date: 04/14/2016 10:00 AM
Subject: RE: Upgrading to IBM i 7.3
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Allow write during save for directories
In previous releases, the "Allow write during save", or *ALWCKPWRT,
attribute did not apply to directories.
Users were restricted from linking, unlinking, or renaming objects in a
directory while it was being saved.
In this release, this attribute now applies to directories and the value
of the *ALWCKPWRT attribute can be
changed for directories as well as stream files. If the SAV command is
specified with SAVACTOPT(*ALL) or
SAVACTOPT(*ALWCKPWRT), and the attribute value for a particular directory
is "Yes", then objects can be
linked, unlinked, or renamed in that directory while it is being saved.
The value for any previously
existing directory is "No", but the attribute value for any new
directories is governed by the "Inherit
allow checkpoint writer", or *INHCKPWRT, attribute of the new directory's
parent directory. This could lead
to a situation where some directories in a directory tree can not be
changed during a save, but other
directories in that tree could be changed during the save. To prevent this
situation, you might wish to
disable the inheritance of the *ALWCKPWRT attribute for directories. To
disable the inheritance immediately,
use the following program: CALL PGM(QSYS/QP0FPTOS) PARM(*TRACE17ON). Used
in this manner, the
disablement of allow checkpoint writer will last until the next IPL. To
automatically disable inheritance at
each IPL, use the following command: QSYS/CRTDTAARA
DTAARA(QUSRSYS/QP0FTRC17) TYPE(*CHAR) LEN(1).
To re-enable the inheritance immediately, use CALL PGM(QSYS/QP0FPTOS)
PARM(*TRACE17OFF). To stop
automatically disabling inheritance at each IPL, use QSYS/DLTDTAARA
DTAARA(QUSRSYS/QP0FTRC17).
Does this also mean that *STMF can be saved while in use?
IFS SWA never worked.
Or is this a different animal?
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Thursday, April 14, 2016 9:24 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Upgrading to IBM i 7.3
Read the IBM i 7.3 Memo To Users very carefully!
I've been harping about ciphers lately. Well, if you're using Lan Console
make sure you're current! IBM i 7.3 cracks down on ancient ciphers on old
versions of Lan Console. Disclaimer: Not speaking from experience as
we've converted from Lan Console to HMC as soon as it was available.
LDAP cipher changes. Good thing we've recently upgraded our IBM Security
Identity Manager (ISIM) from the old IBM Tivoli Identity Manager (ITIM).
But we'll keep an eye on it as I've signed up for IBM notifications on
that product also and I'm getting cipher notifications there also. We use
ISIM to keep our Windows, IBM i, etc passwords all in sync.
Hopefully the link in the IBM i 7.3 MTU to "Discontinued support for
certain software and hardware" get's updated soon. I tried 'really hard'
to get some of the stuff on the 'future' page at
http://www-947.ibm.com/systems/support/i/planning/upgrade/future.html
They did drop some really old stuff. What's left that may seem old to
some is legitamately there for "Don't say we didn't tell you..."
IBM i 7.3>IBM i and related software>Installing, upgrading, or deleting
IBM i and related software>Upgrading or replacing IBM i and related
software>Preparing to upgrade or replace IBM i software>Performing
software>initial
upgrade or replacement tasks>Preparing your console for software
installation Preparing your console for software installation
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzahc/rzahcswsdspport.htm?lang=en-us
There's a sentence in there which says:
<snip>
The console mode display also includes the option to allow your 5250
console to be taken over by another console. When this option is turned
on, the system does not stop with a console failure but continues to run
uninterrupted. For more information, see the topic Console takeover and
recovery .
</snip>
Click on the topic "Console takeover and recovery." Do this!!!! Is there
a drawback? Well, when you first sign on to your system console they will
get a prompt to also log on to System Service Tools (SST) and that person
will have to know a SST user id and password. Tough. Do it anyway!!! At
least prior to the upgrade and until the upgrade, all PTF's, etc are
completed. I'd argue that Joe Dataentryclerk shouldn't be using your
system console for day to day tasks anyways. It's not like there's some
twinax console sitting there. Hint: Make your console ergonomically
vicious. Put the keyboard and monitor in the bottom slot of your rack.
The really saavy user will use HMC remote console anyway and never
physically touch it. Or if they think they just have to they'll remember
that they've also hooked it up to their KVM and use that remotely instead.
I've lost the console during two different upgrades.
I've been doing this for a few years on some of my lpars and it has saved
my bacon during long running saves and reclaim storages. I will configure
this on the rest of my lpars. At least it will be consistent for those
who use the console (which is like once a quarter at most).
And, what the heck, you can run your HMC on a virtual machine now so
physical laying on of hands is like "huh?".
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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
midrange.com
