HKitter, and EPICURE Directory Organization
D.S. Baddorf
The time has come to begin software installations via HKitter. This document details hkit pieces and describes the files that must be provided by the responsible system parties. The directory organization on the target node is discussed and diagrammed.
All updates to products will be done by Deb Baddorf. All files currently in epicuretest areas should be in the new directory tree. Once they have found a new home, the epicuretest area will be deleted. (This will happen in early January.) This will allow for `EOPERATOR' accounts to be established on all front-ends and Disney nodes, so that users can restart system pieces which have stopped for some reason.
Test front-ends ``BUGS'' and ``CYTST'' will still have [DAEWORK...] areas where test versions may be kept. These areas will still be managed by front-end developers. However, they will also have EOPERATOR accounts which will allow the tester to bring up an operating environment on a test machine.
What follows is a description of what the hkitter does, and the files it needs. Logicals describing where files should reside (on non-WARNER nodes) are discussed. The current setup files (*.FILES) for projects DAR, DBSRV, EPICURE, LIBRARY, and MONITOR are appended at the end. Please check the files for products you are responsible for to assure that they are correct and complete.
You should continue to CMS all pertinent files on WARNER prior to the hkit manager's distributing them. The purpose of hkitter is to assure consistency across systems and to allow a single operator environment to be presented for the purposes of restarting a system. No file on a front-end, test, or DISNEY node should be the only copy. These nodes should be expendable. All needed files, backups, old executables for retreating to, etc should be on WARNER, preferably in CMS. All other nodes should always contain the lastest released code versions. We can no longer consider our nodes to be test environments, but rather released product environments.
HKitter is an automated `product' assembler. It does not build the files, so you must have .EXE files and all needed startup files, shutdown files, etc in a known place for the HKitter to find them.
Files needed by HKitter's BUILD_KIT.COM:
The <product>.FILES file tells the hkitter what files to assemble together into a kit. Names are made from the shortened form of the product name. Currently, we have EPICURE.FILES, LIB.FILES, DA.FILES (for DAR), PEEK.FILES (for Ed's RPEEK.EXE in work area MONITOR). There is a DB.FILES, but the contents have never been verified. I'll discuss the contents of these files with the programmers responsible.
The lines in <product>.FILES and what they tell the kitter to do:
%PROJECT name
input-file-spec [output-file]
The output name defaults to input name.
%CMS input-element-spec [output-file]
The output name defaults to input name.
%SAVE_SET B
The save set is initially A. Only A,B,and C are allowed currently.
Once you've closed a set (by starting the next lettered set)
you cannot refer to the first set again. I.E. No backing up.
Sets must be used in alphabetical order.
An example of a very short xxx.FILES file:
! .FILES for Ed's PEEK / MONITOR
%PROJECT monitor
rpeek.exe
peek_startup.hkit peek_startup.com
peek_shutdown.hkit peek_shutdown.com
The first line is a comment. The second line is the equivalent of
``WORK MONITOR''. The third line says to copy (from the
EPICURE_ROOT:[WORK.MONITOR] area) file RPEEK.EXE. The last
two lines say to copy a startup and shutdown file, but to rename
them to *.COM during the copy. Thus the three files specified
(RPEEK.EXE, PEEK_STARTUP.COM, PEEK_SHUTDOWN.COM) will comprise
the HKit for product PEEK. These are all the files which are needed
to run this product.
An example of usage of logicals, subdirectories and CMS:
! mixture of several files.
! This is an example only.
epicure_inc:dbuser.h
epicure_inc:ftd.h
%PROJECT library
%CMS epicurelink.opt
%CMS lib_startup.hkit lib_startup.com
%CMS lib_shutdown.hkit lib_shutdown.com
%PROJECT dar
aaareadme.txt
[.server]da_startup.hkit da_startup.com
Product specific questions and checks go in this optional command file. Ex: check that the system has enough resources to allow DAR's global section. Any checks that can be dones in DCL can probably be done in this file, but the syntax must be what VMSINSTAL expects. Deb can help if you need to provide a CHECKS.COM file. If your CHECKS.COM file does not check for disk space available, or if you don't supply a CHECKS.COM file at all, BUILD_KIT creates a few lines to do so. It looks at the space currently in use by all the kit pieces just before it puts the save-set together, and inserts a check for that much space.
KITINSTAL.COM can be created if you need to put files anywhere other than the default area, EPICURE<product>$ROOT:[SYSTEM] (discussed later). Most products don't need to supply a KITINSTAL.COM file, so the generic version is used. Talk to Deb if you think you need this.
The following logicals are available for programmers and programs to use to access files. See also the directory tree diagram which follows.
The file EPICURE$ROOT:[SYSTEM]PRSTARTUP.COM will startup up all other EPICURE products in the correct order, by calling the <product>_startup.com files from each resident product. File EPICURE$ROOT:[SYSTEM]PRSHUTDOWN.COM will call all products' shutdown files in the correct order.
EPICURE directory structure:
EPICURE | +----------------+------------+-+--------------+------------------ | | | | [.SYS0] ... [.SYSn] [.DATABASE] [.product_Vn_m] ... section | one per node files | in cluster, | for .LOG files | +----------------------+------+ | | [.COM] [.SYSTEM] setup.com * prstartup.com * product.bul * prshutdown.com * product.hlp * xxx_startup.com xxx_shutdown.com ...prod specific files
* KITINSTAL.COM creates these (required by the computing department). Except for the ones under product=EPICURE, they don't do anything. The real files are `xxx_startup.com' and `xxx_shutdown.com', where the xxx means <product>, as in the logical names.
Keywords: Epicure, program
Distribution: normal
Current contents of <product>.FILES files:
EPICURE_ROOT:[WORK.HKITTER.FILES]DA.FILES %PROJECT dar [.server]darinit.exe [.server]darserver.exe [.server]small_darinit.params [.server]large_darinit.params [.server]delgblsect.exe aaareadme.txt [.server]da_startup.hkit da_startup.com [.server]da_shutdown.hkit da_shutdown.com [.server]checks.hkit checks.comEPICURE_ROOT:[WORK.HKITTER.FILES]DB.FILES %PROJECT dbsrv dbserver.exe %CMS db_startup.hkit db_startup.com %CMS db_shutdown.hkit db_shutdown.com kit_files:kitinstal.db kitinstal.com !DBPEEKER needs to be added in here somewhere %SAVE_SET B oa_devices.sec oa_hash.sec oa_shared.sec
EPICURE_ROOT:[WORK.HKITTER.FILES]EPICURE.FILES kit_files:kitinstal.epicure kitinstal.com kit_files:prstartup.com kit_files:prshutdown.com kit_files:shutdown_proc.com kit_files:epicure_startup.com kit_files:epicure_shutdown.com %PROJECT ess essshr.exe %SAVE_SET B rdcs$lib:epicuremsg.exe
EPICURE_ROOT:[WORK.HKITTER.FILES]LIB.FILES rdcs$doc:epicurelib.tex rdcs$doc:epicurelib.rno rdcs$lib:epicurelib.olb epicure_inc:dbuser.for epicure_inc:dbuser.h epicure_inc:ftd.h %PROJECT library %CMS epicurelink.opt %CMS lib_startup.hkit lib_startup.com %CMS lib_shutdown.hkit lib_shutdown.com
EPICURE_ROOT:[WORK.HKITTER.FILES]PEEK.FILES %PROJECT monitor rpeek.exe peek_startup.hkit peek_startup.com peek_shutdown.hkit peek_shutdown.com
Keywords: Epicure, program
Distribution: normal