1. Introduction to WMS Praticals instruction
Annamaria Muoio
University of Catania and INFN
Tutorial
Catania 8-9 Febbraio 2006

2. GLITE SERVICE
The services are related to job management/execution.The accounting is a special case as it will take into account not only computing, but also storage and network resources.
These services communicate with each other as the job request progresses through the system, so that a consistent view of the status of the job is maintained.

3. ACCOUNTING - CE
The first service accumulates information about the usage of Grid resources by the users and by groups of users.This information allows preparation of statistical reports, to track resource usage for individual users, to discover abuses and to help avoid them. Accounting information could be used to charge users for the
Grid resources they have utilised.The information available from the accounting service can also be used to implement submission policies based on user quotas or on resource usage (fair share).
The CE represents a computing resource. Its main functionality is job management (job submission, job control, etc.), but it must also provide other capabilities, such as the provision of information about its characteristics and status. The CE, exposing a Web Service interface, may be used by a generic client: an end-user interacting directly with the Computing Element, or the Workload Manager, which submits a given job to an appropriate CE found by a matchmaking process.
A CE refers to a set, or cluster of computational resources, managed by a LRMS. This cluster can encompass resources that are heterogeneous in their hardware and software configuration.

4. JOB-PROVENANCE PACKAGE-MANAGER
The purpose of JP is keeping track of the definition of submitted jobs, execution conditions and environment, and important points of the job life cycle for a long period (months to years). Those data can be used for debugging, post-mortem analysis, comparison of job execution within an evolving environment, as well as assisted re-execution of jobs. Only data of completed (either successful or failed) jobs are handled.
A Package Management Service is a helper service that automates the process of installing, upgrading, configuring, and removing software packages from a shared area (software cache) on a grid site.

5. General information grid resource
The purpose of the Workload Manager Service is to accept requests for job submission and management coming from its clients and take the appropriate actions to satisfy them.
Their interaction with the WMS is indeed limited to the description of the characteristics and requirements of the request via a high-level, user-oriented specification language, the Job Description Language (JDL) and to the submission of it through the provided interfaces.
grid resource
WMS
traslator
User request

6. Workload Manager Service
The JDL allows the description of the following request types supported by the WMS:
• Job: a simple application
• DAG: a direct acyclic graph of dependent jobs
• Collection: a set of independent jobs

7. General information
The Job Description Language (JDL) is a high-level, user-oriented language
Job a simple job
DAG a Direct Acyclic Graph of dependent jobs
The Workload Management System currently supports the following types for Jobs :
Normal a simple batch,a set of commands to be processed as single unit
Interactive a job whose standard streams are forwarded to the submitting client
MPICH a parallel application using MPICH-P4 implementation of MPI
Partitionable a job which is composed by a set of independent steps/iterations
Checkpointable a job able to save its state
the job execution can be suspended and resumed later, starting from the same point where it was first stopped
a set of independent sub-jobs, each one taking care of a step or of a sub-set of steps, and which can be executed in parallel

8. Service architecture grid resource “submit a job” “User interface”
JDL
grid resource
“submit a job”
“User interface”
Command line
Graphical interface
API
client tools: C++ & Java

9. Service architecture “User interface” “possible operations”
Find the list of resources suitable to run a specific job
“User interface”
“possible operations”
Retrieve checkpoint states of a submitted checkpointable job
Submit a job/DAG for execution on a remote Computing Element
Retrieve the output files of a completed job/DAG (output sandbox)
Check the status of a submitted job/DAG
Retrieve and display bookkeeping information about submitted jobs/DAGs
Cancel one or more submitted jobs/DAGs
Retrieve and display logging information about submitted jobs/DAGs
Retrieve the output files of a completed job/DAG (output sandbox)
Start a local listener for an interactive job

10. WMProxy/Network Server Logging and Bookkeeping
Service architecture
WMS
The WMS components handling the job
   Resource Broker
    CondorC/DAGMan
 Workload Manager
WMProxy/Network Server
   Job Controller
  Log Monitor
Logging and Bookkeeping

11. Architecture Network Server
This is a generic network daemon that provides support for the job control functionality. It is responsible for accepting incoming requests from the UI (e.g. job submission, job removal), which, if valid, are then passed to the Workload Manager.
start

