Re: [ EXTERNAL ]Re: IFS allow save object attribute?

You can always open a case to see if MQ thinks this is a concern. I would
think a socket would not survive across an IPL and either would be locked
or not during a save. If not locked it's probably done with it.

On Thu, May 9, 2024 at 12:44 PM James Ash via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

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.

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