[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=3250]

        Issue #:      3250             Platform:     All      Reporter: mhanby (mhanby)
       Component:     gridengine          OS:        Linux
     Subcomponent:    scheduling       Version:      6.2u5       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
          URL:        http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=248081
       * Summary:     Unable to submit job using advance reservation if h_rt is longer than 32999 seconds
   Status whiteboard:
      Attachments:

     Issue 3250 blocks:
   Votes for issue 3250:


   Opened: Fri Mar 12 14:37:00 -0700 2010 
------------------------


See the discussion here:
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=248081

GE 6.2u5
Linux x86_64
CentOS 5.4

I have created an advance reservation that has a duration of 225 hours and 59 minutes and 64 slots. The users in the ACL for the reservation
can submit jobs to using the reservation ID so long as their h_rt is 32999 seconds or less (9 hours 9 minutes and 59 seconds), any longer
than that and the qsub fails "Unable to run job: error: no suitable queues"

$ qrstat -ar 15
--------------------------------------------------------------------------------
id                             15
name                           testAR
owner                          mikeh
state                          r
start_time                     03/12/2010 13:00:00
end_time                       03/21/2010 23:59:00
duration                       225:59:00
submission_time                03/12/2010 11:36:36
group                          sge
account                        sge
granted_slots_list
all.q@compute-1-4.local=8,all.q@compute-0-8.local=8,all.q@compute-0-7.local=8,all.q@compute-0-3.local=8,all.q@compute-0-12.local=8,all.q@compute-0-10.local=8,all.q@compute-0-5.local=3,all.q@compute-0-6.local=8,all.q@compute-0-14.local=5
granted_parallel_environment   lam_loose_rsh slots 64
mail_options                   abe
acl_list                       mikeh,jdoe

Next we can see the 64 slots in the reservation:
$ qstat -g c
CLUSTER QUEUE                   CQLOAD   USED    RES  AVAIL  TOTAL aoACDS  cdsuE
--------------------------------------------------------------------------------
all.q                             0.66    128     64     64    192      0      0

Now, try and submit two jobs using the reservation:

$ echo `/bin/hostname` | qsub -ar 15 -pe lam_loose_rsh 32 -l h_rt=09:09:59
Your job 111005 ("STDIN") has been submitted

$ echo `/bin/hostname` | qsub -ar 15 -pe lam_loose_rsh 32 -l h_rt=09:10:59
Unable to run job: error: no suitable queues.
Exiting.

It seems that I can submit jobs using this AR so long as the max runtime is less than 32999 seconds. Any job submission 33000 seconds or
longer fails.

If I submit the same jobs without specifying a reservation, they will both submit and run properly.

Reuti also confirmed this behavior, although he found a slightly different max:

=========================================
> I also tried using "h_rt=32999" and "h_rt=33000" with the same
> results.

Yep, I must confirm this. But for me the limit is 9:09:00, i.e. 32940.

-- Reuti
=========================================

[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=3256]

        Issue #:      3256             Platform:     All      Reporter: reuti (reuti)
       Component:     gridengine          OS:        All
     Subcomponent:    clients          Version:      6.2u5       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    roland (roland)
      QA Contact:     roland
          URL:
       * Summary:     qsub -p accepts anything as priority value
   Status whiteboard:
      Attachments:

     Issue 3256 blocks:
   Votes for issue 3256:


   Opened: Tue Mar 30 16:22:00 -0700 2010 
------------------------


The parser for the argument to -p in qsub accepts anything and renders it as 0 when it's a nonsense string. It should through an error for
non numerical arguments.

[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=3259]

        Issue #:      3259             Platform:     All      Reporter: reuti (reuti)
       Component:     gridengine          OS:        All
     Subcomponent:    man              Version:      6.2u5       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
          URL:
       * Summary:     Manpage of qstat still lists Transfer queues
   Status whiteboard:
      Attachments:

     Issue 3259 blocks:
   Votes for issue 3259:


   Opened: Tue Apr 6 10:57:00 -0700 2010 
------------------------


In the section:

   Full Format (with -f and -F)
       Following  the header line a section for each queue separated by a horizontal line is provided. For each queue the infor-
       mation printed consists of

       ·  the queue name,

       ·  the queue type - one of B(atch), I(nteractive), C(heckpointing), P(arallel), T(ransfer)  or  combinations  thereof  or
          N(one),

of qstat Transfer queue are still listed. This reference should be removed.
------- Additional comments from reuti Tue Oct 26 08:49:24 -0700 2010 -------

The same applies to a section of `man qhost`:

       If the -q option is supplied, each host status line also contains extra lines for every queue hosted by the host consist-
       ing of,

       ·  the queue name.

       ·  the queue type - one of B(atch), I(nteractive), C(heckpointing), P(arallel), T(ransfer) or combinations thereof,