epics/epics-base
0
0
Fork 0
Code Issues Pull Requests Projects Wiki Activity

POD text updates to dbCommon and various record types

Browse Source
This commit is contained in:
Andrew Johnson
2021-08-10 20:35:19 -05:00
parent 72626cd5dd
commit 8175cc8e64
10 changed files with 197 additions and 136 deletions
Download Patch File Download Diff File Expand all files Collapse all files
modules/database/src/ioc/db/dbCommon.dbd.pod
+82 -71
View File
@@ -77,12 +77,12 @@ A set of periodic scan intervals
=back
Additional periodic scan rates may be defined for individual IOCs by making a
local copy of menuScan.dbd and adding more choices as required. Scan rates
should normally be defined in order, with the fastest rates appearing first.
Scan periods may now be specified in seconds, minutes, hours or Hertz/Hz, and
plural time units will also be accepted (seconds are used if no unit is
mentioned in the choice string). For example the rates given below are all
valid:
local copy of menuScan.dbd and adding more choices as required. Periodic scan
rates should normally be defined in order following the other scan types, with
the longest periods appearing first. Scan periods can be specified with a unit
string of C<second>/C<seconds>, C<minute>/C<minutes>, C<hour>/C<hours> or
C<Hertz>/C<Hz>. Seconds are used if no unit is included in the choice string.
For example these rates are all valid:
1 hour
0.5 hours
@@ -97,7 +97,7 @@ initialization (before the normal scan tasks are started).
The B<PHAS> field orders the records within a specific SCAN group. This is not
meaningful for passive records. All records of a specified phase are processed
before those with higher phase number. Whenever possible it is better to use
before those with higher phase number. It is generally better practice to use
linked passive records to enforce the order of processing rather than a phase
number.
@@ -109,23 +109,23 @@ The call to post_event is: post_event(short event_number).
The B<PRIO> field specifies the scheduling priority for processing records
with SCAN=C<I/O Event> and asynchronous record completion tasks.
The B<DISV> field specifies a "disable value". Record processing is
immediately terminated if the value of this field is equal to the value of the
DISA field, i.e. the record is disabled. Note that field values of a record
can be changed by database put or Channel Access, even if a record is
The B<DISV> field specifies a "disable value". Record processing cannot
begin when the value of this field is equal to the value of the DISA
field, meaning the record is disabled. Note that field values of a record
can be changed by database or Channel Access puts, even if the record is
disabled.
The B<DISA> field contains the value that is compared with DISV to determine
if the record is disabled. The value of the DISA field is obtained via SDIS if
SDIS is a database or channel access link. If SDIS is not a database or
channel access link, then DISA can be set via dbPutField or dbPutLink.
If the B<PROC> field of a record is written to, the record is processed.
The B<DISA> field contains the value that is compared with DISV to determine if
the record is disabled. A value is obtained for the DISA field from the B<SDIS>
link field before the IOC tries to process the record. If SDIS is not set, DISA
may be set by some other method to enable and disable the record.
The B<DISS> field defines the record's "disable severity". If this field is
not NO_ALARM and the record is disabled, the record will be put into alarm
with this severity and a status of DISABLE_ALARM.
If the B<PROC> field of a record is written to, the record is processed.
The B<LSET> field contains the lock set to which this record belongs. All
records linked in any way via input, output, or forward database links belong
to the same lock set. Lock sets are determined at IOC initialization time, and
@@ -135,15 +135,18 @@ The B<LCNT> field counts the number of times dbProcess finds the record active
during successive scans, i.e. PACT is TRUE. If dbProcess finds the record
active MAX_LOCK times (currently set to 10) it raises a SCAN_ALARM.
The B<PACT> field is TRUE while the record is being processed. For
The B<PACT> field is TRUE while the record is active (being processed). For
asynchronous records PACT can be TRUE from the time record processing is
started until the asynchronous completion occurs. As long as PACT is TRUE,
dbProcess will not call the record processing routine. See Application
Developers Guide for details on usage of PACT.
The B<FLNK> field is a database link to another record (the "target" record).
Processing a record with a specified FLNK field will force processing of the
target record, provided the target record's SCAN field is set to C<Passive>.
The B<FLNK> field is a link pointing to another record (the "target" record).
Processing a record with the FLNK field set will trigger processing of the
target record towards the end of processing the first record (but before PACT is
cleared), provided the target record's SCAN field is set to C<Passive>. If the
FLNK field is a Channel Access link it must point to the PROC field of the
target record.
The B<SPVT> field is for internal use by the scanning system.
@@ -236,35 +239,46 @@ The B<SPVT> field is for internal use by the scanning system.
=head3 Alarm Fields
These fields indicate the status and severity of alarms, or else determine the
Alarm fields indicate the status and severity of record alarms, or determine
how and when alarms are triggered. Of course, many records have alarm-related
fields not common to all records. These fields are listed and explained in the
fields not common to all records. Those fields are listed and explained in the
appropriate section on each record.
The B<STAT> field contains the current alarm status.
The B<SEVR> field contains the current alarm severity.
These two fields are seen outside database access. The B<NSTA> and B<NSEV>
fields are used by the database access, record support, and device support
routines to set new alarm status and severity values. Whenever any software
component discovers an alarm condition, it uses the following macro function:
recGblSetSevr(precord,new_status,new_severity) This ensures that the current
alarm severity is set equal to the highest outstanding alarm. The file alarm.h
defines all allowed alarm status and severity values.
The B<AMSG> string field may contain more detailed information about the alarm.
The STAT, SEVR and AMSG fields hold alarm information as seen outside of the
database. The B<NSTA>, B<NSEV> and B<NAMSG> fields are used during record
processing by the database access, record support, and device support routines
to set new alarm status and severity values and message text. Whenever any
software component discovers an alarm condition, it calls one of these routines
to register the alarm:
recGblSetSevr(precord, new_status, new_severity);
recGblSetSevrMsg(precord, new_status, new_severity, "Message", ...);
These check the current alarm severity and update the NSTA, NSEV and NAMSG
fields if appropriate so they always relate to the highest severity alarm seen
so far during record processing. The file alarm.h defines the allowed alarm
status and severity values. Towards the end of record processing these fields
are copied into the STAT, SEVR and AMSG fields and alarm monitors triggered.
The B<ACKS> field contains the highest unacknowledged alarm severity.
The B<ACKT> field specifies if it is necessary to acknowledge transient
The B<ACKT> field specifies whether it is necessary to acknowledge transient
alarms.
The B<UDF> indicates if the record's value is B<U>nB<D>eB<F>ined. Typically
this is caused by a failure in device support, the fact that the record has
never been processed, or that the VAL field currently contains a NaN (not a
number). UDF is initialized to TRUE at IOC initialization. Record and device
support routines which write to the VAL field are responsible for setting UDF.
The B<UDF> indicates if the record's value is B<U>nB<D>eB<F>ined. Typically this
is caused by a failure in device support, the fact that the record has never
been processed, or that the VAL field currently contains a NaN (not a number) or
Inf (Infinite) value. UDF defaults to TRUE but can be set in a database file.
Record and device support routines which write to the VAL field are generally
responsible for setting and clearing UDF.
=fields STAT, SEVR, NSTA, NSEV, ACKS, ACKT, UDF
=fields STAT, SEVR, AMSG, NSTA, NSEV, NAMSG, ACKS, ACKT, UDF
=cut
@@ -422,9 +436,11 @@ The B<DPVT> field is is for private use of the device support modules.
=head3 Debugging Fields
The B<TPRO> field is used for trace processing. If this field is non-zero a
message is printed whenever this record is processed, and when any other
record in the same lock-set is processed by a database link from this record.
The B<TPRO> field can be used to trace record processing. When this field is
non-zero and the record is processed, a trace message will be be printed for
this record and any other record in the same lock-set that is triggered by a
database link from this record. The trace message includes the name of the
thread doing the processing, and the name of the record being processed.
The B<BKPT> field indicates if there is a breakpoint set at this record. This
supports setting a debug breakpoint in the record processing. STEP through
@@ -435,32 +451,26 @@ database processing can be supported using this.
=head3 Miscellaneous Fields
The B<ASG> field contains a character string value defining the access
security group for this record. If left empty, the record is placed in group
DEFAULT.
The B<ASG> string field sets the name of the access security group used for this
record. If left empty, the record is placed in group C<DEFAULT>.
The B<ASP> field is a field for private use of the access security system.
The B<ASP> field is private for use by the access security system.
The B<DISP> field controls dbPutFields to this record which are normally
issued by channel access. If the field is set to TRUE all dbPutFields
directed to this record are ignored except to the field DISP itself.
The B<DISP> field controls whether puts from outside the IOC are allowed to
modify the fields of this record at all. If the field is set to TRUE all puts
directed to this record are ignored, except for puts to the field DISP itself.
The B<DTYP> field specifies the device type for the record. Each record type
has its own set of device support routines which are specified in
devSup.ASCII. If a record type does not have any associated device support,
DTYP and DSET are meaningless.
The B<DTYP> field specifies the device type for the record. Most record types
have their own set of device types which are specified in the IOC's database
definition file. If a record type does not call any device support routines,
the DTYP and DSET fields are not used.
The B<MLOK> field contains the monitor lock. The lock used by the monitor
routines when the monitor list is being used. The list is locked whenever
monitors are being scheduled, invoked, or when monitors are being added to or
removed from the list. This field is accessed only by the dbEvent routines.
The B<MLOK> field contains a mutex which is locked by the monitor routines in
dbEvent.c whenever the monitor list for this record is accessed.
The B<MLIS> field is the head of the list of monitors connected to this
The B<MLIS> field holds a linked list of client monitors connected to this
record. Each record support module is responsible for triggering monitors for
any fields that change as a result of record processing. Monitors are present
if mlis count is greater than zero. The call to trigger monitors is:
db_post_event(precord,&data,mask), where "mask" is some combination of
DBE_ALARM, DBE_VALUE, and DBE_LOG.
any fields that change as a result of record processing.
The B<PPN> field contains the address of a putNotify callback.
@@ -474,23 +484,24 @@ The B<RDES> field contains the address of dbRecordType
The B<RPRO> field specifies a reprocessing of the record when current
processing completes.
The B<TIME> field contains the time when this record was last processed in
standard format.
The B<TIME> field holds the time stamp when this record was last processed.
The B<UTAG> field can be used to hold a site-specific 64-bit User Tag value
that is associated with the record's time stamp.
The B<TSE> field indicates the mechanism to use to get the time stamp. '0' -
call get time as before '-1' - call the time stamp driver and use the best
source available. '-2' - the device support provides the time stamp from the
hardware. Values between 1-255 request the time of the last occurance of a
generalTime event.
source available. '-2' - the device support sets the time stamp and optional
user tag from the hardware. Values between 1-255 request the time of the last
occurance of a generalTime event.
The B<TSEL> field contains an input link for obtaining the time stamp. If this
link references the .TIME field of a record then the time stamp of the
referenced record becomes the time stamp for this record as well. In this
case, an internal flag is set and ".TIME" is then overwritten by ".VAL". If
any other field is referenced, the field value is read and stored in the .TSE
field which is then used to acquire a timestamp.
link points to the TIME field of a record then the time stamp and user tag of
that record are copied directly into this record (Channel Access links can only
copy the time stamp). If the link points to any other field, that field's value
is read and stored in the TSE field which is then used to acquire a time stamp.
=fields ASG, ASP, DISP, DTYP, MLOK, MLIS, PPN, PPNR, PUTF, RDES, RPRO, TIME, TSE, TSEL
=fields ASG, ASP, DISP, DTYP, MLOK, MLIS, PPN, PPNR, PUTF, RDES, RPRO, TIME, UTAG, TSE, TSEL
=cut
modules/database/src/std/rec/aiRecord.dbd.pod
+13 -1
View File
@@ -157,6 +157,10 @@ They do not affect the functioning of the record at all.
=over
=item *
NAME is the record's name, and can be useful when the PV name that a client
knows is an alias for the record.
=item *
DESC is a string that is usually used to briefly describe the record.
@@ -175,7 +179,10 @@ DOUBLE fields.
=back
=fields DESC, EGU, HOPR, LOPR, PREC
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more about the record name (NAME) and description (DESC) fields.
=fields NAME, DESC, EGU, HOPR, LOPR, PREC
=head3 Alarm Limits
@@ -198,6 +205,11 @@ positive number of seconds will delay the record going into or out of a minor
alarm severity or from minor to major severity until the input signal has been
in the alarm range for that number of seconds.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST, AFTC, LALM
=head3 Monitor Parameters
modules/database/src/std/rec/biRecord.dbd.pod
+4 -3
View File
@@ -102,9 +102,10 @@ C<MAJOR>. The ZSV field holds the severity for the zero state; OSV, for
the one state. COSV causes an alarm whenever the state changes between
0 and 1 and the severity is configured as MINOR or MAJOR.
See L<Alarm Specification> for a complete explanation of the discrete alarm
states. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related to alarms that are
common to all record types.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields ZSV, OSV, COSV
modules/database/src/std/rec/calcRecord.dbd.pod
+6 -3
View File
@@ -453,9 +453,12 @@ The following alarm parameters which are configured by the user, define the
limit alarms for the VAL field and the severity corresponding to those
conditions.
The HYST field defines an alarm deadband for each limit. See L<Alarm Specification>
for a complete explanation of alarms of these fields. L<Alarm Fields|dbCommonRecord/Alarm Fields>
lists other fields related to alarms that are common to all record types.
The HYST field defines an alarm deadband for each limit.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST
modules/database/src/std/rec/calcoutRecord.dbd.pod
+9 -7
View File
@@ -535,13 +535,13 @@ the user and which describes the values being operated upon. The string is
retrieved whenever the routine C<get_units()> is called. The EGU string is
solely for an operator's sake and does not have to be used.
The HOPR and LOPR fields on;y refer to the limits if the VAL, HIHI, HIGH,
The HOPR and LOPR fields only refer to the limits of the VAL, HIHI, HIGH,
LOW, and LOLO fields. PREC controls the precision of the VAL field.
=head4 Menu calcoutINAV
The INAV-INLV fields indicate the status of the link to the PVs specified
in the INPA-INPL fields, respectfully. These field can have four possible
in the INPA-INPL fields respectively. These fields can have four possible
values:
=menu calcoutINAV
@@ -568,7 +568,7 @@ The OUTV field indicates the status of the OUT link. If has the same
possible values as the INAV-INLV fields.
The CLCV and OLCV fields indicate the validity of the expression in the
CALC and OCAL fields respectfully. If the expression in invalid, the field
CALC and OCAL fields respectively. If the expression in invalid, the field
is set to one.
The DLYA field is set to one during the delay specified in ODLY.
@@ -590,10 +590,12 @@ The following alarm parameters, which are configured by the user, define the
limit alarms for the VAL field and the severity corresponding to those
conditions.
The HYST field defines an alarm deadband for each limit. See
L<Alarm Specification> for a complete explanation of alarms and these
fields. C<Alarm Fields> lists other fields related to alarms that are
common to all record types.
The HYST field defines an alarm deadband for each limit.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST
modules/database/src/std/rec/dfanoutRecord.dbd.pod
+30 -15
View File
@@ -90,23 +90,37 @@ Thus if SELN==5, OUTC and OUTA will be used.
=head3 Operator Display Parameters
These parameters are used to present meaningful data to the operator. They
display the value and other parameters of the data fanout record either
textually or graphically.
These parameters are used to present meaningful data to the operator.
They do not affect the functioning of the record at all.
The EGU field can contain a string of up to 16 characters describing the
value on the VAL field.
=over
The HOPR and LOPR fields determine the upper and lower display limits for
graphic displays and the upper and lower control limits for control
displays. They apply to the VAL, HIHI, HIGH, LOW, and LOLO fields. The
record support routines C<get_graphic_double()> and C<get_control_double()>
retrieve HOPR and LOPR.
=item *
NAME is the record's name, and can be useful when the PV name that a client
knows is an alias for the record.
=item *
DESC is a string that is usually used to briefly describe the record.
=item *
EGU is a string of up to 16 characters naming the engineering units that the VAL
field represents.
=item *
The HOPR and LOPR fields set the upper and lower display limits for the VAL,
HIHI, HIGH, LOW, and LOLO fields.
=item *
The PREC field determines the floating point precision (i.e. the number of
digits to show after the decimal point) with which to display VAL and the other
DOUBLE fields.
=back
See L<Fields Common to All Record Types|dbCommonRecord/Operator Display
Parameters> for more on the record name (NAME) and description (DESC) fields.
Parameters> for more about the record name (NAME) and description (DESC) fields.
=fields EGU, HOPR, LOPR, NAME, DESC
=fields NAME, DESC, EGU, HOPR, LOPR, PREC
=head3 Alarm Parameters
@@ -119,9 +133,10 @@ in the corresponding field (HHSV, LLSV, HSV, LSV) and can be either
NO_ALARM, MINOR, or MAJOR. In the hysteresis field (HYST) can be entered a
number which serves as the deadband on the limit alarms.
See L<Alarm Specification> for a complete explanation of alarms and these
fields. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related to alarms that are
common to all record types.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST
modules/database/src/std/rec/longoutRecord.dbd.pod
+10 -6
View File
@@ -172,13 +172,17 @@ record's output. The IVOA field specifies the action to take in this case.
The limit alarms are configured by the user in the HIHI, LOLO, HIGH, and LOW
fields using floating-point values. For each of these fields, there is a
corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR. The
HYST field contains the alarm deadband around each limit alarm.
corresponding severity field which can be either NO_ALARM, MINOR, or MAJOR.
See L<Alarm Specification> for a complete explanation of alarms and
these fields. For an explanation of the IVOA and IVOV fields, see L<Output
Records>. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
The HYST field sets an alarm deadband around each limit alarm.
For an explanation of the IVOA and IVOV fields, see
L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields HIHI, HIGH, LOW, LOLO, HHSV, HSV, LSV, LLSV, HYST, IVOA, IVOV
modules/database/src/std/rec/mbbiRecord.dbd.pod
+6 -3
View File
@@ -413,9 +413,12 @@ The change of state severity (COSV) field triggers an alarm when any change of
state occurs, if set to MAJOR or MINOR.
The other fields, when set to MAJOR or MINOR, trigger an alarm when VAL equals
the corresponding state. See the See L<Alarm Specification> for a complete
explanation of discrete alarms and these fields. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other
fields related to a alarms that are common to all record types.
the corresponding state.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields UNSV, COSV, ZRSV, ONSV, TWSV, THSV, FRSV, FVSV, SXSV, SVSV, EISV, NISV, TESV, ELSV, TVSV, TTSV, FTSV, FFSV
modules/database/src/std/rec/mbboDirectRecord.dbd.pod
+11 -7
View File
@@ -241,17 +241,21 @@ for more information on simulation mode and its fields.
=head3 Alarm Parameters
The possible alarm conditions for mbboDirect records are the SCAN, READ, and
INVALID alarms. The SCAN and READ alarms are not configurable by the user since
they are always of MAJOR severity. See L<Alarm Specification> for a complete
explanation of Scan and Read alarms.
INVALID alarms.
The IVOA field specifies an action to take when the INVALID alarm is triggered.
The IVOA field specifies an action to take when an INVALID alarm is triggered.
There are three possible actions: C<<< Continue normally >>>, C<<< Don't drive
outputs >>>, or C<<< Set output to IVOV >>>. When C<<< Set output to IVOV >>> is
specified and a INVALID alarm is triggered, the record will write the value in
the IVOV field to output. See L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields> for more
information. L<Alarm Fields|dbCommonRecord/Alarm Fields> lists the fields related to
alarms that are common to all record types.
the IVOV field to the output.
See L<Invalid Output Action Fields|dbCommonOutput/Invalid Output Action Fields>
for more information about IVOA and IVOV.
See L<Alarm Specification|https://docs.epics-controls.org/en/latest/guides/EPICS_Process_Database_Concepts.html#alarm-specification>
for a complete explanation of record alarms and of the standard fields.
L<Alarm Fields|dbCommonRecord/Alarm Fields> lists other fields related
to alarms that are common to all record types.
=fields IVOA, IVOV
modules/database/src/std/rec/seqRecord.dbd.pod
+26 -20
View File
@@ -107,8 +107,7 @@ processed, used in combination with the C<OFFS> field:
SELN = SELN + OFFS
I<(By default, the OFFS is initalized to ZERO)>
I<(By default, the OFFS field is initialized to ZERO)>
When B<C<SELM = Mask>> this field is the bitmask that will be used to determine
which links will be processed by the seq record,
@@ -119,7 +118,7 @@ in combination with the C<SHFT> field:
else
SELN = SELN >> SHFT
I<(By default, the SHFT is initalized to -1)>
I<(By default, the SHFT field is initialized to -1)>
=head4 B<Note about SHFT and OFFS fields>
@@ -131,7 +130,7 @@ The SHFT and OFFS fields were introduced to keep compatibility of old databases
that used seq records with links indexed from one.
B<To use the DO0, DOL0, LNK0, DLY0 fields when SELM = Mask, the SHFT field must
be set to ZERO>
be explicitly set to ZERO>
=head4 Selection Algorithms Description
@@ -208,29 +207,37 @@ Routine process implements the following algorithm:
=item 1.
First, PACT is set to TRUE, and the link selection is fetched. Depending on the
selection mechanism, the link selection output links are processed in order from
LNK0 to LNKF. When LNKI<x> is processed, the corresponding DLYI<x> value is
used to generate a delay via watchdog timer.
selection mechanism chosen, the appropriate set of link groups will be
processed. If multiple link groups need to be processed they are done in
increasing numerical order, from LNK0 to LNKF.
=item 2.
After DLYI<x> seconds have expired, the input value is fetched from DOI<x> (if
DOLI<x> is constant) or DOLI<x> (if DOLI<x> is a database link or channel
access link) and written to LNKI<x>.
When LNKI<x> is to be processed, the corresponding DLYI<x> value is first used
to generate the requested time delay, using the IOC's Callback subsystem to
perform subsequent operations. This means that although PACT remains TRUE, the
lockset that the sequence record belongs to will be unlocked for the duration of
the delay time (an unlock occurs even when the delay is zero).
=item 3.
When all links are completed, an asynchronous completion call back to dbProcess
is made (see the Application Developer's Guide for more information on
asynchronous processing.)
After DLYI<x> seconds have expired, the value in DOI<x> is saved locally and a
new value is read into DOI<x> through the link DOLI<x> (if the link is valid).
Next the record's timestamp is set, and the value in DOI<x> is written through
the LNKI<x> output link. If the value of DOI<x> was changed when it was read in
a monitor event is triggered on that field.
=item 4.
Then UDF is set to FALSE.
If any link groups remain to be processed, the next group is selected and the
operations for that group are executed again from step 2 above.
If the last link group has been processed, UDF is set to FALSE and the record's
timestamp is set.
=item 5.
Monitors are checked.
Monitors are posted on VAL and SELN.
=item 6.
@@ -238,12 +245,11 @@ The forward link is scanned, PACT is set FALSE, and the process routine returns.
=back
For the delay mechanism to operate properly, the record is processed
For the delay mechanism to operate properly, the record is normally processed
asynchronously. The only time the record will not be processed asynchronously is
when there are no non-NULL output links selected (i.e. when it has nothing to
do.) The processing of the links is done via callback tasks at the priority set
in the PRIO field in dbCommon (see the Application Developer's Guide for more
information on call
if it has nothing to do, because no link groups or only empty link groups are
selected for processing (groups where both DOLI<x> and LNKI<x> are unset or
contain only a constant value).
=cut