Next: Differences from XCAT-SP
Up: Command-line
Previous: Command-line
  Contents
Specification
When constructing xbooks, users (i.e., programmers) need an environment
where they can quickly debug and develop their scripts. Often, users
will be running a xbook under a particular configuration (i.e., a set of
input parameters) when testing and debugging. Development can often be
slowed if the user has to use a GUI to construct the configuration they
need to test or debug a certain feature. Thus, we provide a command-line
interface to xbook managers so that a xbook configuration can be described
in a configuration file and invoked in a single command. The command-line
interface also provides a way for users to load a particular proxy and
resource file so that the portal environment can be emulated to provide
a realistic debugging and testing environment.
Furthermore, command-line clients allow for xbooks to be executed in
batch. This may sound counter-intuitive as why would you need a xbook at
all if you're launching a bunch of jobs in batch from the command-line?
However, a xbook is more than just a GUI job launching mechanism. It's also
a mechanism for monitoring jobs plus recording meta-data and data locations.
It is therefore useful for users to be able to launch a bunch of xbooks and
then monitor their progress and browse the output from a GUI interface.
An example of where there is useful is when a collaboration decides to
run a large set of Monte-Carlo jobs. This will be launched by one person
but the xbooks will be viewable by all members of the collaboration and so
they can monitor job progress and browse output too. Then if one member
finds a particular result interesting, they can run further, more refined
results (i.e., subxbooks) underneath the xbook that produced it.
Next: Differences from XCAT-SP
Up: Command-line
Previous: Command-line
  Contents
Shava Smallen
2002-12-31