!!___INFO__MARK_BEGIN__
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!
!!  The Contents of this file are made available subject to the terms of
!!  the Sun Industry Standards Source License Version 1.2
!!
!!  Sun Microsystems Inc., March, 2001
!!
!!
!!  Sun Industry Standards Source License Version 1.2
!!  =================================================
!!  The contents of this file are subject to the Sun Industry Standards
!!  Source License Version 1.2 (the "License"); You may not use this file
!!  except in compliance with the License. You may obtain a copy of the
!!  License at http://gridengine.sunsource.net/Gridengine_SISSL_license.html
!!
!!  Software provided under this License is provided on an "AS IS" basis,
!!  WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,
!!  WITHOUT LIMITATION, WARRANTIES THAT THE SOFTWARE IS FREE OF DEFECTS,
!!  MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE, OR NON-INFRINGING.
!!  See the License for the specific provisions governing your rights and
!!  obligations concerning the Software.
!!
!!  The Initial Developer of the Original Code is: Sun Microsystems, Inc.
!!
!!  Copyright: 2001 by Sun Microsystems, Inc.
!!
!!  All Rights Reserved.
!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!___INFO__MARK_END__
Qmon*xmtHelpTitle: Qmon Graphical User Interface Help
Qmon*xmtHelp: \
No help available for this topic !

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*MainControl.?.xmtHelpTitle: @fBMain Control Help
Qmon*MainControl.?.xmtHelp: \
This is @fBQmon Main Control@fR click one of the icons to activate it.\n\
Use @fBHelp->Context Help@fR on the icons to get further information.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*JOB_CONTROL.xmtHelpTitle: @fBJob Control Help
Qmon*JOB_CONTROL.xmtHelp: \
The @fBJob Control@fR dialogue is opened by pressing the @fBJob Control Icon@fR\n\
or by selecting @fBJob Control@fR in the @fBTask@fR menu.\n\
\n\
The purpose of this dialogue is to provide the means to monitor all running and\n\
pending jobs known to the Grid Engine system.\n\
\n\
The dialogue can also be used to manipulate jobs, i.e. to change their attributes,\n\
to suspend, resume and to cancel them.\n\
Three  listings are displayed one for the pending jobs, one for the running jobs\n\
and one for recently finished jobs.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*QUEUE_CONTROL.xmtHelpTitle: @fBQueue Control Help
Qmon*QUEUE_CONTROL.xmtHelp: \
The @fBQueue Control@fR dialogue is opened by pressing the @fBQueue Control Icon@fR\n\
or by selecting @fBQueue Control@fR in the @fBTask@fR menu.\n\
\n\
The @fBQueue Control@fR dialogue provides a quick overview of available queues, their\n\
state and the cluster activity. Here queues can be added, modified and deleted.\n\
It also provides the means to suspend/unsuspend and to disable/enable queues.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*SUBMIT_JOB.xmtHelpTitle: @fBSubmit Job Help
Qmon*SUBMIT_JOB.xmtHelp: \
The @fBJob Submission@fR dialogue is opened by pressing the @fBJob Submit Icon@fR\n\
or by selecting @fBJob Submit@fR in the @fBTask@fR menu.\n\
Another possibility to bring up the @fBJob Submission@fR dialogue, is to push the\n\
@fBSubmit@fR button in the @fBJob Control@fR dialogue.\n\
\n\
The @fBJob Submission@fR dialogue delivers a form to select a Grid Engine job script and to\n\
specify its special requirements. After filling in this form the job can be submitted\n\
to the Grid Engine system.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*COMPLEX_CONFIG.xmtHelpTitle: @fBComplex Configuration Help
Qmon*COMPLEX_CONFIG.xmtHelp: \
The @fBComplex Configuration@fR dialogue is opened by pushing the @fBComplex Config Icon@fR\n\
or by selecting @fBComplex Config@fR in the @fBTask@fR menu.\n\
\n\
The @fBComplex Configuration@fR dialogue displays all defined Grid Engine complexes and their\n\
respective attributes. @fBComplexes@fR are used to attach special behavior to queues and\n\
to classify them.\n\
\n\
Further information about the Grid Engine complex concept is documented in Chapter 12 of the\n\
Grid Engine manual.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*HOST_CONFIG.xmtHelpTitle: @fBHost Configuration Help
Qmon*HOST_CONFIG.xmtHelp: \
The @fBHost Configuration@fR dialogue is invoked by pushing the @fBHost Config Icon@fR\n\
or by selecting @fBHost Config@fR in the @fBTask@fR menu.\n\
\n\
The @fBHost Configuration@fR dialogue serves to add or remove hosts to/from the\n\
@fBGrid Engine system@fR. There are four types of hosts available in Grid Engine.\n\
\n\
The @fBMaster Host@fR is central for the overall cluster activity. It runs the\n\
master daemon @fBsge_qmaster@fR.\n\
The master host requires no further configuration other than performed by the\n\
installation procedure.\n\
\n\
The @fBExecution Hosts@fR are nodes having permission to execute Grid Engine jobs.\n\
Therefore they are hosting Grid Engine queues and run the Grid Engine execution daemon\n\
@fBsge_execd@fR.\n\
\n\
@fBAdministration Hosts@fR are hosts to carry out any kind of administrative activities\n\
or interaction to Grid Engine. To perform administrative tasks it is necessary to do it from\n\
an @fBAdministration Host@fR.\n\
\n\
@fBSubmit Hosts@fR allow for submitting and controlling batch jobs.\n\
\n\
Choose the corresponding dialogue section through the option menu at the top of the\n\
dialogue to add and delete hosts of the corresponding category or to modify the scalings\n\
and the access of an execution host.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*CLUSTER_CONFIG.xmtHelpTitle: @fBCluster Configuration Help
Qmon*CLUSTER_CONFIG.xmtHelp: \
The @fBCluster Configuration@fR dialogue pops up on pressing the @fBCluster Config Icon@fR\n\
or by selecting @fBCluster Configuration@fR from the @fBTask@fR menu.\n\
\n\
The @fBCluster Configuration@fR dialogue allows the display and setting of site\n\
dependent configuration information like valid paths for programs such as @fBmail@fR\n\
or @fBxterm@fR and the setting of parameters to influence Grid Engine behavior.\n\
\n\
There is a @fBglobal@fR configuration, which is provided for the Grid Engine master host as\n\
well as every execution host. In addition, the Grid Engine system may be configured to\n\
use a configuration @fBlocal@fR to every execution host which overrides the entries in the\n\
global configuration.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*SCHED_CONFIG.xmtHelpTitle: @fBScheduler Configuration Help
Qmon*SCHED_CONFIG.xmtHelp: \
The @fBScheduler Configuration@fR dialogue pops up on pressing the @fBScheduler Config Icon@fR\n\
or by selecting @fBScheduler Configuration@fR from the @fBTask@fR menu.\n\
\n\
The @fBScheduler Configuration@fR dialogue allows the display and setting of scheduler\n\
specific parameters to influence the Grid Engine scheduler's behavior.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*CALENDAR_CONFIG.xmtHelpTitle: @fBCalendar Configuration Help
Qmon*CALENDAR_CONFIG.xmtHelp: \
The @fBCalendar Configuration@fR dialogue is opened by clicking on the @fBCalendar Configuration Icon@fR\n\
or by selecting @fBCalendar Configuration@fR in the @fBTask@fR menu.\n\
\n\
@fBCalendar Objects@fR can be added, modified or removed from the Grid Engine system with the\n\
@fBCalendar Configuration@fR dialogue. They can be attached to queues to restrict queue accessibility\n\
to the calendar specified times.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*USER_CONFIG.xmtHelpTitle: @fBUser Configuration Help
Qmon*USER_CONFIG.xmtHelp: \
The @fBUser Configuration@fR dialogue is opened by clicking on the @fBUser Config Icon@fR\n\
or by selecting @fBUser Config@fR in the @fBTask@fR menu.\n\
\n\
@fBManagers, Operators and User Access Lists@fR can be added or removed from the\n\
Grid Engine system with the @fBUser Configuration@fR dialogue.\n\
\n\
There are four user categories in Grid Engine - @fBManagers, Operators, Owners, Users@fR.\n\
\n\
@fBManagers@fR have full capabilities to manipulate Grid Engine. By default the superuser\n\
of the master host and any machine hosting a queue have manager privileges.\n\
\n\
@fBOperators@fR can perform the same commands as managers except that they cannot\n\
add, delete or modify queues.\n\
\n\
@fBOwners@fR are restricted to suspending/unsuspending or disabling/enabling the owned\n\
queues.\n\
\n\
@fBUsers@fR have certain access permissions (see User Access Permissions in the manuals)\n\
but no cluster or queue management capabilities.\n\
Usersets are used additionally as departments. Departments can contain\n\
tickets and influence therefore also the importance of a user's job.\n\
Users have to be defined in the @fBUser@fR tab dialogue page. These users\n\
can then be added to the different @fBPolicy@fR dialogues and prioritized against other users.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*PE_CONFIG.xmtHelpTitle: @fBPE Configuration Help
Qmon*PE_CONFIG.xmtHelp: \
The @fBPE Configuration@fR dialogue is opened by clicking on the @fBPE Config Icon@fR\n\
or by selecting @fBPE Configuration@fR in the @fBTask@fR menu.\n\
\n\
The @fBPE Configuration@fR dialogue serves to configure @fBparallel environments@fR\n\
for the Grid Engine system.\n\
\n\
The environments configured here can be used for submitting parallel jobs to one of the\n\
configured @fBParallel Environments@fR.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*PROJECT_CONFIG.xmtHelpTitle: @fBProject Configuration
Qmon*PROJECT_CONFIG.xmtHelp: \
The @fBProject Configuration@fR dialogue is opened by clicking on the @fBProject Config Icon@fR\n\
or by selecting @fBProject Configuration@fR in the @fBTask@fR menu.\n\
\n\
The @fBProject Configuration@fR dialogue allows the definition and manipulation of Grid Engine\n\
projects.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*RQS_CONFIG.xmtHelpTitle: @fBResource Quota Configuration
Qmon*RQS_CONFIG.xmtHelp: \
The @fBResource Quota Configuration@fR dialogue is opened by clicking on the @fBResource Quota Config Icon@fR\n\
or by selecting @fBResource Quota Configuration@fR in the @fBTask@fR menu.\n\
\n\
The @fBResource Quota Configuration@fR dialogue allows the definition and manipulation of Grid Engine\n\
resource quotas.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*AR_CONFIG.xmtHelpTitle: @fBAdvance Reservation
Qmon*AR_CONFIG.xmtHelp: \
The @fBAdvance Reservation@fR dialogue is opened by clicking on the @fBAdvance Reservation Icon@fR\n\
or by selecting @fBAdvance Reservation Configuration@fR or @fBAdvance Reservation Submission@fR in the @fBTask@fR menu.\n\
\n\
The @fBAdvance Reservation@fR dialogue allows monitoring, creation and manipulation of Grid Engine\n\
advance reservations.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*TICKET_OVERVIEW.xmtHelpTitle: @fBPolicy Configuration
Qmon*TICKET_OVERVIEW.xmtHelp: \
The @fBPolicy Configuration@fR dialogue allows the overview and manipulation of various scheduling policy modules.\n\
Here the @fBPolicy Importance Factor@fR and parameters for @fBUrgency Policy@fR\n\
and @fBTicket Policy@fR can be set.\n\n\
From here access is available to the @fBShare Tree Policy@fR, to the\n\
@fBFunctional Policy@fR and to the @fBOverride Policy@fR dialogues.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*CKPT_CONFIG.xmtHelpTitle: @fBCheckpointing Configuration
Qmon*CKPT_CONFIG.xmtHelp: \
The @fBCheckpoint Configuration@fR dialogue is opened by clicking on the @fBCheckpoint\n\
Config Icon@fR or by selecting @fBCheckpoint Configuration@fR in the @fBTask@fR menu.\n\
\n\
The @fBCheckpoint Configuration@fR dialogue provides the possibility to add and change\n\
Grid Engine checkpointing objects.\n\
Checkpointing is a facility to save the complete status of an executing program or job\n\
and to restore and restart from this so called checkpoint at a later point of time if the\n\
original program or job has been interrupted, e.g. by a system crash.\n\

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*BROWSER.xmtHelpTitle: @fBQmon Browser Help
Qmon*BROWSER.xmtHelp: \
To open the @fBObject Browser@fR click on the icon or select @fBBrowser Dialog@fR\n\
in the @fBTask@fR menu.\n\
\n\
The @fBObject Browser@fR provides the possibility to show information\n\
about the Grid Engine objects Queue and Job, to show the output of stderr/stdout\n\
and to show messages of interactions of qmon with the Grid Engine system.\n\
Apart from that the @fBBrowser@fR is opened when the @fBWhy ?@fR button of the\n\
@fBJob Control@fR dialogue is pressed to show the reasons why a job cannot be scheduled.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*EXIT.xmtHelpTitle: @fBExit Help
Qmon*EXIT.xmtHelp: \
Pressing the @fBExit@fR icon or selecting @fBFile->Exit@fR or simply pressing @fBCtrl + C@fR\n\
causes @fBqmon@fR to exit.