12. Architecture WMProxy start
This is providing access to WMS functionality through a Web Services based interface. It is replacement of the NS in the passage to the Service Oriented Architecture
for the WMS architecture. It provides additional features such as submission and the support for shared and compressed sandboxes of compound jobs.
Architecture WMProxy
start

13. Architecture Workload Manager
start
Then it will pass the job to an appropriate CE for execution, Which resource should be used is the matchmaking process between the submission requests and the available resources.
This is the core component of the WMS. For a computation job there are two main types of request: submission and cancellation. The submission request is to pass the responsibility of the job to the WM.
A WM can adopt different policy.
-a job is matched to a resource then it is passed to the selected resource for execution.
-a job is held by the WM until a resource becomes available
-Intermediate approaches are of course possible.

14. Architecture of WMS start Task queue
It gives the possibility to keep a submission request for a while if no resources are immediately available

15. Architecture Resource Broker
start
This supports the WM and it provides a matchmaking service: given a JDL expression it finds the resources that best match the request.

16. Architecture ISM start
This allows the flexible application of different policies is the decoupling between the collection of information concerning resources and its use This supports the WM and it finds the resources that best match the request. The update is the result of either the arrival of notifications
or active polling of resources or some arbitrary combination of the two.

17. Information and Monitoring Services
The information services are a vital low-level component of any grid; most services will publish or consume information. The information service should create the appearance of a single federated database covering all available information. This implies a query language that supports ad-hoc correlations between information in different services. A candidate for the model is the relational model with SQL as the query language.
Each VO is assigned a number of name-spaces corresponding to a Virtual Database (VDB). Each VDB is associated with a registry and a schema. The schema holds the definitions of the tables and the registry lists the available sources of information (producers) and the consumers. A registry contains a list, for each table, of Producers who have offered to publish for the table. A Consumer runs an SQL query against a table, and the registry selects the best Producers to answer the query in a process called mediation. The Consumer then contacts each Producer directly, combines the information, and returns a set of tuples.

18. Architecture JOB ADAPTER
start
It is responsible for making the final touches to the JDL expression for a job, before it is passed to CondorC for the actual submission

19. Architecture CondorC start
This is responsible for performing the actual job management operations (job submission, job removal, etc.).

20. Condor C
Condor-C allows jobs in one machine's job queue to be moved to another machine's job queue. These machines may be far removed from each other, providing powerful grid computation mechanisms, while requiring only Condor software and its configuration.
There are two aspects to configuration to enable the submission and execution of Condor-C jobs. These two aspects correspond to the endpoints of the communication: there is the machine from which jobs are submitted, and there is the remote machine upon which the jobs are placed in the queue (executed).

21. Architecture DAGMan start
This is a meta-scheduler whose main purpose is to navigate the graph (i.e. the DAG request), it is determine which nodes are free of dependencies, and follow the execution of the corresponding jobs.

22. Architecture Log Monitor
start
This is responsible for watching the CondorC log file, intercepting interesting events concerning active jobs, that is events affecting the job state machine (e.g. job done, job canceled, etc.), and therefore triggering appropriate actions.

23. Architecture Proxy Renewal Service
start
Proxy Renewal Service
It is available to assure that a valid user proxy exists. It relies on the MyProxy service for renewing credentials associated to the request.

24. Architecture Logging & Bookkeping
start
The Logging and Bookkeeping (LB) service provides support for the job monitoring functionality: it stores logging and bookkeeping information concerning events generated by the various components of the WMS. Using this information, the LB service keeps a state machine view of each job.

25. grid resource Security
User, processes and grid services must work in a secure environment.
WMS
grid resource

26. MyProxy
The MyProxy consists of a server and a set of client tools that can be used to delegate and retrieve credentials to and from a server.
The set of binaries provided for the client is made of the following files:
myproxy-init
                        myproxy-get-delegation
myproxy-info
                        myproxy-change-pass-phrase
myproxy-destroy

27. General information
The myproxy-init command allows you to create and send a delegated proxy to a MyProxy server
lifetime
myproxy-init -s <host name> -t <hours> -d -n
no password
It stores a user proxy in the repository
the same user-name as your subject in the certificate
The myproxy-info command returns the remaining lifetime of the proxy
myproxy-info -s <host name> -d

