Thought about this SQL Server backup plan?
While this is functional, there's some holes in here that will make it difficult for to recover in the event of a problem:


I'm not sure what the device is your backing up to for your logs, but based on what I'm seeing here, you're appending all your log backups to the same file/device for all your log backup actions.  This can be cumbersome to manage and can cause you storage issues.
The BACKUP LOG ... WITH TRUNCATE_ONLY is redundant and can possibly cause you data loss.  Your log truncation occurs after every log backup, so that should be sufficient to manage your log, though you should consider scheduling your log backups for every hour 24/7 instead of just 6 AM-11 PM.
Your full backup with it's current syntax will overwrite your previous backup every run, so unless your saving that backup off to tape between the full backup runs, you will not be able to restore previous to your last full backup.
Shrinking databases regularly is VERY bad practice, for a variety of reasons.  Paul Randal talks more about it here.


In general, it looks like your backup/maintenance plan is as follows:


Execute a full backup nightly (1 AM)
Execute transaction log backups every hour
Rebuild fragmented indexes nightly


This is a solid enough plan, it looks like you just need to fill in some of the gaps.  Unfortunately, backup/restore is far to large a topic to cover here.  I recommend you read about this at SQLServerPedia(now ToadWorld).  Since you're committed to SQL 2000, this limits you to making use of some of the currently existing tools out there.  However, plenty of code examples exist to fine tune and polish your currently existing code.

As for index fragmentation, without seeing your code, I can't comment to any possible issues with it.  If it's been working fine up until now, there's probably no issues there, but you can read more about managing this up on MSDN.