AliBaBa: Running BaBar jobs on the grid using gsub AFS Access to local installations of BaBar M.A.S Jones, Roger J. Barlow, Alessandra Forti The University of Manchester We have created a lightweight (server and client) intuitive command line interface through which users can submit jobs with complex software dependencies. We have added functionality that is specific to Babar jobs. gsub solves the input/output sandbox issues by the use of a global file system, currently AFS. Alibaba uses Gridsite to keep track of each job and display the status of sites in that grid. gsub and Alibaba together provide a simple, easy-to-use grid submission and monitoring infrastructure that works and is currently being used by students and even professors for Particle Physics Analysis. 1 Introduction Babar[1] is a B Factory particle physics experiment at the Stanford Linear Accelerator Center. Data collected here are processed at four different Tier A computing centres round the world: SLAC (USA), CCIN2P3 (France), RAL (UK), Karlsruhe (Germany). Data is distributed to and research takes place at several institutes in the UK, all with designated Babar computing resources: the Rutherford Appleton Laboratory and the universities of Birmingham, Bristol, Brunel, Edinburgh, Liverpool, Manchester and Imperial College, Queen Mary and Royal Holloway, University of London. With this number of sites a grid is the obvious way to manage data analysis. The ideal view of job submission to a grid in this context is one where the user prepares an analysis code and small control deck and places this in an ‘input sandbox’. This is copied to the remote computer or file store. The code is executed reading from the input and writing its results to the ‘output sandbox’. The output sandbox is then copied back to the user. Babar is a real particle physics experiment, involving several hundred physicist users, that has accumulated many millions of events, filling many Terabytes of storage. This simple model does not match the actual analysis of Babar data in several respects. This is partly due to the simplicity of the model and its inadequacy to describe real world computing use patterns. It is also partly due to the history of Babar, as its pattern of working evolved in a pre-Grid, central computing environment. Firstly, a "job", as in a piece of work, will be split into hundreds (or even thousands) of "jobs", in the batch system sense of the term. On input a BaBar job needs to access the large event data files, which should be mounted locally to the platform the job is running on. Much of 'analysis' is filtering: an event is read, some (not many) calculations are done, some histograms may be updated and ntuples filled, and the processing moves