[Moabusers] Re: moabusers Digest, Vol 32, Issue 10 (Ouf of Office Response)

[Jonathan Ryskamp]

I will be out of the office on July 23rd and July 24th.

If you need immediate assistance please contact:

Technical Support: 
Nick Ihli
+1 (801) 717-3736
nick.ihli at clusterresources.com

Sales Support:
Michael Jackson
+1 (801) 717-3722
michael at clusterresources.com
And
Jess Arrington
+1 (801) 717-3716
jess at clusterresources.com

Thanks,
Jonathan

>>> moabusers 07/21/07 12:00 >>>

Send moabusers mailing list submissions to
	moabusers at supercluster.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.supercluster.org/mailman/listinfo/moabusers
or, via email, send a message with subject or body 'help' to
	moabusers-request at supercluster.org

You can reach the person managing the list at
	moabusers-owner at supercluster.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of moabusers digest..."


Today's Topics:

   1. QOSCFG OMAXJWC with USERCFG QLIST and MAX.WCLIMIT (Michael Santos)
   2. CLASSCFG[<class>] MAXPROC[QOS:<qos>]=N (Michael Santos)


----------------------------------------------------------------------

Message: 1
Date: Fri, 20 Jul 2007 15:27:35 -0400
From: Michael Santos <msantos at stsci.edu>
Subject: [Moabusers] QOSCFG OMAXJWC with USERCFG QLIST and MAX.WCLIMIT
To: moabusers at supercluster.org
Message-ID: <135FCA37-C629-4D73-8909-D476C884F83B at stsci.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Hi,

	I get a strange difference of behavior when using the following
two  
policies.

Policy 1:

USERCFG[msantos] QLIST=qos1,qos2 MAX.WCLIMIT=8:00:00
QOSCFG[qos1]
QOSCFG[qos2]         OMAXJWC=10:00:00

Policy 2:
USERCFG[msantos] QLIST=qos2,qos1 MAX.WCLIMIT=8:00:00
QOSCFG[qos1]
QOSCFG[qos2]         OMAXJWC=10:00:00

(The only difference is the ordering of QLIST's arguments.)

	Under each policy user msantos submits two jobs, each asking for
 
9:00:00 of wallclock, like so:

msub -l qos=qos1 nine-hour-job.pbs
msub -l qos=qos2 nine-hour-job.pbs

Under policy 1, both job submissions get rejected with the same error:

ERROR:    cannot submit job - wclimit too high for user  
'msantos' (32400 > 28800)

Under policy 2, both job submissions are accepted, the qos1 job is  
blocked, and the qos2 job is run.

	Policy 2 gives the behavior I expected; policy 1 does not.  I  
understand that the ordering of QoSs in QLIST affects the default QoS  
assigned to the jobs of user msantos; however, in both cases I  
explicitly specified the QoS on the command line.

	Is this a bug, or expected behavior?  If expected behavior, I
don't  
think it is documented in the Admin's Guide (at least in Section  
7.3.2.3, where I would have expected it).

	Thank you.

Best regards,
Michael Santos
Space Telescope Science Institute



------------------------------

Message: 2
Date: Fri, 20 Jul 2007 14:38:28 -0400
From: Michael Santos <msantos at stsci.edu>
Subject: [Moabusers] CLASSCFG[<class>] MAXPROC[QOS:<qos>]=N
To: moabusers at supercluster.org
Message-ID: <D9B5F1DD-0403-4B78-968B-7C66EE588535 at stsci.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Hi,

	Section 6.2.1.2 of the Moab Admin's Guide gives:

*CFG[X]  <LIMITTYPE>[<CRED>]=<LIMITVALUE>

	However, when I try

CLASSCFG[<class>] MAXPROC[QOS:<qos>]=N

moab doesn't complain, but it also doesn't enforce the policy.  I  
have checked that, e.g.,

CLASSCFG[<class>] MAXPROC[USER:<user>]=N

works as expected.

	Is this a bug, or is it that the documentation is misleading?   
(Based on the examples, clearly 'CLASSCFG' is an acceptable expansion  
of "*CFG", and "QOS" is explicitly listed as an allowed value of  
<CREDTYPE>.)

	We are running

moab server version 5.1.0p3 (snap NA) (rev. 6956M)

	Thank you.

Best regards,
Michael Santos
Space Telescope Science Institute



------------------------------

_______________________________________________
moabusers mailing list
moabusers at supercluster.org
http://www.supercluster.org/mailman/listinfo/moabusers


End of moabusers Digest, Vol 32, Issue 10
*****************************************