Check the maximum jobs per policy attribute, which is viewable from inside the policy itself.  You can also check max jobs per client, which is viewable from the host properties of the master server, under the "Global Attributes" section.

Both of these parameters can be limiting how many jobs run at once.

1) when they are in the queued state - what is the reason - the job will tell you in the activity monitor.  The reason it gives you will help in tracking down what is wrong.

2) did they ever work, or is this something new?  If they use to work and just started doing this, check the activity montor for all jobs run on a client.  See if it ran ok then when done respawned the backup job again, which failed with a 196.  This happens some times, deactivate the policy and reactivate it get it "read fresh".

Known issue with NBU 5.1 - Several TechNotes:
http://seer.entsupport.symantec.com/docs/274559.htm
http://seer.entsupport.symantec.com/docs/274544.htm
http://seer.entsupport.symantec.com/docs/237534.htm
http://seer.entsupport.symantec.com/docs/275976.htm

Try to see if the jobs are in the same pool.

for exempla:

here we have 3 libraries..

the file policy runs only at the L180, even if the other drives are free, jobs won't go out of the queue unles U change the pool

Check the value of Maximum concurrent write drives for the Storage Unit.

Maximum concurrent write drives is 15 and STU contains 15 drives
targetted volume pool contains 4400 media
810 policies hav same volume pool
limit jobs per policy is not set as there is only 1 client  in each  4 policies

when the job is in queue state for a long time it is not showing anything in activity monitor log

Have you had a look at those TechNotes yet?
Extract from 1st one:
Available drives are not being used. Jobs are staying queued....

As the NetBackup enterprise grows, the response time for the -countmedia function call can take longer to return. This delay is typically seen in environments with volume databases containing over 25000 pieces of media and failing or slow name resolution.

Have you considered upgrading NBU to 6.5.x? bpsched doesn't exit anymore - it's functions are split into seperate scheduler (nbpem) and resource broker (nbrb).
Queued jobs will also display exact reason for job being queued.
Plus you will have the additional advantage of Symantec support...