-COSI-I-NOTSYSCONCEAL, error

[Database Administrator]

Hello,

we are exploring Rdb for possible use within our organization.

One of the first problems I encountered was the following:

SQL> @SYSMGT:[BART]BANKING.SQL
%SQL-F-ERRCRESCH, Error creating database filename
eurobanking:banking.rdb
-RDB-F-SYS_REQUEST, error from system services request
-RDMS-F-FILACCERR, error parsing file
SYSMGT:[RDM$RUJ]BANKING$1E333AA0G0BQOH3MQ29LS6PF6O.RUJ;
-COSI-I-NOTSYSCONCEAL, non-system concealed device name in filename

(Yes, I am following the example in the Comprehensive Guide by Lilian
Hobbs, Ian Smith and Ken England!)

This topic already came up in 1997 in comp.databases.rdb, but then the
cause seemed to be something else.

It appears that Rdb does not accept a /EXEC logical name in
LNM$SYSCLUSTER_TABLE as a valid system concealed device. When I copied
the logical name SYSMGT to the LNM$SYSTEM_TABLE, the problem was
solved.

I find this rather disturbing. In my opinion, (and I believe in the
general opinion of OpenVMS engineering), logical names in
LNM$SYSCLUSTER_TABLE are just as valid as logical names in
LNM$SYSTEM_TABLE. After all, both are elements in the LNM$SYSTEM search
list!

Our clusters are configured in such a way that all logical names that
are common to all cluster members are placed in cluster wide tables. It
would be a pity if we would need to copy the contents of the
clusterwide table to the system table of each node.

Thanks for any thoughts!

Regards,

Bart Zorn

[Database Administrator]

Hi Bart,

It has been my experience that if you dare mention Rdb and "Cluster" in the
same sentence then Rdb support/engineering (and JCC in particular) are
likely to look upon you as a skid-mark on a hotel towel!

Having said that, cluster-wide logicals names are relatively new and IIRC
Rdb has been discouraging the use of concealed logicals since year dot+-2 so
why not just file a bug report. If you don't have a license agreement yet
then try an entry in the www.jcc.com listserver. Big Norm also wanders past
here every now and then so you may even get a useful reply :-)

Regards Richard Maher

wrote in message
news:1158053737.043991.174590@i3g2000cwc.googlegro ups.com...
> Hello,
>
> we are exploring Rdb for possible use within our organization.
>
> One of the first problems I encountered was the following:
>
> SQL> @SYSMGT:[BART]BANKING.SQL
> %SQL-F-ERRCRESCH, Error creating database filename
> eurobanking:banking.rdb
> -RDB-F-SYS_REQUEST, error from system services request
> -RDMS-F-FILACCERR, error parsing file
> SYSMGT:[RDM$RUJ]BANKING$1E333AA0G0BQOH3MQ29LS6PF6O.RUJ;
> -COSI-I-NOTSYSCONCEAL, non-system concealed device name in filename
>
> (Yes, I am following the example in the Comprehensive Guide by Lilian
> Hobbs, Ian Smith and Ken England!)
>
> This topic already came up in 1997 in comp.databases.rdb, but then the
> cause seemed to be something else.
>
> It appears that Rdb does not accept a /EXEC logical name in
> LNM$SYSCLUSTER_TABLE as a valid system concealed device. When I copied
> the logical name SYSMGT to the LNM$SYSTEM_TABLE, the problem was
> solved.
>
> I find this rather disturbing. In my opinion, (and I believe in the
> general opinion of OpenVMS engineering), logical names in
> LNM$SYSCLUSTER_TABLE are just as valid as logical names in
> LNM$SYSTEM_TABLE. After all, both are elements in the LNM$SYSTEM search
> list!
>
> Our clusters are configured in such a way that all logical names that
> are common to all cluster members are placed in cluster wide tables. It
> would be a pity if we would need to copy the contents of the
> clusterwide table to the system table of each node.
>
> Thanks for any thoughts!
>
> Regards,
>
> Bart Zorn
>

[Database Administrator]

Thanks Richard!

I will subscribe to the JCC list and post my question there.

Regards,

Bart

Richard Maher wrote:
> Hi Bart,
>
> It has been my experience that if you dare mention Rdb and "Cluster" in the
> same sentence then Rdb support/engineering (and JCC in particular) are
> likely to look upon you as a skid-mark on a hotel towel!
>
> Having said that, cluster-wide logicals names are relatively new and IIRC
> Rdb has been discouraging the use of concealed logicals since year dot+-2 so
> why not just file a bug report. If you don't have a license agreement yet
> then try an entry in the www.jcc.com listserver. Big Norm also wanders past
> here every now and then so you may even get a useful reply :-)
>
> Regards Richard Maher
>
> wrote in message
> news:1158053737.043991.174590@i3g2000cwc.googlegro ups.com...

[Database Administrator]

curious. please get in touch with Rdb support and log a call
here. It appears that there is code that explitly looks for
"LNM$SYSTEM_TABLE" when a concealed logical is found. I don't
think that this probably is the right check in this case.

The reason that the notsysconceal check is there is because
the user and the dbr (and I suspect potentially the monitor)
all have to have access to the RUJ file. I think though that
maybe this check could be enhanced in this case.

