EPICS Home

Experimental Physics and Industrial Control System


 
1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: versioning ioc startup scripts for a control system
From: Johnny Tang <[email protected]>
Date: Sat, 11 Mar 95 19:08:51 EST
=============================================================
Johnny Tang     Voice: (804)249-7239  E-Mail: [email protected]
Continous Electron Beam Accelerator Facility
12000 Jefferson Avernue, MS 85A
Newport News, Va 23606
=============================================================
Mailer: Elm [revision: 70.85]


I would like to open a discussion on versioning ioc startup 
scripts for a control system. I will use CEBAF as an example
and summarize some of our thoughts on the issure. Any comments, 
suggestions or ideas are welcome and appreciated.

Problems:
1. Managing ioc startup scripts for a single ioc system is 
trivial. However, it become a little more complicated when 
there are multiple iocs and a different set of applications 
(like bpm, magnet, viewer etc.) may be loaded on each different 
iocs. Things even get worse when there are multiple versions of EPICS
systems and multiple versions of applications running among the iocs
in a control system. 

2. Ideally the EPICS system/application developers should test
their new developed codes on the fully simulated test iocs
and then install the codes on operational iocs. However in some
cases the fully simulation is away to expensive, so an operational
test-run for the new code is required. In case of the testing failure,
the previous operational version is required to be restored quickly. 
It is not always true you can determine a testing failure /success
within several minutes or hours.


Solution to the problem:
The problem described in 1 can be presented in a matrix form as
following:

Version_Tag[ ioc_inx, app_inx ]

ex.

	ioc1    ioc2    ioc3    ioc4   .....
epics   3.11a   3.11b   beta8   beta8  .....
bpm     4ch1.0  NULL    NULL    NULL   .....
rf      NULL    rf2.1   rf3.3   rf3.3  .....
fsd     fsd1.0  fsd1.0  fsd1.1  fsd1.1 .....

Each version of the matrix is a version of oprational ioc
startup scripts.

1. All applications are required to check into cvs with a tag
before install it onto operational iocs. One suggest is to
check out the application from CVS and build its operational
copy of database files and modules.
2. An GUI interface to represent the Version_Tag matrix and
a set of version selection choices are helpful to quickly
update the ioc startup scripts automaticlly.



Johnny Tang
Accelerator Software Control --- System Group
CEBAF

Navigate by Date:
Prev: Re: Reserved operand fault using CA on VMS Jeff Hill
Next: Work needing support Bob Dalesio
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Reserved operand fault using CA on VMS Jeff Hill
Next: Work needing support Bob Dalesio
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024