Re: v6r1 save system endsbs hanging

[Jim Oberholtzer <midrangel@xxxxxxxxxx>]

Jim,

A time lag between SAVSYS processing and tape movement is normal and 
should not alarm you.  The system does quite a bit of processing and 
preparation prior to writing large amounts of data to the tape.  You 
most likely did not see the very short writes it makes early in the 
process.  Depending on how large all the user profile are with the 
security information in them, it will take a varying amount of time to 
do a SAVSYS.  At iDevCloud we find the SAVSYS with only a couple of 
profiles beyond the IBM supplied ones takes about 20-25 minutes to a 
3580-xxx device.  That's almost regardless of the attach type, fibre or 
SCSI, so tape time is not really the constraint.

As to the IFS mounts, I don't think I have seen that behavior hang a 
save quite like your describing before, I would call that in.  It sounds 
like a timeout or other issue in the TCP shutdown.  An ENDSBS *ALL 
should take the system to a restricted state.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 2/19/2012 7:30 PM, Jim Franz wrote:
> The endsbs *cntrld  180 (3 minutes was used).
> IBM's endtcpsvr, endhostsvr, endtcp instructions worked, but we saw
> almost 15 minutes from time save entire system started to the actual tape
> moving.
> The issue (we think) is Win 7 pc's with mapped drive over ifs/home/"user".
> (we actually did a test with all pc's down - no problem but
> 2 pc's on (and map is active), before doing the endtcp.. commands and the
> endsbs hangs.
> The mapped drives is a setup from years ago, and never an issue till
> V6r1 and win 7.
> I like the exit pgm idea - for now I gave user a cmd to do the ends before
> a save system (no brms here).
> Thanks for the response,
> Jim
>
> ----- Original Message -----
> From: "Jim Oberholtzer"<midrangel@xxxxxxxxxx>
> To: "Midrange Systems Technical Discussion"<midrange-l@xxxxxxxxxxxx>
> Sent: Sunday, February 19, 2012 9:02 AM
> Subject: Re: v6r1 save system endsbs hanging
>
>
> > >  Was the *IMMED option used on the ENDSBS, or at least a time limit set?
> > >  If not there is almost no chance the system will ever get to a
> > >  restricted state.  I also like Bryan's idea with the exit program.  I
> > >  have not done that before but I am going to look into it.
> > >
> > >  Jim Oberholtzer
> > >  Chief Technical Architect
> > >  Agile Technology Architects
> > >
> > >
> > >  On 2/18/2012 7:51 PM, Bdietz400 wrote:
> > > >>  Its even more important to end tcpip if you are using nfs.   We ended up
> > > >>  putting an exit program in place to end everything before the endsbs
> > > >>  happened.
> > > >>
> > > >>  QIBM_QWC_PRERESTRICT - ENDSYS ENDSBS *ALL pre restricted state processing
> > > >>  (called when ENDSBS *ALL is issued).
> > > >>
> > > >>  --
> > > >>  Bryan
> > > >>
> > > >>
> > > >>  On Feb 18, 2012, at 2:23 PM,<franz400@xxxxxxxxxxxx>   wrote:
> > > >>
> > > > > >>>  >    Doing save system before applying cume to v6r1.
> > > > > >>>  >    The endsbs in the save system never completed.
> > > > > >>>  >    Cancelled from console, ipled, and started save system again.
> > > > > >>>  >    It's going.
> > > > > >>>  >    I see notes that memo to users changed to
> > > > > >>>  >    endtcpsvr
> > > > > >>>  >    endhostsvr
> > > > > >>>  >    endtcp
> > > > > >>>  >    before an endsbs *all.
> > > > > >>>  >    Is this the fix to this issue?
> > > > > >>>  >    Anything in latest cume to resolve this?
> > > > > >>>  >    ps... we have had many issues lately w/win 7 mapping drive over ifs
> > > > > >>>  >  /home/user directories and breaks in connection-wondering if this is
> > > > > >>>  >  why endsbs not completing.
> > > > > >>>  >    Jim
> > > > > >>>  >
> > > > > >>>  >    --