Two different machines, two different uses. The Vesta machine is where you might run things like Emacs, or Pine and everyone else does the same so it's not the place for any serious, CPU intensive work. The Morgan machines are might be a better choice for testing out AIX versions of GISMO or running short scripts, etc. xlsbatch does not open on a Vesta machine, you have to be on a Morgan to use this application. These are the only two machines I used for AIX work.
The Andrew File System is an authenticated global file system used here at SLAC. Give the site documentation a read it's well done. The 3 aspects of this system that I am familiar with are Authentification, AFS Space Requests, and Access Rights.
- Authentification
After you have applied for a Central UNIX account (see Ree Dufersune at the SLUO desk for one of those forms if you havn't filled one out yet) and have access to an NT box, start a Vesta xterm and issue tokens at the command line. You won't have one, the space will be empty. So issue klog and you will be prompted for your id and password, give them and you have the priviledges allotted that user.
- AFS Space Request
Make sure you can make good use of the mount points as they can't be changed. You're not stuck with the name you give the volume. Any renaming is an automatic alias for example, you request 200000 on gisdev and change the name to homebase, when you issue issue fs listquota homebase you'll get a quote for gisdev or the original name.
- Access Rights
The most useful was fs setacl [directory] [username] [permissions]. I gave richard write permission on everything really.
- a GNU product supported by Matt Langston
- visual interface: ddd (Data Display Debugger). Much nicer to use (although our version is getting old), motif touch and feel, current X-Win32 display is sufficient.
- commands (short list! see man page): command line driven as you might guess.
>> ddd [options] (program (core file))
I ran it without any options for the most part. Loading program file allows one to skip from frame to frame where the core contains only the frame that exited. This can be a drag given the modularity of GISMO.
>> bt: back-track (I think!)
pops commands in frame stack. eg. given a frame, bt 4 takes you back four commands in stack.
>> run: used only with program files (clearly)
If you have started ddd without specifying any file, run (program file) will load the symbols and run the specified app. If you initialized ddd with a program, run will know what's up.
>> break: set break points in the source
Initialize ddd with your program file and open the source window. Open the relevant source into that window and select the line you want to break. The break() button in the Source window takes the default source to be main.cxx so you must specify the file you want in the box ():.
eg. (): EMCalSystem.cxx : 25 will create a break point @ line 25.
>> snap to grid: a neat feature that allows graphical representation of data. Dereference pointers in this grid and get a bit of a tree which allows you to watch the data evolve in a frame.
There is much more to this package and it is probably the best debugger out there for UNIX. A new version might be nice, but GISMO is developed on NT anyway and probably won't be used much.
- a SLAC-only I think (ask Richard) supported by SCS unix administration
- visual interface to SCS batch farm and a nice alternative to bsub (see man page for bsub). It has a motif touch and feel, and current default X-Win32 display settings will suffice.
- commands: this guy is really easy to use
>> initialize: xlsbatch &
Notice the lack of any file argument. Just start it and let it check farm activity.
>> submitting a job: the LSF Batch environment
After LSF has returned control and a list of users, click Job/Submit... which will start another window and Filter the directory you called xlsbatch from. If you have a job script ready and waiting, Browse for it, Choose... a queue*, and Submit... It's that easy.
You will receive mail containing any program output and/or completion state. A successful completion is one that has Exited.
* bqueues at the xterm command line will list all the available queues and CPU times for each. You could also just just double click the queue name you of interest in the LSF Batch window. The resulting Queue Information window gives queue vitals and share status.
- an alternative to the LSF batch system is bsub.
If you really want to use bsub (and why would you given xlsbatch), the command line is:
bsub -q [name of queue] -o [name of output file] [script or program to submit]
issuing bsub with no arguments starts a bsub interactive session which I never had cause to use, see the man page (man bsub).
Have a look at any of ~/gisdev/gismo/jobs for an example of script syntax. This script will run the job with particular command line arguments (see State of NLD), convert the GISMO *.dat to a PAW ntuple using NTUPLER and convert that file to a root file using H2Root. The result will be an appropriately named *.hbook and *.root.
In order to use the farm you'll need a work directory /nfs/farm/work/[your user name here] for a GISMO output file at least:
>> issue mkdir /nfs/farm/work/[your user name here] on a Morgan (Vesta won't know where you mean)
- you might think of this as a scratch space analogous to that on VMS. You get 30 Mb (which I believe you can swap with a home directory it gets full but ask Richard) which is wiped after 7 days of inactivity (inactivity being no new file creation or accesses)
A GNU product and supported software here at SLAC. There are man pages for this software and g++ -v will give you the login command path.
- header files (.h, STL):
/afs/slac.stanford.edu/package/gcc/rs_aix41/lib/g++-include/2.7.2.2/
where std/ contains the "extended" library as of this release of g++. This version is old and does not support exception handling.
C.Colgur Last Updated: 01/13/04 12:57