28. General information
The myproxy-destroy destroys any existing proxy stored in the myproxy server
myproxy-destroy -s <host name> -d
The myproxy-get-delegation is used to retrieve information about the proxies stored in the myproxy server
myproxy-get-delegation -s <host name> -d -t <hours> -o <output file> -a <user proxy>
The myproxy-change-pass-phrase command changes the passphrase
myproxy-change-pass-phrase
The first prompts, old password, for credential
Then twice, new passphrase.

29. General information
The most relevant commands to interact with the WMS:
glite-job-list-match <jdl_file>
 glite-job-output <job_Id>
glite-job-submit <jdl_file>
 glite-job-cancel <job_Id>
glite-job-status <job_Id>
> command> --help
information
> man <command>

30. Schema job state
job is to the User Interface, it isn’t transferred to Network Server

31. Schema job state WM is busy No appropriate CE has been found
required dataset is not available
job is waiting for resource allocation
job has been accepted by NS and is waiting for Workload Manager

32. Schema job state
job has been processed by WM and its Helper modules It isn’t transferred to the CE via Job Controller and CondorC.

33. Schema job state
job is waiting in the queue on the CE

34. Schema job state
job is running

35. Schema job state
job exited and it is considered to be in a terminal state by CondorC or it is failed

36. Schema job state waiting in the Workload Manager queue
Computing Element for too long
over-use of quotas
expiration of user credentials
job processing was aborted

37. Schema job state
job has been canceled

38. Schema job state
output sandbox was transferred to the user or removed due to the timeout.

39. Schema DAG state The states Ready and Scheduled don’t exist
because the nodes are involved

40. Schema DAG state
DAGMan has started processing

41. Example a job/DAG description file[
Type = "Job";
JobType = "Normal";
Executable = "myexe";
StdInput = "myinput.txt";
StdOutput = "message.txt";
StdError = "error.txt";
InputSandbox= {"/users/pacini/example/myinput.txt",
"/users/pacini/example/myexe"};
OutputSandbox={"message.txt", "error.txt"};
Requirements= other.GlueCEInfoLRMSType == "PBS";
Rank = other.FreeCPUs; ] [
Type = "dag";
max_nodes_running = 10;
VirtualOrganisation = "EGEE";
nodes = [
nodeA = [
file ="/users/pacini/n1.jdl" ;];
nodeB = [
file ="/users/pacini/n2.jdl" ; ];
file ="/users/pacini/n3.jdl" ; ];
dependencies = {
{ nodeA, {nodeB, nodeC}} } ]; ]

42. GLITE-JOB-SUBMIT
It allows the user to run her application job at one remote resource.
glite-job-submit [options] <jdl file>
-help
usage
-version
version -c
configuration file pointed
instead
configuration standard
file_path
-config
-output
-input
file_path
-resource
ce_id
the job-ad sent to the NS contains a line of the type SubmitTo = ce_id and the job is submitted by the WMS to the resource identified by ce_id without going through the match-making process. Standard format for the CEId is:
<full hostname>:<port number>/jobmanager-<service>-<queue name>
where <service>could be for example lsf, pbs, bqs, condor but can also be a different string as it isfreely set by the site administrator when setting the queue. This option cannot be used for DAGs.Note that when this option is used, the ".BrokerInfo" file is not generated -r
ce_id

43. GLITE-JOB-LIST-MATCH
It displays the list of the resources on which the user is authorized and satisfying the job requirements included in the job description file. The CE identifiers are returned either on the standard output or in a file according to the chosen command options, and are strings univocally identifying the CEs published in the IS. This command cannot be used for DAG requests. The returned CEIds are listed in decreasing order of rank, i.e. the one with the best (greater) rank is in the first place and so on.
glite-job-list-match [options] <jdl file>
-help
usage
-version
version
-verbose -c
configuration file pointed
instead
configuration standard
file_path

44. GLITE-JOB-LIST-MATCH
-config
-output
file_path
-noint
every interactive question to the user is skipped. All warning and errors are written:
glite-job-output_<UID>_<PID>_<timestamp>.log
under the /tmp.
This information about the API functions are displayed on the standard output and are written to the file
glite-job-output_<UID>_<PID>_<timestamp>.log
under the /tmp.
-debug
this command is relocated to the location pointed by file_path. It must be last argument of the command.
-logfile
file_path
-rank
It displays the "matching" CEIds and the associated ranking values.

