Mark -

Why not just store it in a Data Area, something like this: 

ENDSBS     SBS(&SBS)                                    
MONMSG     MSGID(CPF1053) EXEC(CHGDTAARA +              
             DTAARA(*LIBL/CTRLSBS) VALUE(&SBS)) +  
             /* Ending controlling subsystem &1 not +   
             allowed. */         

Keep in mind that I'm not really a programmer, I just play one on TV.

Another option is the judicious use of omits in your backups.  I once
had a long discussion with someone who refused to run SWA backups
because their company ran multiple web servers and the backups would
flag unsaved objects.  (SWA without shutting down the web servers.)
Since the unsaved objects were only log files my solution was to leave
the web servers running and use omits, e.g. ('/www/adefault/logs'
*OMIT), ('/QIBM/UserData/HTTPA/admin/logs' *OMIT) and
('/QIBM/UserData/WebASE/ASE5/SYSINST/logs' *OMIT)   

The bottom line is that it's your environment and only you can make the
best decisions on your backup/DR strategy.

PS.  Looking more closely at the CPF1053 message I see that "Ending the
controlling subsystem is allowed only from an interactive job that was
started from a *SIGNON workstation entry in the controlling subsystem."
So doing this from a batch or passthru job will work, but don't do it
from the console!

Regards,
 
Scott Ingvaldson
iSeries System Administrator
GuideOne Insurance Group

                                                        
-----Original Message-----
date: Tue, 11 Apr 2006 10:24:11 -0400
from: "mlazarus@xxxxxxxx" <mlazarus@xxxxxxxx>
subject: RE: Retrieving active controlling subsystem

Scott,

 So far, that's the best suggestion I've received.  Now I'd like to take
this a step further.  

 We have a condition we call "partially restricted." In order to make
our
save-while-active backups less complicated, we shut down all subsystems
that might lock objects in our nightly backup.  Once the ENDSBS command
has
run it might take a little while for the subsystems to end.  So I'm
writing
a utility to see if any subsystems are active that are not in a special
"exempt list" and returning an "active" flag, so that the calling
procedure
can wait and try again a little later.

 The controlling subsystem should not need to be in the exempt list,
since
it's always exempt. My problem is, if the active controlling subsystem
does
not match the QCTLSBSD value I will not have a way to determine that
it's
OK to skip it.

 Since the ENDSBS knows to send CPF1053, the status must be somewhere.
Any
ideas?

 -mark

Original Message:
-----------------
From: Ingvaldson, Scott SIngvaldson@xxxxxxxxxxxx
Date: Tue, 11 Apr 2006 08:12:31 -0500
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Retrieving active controlling subsystem


I'm not sure that you can end the controlling subsystem by itself.  When
I do an ENDSBS SBS(QCTL) I get message CPF1053 -    Ending controlling
subsystem QCTL not allowed.

So if you RTVSYSVAL QCTLSBSD then an ENDSBS for the QCTLSBSD value you
can monitor for CPF1053.  I'm not sure you even need to go that far, you
can probably just start ending active subsystems and monitor for the
CPF1053.

Regards,
 
Scott Ingvaldson
iSeries System Administrator
GuideOne Insurance Group


-----Original Message-----
date: Mon, 10 Apr 2006 17:37:50 -0400
from: "mlazarus@xxxxxxxx" <mlazarus@xxxxxxxx>
subject: Re: Retrieving active controlling subsystem

Mark,

 I'm looking for the "current active" controlling subsystem.  If I do a
CHGSYSVAL QCTLSBSD, then I believe that the retrieve will not give me
which one is currently active, rather which one *will* be active.

 -mark


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.