I get the idea of not wanting to save objects that aren't worthy of being saved.
But I've got applications with folders down in the bowels of these folders that are not controlled by me. Case in point are objects in subfolders of /QIBM/UserData/mqm/sockets... with this attribute off. MQ controls the attributes on these objects, not me. I don't know if I need these objects if I have to go back and restore, and/or what levels of complication this leaves for me when that time comes.
I'm trying to get a good backup of my machine, and these objects come up as not saved. I would like a nice clean 'it worked' or 'It didn't' message my operators can glance at with some confidence after a save, but these allow save *NO objects gum that up, and force us into reviewing the joblogs of the saves to determine if we really have a complete backup or not. I'm not adverse to excluding these objects from the saves, but forcing us to scrutinize joblog detail after each save operation just seems like cruel and unusual punishment.
Jim Ash
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Rob Berendt
Sent: Thursday, May 9, 2024 7:58 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: [ EXTERNAL ]Re: IFS allow save object attribute?
One thing to think about is that save while active of IFS is a sick joke.
So much of the stuff in there considered expendable is flagged that way as it will never get saved with a backup while the system is live. Examples are log and trace files. Some would even be a conflict in a restricted state, like maybe BRMS log files. And it's not just that they will get skipped on a save, if a process tries to use it when it is temporarily locked by a save it may abort the process.
I, too, flag the image catalogs as not to save. They are huge, slow down the save, and I plan on them not being there. I suppose if I just had to have them I could flag them as allow save but I don't tend to get so far behind on hardware that I need to save my image catalogs to unload/reload on to newer hardware and then upgrade the OS on the new hardware. My save instructions note this 'just in case'.
I've done numerous unload/reloads and never has IBM's use of ALWSAV(*NO) been a problem.
On Wed, May 8, 2024 at 8:51 PM James Ash via MIDRANGE-L < midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
I'm trying to clean up my IFS backups and I've had problems in the
past with objects not being saved because the attribute to allow an
object to be saved was *NO.
I'm having a hard time grasping why I wouldn't want to save this
object (or any object) on my system and why this attribute even
exists. It just seems like a setup for failure.
If I change all the *NO attributes to *YES, am I causing the failure
of some process or is this all just about saving space and time on my backups?
Jim Ash
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit:
https://list/
s.midrange.com%2Fmailman%2Flistinfo%2Fmidrange-l&data=05%7C02%7Cjash%4
0littletoncoin.com%7C3f680ad0f84e406bfb3a08dc701f4afe%7Cf671045cabcb48
3e800849f5e77d0a0d%7C0%7C0%7C638508526917913881%7CUnknown%7CTWFpbGZsb3
d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
C0%7C%7C%7C&sdata=pJBHbR%2B1p%2BPbxeQ0ngyno4IKITw6vx2hik%2Bt6yuMRGU%3D
&reserved=0 or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