45. GLITE-JOB-LIST-MATCH
The vo-specific configuration file pointed to by file_path is used instead of the standard vo-specific configuration file.
-config -vo
file_path -o
It returns the CEIds list in the file specified by file_path. This can be either a simple name or an absolute path.
file_path
It displays on the standard output the job class-ad that is sent to the Network Server generated from the job description file. This differs from the content of the job description file because some attributes cannot be directly inserted by the user (e.g., defaults for Rank and Requirements if not provided, VirtualOrganisation etc). -v

46. GLITE-JOB-LIST-MATCH
-vo vo_name
It allows the user to specify the Virtual Organisation she/he is currently working for. If the user proxy contains VOMS extensions then the VO specified through this option is overridden by the default VO contained in the proxy (i.e. this option is only useful when working with non-VOMS proxies). The following rule is followed for determining the user’s VO:
the default VO from the user proxy
the VO specified through the –vo or –config-vo options
the VirtualOrganisation attribute in the JDL
 If none of the listed trials has success an error is returned and the submission is aborted. This option is allowed only when used together with the –all one.
If glite-job-list-match exits with a value of 0 in case of success and >0 in case of failure

47. GLITE-JOB-OUTPUT
It is used to retrieve the output files of a job/DAG with a job/DAG including the OutputSandbox attribute. After the user can download the files generated by the job/DAG and temporarily stored on the Resource Broker. It is also possible to specify a list of job identifiers when calling this command or an input file containing Ids by means of the –input option. It is important to note that the OutputSandbox of a submitted job can only be retrieved when the job has reached the Done status indicating that the job has successfully terminated its execution and the OutputSandbox files are ready for retrieval on the RB node. glite-job-output will always fail for jobs that are not yet in the Done status.
glite-job-output [options] <job Id(s)>
-help
usage
-version
version
-config
-input
file_path

48. GLITE-JOB-OUTPUT -dir directory_path
It retrieved files (listed by the user through the OutputSandbox attribute)that are stored in the location indicated by directory_path/<login name>_<jobId unique string>. For each DAG node the directory named <node Id unique string>is created inside the just mentioned dir for each DAG node. -c
configuration file pointed
instead
configuration standard
file_path
-config
-input
file_path
It makes the command return the OutputSandbox files for each jobId contained in the file_path. This option can’t be used if one (or more) jobIds have been already specified. The format of the input file must be as follows: one jobId for each line and comment lines must begin with a "#" or a "" character. -i
file_path

49. GLITE-JOB-OUTPUT
-noint
every interactive question to the user is skipped. All warning and errors are written:
glite-job-output_<UID>_<PID>_<timestamp>.log
under the /tmp.
This information about the API functions are displayed on the standard output and are written to the file
glite-job-output_<UID>_<PID>_<timestamp>.log
under the /tmp.
-debug
this command is relocated to the location pointed by file_path
-logfile
file_path
-jobId
It must be last argument of the command.
If glite-job-output exits with a value of 0 in case of success and >0 in case of failure and <0 in case of partial failure

50. GLITE-JOB-STATUS
It prints the status of a job/DAG submitted. It is sent to the LB that provides the information. For a DAG it provides the status information for the DAG itself and all of its nodes. It is possible to retrieve the status of individual nodes of a DAG simply passing their own identifiers to the command.
glite-job-status [options] <job Id(s)>
-help
usage
-version
version
-config
-output
-input
file_path
It displays status information about all job owned by the user. This option can’t be used either if one or more jobIds have been specified or if the –input option has been specified. All LBs listed in the vo-specific WMS-UI configuration file are contacted to fulfil this request
-all

51. GLITE-JOB-STATUS It makes the query LB for jobs that have
been submitted after the specified
date/time. If only hours and minutes are
specified then the current day and year are taken into account.
-to
-from
[MM:DD:]hh:mm[:[CC]YY]
-verbosity
verb_level -c
configuration file pointed
instead
configuration standard
file_path
the vo-specific configuration file pointed to by file_path
instead
the standard vo-specific configuration file. It is allowed only when used together with the –all one.
-config-vo
file_path