!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_job.job_main_layout*xmtHelpTitle: @fBJob Control Help
Qmon*qmon_job.job_main_layout*xmtHelp: \
The @fBJob Control@fR dialogue permits the controlling and monitoring of all running\n\
and pending jobs known to the system.  Here it is possible to influence the jobs in\n\
different ways:\n\
- open the @fBSubmit Dialogue@fR with the @fBSubmit@fR button\n\
- open the @fBPolicy Configuration@fR with the @fBTickets@fR button\n\
- @fBSuspend, Resume and Delete@fR jobs\n\
- ask for the reason @fBWhy ?@fR a job cannot be scheduled\n\
- change the hold state of jobs with the @fBHold@fR button\n\
- change the priority of pending jobs with the @fBPriority@fR button\n\
- change the attributes of pending jobs with @fBQalter@fR\n\
- clear job error states with @fBClear Error@fR\n\
- adjust the display behavior and the kind of jobs displayed with @fBCustomize@fR.\n\
\n\
Three list environments are displayed in a folder page.\n\
One for the still @fBPending Jobs@fR waiting to be dispatched to an appropriate resource.\n\
One for the already @fBRunning Jobs@fR showing jobs which are processing and their\n\
respective state.\n\
And the last folder page displays recently @fBFinished Jobs@fR.\n\
\n\
Without any customization the columns @fBJobId, Priority, JobName, Owner, Status@fR and\n\
@fBQueue@fR are displayed. In the @fBJob Customize@fR dialogue additional information\n\
about the job can be selected for display and a selection of jobs that shall be shown\n\
can be made.\n\
Instead of displaying additional fields permanently in the @fBJob Control@fR dialogue\n\
it is possible to use the @fBObject Browser@fR to view additional information about\n\
a job. To show up the @fBBrowser@fR push the @fBBrowser Icon@fR in the @fBMain Control Window@fR.\n\
In the @fBBrowser@fR dialogue toggle the @fBJob@fR button and point with the mouse to a\n\
job in the tabular areas in the @fBJob Control@fR dialogue.\n\
\n\
For most of the tasks jobs have to be selected first. To select a job the following\n\
key + mouse combinations are used:\n\
@f[BI]Mouse1 + double click@fR\n\
Enter the clicked to field (for columns Queue and additionally selected fields)\n\
@f[BI]Mouse1@fR\n\
Begin of selection, one row is selected, already selected areas are unselected.\n\
@f[BI]Shift + Mouse1@fR\n\
Extend of selection, select all rows between Begin of selection and the clicked to row.\n\
@f[BI]Ctrl + Mouse1@fR\n\
Toggle the selection, the clicked to row is selected if it was unselected and unselected\n\
otherwise.\n\
\n\
The selected jobs can be manipulated by the buttons labeled @fBSuspend, Resume, Delete,\n\
Why, Priority, Qalter, Hold and Clear Error@fR at the right hand side of the window.\n\
\n\
Suspending a job means the equivalent to sending the signal @fBSIGSTOP@fR to the process\n\
group of the job with the @fBUNIX kill@fR command. I.e. the job is halted and does no\n\
longer consume CPU time. If a job is suspended it is displayed in a different color which\n\
can be configured in the application default file @fB$HOME/Qmon@fR.\n\
Here the entries @fBjob_suspend_color, job_suspend_on_subordinate_color, job_delete_color@fR\n\
define the used colors for suspended jobs, for jobs which ran in a queue which has been\n\
suspended on subordinate (see Queue Control Help and the User Manual) and for jobs that\n\
have been deleted. The default colors are turquoise for suspended jobs, magenta for\n\
jobs that are suspended on subordinate and orange for jobs that are marked for deletion.\n\
Additionally the status of the jobs is displayed as a letter combination as for\n\
@fBGrid Engine qstat@fR in the @fBStatus@fR column.\n\
Further information on the abbreviations and the meaning of the different states can be\n\
found in the @fBqstat@fR man page.\n\
\n\
Resuming the job sends the signal @fBSIGCONT@fR thereby resuming the job.\n\
\n\
The actions suspend, resume, delete, modify priority, modify hold and qalter may only be\n\
applied to a job by the @fBjob owner@fR or by @fBGrid Engine managers@fR and @fBoperators@fR.\n\
\n\
Suspension, Resume and Deletion can be forced, i.e. registered with @fBsge_qmaster@fR\n\
without notification of the @fBsge_execd@fR controlling the job(s), in case the corresponding\n\
@fBsge_execd@fR is unreachable, e.g. due to network problems.\n\
\n\
For the selected jobs the input of the priority popup is set as priority for the selected\n\
jobs and the pending jobs are sorted according to their new priority.\n\
\n\
To change the Hold state of pending jobs these are selected and pressing @fBHold@fR pops up\n\
a little dialog to set or reset the hold state. There are three different kinds of holds the\n\
user hold which can be set by the owner of the job, an operator or manager, the operator hold\n\
which needs at least operator privileges and finally the system hold which requires manager\n\
privileges to be changed.\n\
If only one job is selected the current hold state of the job is displayed otherwise this is\n\
not the case. Change the hold state and press @fBOk@fR to report it to the Grid Engine system or\n\
@fBCancel@fR to dismiss.\n\
\n\
To change other attributes of a pending job select this job and press @fBQalter@fR. This\n\
pops up the @fBJob Submission@fR dialogue in a restricted mode. If the changes are committed\n\
with the @fBQalter@fR button of the @fBJob Submission@fR dialogue, the dialogue closes and\n\
the changes are reported to the master and displayed in the @fBJob Control@fR dialogue.\n\
To leave the @fBJob Submission@fR dialogue without doing any changes press the @fBDone@fR button.\n\
\n\
The @fBCustomize@fR button allows the setting of the job attributes displayed and the\n\
specification of job filtering criteria. The @fBJob Customize@fR folder pops up.\n\
The @fBSelect Fields@fR dialogue is used to display additional job attributes.\n\
The @fBFilter Jobs@fR dialogue allows the selection of filtering criteria to restrict the\n\
number of jobs being displayed.\n\
The @fBFilter by Owner@fR input field allows the specification of a list of user names like\n\
@fBjoe sam jim@fR. Also wildcards are allowed like @fBj* sam@fR thus filtering out all jobs\n\
whose owner names don't match the specified names. @fBCompact Job array Display@fR collapses\n\
the display of job arrays. Otherwise every job array task is shown as a single line in the\n\
tabular areas of the @fBJob Control@fR dialogue.\n\
If one of the available resources is specified only those jobs are displayed whose resource\n\
requirements are fulfilled by the configured queues.\n\
The customization settings can be saved to $HOME/.qmon_preferences in order to keep them\n\
across qmon sessions.\n\
\n\
To keep the information being displayed up-to-date, qmon uses a polling scheme to retrieve\n\
the status of the jobs from sge_qmaster.\n\
A refresh can be forced by pressing the @fBRefresh@fR button.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_cq.cq*xmtHelpTitle: @fBQueue Control Help
Qmon*qmon_cq.cq*xmtHelp: \
The purpose of the @fBQueue Control@fR dialogue is to provide a quick overview of the\n\
queues available and their state in the cluster.\n\
Furthermore new queues can be @fBadded@fR, existing queues can be @fBmodified or deleted@fR\n\
and they can be @fBsuspended and resumed or disabled and enabled@fR.\n\
If put into an error state they can be reactivated by @fBClear Error@fR.\n\
\n\
The dialogue displays a tabular view of @fBCluster Queues@fR and the corresponding\n\
@fBQueue Instances@fR for each queue in the Grid Engine system.\n\
If the main display area is empty no queues are configured or filters\n\
hide the queues not fulfilling the @fIfilter criteria@fR.\n\
If this is the case the @fBCustomize@fR button is renamed to @fBCustomize +@fR.\n\
Under @fBCustomize@fR it is possible to select queues according to its accessibility by a user, referencing\n\
special parallel environments, fulfilling a queue name pattern or being in a special queue state.\n\
\n\
Every line in the table corresponds to a cluster queue or queue instance. To perform an action on\n\
a queue or queue instance one (or more) entries can be selected.\n\n\
For cluster queues the following actions are possible:\n\n\
@fBAdd@fR to add a new cluster queue\n\
@fBModify@fR to delete one or more cluster queues\n\
@fBQueue Sick ?@fR to perform a sanity check of a queue\n\
\n\
For cluster queues and queue instances these actions apply:\n\n\
@fBSuspend@fR to suspend all queue instances of a cluster queue or\n\
only a subset thereof\n\
@fBResume, Disable, Enable, Reschedule, Clear Error@fR to unsuspend, disable,\n\
enable, reschedule and clear errors like for Suspend above.\n\
\n\
For Queue Instances these two additional actions are available:\n\n\
@fBLoad@fR pops up a load dialogue for the selected queue instances.\n\
@fBExplain@fR shows a browser listing of @fBa@fRlarm, suspend @fBA@fRlarm,\n\
@fBE@fRrror and ambiguous @fBc@fRonfiguration reasons in the qmon browser\n\
dialogue depending on the explain toggle selector.\n\
\n\
The @fBSuspend/Resume or Disable/Enable@fR operation require notification of the\n\
corresponding @fBsge_execd@fR. If this is not possible (e.g. because the host is down) a\n\
@fBsge_qmaster@fR internal status change can be forced if the @fBForce@fR toggle is enabled.\n\
If a queue is suspended it is closed for further jobs and the jobs already running are\n\
suspended. The queue and it's jobs are unsuspended as soon as the queue is resumed.\n\
\n\
Queues which are disabled are closed, however the jobs executing in those queues are\n\
allowed to continue. To disable a queue is commonly used to "drain" a queue.\n\
The enable makes a queue eligible for job execution again. If a queue runs in an error\n\
state for a certain reason the Clear Error is used to reset the queue.\n\
To perform suspend/resume and disable/enable operations @fBowner@fR or @fBGrid Engine manager\n\
or operator@fR privileges are required.\n\
\n\
To force an update of queue information press the @fBRefresh@fR button.\n\
With the @fBDone@fR button the @fBQueue Control@fR dialogue is closed.\n\
\n\
The @fBAdd@fR button opens the @fBQueue Configuration@fR subdialogue in @fBAdd mode@fR\n\
to add a new queue to the Grid Engine system.\n\
The @fBClone@fR button lets you add a new cluster queue starting with\n\
the configuration of an already existing cluster queue.\n\
The @fBModify@fR button opens the @fBQueue Configuration@fR subdialogue in @fBModify mode@fR.\n\
Here exactly one queue has to be selected and the @fBModify@fR button pops up the @fBQueue\n\
Configuration@fR dialogue with the the values of this specific queue set.\n\
In the @fBQueue Configuration@fR subdialogue the specific queue operations are performed.\n\
For further information on navigating this dialogue see the help there.\n\
The @fBCustomize@fR button allows the configuration of queue filtering.\n\
The customization settings can be saved to $HOME/.qmon_preferences in order to keep them\n\
across qmon sessions.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*cq_dialog_shell*xmtHelpTitle: @fBQueue Configuration Help
Qmon*cq_dialog_shell*xmtHelp: \
The @fBQueue Configuration@fR subdialogue provides the means to @fBadd and modify@fR queues.\n\
It consists of two sections, the upper part shows two input fields for the @fIQueue Name@fR\n\
and one to add a @fIhost or hostgroup name@fR to the @fIHostlist@fR. The Hostlist shows the hostgroups\n\
or hosts that are represented by the cluster queue.\n\
The @fBAdd@fR and @fBDelete@fR buttons let you add a new host or hostgroup entered in the input field next\n\
to the Hostlist or delete a host or hostgroup selected in the Hostlist.\n\
On the right there is the @fBOk, Cancel and Help@fR button.\n\n\
The button @fBRefresh@fR updates\n\
any input helpers that changed during editing e.g. the available PE or Checkpoint object lists.\n\n\
The lower part consists of a list containing @fIHost or Hostgroup@fR entries named\n\
@fBAttributes for Host/Hostgroup@fR.\n\
Next to this list a folder of configuration pages for the different categories of\n\
queue attributes is presented. The following categories of queue parameters are shown:\n\
@fBGeneral Configuration, Execution Method, Checkpointing, Load/Suspend Thresholds, Limits,\n\
Complexes, Subordinates, User Access, Project Access, Parallel Environment and Owners.@fR\n\
\n\
The following steps are usually processed to define a new cluster queue:\n\n\
@fBStep 1:@fR\n\
Enter the queue name and enter the hosts or preferably one or more hostgroups.\n\n\
@fBStep 2:@fR\n\
Adjust the default settings for the cluster queue (select @@/) and enter your changes\n\
for the different tabbed pages.\n\n\
@fBStep3:@fR\n\
Define any hosts or hostgroups within this cluster queue that have special attribute values\n\
by adding them to the list on the left, selecting it and entering the deviating values.\n\
The fields are made editable by clicking the lock icons left to the attribute name.\n\
To access the different attribute categories select the corresponding tabbed page.\n\
When the host or hostgroup is changed the changes are temporarily saved.\n\
To delete a special setting either check off the corresponding attribute lock or delete the host or hostgroup\n\
completely from the list on the left.\n\n\
@fBStep 4:@fR\n\
Save or dismiss your changes by pressing @fBOk@fR or @fBCancel@fR. If an error\n\
or misconfiguration occurs an error dialogue pops up. Otherwise the dialogue closes.\n\
\n\
The forms of the different attribute categories comprise the following fields, for a more\n\
thorough explanation of the meaning of the different parameters refer to the @fBqueue_conf@fR\n\
manual page.\n\
\n\
@fBGeneral Configuration@fR\n\
@fISequence Nr@fR allows the @fBSort by Sequence Number@fR sorting of queues during scheduling.\n\
Processors (s.th. like 1-4) that shall be used by the jobs running on the queue.\n\
@fItmp Directory@fR the temporary directory.\n\
@fIShell@fR that shall be used to execute the job scripts. This can also be another command interpreter\n\
than a usual Unix shell.\n\
@fIShell Start Mode@fR defines the way how shell scripts are handled by the Shell.\n\
@fIInitial State@fR defines if this queue is accessible for scheduling after startup.\n\
@fIRerun Jobs@fR defines that jobs that aborted on this queue are restarted automatically this may be useful\n\
for checkpointed jobs for example.\n\
@fICalendar@fR contains the name of the calendar attached to this queue to manage the accessibility of\n\
the queue based on date and time.\n\
@fINotify Time@fR is the time that passes before a KILL signal is sent after sending user defined signals.\n\
@fIJob's Nice@fR is the UNIX nice value that the job is started with.\n\
@fISlots@fR defines the maximum number of jobs that can run on this queue per queue instance.\n\
@fIType@fR defines the capability of the queue to handle special classes of jobs like Batch or Interactive.\n\
\n\
@fBExecution Method@fR\n\
@fIProlog@fR defines the prolog path. The prolog is executed before the job is executed.\n\
@fIEpilog@fR defines the epilog path. The epilog is executed after the job has been executed.\n\
@fIStarter Method@fR defines the executable that is used to start a job.\n\
@fISuspend Method, Resume Method and Terminate Method@fR can be used as a replacement for the\n\
default mechanisms for suspension, release of a suspension and termination of a job.\n\
Per default the signals SIGSTOP, SIGCONT and SIGKILL are delivered which may not be\n\
appropriate.\n\ It is either possible to define an executable path here to execute a\n\
corresponding command or to define a different signal as a positive number or with the SIG\n\
prefix. There are the following variables that can be used and that are expanded at runtime:\n\
@fI$host@fR: the name of the host on which the procedure is started\n\
@fI$job_owner@fR: the user name of the job owner\n\
@fI$job_id@fR: the actual job id\n\
@fI$job_name@fR: the job's name\n\
@fI$queue@fR: the name of the queue\n\
@fI$job_pid@fR: the UNIX pid of the job\n\
\n\
@fBCheckpointing@fR\n\
@fIMinCpuTime@fR is the periodic checkpoint interval.\n\
All time values can be set using the time input helper subdialogue.\n\
@fIReferenced Ckpt Objects@fR allows to attach special checkpoint objects that have been defined already\n\
to the cluster queue.\n\
\n\
@fBLoad/Suspend Thresholds@fR\n\
The @fILoad Thresholds@fR prevent the scheduling of additional jobs to the queue. A threshold\n\
can be supplied for any load value.\n\
For entering load values see the remarks in @fBCheckpointing Parameters@fR above.\n\
If one of the load thresholds is exceeded the queue is set to the @fBalarm state@fR and\n\
no more jobs are scheduled to this queue.\n\
The @fISuspend Thresholds@fR can be used to suspend jobs running on this queue if a load\n\
value is exceeded.\n\
@fISuspend Interval@fR is the time interval in which further @fIJobs suspended per Interval@fR jobs\n\
are suspended.\n\
\n\
@fBLimits@fR\n\
The hard and soft limits which are imposed on the jobs running in the queue.\n\
To fill in values either @fBDouble Click@fR on the value fields and enter them directly\n\
or use the helper dialogues by @fBClicking the helper icon@fR.\n\
\n\
@fBComplexes@fR\n\
@fBConsumable/Fixed Attributes@fR of the queue can be defined here.\n\
\n\
@fBSubordinates@fR\n\
The queues which are subordinated to the configured queue. Subordinated queues are\n\
suspended if the configured queue becomes @fBbusy@fR and unsuspended if the configured\n\
queue is no longer busy. The number of job slots which have to be occupied in the\n\
configured queue to trigger the suspend of an subordinate queue can be filled in in\n\
the column @fBMaxSlots@fR for every subordinate queue. If no value is given the\n\
subordinate queue is suspended if all slots of the configured queue are occupied.\n\
Subordinate queues can be used to implement high and low priority queues as well as\n\
stand-alone queues.\n\
\n\
@fBUser Access@fR\n\
The user access lists being attached to the allow or deny access lists of the queue.\n\
Users or user groups belonging to access lists which are included in the allow list\n\
have access to the queue. Those being associated with the deny list may not access the\n\
queue. If the allow list is empty access is unrestricted unless explicitly stated\n\
in the deny list.\n\
There is a link to the @fBUser Configuration Dialogue@fR where it is possible to setup\n\
user access lists. Click on the icon to go there.\n\
\n\
@fBProject Access@fR\n\
The project being attached to the allow or deny project access lists of the queue.\n\
Jobs running under a project belonging to the project allow list have access to the queue.\n\
Those being associated with the project deny list may not access the queue. If the allow list is\n\
empty access is unrestricted unless explicitly stated in the deny list.\n\
There is a link to the @fBProject Configuration Dialogue@fR where it is possible to setup\n\
projects. Click on the icon to go there.\n\
\n\
@fBParallel Environment@fR\n\
@fIReferenced PE@fR allows to attach special Parallel Environment objects that have been defined already\n\
to the cluster queue.\n\
\n\
@fBOwners@fR\n\
The list of queue owners. An owner of a queue is given permission to @fBSuspend/Resume@fR\n\
or @fBDisable/Enable@fR the queue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_submit.submit_layout*xmtHelpTitle: @fBSubmit Job Help
Qmon*qmon_submit.submit_layout*xmtHelp: \
The @fBJob Submission@fR dialogue allows to submit jobs into the Grid Engine system.\n\
For general information on how to submit a Grid Engine job, please refer to the examples given in\n\
the @fBGrid Engine User Guide@fR and the qsub(1) man page.\n\
\n\
To submit a job you first have to select the directive @fBPrefix@fR which is used to interpret\n\
@fBGrid Engine command directives@fR contained in the script file. The @fBprefix@fR defaults to\n\
@fB#$@fR if nothing is specified.\n\
The next step is to choose a script by either entering its name with absolute path or relative to\n\
the current working directory of qmon or by simply selecting the specific @fBJob Script@fR from\n\
the @fBFile Selection Box@fR popped up by pressing the icon right aside the @fBJob Script@fR input field.\n\
If there are any default files delivered which contain @fBGrid Engine command directives@fR or if\n\
the job script contains any @fBGrid Engine command directives@fR, they are evaluated. The settings\n\
that apply to the job are shown in the dialogue.\n\
\n\
There are three levels of default files possible and all of them are optional. The one with\n\
the lowest priority is stored under @fB$Grid Engine_ROOT/$SGE_CELL/common/sge_request@fR, the\n\
second level is stored under @fB$HOME/.sge_request@fR and the third level with the highest\n\
priority of the default files is stored in the current working directory of qmon under\n\
@fB./.sge_request@fR.\n\
If there are any script file embedded Grid Engine command line directives, they override the settings\n\
of the default files.\n\
\n\
After the script has been selected, one can adjust the requirements of the job to be submitted.\n\
@fBJob Tasks@fR allows the submission of job arrays. They are specified as min[-max[:step]][,...]\n\
e.g. 1-10:2,20,24-27.\n\
@fBJob Name@fR contains the name of the script file and can be overwritten.\n\
@fBJob Args@fR contains any arguments delivered to the job script. They are separated by\n\
blanks as on the command line.\n\
With the @fBPriority@fR spinbox the job gets an initial priority value. Users without manager\n\
or operator privileges may only lower their initial priority value.\n\
With the @fBJob Share@fR spinbox the job can be weighted compared to other\n\
jobs. The job share has an influence in the Share Tree Policy and  the\n\
Functional  Policy.\n\
The @fBStart At@fR field sets the time when the job is considered eligible for execution.\n\
The @fBCurrent Working Directory@fR toggle button indicates whether the job is to be executed\n\
in the current working directory (for identical directory hierarchies between the submit and\n\
the potential execution hosts only). For qmon the current working directory is the directory where\n\
qmon has been started.\n\
The @fBShell@fR field specifies the command interpreter to be used to execute the job script.\n\
There can be different command interpreters specified in the form @fBhost:interpreter@fR in\n\
the input field or via the helper dialogue by filling in the corresponding matrix entries.\n\
\n\
The @fBMerge Output@fR flag enables/disables the combination of the job's stderr into its stdout.\n\
If @fBstdout, stderr@fR fields are empty, the output of the job is written to the\n\
files <job_name>.o<job_id>[.<array_task_id>] or <job_name>.e<job_id>[.<array_task_id>] in the user's\n\
home directory,\n\
where <job_name> is the name of the job entered in @fBJob Name@fR and <job_id> is the Grid Engine\n\
job id under which the job is running. <array_task_id> is the task id of the task of the job array\n\
and is therefore only present for job arrays.\n\
The standard output redirection can be used to write the output to another place. This is done\n\
in the input fields @fBstdout and stderr@fR and by the corresponding helper dialogues.\n\
If the specified path is a directory, the output streams are put with the default names under\n\
this directory.\n\There are also pseudo environment variables that are expanded at runtime that can\n\
be used to build pathnames.\n\
$HOME       home directory on execution machine\n\
$USER       user ID of job owner\n\
$JOB_ID     current job ID\n\
$JOB_NAME   current job name\n\
$HOSTNAME   name of the execution host\n\
$TASK_ID    job array task index number\n\
Alternatively to $HOME the ~ symbol can be used as in csh(1) or ksh(1), it works also with\n\
user names but the necessary write permissions must exist.\n\
\n\
With the @fBRequest Resources@fR button the @fBRequested Resources@fR dialogue is opened\n\
in order to specify the @fBResource Requirements@fR of the job. If resources are requested,\n\
the icon pins are displayed completely filled with color.\n\
\n\
The @fBRestart behavior option menu@fR defines the job's restart behavior.\n\
@fBNotify Job@fR defines that the job will receive warning signals before the\n\
real signal arrives this is useful for checkpointing jobs for example.\n\
With @fBHold Job@fR jobs and if specified only special tasks of a job array can be\n\
submitted as hold. So they are not eligible for execution until their hold has been\n\
released. This is done in the @fBJob Control@fR dialogue. The task range is specified\n\
as for the @fBJob Tasks@fR field.\n\
@fBStart Job Immediately@fR defines if the job has to be scheduled immediately. This is always\n\
true for @fBInteractive Jobs@fR.\n\
The @fBJob Reservation@fR toggle indicates whether a reservation for this job\n\
should be done.\n\
\n\
The button list on the right is used to perform different tasks concerning of job submission.\n\
The button labeled with @fBBatch@fR toggles between batch and interactive mode for submitting\n\
either batch or interactive jobs.\n\
The @fBSubmit@fR button submits the job into the Grid Engine system.\n\
The @fBEdit@fR button is used to edit a chosen job script.\n\
The @fBClear@fR button clears and resets all fields of the dialogue. One has to rechoose a Job Script.\n\
The @fBReload Button@fR discards any additional manually performed changes in the dialogue and restores\n\
the state of the dialogue after loading the Job script file merged with the default files if there were\n\
any present.\n\
The @fBSave Settings@fR button can be used to write special submit configurations to a file.\n\
With @fBLoad Settings@fR these settings are loaded over a job setting the stored parameters\n\
for the chosen job.\n\
\n\
Under @fBAdvanced@fR more elaborate settings are available.\n\
The @fBParallel Environment@fR field allows the input of a parallel environment and the\n\
corresponding range specifications. A helper dialogue listing configured PEs is associated\n\
at the right.\n\
In the @fBEnvironment@fR field environment variables can be delivered.\n\
In the @fBContext@fR field context variables can be delivered.\n\
In the @fBCheckpoint Object@fR field a special checkpoint object can be requested.\n\
The @fBAccount@fR field contains a string which is stored in the accounting record for this\n\
job.\n\
The @fBMail@fR section contains the events when the user is notified by electronic mail and\n\
the mail addresses to which these notification is sent.\n\
In the @fBSoft/Hard Queue List@fR input fields the job can be directed to special queues.\n\
@fBTransfer QS Arguments@fR contains information that will be handed over literally to the\n\
submit command of a foreign queuing system connected to Grid Engine through the @fBQueuing System\n\
Interface@fR.\n\
In the @fBJob Dependencies@fR field the job numbers that the current job depends on, can be\n\
entered.\n\
In the @fBHold Array Dependencies@fR field the job numbers that the current job depends un with array dependency,\n\
can be entered.\n\
The @fBDeadline@fR field allows entering the deadline when a job shall be fulfilled.\n\
This leads to an increase of the priority of this job when it approaches its deadline.\n\
Only @fBDeadline Users@fR can submit deadline jobs.\n\
\n\

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*request_shell.request*xmtHelpTitle: @fBRequested Resources Help
Qmon*request_shell.request*xmtHelp: \
The @fBRequested Resources@fR dialogue allows to specify the requirements a job has to fulfill.\n\
To enter a requirement double click on one of the available resources then you can enter\n\
the required value and depending on the @fBHard/Soft Request@fR radio buttons the item is\n\
added to the @fBHard/Soft Resources List@fR. To change one of the requirements double click\n\
it in the @fBHard/Soft Resources List@fR. To remove it select it and press the @fIRight Mouse@fR\n\
button or @fIClear@fR to remove all requested items.\n\
@fBOk@fR saves the requested resources for this job submission. @fBCancel@fR dismisses any change.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!Qmon*request_shell.request*xmtHelpTitle: @fBRequested Resources Help
!Qmon*request_shell.request*xmtHelp: \
!When submitting a Grid Engine job a requirement profile of the job can be specified.\n\
!The user can specify attributes or characteristics of a host or queue which the job \n\
!requires to run successfully.\n\
!Grid Engine will map these job requirements onto the host and queue configurations of the Grid Engine\n\
!cluster and will so find suitable hosts for the job.\n\
!The available attributes to choose from are displayed in the @fBRequested Resources Dialogue@fR.\n\
!There can be queue properties, global or host specific load parameters as well as user defined\n\
!attributes available.\n\
!The Grid Engine administrator commonly chooses only a subset of all available attributes to be\n\
!requestable by the user.\n\
!The currently requestable resources are displayed in the @fBAvailable Resources@fR section of the\n\
!@fBRequested Resources Dialogue@fR. On the left hand side of the dialogue the user chosen resources\n\
!are displayed.\n\
!They are separated into the categories @fBHard Resources@fR which have to be fulfilled to get the\n\
!job running and @fBSoft Resources@fR which should be fulfilled but are not absolutely necessary for the\n\
!execution of the job.\n\
!The entries in the lists can be manipulated by @fBDouble Clicking@fR with the @fBLeft Mouse Button@fR on\n\
!the specific item. A type dependent helper dialogue opens up and permits the addition of an item to the\n\
!@fBHard Resources@fR list if @fBHard Request@fR is selected or to the @fBSoft Resource@fR list if \n\
!@fBSoft Request@fR is selected, and the double click occurs in the @fBAvailable Resources@fR section.\n\
!If the double click is performed in the @fBHard/Soft Resources@fR section, the item can be @fBchanged@fR.\n\
!To @fBdelete@fR an item from the @fBHard/Soft Resources@fR section click @fBRight Mouse@fR button over the\n\
!item to delete all items from one of the sections @fBHard/Soft Resources@fR choose the corresponding\n\
!type @fBHard/soft Request@fR and press @fBClear@fR.\n\
!To discard any changes to the requested resources press the @fBCancel@fR button. To keep them leave the\n\
!dialogue with @fBOk@fR. If there are any resources requested for the job the @fBRequested Resources@fR icon\n\
!in the @fBJob Submission Dialogue@fR changes color.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_cplx.cplx_layout*xmtHelpTitle: @fBComplexes Configuration Help
Qmon*qmon_cplx.cplx_layout*xmtHelp: \
The definition of @fBcomplexes@fR provides all pertinent information concerning\n\
the resource attributes a user may request for a Grid Engine job and for the interpretation\n\
of these parameters within the Grid Engine system.\n\
\n\
To get general information about the @fBComplexes Concept@fR please refer to the\n\
@fBGrid Engine Installation and Administration Guide and complex(5)@fR.\n\
\n\
The @fBComplex Configuration@fR dialogue provides the abilities to introduce\n\
new resource attributes to the system and to remove or modify existing\n\
ones.\n\
\n\
A set of predefined resource attributes describing queue and host characteristics are setup during installation.\n\
\n\
Complex attributes can be filled into the attribute matrix. It consists of\n\
eight fields. The first field is the @fBName@fR of the attribute, the second field is a\n\
@fBShortcut@fR for the attribute, the third field is the @fBType@fR of the attribute and tells\n\
the system how to interpret the delivered values. Allowed types are @fBSTRING, CSTRING, RESTRING\n\
MEMORY, TIME, INT, BOOL, HOST and DOUBLE@fR.\n\
The fourth field specifies the @fBRelation@fR to use in comparing user requested values with\n\
system delivered values.\n\
The fifth field decides if a complex attribute is @fBrequestable@fR by the user, here\n\
YES, NO and FORCED are allowed values. If FORCED is selected this attribute must be requested.\n\
The sixth field is the @fBConsumable@fR flag. It can be set to YES and NO where YES is only meaningful\n\
for numeric attributes (INT, MEMORY, TIME, DOUBLE). When set to YES the consumption of the\n\
resource can be managed by Grid Engine internal bookkeeping.\n\
The seventh field defines a @fBDefault@fR value. This is only meaningful for consumable complex\n\
attributes. Grid Engine assumes the resource amount denoted in the default parameter\n\
implicitly to be consumed by jobs being dispatched to a host or queue managing the consumable\n\
attribute. Jobs  explicitly requesting the attribute via a Resource Request override this\n\
DEFAULT value.\n\
The eighth field defines the @fBUrgency@fR. The urgency value allows influencing\n\
job priorities on a per resource base.\n\
\n\
To enter a line to the matrix enter the information in the input fields and option menus\n\
and press @fBAdd@fR to put it into the @fBAttributes matrix@fR. To change or delete a\n\
line form the matrix select the line(s) with the mouse and press @fBDelete@fR or commit\n\
the changed attribute line with @fBAdd@fR or @fBModify@fR.\n\
\n\
To load attributes from a complex file push the @fBLoad@fR button, select the complex file\n\
in the file selection box. This loads the values from the file into the matrix.\n\
To save your current matrix settings to file use the @fBSave@fR button.\n\
\n\
After filling in the attributes they are stored permanently in the system by pressing the\n\
@fBOk@fR button. If everything is all right the complex editor closes and the new attributes are available for further use.\n\

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_host*xmtHelpTitle: @fBHost Configuration Help
Qmon*qmon_host*xmtHelp: \
Grid Engine hosts are classified into four groups, depending on which Grid Engine daemons are running on\n\
the system and how the hosts are registered at @fBsge_qmaster@fR.\n\
The @fBMaster Host@fR is central for the overall cluster activity. It runs the @fBsge_qmaster@fR\n\
daemon which controls all Grid Engine components such as queues and jobs and maintains the status of the\n\
system.\n\
\n\
@fBExecution hosts@fR are nodes having permission to execute Grid Engine jobs and are therefore hosting\n\
Grid Engine queues. The @fBsge_execd@fR daemon runs on these hosts.\n\
@fBAdministration hosts@fR can carry out any administrative activity concerning the Grid Engine system.\n\
The @fBMaster Host@fR and the @fBExecution hosts@fR are automatically @fBAdministration hosts@fR.\n\
@fBSubmit Hosts@fR allow for submitting and controlling batch jobs only.\n\
\n\
@fBAdministration Host@fR\n\
\n\
The administrative host permission can be given to other hosts too. This is done by adding a host in\n\
the @fBHost Configuration@fR dialogue. Selecting @fBAdministration Host@fR from the folder shows the\n\
@fBAdministration Host@fR configuration page. Enter a hostname in the host field and press @fBReturn@fR\n\
or the @fBAdd@fR button, thus a new administrative host is added to the Grid Engine system.\n\
To remove administrative hosts from the Grid Engine system, select these hosts and press the @fBDelete@fR\n\
button.\n\
The @fBDone@fR button quits the dialogue.\n\
\n\
@fBSubmit Host@fR\n\
\n\
The submit host permission can be given to other hosts too. This is done by adding a host in\n\
the @fBHost Configuration@fR dialogue. Selecting @fBSubmit Host@fR from the folder shows the\n\
@fBSubmit Host@fR configuration page. Enter a hostname in the host field and press @fBReturn@fR\n\
or the @fBAdd@fR button, thus a new submit host is added to the Grid Engine system.\n\
To remove submit hosts from the Grid Engine system, select these hosts and press the @fBDelete@fR\n\
button.\n\
The @fBDone@fR button quits the dialogue.\n\
\n\
@fBExecution Host@fR\n\
The execution host permission can be given to any host. This is done by adding a host in\n\
the @fBHost Configuration@fR dialogue. Selecting @fBExecution Host@fR  from the folder shows the\n\
@fBExecution Host@fR configuration page. This page consists of a list of configured execution host\n\
on the left and there corresponding configuration attributes in stacked attribute lists on the right.\n\
By selecting one of the execution hosts the corresponding attributes are displayed.\n\
To add a new execution host press @fBAdd@fR this pops up the execution host configuration editor.\n\
Here the hostname of the new execution host can be specified the @fBLoad Scaling@fR factors, the\n\
@fBAccess Attributes@fR, the @fBConsumables/Fixed Attributes@fR and @fBUsage Scaling@fR can be changed.\n\
\n\
The configuration helper dialogue consists of a folder with the categories @fBScaling@fR for\n\
@fBLoad Scaling, Usage Scaling@fR\n\
settings, @fBConsumables/Fixed Attributes@fR for host based attachment of consumables and fixed attributes,\n\
@fBUser Access@fR for host based accessibility settings and @fBProject Access@fR\n\
for host based definition of project access.\n\
The scaling can be used to weight special load or usage values for better comparability of distinct\n\
cluster machine types. The other settings are mainly the counterpart to queue based configuration\n\
settings on the host level. So it is possible for example to attach for all queues residing on a\n\
special host the access permissions once on the host level.\n\
\n\
To modify an existing execution host press @fBModify@fR and proceed as with adding a host.\n\
\n\
To remove any execution host from the Grid Engine system, select this host and press the @fBDelete@fR\n\
button.\n\
\n\
With the @fBShutdown@fR button the corresponding @fBsge_execd@fR can be shut down.\n\
\n\
The @fBDone@fR button quits the dialogue.\n\n\
@fBHost Groups@fR\n\
\n\
The @fBHost Group@fR tab shows already defined host groups and their\n\
corresponding members.\n\
@fBAdd@fR and @fBModify@fR allow the addition of a new host group or the\n\
extension of an already existing one.\n\
A helper dialogue is shown where the host group name can be defined (e.g.\n\
@@myhostgroup) and the members, either host names or an existing hostgroup\n\
can be entered.\n\
The defined host groups can be used to access a set of hosts under\n\
one name. This is especially useful when defining cluster queues.\n\
The @fBDone@fR button quits the dialogue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_cluster.cluster_layout*xmtHelpTitle: @fBCluster Configuration Help
Qmon*qmon_cluster.cluster_layout*xmtHelp: \
The @fBCluster Configuration@fR combines from two parts, the @fBglobal configuration@fR and\n\
host specific @fBlocal configuration@fR.\n\
It reflects any site dependencies and general parameters of the Grid Engine cluster.\n\
The local configuration supersedes any parameters in the global configuration.\n\
\n\
The @fBsge_conf(5)@fR manual gives a detailed information about the configuration entries available.\n\
\n\
The @fBCluster Configuration@fR dialogue displays a list of all configurations available in the system.\n\
There is at least the @fBglobal configuration@fR available. @fBLocal configurations@fR are named by the\n\
corresponding host name.\n\
Selecting one of the configuration names in the @fBHost@fR list displays the corresponding configuration\n\
values. The actual configuration is build by merging the local and the global configuration where the\n\
local configuration overrides the corresponding entries of the global configuration.\n\
\n\
To modify a configuration select the corresponding configuration and press @fBModify@fR to bring the\n\
@fBCluster Settings@fR dialogue up.\n\
In the case of @fBglobal configuration@fR all fields are accessible apart from\n\
settings that are only changeable during system installation. For @fBhost specific configuration@fR\n\
only parts of the dialogue can be edited. The dialogue consist of a folder with the sections\n\
@fBGeneral Settings@fR and @fBAdvanced Settings@fR.\n\
Pressing @fBOk@fR registers the changes with sge_qmaster. @fBCancel@fR dismisses any changes.\n\
\n\
To delete any host specific local configurations choose the appropriate hostname in the @fBHost@fR list\n\
and press the @fBDelete@fR button.\n\
\n\
The @fBDone@fR button leaves the dialogue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_manop*xmtHelpTitle: @fBUser Configuration Help
Qmon*qmon_manop*xmtHelp: \
There are four user categories in Grid Engine, @fBManagers, Operators, Owners and Users@fR.\n\
@fBManagers@fR have @fBfull capabilities@fR to manipulate Grid Engine. By default the @fBsuperuser@fR\n\
or @fBadmin_user@fR of the master host and any machine hosting a queue have manager privileges.\n\
@fBOperators@fR can perform the same commands as managers except that they cannot\n\
add, delete or modify queues.\n\
@fBOwners@fR are restricted to suspending/unsuspending or disabling/enabling the owned\n\
queues.\n\
@fBUsers@fR have certain access permissions (see User Access Permissions in the manuals)\n\
but no cluster or queue management capabilities.\n\
Usersets are used additionally as departments. Departments can contain\n\
tickets and influence therefore also the importance of a user's job.\n\
Users have to be defined in the @fBUser@fR tab dialogue page. These users\n\
can then be added to the different @fBPolicy@fR dialogues and prioritized against other users.\n\
\n\
The term @fBUser@fR is used additionally for registered users that can be manipulated in\n\
the different @fBTicket Policy@fR dialogues.\n\
\n\
The @fBUser Configuration@fR dialogue comes up as a folder with the following categories:\n\
@fBManager, Operator, Userset and User@fR.\n\
\n\
To add any additional users as managers select the @fBManager@fR folder page and enter a valid\n\
username in the input field and press @fBReturn@fR or the @fBAdd@fR button. To remove any users\n\
from the manager list select these users in the list and press the @fBDelete@fR button.\n\
Manipulations of managers must be done on an @fBadministration host@fR.\n\
\n\
To add any additional users as operators select the @fBOperator@fR folder page and enter a valid\n\
username in the input field and press @fBReturn@fR or the @fBAdd@fR button. To remove any users\n\
from the operator list select these users in the list and press the @fBDelete@fR button.\n\
Manipulations of operators must be done on an @fBadministration host@fR.\n\
\n\
@fBUsersets@fR are used as @fBAccess Lists@fR and Departments@fR.\n\
Two usersets have special meaning. @fBdeadlineusers@fR is\n\
used to define those users who are allowed to submit @fBDeadline Jobs@fR. The @fBdefaultdepartment@fR\n\
is attached to every user who is not a member of a administrator defined department. Users can only\n\
be members of one department. To add a new userset, press @fBAdd@fR. In the helper dialogue choose\n\
the type of userset and add any users. For access lists the @@<unix group> notation\n\
can be used to build an access list containing a UNIX group.\n\
@fBOk@fR registers the new userset at sge_qmaster and @fBCancel@fR dismisses any changes.\n\
For modification of an already existing userset select it, press @fBModify@fR and proceed as for\n\
@fBAdd@fR.\n\
To remove a userset select it and press @fBDelete@fR.\n\
In the @fBUser@fR tab you can add a user for the @fBTicket Policies@fR and attach a default\n\
project to the user. Enter the user name in the input field\n\
and press @fBReturn@fR or @fBAdd@fR, this adds a new line to the matrix. If the @fIDefault Project@fR\n\
shall be changed, select those users and press the @fBDefault Project@fR title button to pop up\n\
a list of configured projects. Pressing @fBOk@fR in the helper changes the project entry for the\n\
selected users.\n\
\n\
The @fBDone@fR button leaves the dialogue. The @fBTickets@fR button links to the\n\
@fBPolicy Configuration@fR dialogue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_pe.pe_layout*xmtHelpTitle: @fBParallel Environment Configuration Help
Qmon*qmon_pe.pe_layout*xmtHelp: \
A parallel environment (PE) is a software package designed for concurrent computing in networked\n\
environments or parallel platforms. Examples for two of the most common message passing environments\n\
are PVM and MPI. All these systems show different characteristics and have segregative requirements.\n\
Arbitrary PE's can be interfaced by Grid Engine as long as suitable start-up and stop procedures are provided.\n\
For further information refer to the manuals.\n\
\n\
The @fBParallel Environment Configuration@fR dialogue displays a list of already configured PEs in the\n\
@fBPE List@fR on the left hand side of the dialogue. In the @fBConfiguration@fR section the currently\n\
configured values are shown.\n\
To add or modify a PE object press the @fBAdd@fR or @fBModify@fR button respectively. For the modify an\n\
existing PE has to be chosen from the @fBPE List@fR.\n\
The @fBPE modification dialogue@fR pops up having either a template PE entry or the PE to be modified.\n\
The @fBName@fR input field either displays the name of the PE to modify or has to be entered as name for\n\
the new PE. The @fBSlots@fR spinbox allows the input of the number of job slots in total which may be\n\
occupied by all PE jobs running concurrently.\n\
To add or change the @fBUser Lists@fR and the @fBXuser Lists@fR which\n\
allow/deny access to the PE can be selected by pressing the button next to\n\
the lists showing already attached @fBUser Lists@fR and @fBXuser Lists@fR.\n\
In the @fBStart Proc Args and Stop Proc Args@fR the precise invocation sequence\n\
of the PE start-up and stop procedures is entered.\n\
Further information on the use of @fBAllocation Rule@fR, @fBUrgency Slots@fR,\n\
@fBControl Slaves@fR, @fBAccounting Summary@fR and @fBJob is first Task@fR can be found in @fBsge_pe(5)@fR.\n\n\
By pressing the @fBOk@fR button the added/modified PE configuration is checked and added to the Grid Engine\n\
system. The @fBCancel@fR button discards any changes.\n\
\n\
To delete a PE object, select it in the @fBPE List@fR and press @fBDelete@fR.\n\
The @fBDone@fR button quits the dialogue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_ckpt.ckpt_layout*xmtHelpTitle: @fBCheckpointing Configuration Help
Qmon*qmon_ckpt.ckpt_layout*xmtHelp: \
@fBGrid Engine@fR provides various levels of checkpointing support. The checkpointing\n\
environment described here is a means to configure the different types of  checkpointing\n\
in use for your @fBGrid Engine@fR cluster or parts thereof (see @fBcheckpoint(5)@fR).\n\
For that purpose you can  define  the  operations which  have to be executed in\n\
initiating a checkpoint generation, a migration of a checkpoint to another host or\n\
a restart of a checkpointed application as well as the list of queues which are\n\
eligible for a checkpointing method.\n\
\n\
The @fBCheckpoint Configuration@fR dialogue displays a list of already configured\n\
Checkpoint Objects in the @fBCheckpoint Objects@fR list.\n\
The corresponding configuration parameters are shown in the @fBConfiguration@fR section.\n\
To add or modify a checkpoint object press the @fBAdd@fR or @fBModify@fR button respectively.\n\
For the modify an existing checkpoint object has to be chosen from the @fBCheckpoint Objects@fR list.\n\
The @fBCheckpoint modification dialogue@fR pops up having either a template\n\
checkpoint object or the checkpoint object to be modified.\n\
The @fBName@fR input field either displays the name of the checkpoint object to be modified\n\
or has to be entered as name for the new checkpoint object.\n\
The @fBInterface@fR option menu allows the selection of a checkpointing interface.\n\
Currently the types USERDEFINED, HIBERNATOR, TRANSPARENT, CPR, CRAY-CKPT, APPLICATION-LEVEL are valid.\n\
The @fBCheckpoint Command@fR is a command-line type command string to be executed\n\
by @fBGrid Engine@fR in order to initiate a checkpoint.\n\
The @fBMigration Command@fR is a command-line type command string to be executed\n\
by @fBGrid Engine@fR during a migration of a checkpointing job from one host to another.\n\
The @fBRestart Command@fR is a command-line type command string to be executed\n\
by @fBGrid Engine@fR when restarting a previously checkpointed application.\n\
The @fBCheckpointing directory@fR is a file system location to which checkpoints\n\
of potentially considerable size should be stored.\n\
The @fBCheckpoint Signal@fR specifies a UNIX signal to be sent to a job by @fBGrid Engine@fR\n\
to initiate a checkpoint generation. The value for this field can either be a\n\
symbolic name from the list produced by the -l option of the kill(1) command or\n\
an integer number which must be a valid signal on the systems used for checkpointing.\n\
The @fBCheckpoint When@fR specifies the  points  of  time  when checkpoints are\n\
expected to be generated.\n\
\n\
By pressing the @fBOk@fR button the added/modified Checkpoint configuration is checked and\n\
added to the Grid Engine system. The @fBCancel@fR button discards any changes.\n\
\n\
To delete a checkpoint object, select it in the @fBCheckpoint Objects@fR list and press @fBDelete@fR.\n\
The @fBDone@fR button quits the dialogue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*sconf_shell*xmtHelpTitle: @fBScheduler Configuration Help
Qmon*sconf_shell*xmtHelp: \
The @fBScheduler Configuration@fR dialogue permits the setting of scheduler specific\n\
parameters. It is subdivided in @fBGeneral Parameters and Load Adjustment@fR.\n\
A complete description of the different scheduler relevant settings can be\n\
found in @fBsched_conf (5)@fR.\n\
\n\
The @fBAlgorithm@fR allows for the selection  of  alternative  scheduling  algorithms.\n\
The @fBSchedule Interval@fR specifies how often the scheduler is triggered.\n\
The @fBReprioritize Interval@fR specifies the interval jobs are reprioritized\n\
on the exec host based on the current ticket amount of running jobs.\n\
\n\
@fBDefault Duration@fR is assumed as runtime for jobs that have neither -l h_rt=\n\
nor -l s_rt=... specified. In contrast to a time limit this setting is not\n\
enforced.\n\
The @fBMax. Jobs/User@fR specifies how many jobs per user\n\
should be scheduled. If the value is zero no restrictions apply.\n\
The queues can be sorted according to the @fBLoad Formula@fR when @fBSort by Load@fR is\n\
selected. If @fBSort by sequence number@fR is selected the queues are sorted according to\n\
the sequence number entered in the @fBGeneral@fR section of the @fBQueue Configuration@fR\n\
dialogue.\n\
The @fBJob Scheduling Information@fR part allows enabling/disabling of job scheduling information\n\
for all or part of the jobs. The input field serves to enter a job range as min[-max][,...] to\n\
define for which jobs scheduling information is requested.\n\
The @fBLoad Formula@fR is the formula of load parameters which should be used by the\n\
@fBSort by Load@fR method.\n\
Because the load reports are delayed @fBLoad Adjustment@fR is the value which will be added to\n\
the load for correcting this delay. The @fBLoad Adjustment Decay Time@fR specifies the time\n\
during which the load correction is decreased to 0.\n\
When @fBFlush Submit Seconds@fR is set to 1 or larger the scheduler will be\n\
triggered x seconds after a job was submitted to the system. Otherwise in the\n\scheduling interval.\n\
When @fBFlush Finish Seconds@fR is set to 1 or larger the scheduler will be triggered\n\
x seconds after a job has finished. Setting this parameter to 0 disables the\n\
flush after a job has finished.\n\
@fBMaximum Reservation@fR defines the maximum number of reservations scheduled\n\
within a schedule  interval.\n\
After having changed the scheduler configuration these changes are made permanent by pressing @fBOk@fR.\n\
@fBCancel@fR dismisses any changes and quits the dialogue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_cal*xmtHelpTitle: @fBCalendar Configuration Help
Qmon*qmon_cal*xmtHelp: \
The @fBCalendar Configuration@fR dialogue allows the configuration of Grid Engine calendars.\n\
They are used to restrict the accessibility of Grid Engine queues to certain dates and times.\n\
\n\
Press @fBAdd@fR to add a new calendar. This pops up the calendar definition helper dialogue.\n\
Here you can enter a calendar entry according to the examples given there.\n\
To modify an existing calendar select it in the @fBCalendars@fR list and press @fBModify@fR.\n\
To delete one select it and press @fBDelete@fR. The current settings of the highlighted calendar\n\
is shown in the @fBConfiguration@fR area.\n\
@fBDone@fR quits the dialogue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_tov.tov_layout*xmtHelpTitle: @fBPolicy Configuration Help
Qmon*qmon_tov.tov_layout*xmtHelp: \
The @fBPolicy Configuration@fR dialogue allows the setting and manipulation of all\n\
relevant policy related settings as urgency, tickets and shares of the Grid Engine system.\n\
For more detailed information consult the man page @fBsched_conf(5)@fR and @fBsge_priority(5)@fR.\n\n\
The main dialogue consists of four main sections.\n\
The @fBPolicy Importance Factor@fR section allows to adjust the importance of\n\different scheduling policies compared to each other.\n\
The @fBUrgency Policy@fR part allows the specification of @fBWeight Deadline@fR\n\
and @fBWeight Waiting Time@fR.\n\
The next section defines @fBTicket Policy@fR related settings.\n\
The number of @fBTotal Share Tree Tickets and Total Functional Tickets@fR can\n\
be defined on the right. The actual amount is visible on the left.\n\
If changes have been made in the @fBEdit Tickets@fR part, they are made permanent\n\
by pressing the @fBApply@fR button.\n\
\n\
@fBShare Override Tickets@fR and @fBShare Functional Tickets@fR toggle if shares\n\
or functional tickets are distributed among jobs of a specific object or each\n\
job gets the full amount of shares or functional tickets.\n\
@fBReport Pending Job Tickets@fR enables the reporting of pending job tickets\n\
to sge_qmaster. This influences the sort order of jobs in qstat and qmon.\n\
@fBMaximum Functional Jobs@fR is the maximum number of pending jobs to schedule\n\
in the  functional policy. The default value is 200.\n\
@fBMaximum Pending Tasks Per Job@fR is the maximum number of subtasks per pending\n\
array job to schedule. This parameter exists in order to reduce scheduling\n\
overhead. The default value is 50.\n\
@fBTicket Policy Hierarchy@fR defines the priority of different ticket based\n\
policies if they are combined.\n\
From the @fBTicket Policy@fR section the different ticket policy subdialogues can be reached.\n\
The four ticket based policies are @fBShare-based Policy, Functional Policy, Initiation Deadline Policy\n\
and Override Policy@fR.\n\
Share-based and Functional Policy allow the long term adjustment of job scheduling\n\
and resource management.\n\
Override Policy is used to overrule the long term policies under certain circumstances.\n\
More details concerning the subdialogues are explained there. The different policies\n\
are accessed via @fBShare Tree Policy, Functional Policy and Override Policy@fR.\n\
In addition it is possible to go to the @fBUser Configuration@fR dialogue to\n\
add or modify the users that are allowed to submit deadline jobs.\n\
Users allowed to submit deadline jobs are registered in the special userset\n\
@fBdeadlineusers@fR. This is done with @fBUsers Allowed To Submit Deadline Jobs@fR.\n\
\n\
The @fBRefresh@fR button contacts the master daemon to get the freshest valid data.\n\
With @fBDone@fR one quits the @fBPolicy Configuration@fR dialogue.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_project.project_layout*xmtHelpTitle: @fBProject Configuration Help
Qmon*qmon_project.project_layout*xmtHelp: \
The @fBProject Configuration@fR dialogue allows the definition and manipulation\n\
of @fBGrid Engine@fR projects. A project can be attached to a Grid Engine job and enforces\n\
or delays the execution of this job depending on the ticket share of this project.\n\
The dialogue displays the currently available projects on the left. The right\n\
part of the dialogue shows the according configuration values for the highlighted\n\
project.\n\
To add a new project press the @fBAdd@fR button. A subdialogue pops up which\n\
permits to enter the name of the new project and to attach certain access restrictions.\n\
To allow access only to those users contained in a special userset, press the\n\
list icon to the right of the 'User Lists' part and choose a userset. So the project\n\
is only accessible by users in the chosen usersets.\n\
To deny access to certain users the same procedure applies.\n\
Pressing the @fBOk@fR button adds the new project permanently and the @fBCancel@fR button\n\
dismisses the changes.\n\
With @fBModify@fR the same subdialogue as for the @fBAdd@fR button appears with\n\
the values filled in for the highlighted project.\n\
The @fBDelete@fR button serves to remove the selected project from the system.\n\
The @fBDone@fR button closes the @fBProject Configuration@fR dialogue.\n\
\n\
To change the @fBOverride Tickets@fR or the @fBFunctional Share@fR of a project\n\
the @fBFunctional Policy@fR and @fBOverride Policy@fR subdialogues from the\n\
@fBTicket Overview@fR dialogue have to be used.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*browser_shell.browser_layout*xmtHelpTitle: @fBQmon Browser Help
Qmon*browser_shell.browser_layout*xmtHelp: \
The @fBObject Browser@fR can be used to look at additional information for the Grid Engine objects\n\
@fBqueue and job@fR, to display the @fBstdout/stderr@fR output of qmon and to view @fBqmon messages@fR\n\
that are produced when a job is submitted or any administrative tasks are performed.\n\n\
To enable the browsing of one of these categories press the corresponding button in the @fBObjects@fR\n\
field.\n\
\n\
@fBstdout, stderr@fR enable redirection of messages that go usually to the console to be redirected to the browser\n\
window.\n\n\
@fBQueue@fR enables the browsing of queue information by dragging the mouse over a queue line in the Queue Control dialog.\n\n\
@fBJob@fR enables the browsing of job information by dragging the mouse over a job line in the Job Control dialog.\n\n\
@fBMessages@fR switches on the display of informative or error messages that are returned by the master.\n\
\n\n\
Any output can be cleared by pressing the @fBClear@fR button.\n\
The @fBDone@fR button closes the @fBObject Browser@fR.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_sharetree.sharetree*xmtHelpTitle: @fBShare Tree Policy Help
Qmon*qmon_sharetree.sharetree*xmtHelp: \
The @fBShare Tree Policy@fR allows the Grid Engine manager to specify how system\n\
resources should be shared among Grid Engine users and projects over a sliding\n\
window of time.\n\
\n\
This is accomplished by setting up a share tree in which the available resources\n\
are divided up among the nodes at each hierarchical level based on the number of\n\
@fBshares@fR given to each node.\n\
During scheduling, Grid Engine maps each active job to a node in the share tree.\n\
Grid Engine tracks the actual usage for each node and compares this to the\n\
@fBtargeted share@fR as defined by the number of shares assigned to each node.\n\
Grid Engine will then assign an appropriate number of tickets to each active job\n\
in order to meet the resource utilization goals defined by the share tree.\n\
Each leaf node in the share tree may be a Grid Engine user or project.\n\
Projects may also be specified as group nodes. A project may appear only once\n\
in the share tree. A user may appear multiple times in the share tree, but only\n\
once in a given project sub-tree and only once outside of any project sub-tree.\n\
Each leaf node under a project group node must be a Grid Engine user. All jobs\n\
which map to a project leaf node will equally share the shares defined in that node.\n\
A user leaf node named "default" can be defined as a descendant of a project node in\n\
the share tree. The default node defines how many shares users get who are running in\n\
the project, but who are not explicitly specified as descendant user nodes of the project.\n\
\n\
Shares are used to represent how resources should be divided up among sibling nodes.\n\
If node A is given 100 shares and sibling node B is given 50 shares, the Grid Engine\n\
manager is indicating that node A should get twice as much of the available system\n\
resources as node B. Shares are only compared between sibling nodes.\n\
They are only used to translate into targeted percentages of resources that Grid Engine\n\
will try to deliver. Grid Engine looks at all the active jobs and divides up the tickets\n\
allocated to the Share Tree Policy among the active jobs based on the share tree.\n\
\n\
The share tree dialogue allows the setting and manipulation of the share tree policy.\n\
The left side of the dialogue allows the current share tree to be displayed and edited.\n\
The nodes of the share tree are hierarchically displayed in the scrollable window.\n\
Lower levels of the share tree can be collapsed/exploded by pointing to a group node and\n\
double-clicking with the left mouse button. The attributes of each node can be individually\n\
displayed under the @fBNode Attributes@fR by highlighting the node.\n\
\n\
To highlight an individual node, place the pointer on the node and click on the left mouse\n\
button. The @fBIdentifier@fR attribute is the name of the node. The @fBShares@fR attribute\n\
is the number of shares associated with the node. The @fBLevel Percentage@fR attribute is the\n\
percentage of resources that the node should receive in comparison to the other sibling nodes.\n\
The @fBTotal Percentage@fR attribute is the percentage of resources that the node should receive\n\
in comparison to all the other nodes in the share tree. The @fBActual Resource Share@fR\n\
attribute is the percentage of resources that the node is actually receiving over the sliding\n\
window of time defined by the @fBHalftime@fR Share Tree Policy parameter.\n\
The @fBTargeted Resource Share@fR attribute is the current percentage of available resources\n\
that Grid Engine has targeted for the node based on the nodes in the share tree which have\n\
active jobs. The @fBCombined Usage@fR attribute is the amount of combined CPU, memory, and I/O\n\
usage which has been accumulated by the node.\n\
\n\
The @fBRefresh@fR button refreshes the display with the freshest share tree values from Grid Engine.\n\
The @fBApply@fR button registers any changes with sge_qmaster.\n\
The @fBDone@fR quits the dialogue without any additional action, so be aware and @fBApply@fR first.\n\
\n\
The @fBAdd Node@fR and @fBAdd Leaf@fR buttons can be used to add new nodes to the share tree.\n\
The @fBAdd Node@fR button adds a group node and the @fBAdd Leaf@fR button adds a leaf node.\n\
To add a node, highlight the node under which you want to add a new node and click on the @fBAdd\n\
Leaf@fR or @fBAdd Node@fR button. A helper dialogue will be displayed where you can enter the node\n\
@fBName@fR and its @fBShares@fR. To modify the name or the number of shares of a node, highlight\n\
the node and click on the @fBModify@fR button. The @fBCut@fR, @fBPaste@fR, and @fBCopy@fR buttons\n\
can be used to prune and graft sections of the share tree. The @fBFind@fR buttons can be used to\n\
locate a particular node in the share tree. The @fBFind@fR button accepts hierarchical\n\
specifications. The use of a '/' in the specification represents a parent/child relationship.\n\
For instance, "ProjectA/davidson" finds the "davidson" node which is a child of the "ProjectA" node.\n\
The use of a '/' as the first character in a specification represents the "Root" node in the share\n\
tree. The specification "/ProjectA/davidson" finds the "davidson" node which is a child of the\n\
"ProjectA" node which is a child of the "Root" node. The use of a '.' in a specification\n\
represents a descendant relationship, such that the specification "ProjectA.davidson" finds\n\
the "davidson" node which is a descendant of a node "ProjectA". A '*' instead of a name represents\n\
a wild-card and will match any node at the specified level. For instance, the specification\n\
"/*/*/davidson" will find the first occurrence of the "node" davidson which is three levels below\n\
the "Root" node. Any node names (not just users or projects) may be specified in a node\n\
specification.\n\
\n\
The Share Tree Policy Parameters portion of the dialogue is displayed by pressing the red arrow\n\
button at the bottom of the dialogue. The @fBCPU@fR, @fBMEM@fR, and @fBI/O@fR slider bars determine\n\
the composition of the @fBCombined Usage@fR displayed for each node in the share tree.\n\
The locks keep the current setting of one of the categories constant and allow the distribution of\n\
the remaining ratio between the other categories.\n\
The @fBHalflife Decay List@fR allows to configure different decay rates for the\n\
finished_jobs usage types, which is used in the pending job ticket calculation\n\
to account for jobs which have just ended.\n\
The @fBHalflife@fR parameter specifies how fast to decay usage in the share tree. Usage will be\n\
decayed at a rate in which half the usage will be gone after the @fBHalflife@fR period of time.\n\
This defines the sliding window of time over which usage is tracked for the share tree.\n\
The @fBCompensation Factor@fR limits the amount of compensation that Grid Engine will give to a\n\
user in order to reach their targeted resource share.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*fticket_layout*xmtHelpTitle: @fBFunctional Policy Help
Qmon*fticket_layout*xmtHelp: \
The @fBFunctional Policy@fR dialogue allows the Grid Engine manager to specify how system\n\
resources should be shared among Grid Engine @fBUsers, Departments, Projects and Job@fR.\n\
\n\
Selecting one of the categories listed above from the @fBoption menu@fR topleft displays all\n\
configured objects of this kind in the matrix with their current settings. To change the number\n\
of @fBFunctional Shares@fR click the cell in the @fBFunctional Shares@fR column and change the\n\
number of tickets. This changes the objects percentage of the functional ticket share.\n\
By pressing the @fBRed Arrow@fR at the bottom right it is possible to apply a weighting to\n\
the different object types.\n\
To register the changes with @fBsge_qmaster@fR press @fBApply@fR. The message area at the bottom\n\
confirms either @fBSuccess or Failure@fR.\n\
@fBDone@fR quits the dialogue.\n\
The @fBTwisted Red Arrow@fR links to the corresponding object configuration dialogue.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*oticket_layout*xmtHelpTitle: @fBOverride Policy Help
Qmon*oticket_layout*xmtHelp: \
The @fBOverride Policy@fR dialogue allows the Grid Engine manager to specify how shorttrem system\n\
resources should be overridden among Grid Engine @fBUsers, Departments, Projects and Job@fR.\n\
\n\
Selecting one of the categories listed above from the @fBoption menu@fR topleft displays all\n\
configured objects of this kind in the matrix with their current settings. To change the number\n\
of @fBFunctional Shares@fR click the cell in the second column and change the\n\
number of tickets. This changes the number of override tickets.\n\
To register the changes with @fBsge_qmaster@fR press @fBApply@fR. The message area at the bottom\n\
confirms either @fBSuccess or Failure@fR.\n\
@fBDone@fR quits the dialogue.\n\
The @fBTwisted Red Arrow@fR links to the corresponding object configuration dialogue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*rqs*xmtHelpTitle: @fBResource Quota Help
Qmon*rqs*xmtHelp: \
The @fBResource Quota Configuration@fR dialogue allows the Grid Engine manager to specify how system\n\
resources should be restricted by quotas. The corresponding allowed syntax is explained in sge_resource_quota(5) man page.\n\
\n\
In qmon the complete set of reqsource quotas is shown as for qconf -srqs and changed as for qconf -mrqs. (see qconf(1))\n\
A template section to start with is\n\
{\n\
   name         template\n\
   description  NONE\n\
   enabled      FALSE\n\
   limit        to slots=0\n\
}\n\
\n\
To register the changes with @fBsge_qmaster@fR press @fBOk@fR.\n\
@fBCancel@fR discards any changes and quits the dialogue.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*ar_main_layout*xmtHelpTitle: @fBAdvance Reservation
Qmon*ar_main_layout*xmtHelp: \
The @fBAdvance Reservation@fR dialogue allows the Grid Engine manager to submit and manipulate Advance Reservation objects.\n\
See qrsub(1) and qrstat(1) man page for the command line counterpart.\n\
\n\
The following operations are possible\n\
- open the @fBAR Submit Dialogue@fR with the @fBSubmit@fR button\n\
- @fBDelete@fR AR objects\n\
- adjust the display behavior of ARs with @fBCustomize@fR.\n\
\n\
A list of all Adance Reservations is shown.\n\
\n\
Without any customization the columns @fBARId, ARName, Owner@fR and\n\
@fBState@fR are displayed. In the @fBAR Customize@fR dialogue additional information\n\
about the AR can be selected for display.\n\
The default sort order is by AR_id. If a different label is pressed the sorting order changes. Pressing the same label again\n\
reverts the sort order from ascending to descending.\n\
\n\
For most of the tasks ARs have to be selected first. To select an AR the following\n\
key + mouse combinations are used\n\
@f[BI]Mouse1@fR\n\
Begin of selection, one row is selected, already selected areas are unselected.\n\
@f[BI]Shift + Mouse1@fR\n\
Extend of selection, select all rows between Begin of selection and the clicked to row.\n\
@f[BI]Ctrl + Mouse1@fR\n\
Toggle the selection, the clicked to row is selected if it was unselected and unselected\n\
otherwise.\n\
The Select All button can be used to select all jobs in a tab.\n\
\n\
The selected ARs can be deleted by the button labeled @fBDelete@fR at the right hand side of the window.\n\
\n\
Deletion can be forced, i.e. registered with @fBsge_qmaster@fR\n\
without notification of the @fBsge_execd@fR controlling the ARs, in case the corresponding\n\
@fBsge_execd@fR is unreachable, e.g. due to network problems.\n\
\n\
The @fBCustomize@fR button allows the setting of additional AR attributes to display\n\
The @fBAR Customize@fR folder pops up.\n\
The @fBSelect Fields@fR dialogue is used to display additional AR attributes.\n\
The customization settings can be saved to $HOME/.qmon_preferences in order to keep them\n\
across qmon sessions by clicking the @fBSave@fR button in the @fBAR Customize@fR dialogue instead of @fBOk@fR.\n\
\n\
To keep the information being displayed up-to-date, qmon uses a polling scheme to retrieve\n\
the status of the ARs from sge_qmaster.\n\
A refresh can be forced by pressing the @fBRefresh@fR button.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Qmon*qmon_arsub.arsub_layout*xmtHelpTitle: @fBSubmit Advance Reservation Help
Qmon*qmon_arsub.arsub_layout*xmtHelp: \
The @fBAR Submission@fR dialogue allows to submit advance reservations into the Grid Engine system.\n\
For general information on how to submit a Grid Engine advance reservation please refer to the examples given in\n\
the @fBGrid Engine User Guide@fR and the qrsub(1) man page.\n\
\n\
To submit an AR you have to specify at least a duration that is greaeter than zero.\n\
If no Start At time is delivered the AR is dispatched immediately otherwise at the Start At time.\n\
Instead of specifying the Duration an End At in the future can be entered.\n\
\n\
With the @fBRequest Resources@fR button the @fBRequested Resources@fR dialogue is opened\n\
in order to specify the @fBResource Requirements@fR of the AR. If resources are requested,\n\
the icon pins are displayed completely filled with color.\n\
\n\
The button list on the right is used to perform different tasks concerning of AR submission.\n\
The @fBSubmit AR@fR button submits the AR into the Grid Engine system.\n\
The @fBClear@fR button clears all dialogue entries.\n\
The @fBDone@fR button discards any changes and quits the dialogue.\n\
The @fBParallel Environment@fR field allows the selection of a parallel environment and the\n\
corresponding range specifications. A helper dialogue listing configured PEs is associated\n\
at the right.\n\
In the @fBCheckpoint Object@fR field a special checkpoint object can be requested.\n\
The @fBAccount@fR field contains a string which is stored in the accounting record for this\n\
AR.\n\
The @fBMaster Queue List@fR is only meaningful for a parallel AR request.\n\
This option is used to reserve the proper queues to match this request if it would be requested by a qsub.\n\
The @fBCluster Queue List@fR defines or redefines a list of cluster queues, queue domains or queue instances,\n\
that may be reserved by the AR. This parameter has all the properties of a resource request and will be merged\n\
with requirements derived from the Resource Request option described above.\n\
The @fBAccess Allowed@fR line allows the setting of an access list for this AR.\n\
The @fBAccess Denied@fR line allows the setting of an access list for this AR that denies access\n\
for any user contained therein.\n\
The @fBHandle Hard Error@fR specifies the behavior when the AR goes into an error state. The\n\
AR goes into error state when a reserved host goes into unknown state, a queue error happens,\n\
or when a queue is disabled or suspended.\n\
If hard error is checked, as long as the AR is in error state no jobs using the AR will be scheduled.\n\
Otherwise the AR stays usable with the remaining resources.\n\
The @fBConsider only INTERACTIVE Queues@fR tries to start any job on interactive queues only.\n\
The @fBVerify Mode@fR defaults to 'Error' and can be changed to 'Just verify'.\n\
In 'Just verify' the AR is only verified and no AR is submitted.\n\
The @fBMail@fR section contains the events when the user is notified by electronic mail and\n\
the mail addresses to which these notification is sent.\n\
