Experimental Physics and
Industrial Control System

[email protected] (Jim B. Kowalkowski) · Mon, 12 Feb 1996 08:05:26 -0600

Nick,

>> I feel that one of the important uses for this library is dbLoadRecords()
>> which runs on the IOC.  This tools should not be openning any more than one
>> file.  The substitions are required to be on the vxWorks command
>> line as they are today and nothing must be embedded in the ".db", except
>> the $(var) variables.  In other words, I feel that in many instances that
>> embedding substitution information at the top of files is not appropriate.
>
>Could some of this change with Marty's new stuff? What Marty hasn't got
>in his new system yet is variable substitution (at least, I can't see
>it in his December notes), but I gather he wants to do this by his
>response to this thread - then he can get rid of dbLoadTemplates as
>well as dbLoadRecords.

This is true, dbLoadRecords() and dbLoadTemplates() will go away.
However, the ascii read utility will provide the same capabilities as
the current dbLoadRecoreds() and dbLoadTemplates().  We have a large
group of people that use these utilities.

The parser in the new dbLoadAscii() function will be modified to accept
the ".db" file format, the dbLoadTemplates() file format, and recognize
substitution variables anywhere.  The advantage of this merger is that
we only need to support one parser instead of three.

> A suggestion is that we might have a database file fragment like the
> following:
>
> set gizmo telescope
> include "gizmo_database.db"
> set gizmo accelerator
> include "gizmo_database.db"
> 
> where gizmo_database.db contains:
> 
> record( ao, $(gizmo):output ) {
> .
> .
> .
> }
> 

What if the user is creating 300 instances of a ".db" file at boot
time and each instantiation required 6 variable changes?  With your
format, there would be 300*6 "set" statements and 300 include statements.
The format implies that the ".db" file will be opened 300 times.  As
we all know, there is significant overhead when openning a file under
vxWorks with ftp.  The current format of dbLoadTemplates() does not
imply an implementation, so the file could be openned once and parsed
300 times.  The current dbLoadTemplates() format also allows the
instances to be named - a feature that currently is not used by any tools
but might be useful in the future.  I think that the current dbLoadTemplates()
format is more readable in the case where there are many
instantiations and many variables.  At APS there are many cases where there
are 20+ variable that need to be set for an instantiation of a template.

#------with current dbLoadTemplates() format:
file gizmo_database.db
{
 i1{ pre=part1,parm=big,   alarm_limit=20, node=1, link=2, scan="1 second" }
 i2{ pre=part2,parm=medium,alarm_limit=30, node=2, link=2, scan=".1 second" }
 i3{ pre=part3,parm=medium,alarm_limit=30, node=3, link=1, scan=".5 second" }
 i4{ pre=part4,parm=small, alarm_limit=40, node=4, link=1, scan=".5 second" }
 .
 .
 .
 i300 { }
}

#------with your format:

set pre part1
set parm big
set alarm_limit 20
set node 1
set link 2
set scan "1 second"
include "gizmo_database.db"

set pre part2
set parm medium
set alarm_limit 30
set node 2
set link 1
set scan ".1 second"
include "gizmo_database.db"
.
.
.

where gizmo_database.db contains:

record( ao, $(pre):thing ) {
	field(SCAN,"$(scan)")
	field(HIHI,"$(alarm_limit)")
	field(OUT,"L$(link) N$(node)....")
	field(DESC,"$(parm)")
}

> This assumes the new keyword in the ascii database definition is "set"
> (it could be "define"). This would provide a mechanism similar to
> dbLoadTemplates, but not the same. I don't really like the
> dbLoadTemplates that much - it doesn't really extend to the new
> database system so well because it really has to be performed as a
> extra step.
> 

Why not support both formats?  I could see this format as being useful.
I place where it would be good it to reduce the amount the dbLoadxxxx()
statements in the vxWorks startup.cmd file.  With your format, a
standard startup.cmd script could contain one dbLoadxxxx(), where the
file it loads contains includes for each of the ".db" files required
in the IOC.

>>
>> I think it is important to retain a "substitution file" type of syntax
>> for tools such as dbLoadTemplates().  It permits the files that the
>> substitutions are being performed one to be unaware of how they are being
>> used.  I feel this is an important attribute.  I will argue this point
>> further if required.  Hopefully I'm not missing something in your proposed
>> design that allows these types of substitutions.
>
>I think you could arrange this by having a substitution file being an
>include file... i.e, you could have:
>
>include "telescope_substitutions.db"
>include "gizmo_database.db"
>include "accelerator_substitutions.db"
>include "gizmo_database.db"
>
>I don't think the macro mechanism itself has to know much about
>substitution files - that is up to the application.
>

This makes the situation I talked about above with the 300 instantiations
even worse.  Now you are forcing 600 file opens.  In addition, if I am
understanding you correctly, the user files would look like this:

# ------- instance 1 substitutions file --------
set pre part1
set parm big
set alarm_limit 20
set node 1
set link 2
set scan "1 second"

# ------- instance 2 substitutions file --------
set pre part2
set parm medium
set alarm_limit 30
set node 2
set link 1
set scan ".1 second"

.
.
.
# ------- instance 300 substitutions file --------

Now the user needs to maintain 300 files.  Tell me if there is something
I am misunderstanding.

Jim Kowalkowski

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System