52. GLITE-JOB-STATUS status_value -exclude status_value -status
It returns the status information for all those jobs that are currently in the status specified by <status_value>
Possible status values are: SUBMITTED, WAITING, READY, SCHEDULED, RUNNING, DONE, ABORTED, CANCELLED, CLEARED -e
status_value
tag_name=
tag_value
-user-tag
It returns the status of the jobs that have been submitted with an associated tag named <tag name>whose value is <tag value> -o
It writes the bookkeping information in the file specified by file_path instead of the standard output.
file_path can be either a simple name or an absolute path (on the submitting machine).
file_path

53. GLITE-JOB-STATUS
-vo vo_name
It allows the user to specify the Virtual Organisation she/he is currently working for. If the user proxy contains VOMS extensions then the VO specified through this option is overridden by the default VO contained in the proxy (i.e. this option is only useful when working with non-VOMS proxies). The following rule is followed for determining the user’s VO:
the default VO from the user proxy
the VO specified through the –vo or –config-vo options
the VirtualOrganisation attribute in the JDL
 If none of the listed trials has success an error is returned and the submission is aborted. This option is allowed only when used together with the –all one.

54. GLITE-JOB-STATUS
-noint
every interactive question to the user is skipped. All warning and errors are written:
glite-job-status_<UID>_<PID>_<timestamp>.log
under the /tmp.
This information about the API functions are displayed on the standard output and are written to the file
glite-job-status_<UID>_<PID>_<timestamp>.log
under the /tmp.
-debug
this command is relocated to the location pointed by file_path
-logfile
file_path
-jobId
It must always be as last arguments.
If glite-job-status exits with a value of 0 in case of success and >0 in case of failure and <0 in case of partial failure

55. level 2 level 0 level 1 level 3 glite-job-status
It sets the detail level of information about the job
displayed to the user. Possible values for verb_level are 0,1,2 and 3. -v
verb_level
level 2
job Id            
Current Status  
job Id
Current Status
exit_code
Status Reason
Reached on
destination  
 cancelling - cancelReason
ce_node - children_hist
children_num - subjob_failed
condorId - cpuTime
expectUpdate - expectFrom
jobtype - lastUpdateTime
location - network_server
owner - resubmitted
jdl - matched_jdl
condor_jdl             -rsl
stateEnterTimes  
level 0
level 1
level 3

56. GLITE-JOB-CANCEL
It cancels a job. Before cancellation, it prompts the user for confirmation. The cancel request is sent to the Network Server that forwards it to the WM that fulfills it. It is not allowed to issue a cancel request for a node of a DAG: you have to cancel the whole DAG. Only the owner of the job can remove the job. Job states for which cancellation is allowed are:
Submitted
  Waiting
Ready
Scheduled
Running
Unknown

57. GLITE-JOB-CANCEL glite-job-cancel [options] <job Id(s)> -help
usage
-version
version
It cancels jobs/DAGs identified by the Ids contained in the file_path. It can’t be used neither if one or more Ids have been specified nor with the -all option. -i
file_path
-config
-output
-input
file_path -c
configuration file pointed
instead
configuration standard
file_path

58. GLITE-JOB-CANCEL
It cancels all job owned by the user. It can’t be used either if one or more Ids have been specified explicitly or with the -input option.
-all
The vo-specific configuration file pointed to by file_path is used instead of the standard vo-specific configuration file. This option is allowed only when used together with the –all one.
-config -vo
file_path
It allows the user to specify the Virtual Organisation she/he is currently working for. If the user proxy contains VOMS extensions then the VO specified through this option is overridden by the default VO contained in the proxy.
-vo

59. GLITE-JOB-CANCEL
-noint
every interactive question to the user is skipped. All warning and errors are written:
glite-job-cancel_<UID>_<PID>_<timestamp>.log
under the /tmp.
This information about the API functions are displayed on the standard output and are written to the file
glite-job-cancel_<UID>_<PID>_<timestamp>.log
under the /tmp.
-debug
this command is relocated to the location pointed by file_path
-logfile
file_path
-jobId
It must always be the last arguments.
If glite-job-cancel exits with a value of 0 in case of success and >0 in case of failure and <0 in case of partial failure

