Kbase 2893: S/E 43 or 609 on BTOS opening 6+ databases: THIS IS WHY
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
S/E 43 or 609 on BTOS opening 6+ databases: THIS IS WHY
920715-elp01
THE SYMPTOM:
Connecting to a sixth database in single user mode,
the user will get the PROGRESS error 43 or 609,
with the BTOS error code 214.
The PROGRESS error 43 indicates that a file
could not be opened/created.
The BTOS/CTOS status codes manual says the following
regarding the 214 error code
(which is TOTALLY misleading in this circumstance):
File Management: No free file number.
Open fewer files concurrently
or specify more File Control Blocks (FCBs)
and file user blocks (FUBs) per User Control Block
(UCB) at system build.
The user, after wasting lots of time trying to follow
this "advice" will call and complain that
regenerating his OS did not make a difference.
THE PROBLEM:
The problem has NOTHING TO DO WITH FCB's OR UCB's!
Currently there is a limit imposed by the BTOS C language
as to the number of files which
can be opened using the C language "open()" function.
This limit is hard coded at 20.
PROGRESS uses this function to open the database files:
.db, .lg, and .bi. It is also used to open the .cfg file,
the .env file, and the promsgs file.
The BTOS C functions maintain a fixed length array of
file descriptors, and connect to six databases simultaneouly
exceeds the capacity of this array.
THE VITALS:
We link with the BTOS C verion 1.1.0
THE WORKAROUND:
To fix the problem, the user will have to have the
BTOS C source installed on his machine.
The offending array, and hard-coded limit is in the file
"<BTOSCLIB>ctosio.c". This file will have to be altered,
recompiled, and then PROBUILD used to recreate the run-files.
In the file ctosio.c the definition of the constant NFDS
must be changed on line #19:
#define NFDS 20
to a number large enough for the number of databases
that the user expects to connect to, i.e.:
#define NFDS 50
Next, the array must be initialized for the correct
number of file descriptors. The array definition and
initialization begins on line #25:
static struct filedesc {
long fd_loc;
long fd_eof;
int fd_xfd;
} _fdesc_[NFDS] = {
{ 0, 0, -1 }, /* 0 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 5 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 10 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 15 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 19 */
};
This array should simply be extended so that all array elements are
initialized.
static struct filedesc {
long fd_loc;
long fd_eof;
int fd_xfd;
} _fdesc_[NFDS] = {
{ 0, 0, -1 }, /* 0 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 5 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 10 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 15 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 20 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 25 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 30 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 35 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 40 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 45 */
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 },
{ 0, 0, -1 }, /* 49 */
};
The user will have to create a link submit file
using PROBUILD for whatever runfiles he wants
to increase this limit to.
The modified file ctosio.c will have to be compiled,
and the object file manually added to the link submit.
Use the BTOS editor for this.
The link submit contains a list of object files to be
linked into the runfile. Add the new ctosio.obj anyplace
after the file "[sys]<BTOSC>c0l.obj".
THE SOLUTION:
A permanent solution has not yet been decided on as of 15 July 92.
Version 6.2g70 is the most recent commercial version. Version 6.2g71
is currently being tested by Technical Support for commercial release.
Because this problem has always existed, and has just recently been
called to our attention, we do not anticipate that many users will
have a problem with this limit. Therefore, our priority is to get
6.2g71 commercial, rather than fix this problem, and remake and retest
the 6.2g71 media masters.
The issue involved in a permanent fix, is that if we modify our version
of ctosio.c, then HLI and HLC users who link with their version will
have problems. If we write our own version of ctosio.c, and ship it
with the PROBUILD object files, then the PROBUILD database will have
to be modified and tested. Maintaining our own version of ctosio.c
is also not desirable because of the problem of merging any future
Unisys changes to this file, and the fact that the next version of
PROGRESS will likely be done using CTOS Microsoft C instead of BTOS C.
If the user does not have BTOS C, but he is up on the
most recent commercial version of BTOS/CTOS PROGRESS.
We can send him a run file with the number
of files cranked up.
Progress Software Technical Support Note # 2893