Helo all,
I discovered this problem on the MVS server some time ago and reported it to
IBM. Here is the reply that i got :
You appear to have stumbled into a tricky little are here. A couple of
APARs have already been written in this area of multiple backup
stgpools with Wait=Yes set.
The one which best applies here is PQ19011 (which was closed on Sept
1st but has no PTF for it yet). This describes a 'race' condition
between the multiple processes set off by your Backup Stgpool command
with MAXPR=4. The problem is that when any one of the 4 processes
finishes, it can free some of the shared (in memory) resources used by
the others. This can, in the worst cases, cause the ADSM server to
crash.
In your case we started processes 59,60,61, and 62 for the first
Backup STG command. These 'race' and do NOT end in sequence. When
process 62 ends, we (wrongly) assume that the whole command has
finished and kick off the second Backup STG command (which starts
processes 63,64,65, and 66). In fact, process 61 did the bulk of the
first Backup STG and did not complete until 08:51:47.
I'm afraid there is no fix yet. The PQ19011 APAR recommends you
circumvent the problem for now by either using WAIT=NO or MAXPR=1.
It shouldn't take too much longer using maxpr=1 because 1 process is
doing most of the work anyway already.
....
I was told the fixtest may be available around December time.
Seasons greetings.
Thanks,
Kuli.
Kulbinder Toora
01384 296191 x3498
e-mail - Kulbinder.toora AT meb.co DOT uk
Midlands Electricity
> -----Original Message-----
> From: Hilton Tina [SMTP:HiltonT AT TCE DOT COM]
> Sent: Monday, December 28, 1998 12:49 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: ADSM Scripts
>
> When I upgraded to version 3, I rewrote my script to use wait=yes for all
> the commands (backup stg, backup db, etc.). I never noticed that my
> maxprocess=2 parameter was being ignored now until I looked after reading
> your email, Roger.
>
> There's nothing that I could find in the manual that says the maxpr=nn
> parameter is only for background processes, not foreground ones with the
> wait=yes parameter. Has anyone else found documentation that says IBM
> intended this to be true?
>
> Tina
>
> > -----Original Message-----
> > From: Roger Hohmann [SMTP:Roger_Hohmann AT WESTLB DOT DE]
> > Sent: Monday, December 28, 1998 2:55 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: ADSM Scripts
> >
> > I use it with wait=yes, but it seems to be limited to one (1) session
> > (one process at a time). So I am copying my smaller pools first and my
> > big one last with wait=n and maxsess=3.
> >
> >
> > -----Original Message-----
> > From: Hilton Tina [SMTP:HiltonT AT TCE DOT COM]
> > Sent: Wednesday, December 23, 1998 7:23 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: ADSM Scripts
> >
> > I do it inside a script, but with version 3 of the server use the
> > wait=yes
> > option. You won't get control back until the backup has finished. I
> > assume
> > it works the same way in a macro, but haven't tested it.
> >
> > > -----Original Message-----
> > > From: Remeta, Mark [SMTP:MRemeta AT SELIGMANDATA DOT COM]
> > > Sent: Wednesday, December 23, 1998 1:00 PM
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > Subject: ADSM Scripts
> > >
> > > Hello all!
> > >
> > > I want to write a ADSM macro/script that will do several storage pool
> > > backups but I don't want to start the second one until the first one
> > > completes. How can I determine, in a macro, that the first backup
> > > command completed before I issue the second?
> > >
> > > Thanks in advance,
> > >
> > > Mark Remeta
> > > Seligman Data Corp.
> > > 100 Park Avenue
> > > New York, NY 10017
> > > (212)716-2810
>
> ================================================================
> This incoming e-mail (and any attachments) has been checked at MEB
> (UK 01384 296191), and has been found to be clean from any
> virus infection (using Dr Solomon's v7.90).
>
> If you have any queries about viruses, please contact PC Tech
> Support (09 3521) or about the external e-mail system, contact
> David Perry (09 3673).
>
> ================================================================
================================================================
This outgoing e-mail (and any attachments) has been checked
(using Dr Solomon's v7.90) at MEB (UK 01384 296191) before
despatch, and has been found to be clean from any virus infection.
If you have any queries about viruses, please contact PC Tech
Support (09 3521) or about the external e-mail system, contact
David Perry (09 3673).
================================================================
|