60. GLITE-JOB-GET-LOGGING-INFO
The job logging information are stored permanently by the Logging & Bookkeping service and can be retrieved also after the job has terminated its life-cycle, differently from the bookkeeping information that are in some way "consumed" by the user during the job existence.
For a DAG this returns events associated to the DAG. Logging information about the DAG nodes have to be quiered using the individual node identifiers. This request is sent to the LB service that queries the DB and returns the retrieved information. The most common information fields are:
Event
source
destination
result
timestamp

61. GLITE-JOB-GET-LOGGING-INFO
This option can be specified with four values, 0, 1, 2 and 3. The default level is 1. If there is the level of verbosity 0 only the events names are displayed while with 2 there are following additional information:
host
nsubjobs
dest_host
local_jobid
dest_instance
queue
user
status_code
dest_jobid
node ns

62. GLITE-JOB-GET-LOGGING-INFO
If there is the level verbosity 3, there are additional information,mostly consisting in the job description:
jdl
job
descr
classad
seqcode
level

63. GLITE-JOB-GET_LOGGING_INFO
glite-job-logging-info [options] <job Id(s)>
-help
usage
-version
version -i
file_path
It retrieves info for alls Ids contained in the file_path.
-vebosity
verb_level -v
It sets the detail level of information about the job displayed to the user
verb_level
-config
-output
-input
file_path -c
configuration file pointed
instead
configuration standard
file_path

64. GLITE-JOB-GET_LOGGING_INFO
It saves the retrieved state in the file specified by file_path. This can be either a simple name or an absolute path -o
file_path
-noint
every interactive question to the user is skipped. All warning and errors are written:
glite-job-logging_<UID>_<PID>_<timestamp>.log
under the /tmp.
This information about the API functions are displayed on the standard output and are written to the file
glite-job-logging_<UID>_<PID>_<timestamp>.log
under the /tmp.
-debug

65. GLITE-JOB-GET_LOGGING_INFO
this command is relocated to the location pointed by file_path
-logfile
file_path
-jobId
this must always be provided as last arguments for this command.
If glite-job-get logging-info exits with a value of 0 in case of success and >0 in case of failure and <0 in case of partial failure

66. GLITE-JOB-ATTACH
It attaches a listener to submitted interactive job and displays them on a dedicated window.
job-attach [options] <job Id>
-help
usage
-version
version
–port port_num -p
this starts a listener on the local machine on the specified port and logs these information to the Logging & Bokkeeping associated to the job. -p

67. GLITE-JOB-ATTACH
If the connection to UI node isn’t possible, the user can specify this option that provides a simple standard non-graphical interaction with the running job.
-nogui
This allows the user to interact with the job through her/his own tools. It is important to note that the WMS-UI has no more control over the launched listener process that has to be killed by the user.
-nolisten
–config
file_path -c
configuration file pointed
instead
configuration standard
file_path
–input
file_path

68. GLITE-JOB-ATTACH
It allows to select one of the jobIds contained in the file_path -i
file_path
-noint
every interactive question to the user is skipped. All warning and errors are written:
glite-job-attach_<UID>_<PID>_<timestamp>.log
under the /tmp.
This information about the API functions are displayed on the standard output and are written to the file
glite-job-attach_<UID>_<PID>_<timestamp>.log
under the /tmp.
-debug

69. GLITE-JOB-ATTACH
this command is relocated to the location pointed by file_path
-logfile
file_path
-jobId
this must always be provided as last arguments for this command.
If glite-job-attach exits with a value of 0 on success and >0 on failure.

70. GLITE-JOB-GET-CHKPT
It retrieves a checkpoint state. Checkpoint states are retrieved from the LB server. It can be used only for checkpointable jobs.
glite-job-get-chkpt [options] <job Id>
-help
usage
-version
version
-config
-output
-input
file_path
configuration file pointed
instead
configuration standard -c
file_path
last state_num saved if
the option is not used state_num = 0
-cs
state_num

71. GLITE-JOB-GET-CHKPT
It allows to select one of the jobIds contained in the file_path -i
file_path
It saves the retrieved state in the file specified by file_path. This can be either a simple name or an absolute path -o
file_path
every interactive question to the user is skipped. All warning and errors are written:
glite-job-attach_<UID>_<PID>_<timestamp>.log
under the /tmp.
-noint
This information about the API functions are displayed on the standard output and are written to the file
glite-job-attach_<UID>_<PID>_<timestamp>.log
under the /tmp.
-debug