"Bart.Zorn@gmail.com" wrote:
>
> Hello,
>
> we are exploring Rdb for possible use within our organization.
>
> One of the first problems I encountered was the following:
>
> SQL> @SYSMGT:[BART]BANKING.SQL
> %SQL-F-ERRCRESCH, Error creating database filename
> eurobanking:banking.rdb
> -RDB-F-SYS_REQUEST, error from system services request
> -RDMS-F-FILACCERR, error parsing file
> SYSMGT:[RDM$RUJ]BANKING$1E333AA0G0BQOH3MQ29LS6PF6O.RUJ;
> -COSI-I-NOTSYSCONCEAL, non-system concealed device name in filename
>
> (Yes, I am following the example in the Comprehensive Guide by Lilian
> Hobbs, Ian Smith and Ken England!)
>
> This topic already came up in 1997 in comp.databases.rdb, but then the
> cause seemed to be something else.
>
> It appears that Rdb does not accept a /EXEC logical name in
> LNM$SYSCLUSTER_TABLE as a valid system concealed device. When I copied
> the logical name SYSMGT to the LNM$SYSTEM_TABLE, the problem was
> solved.
>
> I find this rather disturbing. In my opinion, (and I believe in the
> general opinion of OpenVMS engineering), logical names in
> LNM$SYSCLUSTER_TABLE are just as valid as logical names in
> LNM$SYSTEM_TABLE. After all, both are elements in the LNM$SYSTEM search
> list!
>
> Our clusters are configured in such a way that all logical names that
> are common to all cluster members are placed in cluster wide tables. It
> would be a pity if we would need to copy the contents of the
> clusterwide table to the system table of each node.
>
> Thanks for any thoughts!
>
> Regards,
>
> Bart Zorn

--
- - - - -
opinions expressed here are mine and mine alone
and certainly are not intended in any way to
express or represent any opinions or commitment
of oracle corporation.

norman lastovica / oracle rdb engineering

[Database Administrator]

Thanks, Norman.

Problem is that we don't have (yet) a service agreement with Oracle. Is
there any way to have this put on a bug list or something?

Bart

Norman Lastovica wrote:
> curious. please get in touch with Rdb support and log a call
> here. It appears that there is code that explitly looks for
> "LNM$SYSTEM_TABLE" when a concealed logical is found. I don't
> think that this probably is the right check in this case.
>
> The reason that the notsysconceal check is there is because
> the user and the dbr (and I suspect potentially the monitor)
> all have to have access to the RUJ file. I think though that
> maybe this check could be enhanced in this case.
>
> "Bart.Zorn@gmail.com" wrote:
> >

[ snip ... ]

> --
> - - - - -
> opinions expressed here are mine and mine alone
> and certainly are not intended in any way to
> express or represent any opinions or commitment
> of oracle corporation.
>
> norman lastovica / oracle rdb engineering

[Database Administrator]

"Bart.Zorn@gmail.com" wrote:
>
> Thanks, Norman.
>
> Problem is that we don't have (yet) a service agreement with Oracle.

got it. I hope that you do decide to get one.

>Is there any way to have this put on a bug list or something?

I've added it to an internal problem report. I suspect that
we'll try to get it addressed in the next rdb 72 release (unnamed
and not yet fully scheduled for release date).

>
> Bart
>
> Norman Lastovica wrote:
> > curious. please get in touch with Rdb support and log a call
> > here. It appears that there is code that explitly looks for
> > "LNM$SYSTEM_TABLE" when a concealed logical is found. I don't
> > think that this probably is the right check in this case.
> >
> > The reason that the notsysconceal check is there is because
> > the user and the dbr (and I suspect potentially the monitor)
> > all have to have access to the RUJ file. I think though that
> > maybe this check could be enhanced in this case.
> >
> > "Bart.Zorn@gmail.com" wrote:
> > >
>
> [ snip ... ]
>
> > --
> > - - - - -
> > opinions expressed here are mine and mine alone
> > and certainly are not intended in any way to
> > express or represent any opinions or commitment
> > of oracle corporation.
> >
> > norman lastovica / oracle rdb engineering

--
- - - - -
opinions expressed here are mine and mine alone
and certainly are not intended in any way to
express or represent any opinions or commitment
of oracle corporation.

norman lastovica / oracle rdb engineering

[Database Administrator]

Hi Norman,

Thanks!

And I share your hope!

Regards,

Bart

Norman Lastovica wrote:
> "Bart.Zorn@gmail.com" wrote:
> >
> > Thanks, Norman.
> >
> > Problem is that we don't have (yet) a service agreement with Oracle.
>
> got it. I hope that you do decide to get one.
>
> >Is there any way to have this put on a bug list or something?
>
> I've added it to an internal problem report. I suspect that
> we'll try to get it addressed in the next rdb 72 release (unnamed
> and not yet fully scheduled for release date).
>
> >
> > Bart
> >
> > Norman Lastovica wrote:
> > > curious. please get in touch with Rdb support and log a call
> > > here. It appears that there is code that explitly looks for
> > > "LNM$SYSTEM_TABLE" when a concealed logical is found. I don't
> > > think that this probably is the right check in this case.
> > >
> > > The reason that the notsysconceal check is there is because
> > > the user and the dbr (and I suspect potentially the monitor)
> > > all have to have access to the RUJ file. I think though that
> > > maybe this check could be enhanced in this case.
> > >
> > > "Bart.Zorn@gmail.com" wrote:
> > > >
> >
> > [ snip ... ]
> >
> > > --
> > > - - - - -
> > > opinions expressed here are mine and mine alone
> > > and certainly are not intended in any way to
> > > express or represent any opinions or commitment
> > > of oracle corporation.
> > >
> > > norman lastovica / oracle rdb engineering
>
> --
> - - - - -
> opinions expressed here are mine and mine alone
> and certainly are not intended in any way to
> express or represent any opinions or commitment
> of oracle corporation.
>
> norman lastovica / oracle rdb engineering