Opened a case this morning on this.  Job Scheduler is crashing
unexpectedly, corrupting bin\bpsched.d\pempersist and retirepersist.
Stopping the services, removing the two files and restarting services
fixes the scheduling problem, but the reason why JS is dying is still
out there.  I now have a new case, at a lower level, to try and diagnose
why JS is crashing.

Jason

> -----Original Message-----
> From: veritas-bu-bounces at mailman.eng.auburn.edu 
> [mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf 
> Of Brooks, Jason
> Sent: Wednesday, August 16, 2006 8:58 AM
> To: veritas-bu at mailman.eng.auburn.edu
> Subject: [Veritas-bu] NBU 6.0 MP3 Scheduler Problems?
> 
> Last week, we upgraded to MP3 in order to take advantage of 
> the new BMR features.  The past two nights, however, I've 
> seen some odd behavior that makes me question the reliability 
> of the scheduler.  Here's what
> happens:
> 
> At 8:43PM, the policy for my inside Windows servers kicked 
> off, but all clients failed, either with a return of 50 or 
> 200.  The 50s, I'll look at, but the several 200s bother me.  
> The policy looks like this:
> 
> Policy Name:       Windows-Inside-Tape
> Options:           0x0
> template:          FALSE
> c_unused1:         ?
> Names:             (none)
> Policy Type:       MS-Windows-NT (13)
> Active:            no
> Effective date:    03/08/2006 13:47:15
> Backup netwrk drvs:no
> Collect TIR info:      no
> Mult. Data Stream: yes
> Perform Snapshot Backup:   no
> Snapshot Method:           (none)
> Snapshot Method Arguments: (none)
> Perform Offhost Backup:    no
> Backup Copy:               0
> Use Data Mover:            no
> Data Mover Type:           0
> Use Alternate Client:      no
> Alternate Client Name:     (none)
> Enable Instant Recovery:   no
> Policy Priority:   25
> Max Jobs/Policy:   Unlimited
> Disaster Recovery: 0
> Collect BMR Info:  no
> Keyword:           (none specified)
> Client Encrypt:    no
> Checkpoint:        yes
>       Interval:    15
> Residence:         hobbes-hcart3-robot-tld-0
> Volume Pool:       Windows_Differential
> Client/HW/OS/Pri:  cheyney PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  origin PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  intranet PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  odyssey PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  ciscoacs PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  foundation PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  comet PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  linus PC WindowsNET 0 0 0 0 ?
> Client/HW/OS/Pri:  pug PC WindowsNET 0 0 0 0 ?
> Client/HW/OS/Pri:  lenel PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  lupd PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  resource25 PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  alumni PC Windows2000 0 0 0 0 ?
> Client/HW/OS/Pri:  snoopy.longwood.edu PC WindowsNET 0 0 0 0 ?
> Client/HW/OS/Pri:  159.230.64.109 PC WindowsNET 0 0 0 0 ?
> Include:           NEW_STREAM
> Include:           ALL_LOCAL_DRIVES
> Exclude:           (none defined)
> Schedule:          Windows-Tape-Full
>   Type:            FULL (0)
>   Frequency:       7 day(s) (604800 seconds)
>   Maximum MPX:     1
>   Synthetic:       0
>   PFI Recovery:    0
>   Retention Level: 3 (1 month)
>   u-wind/o/d:      0 0
>   Incr Type:       DELTA (0)
>   Alt Read Host:   (none defined)
>   Max Frag Size:   0 MB
>   Number Copies:   1
>   Fail on Error:   0
>   Residence:       (specific storage unit not required)
>   Volume Pool:     (same as policy volume pool)
>   Daily Windows:
>    Day         Open       Close       W-Open     W-Close
>    Sunday      000:00:00  000:00:00
>    Monday      000:00:00  000:00:00
>    Tuesday     000:00:00  000:00:00
>    Wednesday   000:00:00  000:00:00
>    Thursday    000:00:00  000:00:00
>    Friday      022:30:00  038:50:00   142:30:00  158:50:00
>    Saturday    000:00:00  000:00:00
> Schedule:          Windows-Tape-Diff-Incremental
>   Type:            INCR (1)
>   Frequency:       1 day(s) (86400 seconds)
>   Maximum MPX:     4
>   Synthetic:       0
>   PFI Recovery:    0
>   Retention Level: 3 (1 month)
>   u-wind/o/d:      0 0
>   Incr Type:       DELTA (0)
>   Alt Read Host:   (none defined)
>   Max Frag Size:   0 MB
>   Number Copies:   1
>   Fail on Error:   0
>   Residence:       (specific storage unit not required)
>   Volume Pool:     (same as policy volume pool)
>   Daily Windows:
>    Day         Open       Close       W-Open     W-Close
>    Sunday      020:30:00  031:50:00   020:30:00  031:50:00
>    Monday      020:30:00  031:50:00   044:30:00  055:50:00
>    Tuesday     020:30:00  031:50:00   068:30:00  079:50:00
>    Wednesday   020:30:00  031:50:00   092:30:00  103:50:00
>    Thursday    020:30:00  031:50:00   116:30:00  127:50:00
>    Friday      000:00:00  000:00:00
>    Saturday    013:50:00  013:50:00
> 
> Examining the All Log Entries, I see that the 200s are red herrings.
> The client process actually aborts first, but server reports a 200.
> 
> To try and debug, I've adjusted the logging level on one of 
> the clients and tried to run a manual backup.  The backup has 
> yet to show in the Activity Monitor.  In addition to the 
> oddities with this policy, nothing runs after it.  But there 
> are about 4 policies that should.  
> 
> One final oddity: yesterday morning when I came in, I RDP'd 
> into the master and kicked up the NBU Console.  It showed 
> nothing and complained about EMM not running.  Killed the 
> console, went to services and EMM was running.  I ended up 
> rebooting to get things back up.  My DSSU jobs ran fine 
> yesterday afternoon, but there wasn't much to relocate.
> 
> My master server is Windows 2003 Standard; media, same.  Both 
> are attached to an ADIC Scalar i2K.
> 
> Any ideas, short of calling Symantec?  Anyone seen something similar?
> 
> ------------
> Jason Brooks
> Computer Systems Engineer
> IITS - Longwood University
> voice - (434) 395-2916
> fax - (434) 395-2035
> mailto:<brooksje at longwood.edu> 
> 
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu 
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>