72. GLITE-JOB-GET-CHKPT
this command is relocated to the location pointed by file_path
-logfile
file_path
-jobId
This must always be provided as last arguments for this command.
If glite-job-get-chkpt exits with a value of 0 on success and >0 on failure.

73. Command Sequence

74. Command Sequence
Voms-proxy-init

75. Command Sequence glite-job-list-match helloworld.jdl
It gets a list of available CE

76. Command Sequence glite-job-submit helloworld.jdl
It assigneds one id to job

77. Command Sequence
Job has terminated its execution

78. Command Sequence The output of Job is retrieved to WMS-UI path
directory

79. Command Sequence
location

80. Command Sequence
If there is a problem it’s possible to view the job related events

81. Command Sequence
If there is a problem it’s possible to cancel it

82. Guide from Client configuration description of request to to generated
output
run on a grid resource

83. Configuration
Configuration of the WMS UI is accomplished through the file:
directory
file
$GLITE_LOCATION/etc/<vo name>/glite_wmsui.conf
A Virtual Organisation (VO) comprises a set of individuals and/or institutions having direct access to computers, software, data, and other resources for collaborative problem-solving or other purposes. Virtual Organisations are a concept that supplies a context for operation of the Grid that can be used to associate users, their requests, and a set of resources. The sharing of resources in a VO is necessarily highly controlled.
$GLITE_LOCATION/etc/vo_template/glite_wmsui.conf +
New VO

84. Example [ VirtualOrganisation = "atlas";
V.O. [
VirtualOrganisation = "atlas";
NSAddresses = {
"ibm139.cnaf.infn.it:7772", "gundam.cnaf.infn.it:7772" }; LBAddresses = {{"ibm139.cnaf.infn.it:9000"},{"gundam.cnaf.infn.it:9000", "neo.datamat.it:9000", "grid003.ct.infn.it:9876"}
}; HLRLocation = "lilith.to.infn.it:56568:/C=IT/O=INFN/OU=Personal Certificate/L=Torino/CN=Andrea
= "skurut.cesnet.cz";LoggingDestination = "localhost:9002"; // local instance of LB logging service]
this is a string representing the name of the virtual organisation
Hostname:port
Network Servers
Group of Logging and Bookkeping
Distribuite load
Network Server

85. Example [ VirtualOrganisation = "atlas"; NSAddresses = {
"ibm139.cnaf.infn.it:7772", "gundam.cnaf.infn.it:7772" }; LBAddresses = {{"ibm139.cnaf.infn.it:9000"},{"gundam.cnaf.infn.it:9000", "neo.datamat.it:9000", "grid003.ct.infn.it:9876"}
}; HLRLocation = "lilith.to.infn.it:56568:/C=IT/O=INFN/OU=Personal
MyProxyServer = "skurut.cesnet.cz";LoggingDestination = "localhost:9002"; // local instance of LB logging service]
It’s responsible for managing the economic transactions and the accounts of user and resources
hostname:port:X509contactstring

86. Example [ VirtualOrganisation = "atlas"; NSAddresses = {
"ibm139.cnaf.infn.it:7772", "gundam.cnaf.infn.it:7772" }; LBAddresses = {{"ibm139.cnaf.infn.it:9000"},{"gundam.cnaf.infn.it:9000", "neo.datamat.it:9000", "grid003.ct.infn.it:9876"}
}; HLRLocation = "lilith.to.infn.it:56568:/C=IT/O=INFN/OU=Personal
MyProxyServer = "skurut.cesnet.cz";
LoggingDestination = "localhost:9002"; // local instance of LB logging service]
hostname

87. Example [ VirtualOrganisation = "atlas"; NSAddresses = {
"ibm139.cnaf.infn.it:7772", "gundam.cnaf.infn.it:7772" }; LBAddresses = {{"ibm139.cnaf.infn.it:9000"},{"gundam.cnaf.infn.it:9000", "neo.datamat.it:9000", "grid003.ct.infn.it:9876"}
}; HLRLocation = "lilith.to.infn.it:56568:/C=IT/O=INFN/OU=Personal
MyProxyServer = "skurut.cesnet.cz";
LoggingDestination = "localhost:9002"; // local instance of LB logging service]
It defines the address of the LB
Hostname:port