Couldn't I just set up multiple schedulers that all start up at about the
same time to make it  parallel.  That way I don't need to try and extract
the errorlevels for each process and try to combine them somehow.

I tried adding a START command in front of the FULL backup at the beginning
of my batch file (to make the first FULL backup run in parallel with the
rest)  but I ended up with a 418 error, and an unreadable tdpexc.log file
(the outputs from the parallel backup jobs are all mixed together often in
mid sentence).   I will have to ask our storage team what they saw on their
side but in my logs I got

5060E A Tivoli Storage Manager API error has occurred.
02/18/2018 17:02:34 ANS1245E (RC122)  The file has an 0n2/18/2018 17:02:34
ANS1245E (RC122)  The file has an unknown format.

02/18/2018 17:13:20 ANS1236E (RC115)  An unexpected error occurred.
02/18/2018 17:13:20 ACN5060E A Tivoli Storage Manager API error has
occurred.

02/18/2018 17:14:05 ACN5918W The mailbox history did not update
successfully on the TSM Server.
02/18/2018 17:14:05 ACN5060E A Tivoli Storage Manager API error has
occurred.

02/18/2018 17:24:30 ANS1236E (RC115)  An unexpected error occurred.
02/18/2018 17:24:30 ACN5060E A Tivoli Storage Manager API error has
occurred.



On Sun, Feb 18, 2018 at 4:55 PM, Harris, Steven <
steven.harris AT btfinancialgroup DOT com> wrote:

> Tom
>
> It is a failing of TSM/SP that a basic function is deemed "good enough" by
> the people who decide such things within IBM and the real-world
> implementation is left to users. Your problem is not uncommon and a
> solution should be a standard part of the marketed offering.
>
> You will need some powershell skills. Use the powershell cmdlets that come
> with TDP for Exchange and run your processes in parallel. You will need to
> code some funky error checking to make sure the correct return codes are
> returned.
>
> Regards
>
> Steve
>
> Steven Harris
> TSM Admin/Consultant
> Canberra ACT
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Tom Alverson
> Sent: Monday, 19 February 2018 6:45 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Exchange backup speed
>
> Remco:
>
> I appreciate all feedback, blunt or not.  I am relatively new to TSM but I
> only work on windows client issues.  A separate team works on the TSM
> storage servers and they are very experienced
>
> The servers are loafing, they have 4 cores with 32 processors, and 384GB
> of ram, not of which is anywhere near the limit.  The only bottleneck right
> now is the 10GB interfaces in the exchange server and TSM storage servers
> must pass through a 1GB embedded rack switch that I have been urging them
> upgrade.  If we could get anywhere near 1GB network throughput on the
> exchange backups that would be good.
>
> I'm sure the storage servers are not under stress based on performance of
> other backups we have running.
>
> On Sun, Feb 18, 2018 at 1:03 PM, Remco Post <r.post AT plcs DOT nl> wrote:
>
> > Hoi Tom,
> >
> > this might sound a bit blunt, but from what you’re asking I get the
> > strong impression that this the first time you’re working with TSM. So
> > I’m a bit anxious to give you any advise, fearing that it might lead to
> more problems.
> >
> > In general with performance issues I would look into the generic
> > performance indicators of the exchange servers first. Secondly, check
> > for any network bottlenecks between the exchange server and the TSM
> server.
> > Thirdly you can look into the performance indicators of your TSM server.
> > All with normal tools.
> >
> > > Op 17 feb. 2018, om 00:55 heeft Tom Alverson
> > > <tom.alverson AT GMAIL DOT COM>
> > het volgende geschreven:
> > >
> > >>
> > >>
> > >> We are trying to speed up our Exchange backups that are currently
> > >> only
> > > using about 15% of the network bandwidth.  Our servers are running
> > Windows
> > > 2012R2 and Exchange 2013 CU15 with TSM 7.1.0.1 and TDPEXC 7.1.0.1.
> > > Currently we are backing up 15 DAGS per Exchange server (we have
> > > multiple exchange servers) and we are only backing up on servers
> > > that are standby replicas.  Currently we are trying a 14 day
> > > schedule were we do a full backup of a different DAG per day, and
> > > incrementals on the rest.  Even doing this we are having trouble
> > > completing them in 24 hours (before the next day's backup is supposed
> to start).
> > >
> > > I saw an old posting from Del saying to increase RESOURCEUTILIZATION
> > > on
> > the
> > > DSMAGENT.  Does that mean the DSM.OPT in the BACLIENT folder?  It
> > > was set at 2.  Do either the buffers or buffrsize options make any
> difference?
> > >
> > > Also if we want to "parallelize" the backups does that mean separate
> > > scheduler services for each one?  We currently use 14 different
> > > batch
> > files
> > > (for the 14 days of the cycle) with something like this:
> > >
> > > [day1.bat]
> > >
> > > tdpexcc.exe backup dag1 full
> > > tdpexcc.exe backup dag2,dag3,dag4,dag5 incr tdpexcc.exe backup
> > > dag6,dag7,dag8,dag9 incr tdpexcc.exe backup dag10,dag11,dag12,dag13
> > > incr tcpexcc.exe backup dag14,dag15 incr exit
> >
> > --
> >
> >  Met vriendelijke groeten/Kind Regards,
> >
> > Remco Post
> > r.post AT plcs DOT nl
> > +31 6 248 21 622
> >
>
>
> This message and any attachment is confidential and may be privileged or
> otherwise protected from disclosure. You should immediately delete the
> message if you are not the intended recipient. If you have received this
> email by mistake please delete it from your system; you should not copy the
> message or disclose its content to anyone.
>
> This electronic communication may contain general financial product advice
> but should not be relied upon or construed as a recommendation of any
> financial product. The information has been prepared without taking into
> account your objectives, financial situation or needs. You should consider
> the Product Disclosure Statement relating to the financial product and
> consult your financial adviser before making a decision about whether to
> acquire, hold or dispose of a financial product.
>
> For further details on the financial product please go to
> http://www.bt.com.au
>
> Past performance is not a reliable indicator of future performance.
>