RE: full system save. Option 21

[D.BALE@xxxxxxxxxxxxx]

I'm really stretching my memory on this one, so bear with me if I get way out
of whack.

Several years ago when I was a programmer / system operator for this one
client, I wrote the backup app from scratch.  Because of the available tape
capacity and the time allocated, I was able to do essentially a SAVE 21:
SAVSYS, SAVLIB *ALLUSR, SAVDLO, SAV.  My application had a DLYJOB RSMTIME
after the INZTAP, and at 1:00 (?) in the morning, the app took the system to a
restricted state (ENDSBS).  Since I didn't get in until 9:00 and we had people
on the shop floor coming in at 6:00 a.m., the AS/400 *HAD* to be up and
running.  There was no allowance for messages waiting to be answered and I
didn't particularly care to be answering phone calls that early.

So, I didn't worry about break messages.  I globally monitored a CPF0000 &
MCH0000 (others?), and quickly figured out which messages I had to monitor,
and take specific action for, and made those changes to the program.  Before
long, the global MONMSG never got hit.

Now, I suppose that if the SAVE 21 being run and is being watched by someone
(a nighttime operator), then allowing messages to break is probably a good
idea.

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------
Dan

yeah you still need to sign on, although I suppose you could acquire the
device as discussed in a separate thread - I don't like this idea for the
console though.

My observation of BRMS was that it kicked off a program that then just
waited on a data queue (QRCVDTAQ with a timeout of  -1  (wait forever
(corrections accepted :))))

Additionally you could interrupt it by signing back in - I presume it
either checked two dataqueues cycling between them, or alternatively the
"signing back in" action caused a return to screen control entry to be
placed on the dataqueue. In other words, the BRMS screen displays an option
on the console to allow you to interrupt processing at the console - an
important feature in my mind !

I've made that sounds more complex than it seems, and no doubt someone more
knowledgeable about BRMS will correct me or add to the discussion.

I have been meaning to get around to this for quite a while (i.e. adding
the console wait on data queue function to my save programs), but the first
thing I need to add (like BRMS appears to have - can someone confirm ?) is
the ability to prevent break messages that arrive on the console
interrupting processing. This is in fact the major reason I haven't
progressed this

On this topic - how WOULD you ensure that a screen waiting on a dataqueue
"ignored" or otherwise handled break messages. My own initial
experimentation with RCVMSG was fruitless, though I did not spend a lot of
time on it.

Hope this provides more food for thought

At 05:39 PM 04/24/01 -0400, you wrote:
>Not having had any extensive experience with data queues, I thought I have
>seen where they are used for this type of thing.  Using the data queue
 method,
>does the system console still need to be signed on for it to work?  And,
>therefore, still requiring restricted access to the system console?
>
>I see your point, though, with it offering more flexibility for scheduling.
>It also allows for a remote administrator (like myself) to hold or reschedule
>the scheduled job in case the branch needs to operate past the normally
>scheduled time.  I like it!
>
>- Dan
>Dan Bale says "Ban Dale!"
>IT - AS/400
>Handleman Company
>248-362-4400  Ext. 4952
>D.Bale@Handleman.com
>   Quiquid latine dictum sit altum viditur.
>   (Whatever is said in Latin seems profound.)
>
>-------------------------- Original Message --------------------------
>
>Dan
>
>Can't speak for Robot or whatever, and I use the same method as you have
>historically used.
>
>A strategy I have seen suggested at various times and one which BRMS
>appears to use (from what I've seen of it)  is to have a console job signed
>on that waits on a data queue. When something is recieved on the data queue
>then something happens. (DUH!)
>
>In this case it runs the system (or other) save and as its signed on at the
>console, it is able to run a SAVSYS. The job that sends the data queue
>entry could be on the scheduler or wherever, giving a tad more flexibility
>than the DLYJOB option.
>
>Hope this helps
>
>Regards
>Evan Harris
>
> >Does anyone know if the 3rd party backup products do anything more than
> stick
> >a DLYJOB RSMTIME(&TIME) before it does the SAVE 21 stuff?  I did this years
> >ago where the system console was in a locked room for which only the MIS
> >manager & myself had a key.  Every afternoon I'd load the next day's backup
> >tape in the tape drive, call up a special menu on the system console, take
>  the
> >option.  The first thing it did was to INZTAP the tape, this was also a
>  sanity
> >check that the drive was "ready".  I walked out of the computer room and
> >locked the door.  Then it hit a DLYJOB RSMTIME(020000) before ENDSBS
> *ALL and
> >running all of the SAVe commands.
> >
> >Not knowing any better to do otherwise, my method requires restricted
 access
> >to the system console.  Do the 3rd party backup products do it any better
>  than
> >that?
> >
> >Dan Bale
> >IT - AS/400
> >Handleman Company
> >248-362-4400  Ext. 4952
> >D.Bale@Handleman.com
> >   Quiquid latine dictum sit altum viditur.
> >   (Whatever is said in Latin seems profound.)
> >
> >-------------------------- Original Message --------------------------
> > > I would like to be able to schedule a job to run a full
> > > system backup.  Is this possible?
> >
> >Not really, as the full system save runs in restricted state.
> >
> >Some 3rd party backup products (Robot/Save is the one that comes to mind)
> >provides support to schedule a full system save.  I think you have to run a
> >backup agent on your console and it checks the time and takes the system
> >into restricted state prior to trying to run a full system save.
> >
> >david
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---