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



I know that the initial purpose of this question was to determine the
controlling subsystem due to the possibility that it *MIGHT* be
different from the sysval QCTLSBSD.  After all of this discussion
wouldn't it just be easier just to ensure that QCTLSBSD never gets
changed?  I'm guessing that there is not a compelling business case for
changing the controlling subsystem on any regular basis.  Please let me
know if I'm wrong because I'd love to know why anyone's controlling
subsystem would need to be changed more than once.

Regards,
 
Scott Ingvaldson
iSeries System Administrator
GuideOne Insurance Group


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

Scott,

 Because this piece of the job stream is just supposed to report back to
its caller whether all subsystems (not in the exemption list or
controlling
subsystem) have been ended.  If I don't know how to automatically
exclude the controlling subsystem, then I may erroneously report back
that there's still an active subsystem.

 Also, there's no guarantee that the calling program will attempt to
ENDSBS the controlling subsystem in order to update that *DTAARA.

 -mark

Original Message:
-----------------
From: Ingvaldson, Scott SIngvaldson@xxxxxxxxxxxx
Date: Tue, 11 Apr 2006 11:03:04 -0500
To: midrange-l@xxxxxxxxxxxx, mlazarus@xxxxxxxx
Subject: RE: Retrieving active controlling subsystem


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.