Zebra enhancement ideas ________________________ R.Raja 11-Aug-95 1)Protecting against Unprotected links in Zebra ____________________________________________________ One of the main objections to the Zebra is the occurrence of unprotected links. This is a self-inflicted wound in D0. It occurs mainly in muon and tracking codes. The calorimeter code uses the following system to protect itself against unprotected links. It puts all permanent links in its code in a common block called /ZLINKC/. This common block is declared to Zebra as a link area by a call to MZLINK. Any routine that uses a link, has this common block included in it. Instead of a declaration such as INTEGER LPELC LPELC = GZPELC() The code would have INCLUDE D0$INC:ZLINKC.INC LPELC = GZPELC() The INTEGER LPELC declaration is contained in the common block /ZLINKC/. This scheme can be imposed on tracking and muon code by inventing similar common blocks /ZLINKM/ and /ZLINKT/ with all the links declared. We would then write a scanning program that would go through all the code looking for occurrences of unprotected links and replacing them with the appropriate INCLUDE statement. This can also be done manually if preferred. An abbreviated version of /ZLINKC/ is given below. C---------------------------------------------------------------------- C- C- Created 2-MAY-1989 Rajendran Raja C- C---------------------------------------------------------------------- INTEGER LNKMX PARAMETER(LNKM X = 100 ) ! maximum number of links INTEGER CSTLNK ! Structural links INTEGER CRFLNK ! Reference links COMMON /ZLINKC/CSTLNK(LNKMX),CRFLNK(LNKMX) C C the user can add more links by equivalencing to CSTLNK,CRFLNK C arrays. C C INTEGER LCAD1,LCAD2 ! Structural links C... C INTEGER LMTRH,LCAPH INTEGER LPARH,LCACL INTEGER LCACH,LJETS INTEGER LJTSH,LJPTS INTEGER LPELC,LPPHO INTEGER LPNUT,LPVES INTEGER LBANK ! generic bank address C INTEGER LCAHTR,LCAPHR ! Reference links EQUIVALENCE (CSTLNK(1),LCAD1),(CSTLNK(2),LCAD2) C C... C EQUIVALENCE (CSTLNK(3),LHITS),(CSTLNK(4),LCAHT) EQUIVALENCE (CSTLNK(21),LPELC),(CSTLNK(22),LPPHO) EQUIVALENCE (CSTLNK(25),LPJET),(CSTLNK(26),LCMAP) EQUIVALENCE (CSTLNK(28),LFAKE),(CSTLNK(29),LGEAN) EQUIVALENCE (CSTLNK(31),LHMTE),(CSTLNK(32),LHMTP) EQUIVALENCE (CSTLNK(35),LPNUT1),(CSTLNK(36),LPNUT2) EQUIVALENCE (CSTLNK(38),LJNEP) EQUIVALENCE (CSTLNK(41),LZFIT) C EQUIVALENCE (CRFLNK(1),LCAHTR),(CRFLNK(2),LCAPHR) !REF LINKS ---------------------------------------------------------------------------- 2)Enhancement of .ZEB files Our ZEB files can be modified to contain more information. A clear improvement would be to add Mnemonic names for variables as well ranges of variables if needed. These mnemonics can then be used to build Fortran structures, NTUPLES or ADAMO entities from Zebra banks using a program. Another possibility is to convert the ZEB files to the DZDOC format. 3)Zebra Checker- Very often, the ZEB files are out of date and do not correspond to the banks in length or format. A program can easily be written to match the MZFORM info in the bank , with the ZEB file info. 4)DBANK should be enhanced to be platform independent. A version to be made available for Level 3 nodes as well. 5)ZBANK be enhanced to use the ZEB file information for formatting the print routines it writes. With the above modifications, most of the short comings of zebra can be circumvented. While it may not be as elegant as Object oriented schemes, in the long run, it is my view that the first priority of D0 is to write the upgrade tracking software and then to retrofit the rest of D0 software to the new scheme. I do not believe we have the skilled manpower needed to accomplish the huge task of essentially re-writing RECO and do the upgrade tracking software and improve all the ID algorithms as well in the proposed time frame.