Experimental Physics and
Industrial Control System

Matthias Clausen <[email protected]> · Sat, 03 Jul 2004 19:12:44 +0200

Andrew Johnson wrote:
Luedeke Andreas wrote:

at the SLS we upload the channels at boot time from the IOC to an
oracle table. This is done by a perl script running on the boot pc
started by the ioc using rsh, reading a file generated before by the
IOC using the dbl command. Not quite the portability you would like
to have for epics 3.14 applications: you need to save a file from the
IOC and you need to have an rsh mechanism.

The rsh mechanism is not essential if you arrange to have a program
running on the fileserver which is monitoring all of the dbl output
files; when it notices a change it triggers the update sequence. If
you're not so worried about short delays you could also just have a
cron job that periodically checks for updates. This might also be
more appropriate if the processing after a reboot can take a long time
to run, as you can limit how often the processing can be started.
Bear in mind that the list of PVs (i.e. CA Channel names) is not the
same as the output from dbl, which just gives you the record names. A
truly omniscient nameserver would also need to know the record type,
and the set of publicly accessible field names for that record type on
that particular IOC [don't forget that two IOCs that use two different
DBD files can have a different set of fields in the same record type,
you must make sure you're using the IOC's DBD file to be sure what
fields it will have]. A simple way to resolve this would be to dump
the DBD file at boot time as well as the dbl output.
It should be relatively straightforward to write some IOC-side code
which queries the database in memory using dbStaticLib routines, and
sends the results directly to the name server; I'm not aware of anyone
who has actually implemented something like this though. This code
would be able to resolve the field names issue without having to write
a parser to extract the DBD filename(s) from the st.cmd file.

I would be still interested to hear more about the straightforward way
Andrew mentions here.

Sending:

- the record name

- the record type

- the DBD files - but only if requested (as an option)

DBD files are not necessary if the database loaded has been created from
Oracle which generates databases with a certain set (version) of DBD
files. In other cases the DBD files might have a version number. The
little task on the IOC would only have to send the version number
(defined on the IOC as an env. variable) along with the record
names/type information.

Combining this little task on the IOC with the ca name server from Joan
Sage would add functionality to it. Connecting the ca name server to
Oracle(option) and adding an LDAP server(option) would complete the
picture many of us might have in mind.
-Matthias

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System