Reply To: Multiple Unix Users

[Richard Hart]

Gene.

I hope this helps

Cloverleaf software is installed as standard with user ‘hci’; user ‘hcimgr’ is in the same group as hci and we use this to create any sites that are possibly ‘shared’ by the developers, occasionally dev and always test and production sites.

We work on the AIX server and use the GUI’s from there – rarely use the client software as his restricts our work.

We use ‘sudo’ to login as user hcimgr from our own logins.  

We have a test server that runs test sites and developers own sites.

The production server has production servers and some ‘dummy’ sites used to prove code installation changes.

We connect Metro hospitals and generally have one Cloverleaf site for each type and connection

ie

we have one AHS site for each hospital that runs an AHS (Allied Health System) application.

We use our own monitoring that reports issues with the enterprise tool to Ops.  We have provided Ops with procedures and a menu that performs all useful actions.  We get a call if Ops cannot rectify the issue.

We use CVS to store all scripts/NetConfig files etc.

Almost all of our translation code is TCL – we have a library of ‘smart’ code so a translation of a segment (within a translation script) is quite simple [see below] – the ‘GlobCXT$HciConnName ‘gives access to local namspace and allows us to ‘pass’ the namespace, so library code has access to the namespace.

We also ensure that all scripts contain a version id that is printed at thread startup.

A typical migration will start with a developer performing the change and unit testing in their schema – usually with shell scripts

eg …

export TEST_THDNAME=top_prod_rp_adt_in

DAT=ccm_xlate_top.dat

OUT=ccm_xlate_top.out

ERR=ccm_xlate_top.err

hcitpstest -r run -a -L -f nl    -S -c sms_ib_data -e "" ./$DAT "ccm_xlate_top" > $OUT 2>$ERR

The code is migrated to test for user system testing and then onto prod.

We use Unix links so that all Cloverleaf sites of a particular type share the same TCL translation scripts. Our ‘upgrade’ process creates a separate directory for the code [the existing TCL scripts and the new script] and the upgrade script changes the Unix link to the new directory and bounces the thread and checks that the correct revision is installed.  A backout is simply the reverse of this.  The script handles all sites/threads and reports success/failure.

proc XlateMSH {aAllFields} {

   global HciConnName

       #

       # sending application

       #

   set myId 2

   set aAllFields [lreplace $aAllFields $myId $myId "TOP@[GlobCXT$HciConnName GET SITE]"]

       #

       # sending facility

       #

   set myId 3

   set aAllFields [lreplace $aAllFields $myId $myId  QDX]

       #

       # receiving application

       #

   set myId 4

   set aAllFields [lreplace $aAllFields $myId $myId "[GlobCXT$HciConnName GET MSHRCV]"]

       #

       # receiving facility

       #

   set myId 5

   set aAllFields [lreplace $aAllFields $myId $myId CCM]

....

       #

       # return the segment we have just created

       #

   return $aAllFields

}