T.R | Title | User | Personal Name | Date | Lines |
---|
745.1 | ALL-IN-1 takes 6 - 5 second waits | SHALOT::WARFORD | Richard Warford @OPA DTN 393-7495 | Fri May 22 1992 14:01 | 5 |
| ALL-IN-1 has a hard coded 30 second delay loop trying to get access to
a record in an RMS file. Sorry - without a patch I don't believe it
is possible to change.
Rick
|
745.2 | I just couldn't resist! | SHALOT::DUNCAN | Joe - CIS/EIC Doc. Mgmt. Solution Set Consultant | Fri May 22 1992 15:50 | 5 |
| Of course, if the data file were actually an Rdb table (or even an RMS
file access via RdbAccess for RMS), and you were using SRA to access
the data, you have control over the timeout interval used! ;-)
Joe Duncan @ OPA
|
745.3 | there is no 30 second timer | SKNNER::SKINNER | I'm doing my EARS | Fri May 22 1992 16:42 | 13 |
| Actually, the I/O timer for a locked record is 1 second, and is retried up to
10 times for a maximum of 10 seconds of delay from ALL-IN-1's I/O routines.
If RMS "imposes" a delay timer, then that delay (times the 10 retries) would be
added to ALL-IN-1's.
In looking at the VMS File Definition Language Facility manual (using
Bookreader) under CONNECT, it appears that you must set WAIT_FOR_RECORD before
the TIMEOUT_ENABLE/_PERIOD is honored. Did you? BTW, the Bookreader version
of this manual has the TIMEOUT_ENABLE/_PERIOD descriptions written very poorly,
as it implies that _ENABLE is a numeric attribute (it's not). I have no idea
if the paper version of the manual is different than the Bookreader version.
/Marty
|
745.4 | I'm sorry; there is | IOSG::SHOVE | Dave Shove -- REO-D/3C | Fri May 22 1992 16:57 | 6 |
| But there's also a bit of code in OARMS which explicitly sets the value
for the RMS timeout to 30 secs. As in:
RAB[RAB$B_TMO] = 30;
Dave.
|
745.8 | sorry for any misled readers | SKNNER::SKINNER | I'm doing my EARS | Fri May 22 1992 17:33 | 22 |
| I stand corrected. I didn't search the sources for the TMO value, but tried
to relay information I knew. My information was stale, and only related to
calls to the OAIO module, not OARMS.
There are no retries being done by ALL-IN-1 in the OARMS module, so whatever
value is stored in RAB$B_TMO is the only delay.
But looking at what has now been pointed out to me, how does the TMO value of
30 interrelate with .0's question? I presume that his explicit setting of 8
seconds is not considered. If so, why was this approach taken? If the file
"designer" can't get the desired features of the .FDL to be used, how can future
versions of ALL-IN-1 be coded so that they can? Perhaps by conditionalizing
the setting of RAB$B_TMO to only happen if the file doesn't have an explicit
setting?
One thing seems to be "missing" from ALL-IN-1: a central module/linker options
for setting "limiting" values such as this choice of 30, the number of SDAFs
and... Not that customers should feel encouraged to change these things, but
at least they could be patched more easily if the need arises as they would
be forced to have global names for the locations.
/Marty
|
745.10 | | COMICS::TALBOT | Trevor Talbot | Wed May 27 1992 18:03 | 5 |
| Officially logged,
SPR number is R11-51871 ...just in case you need to follow up.
-Trev
|