next up previous contents
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 up previous contents
Next: Differences from XCAT-SP Up: Command-line Previous: Command-line   Contents
Shava Smallen 2002-12-31