DAL 1.3: Use With Different Oracle Process Names

I tried to install DAL 1.3 for ORACLE V6 on a VAX/VMS system for an evaluation period. In the installation manual it says that the ORACLE V6 processes should have the following names: ORA_DEMO_RMON, ORA_DEMO_SMON. I can't imagine a lot of sites using these names for the ORACLE processes of their production database. In the installation notes I couldn't find the necessary commands to type if you have other ORACLE process names, in order to get DAL to work. Can you give me some guidelines? The VMS process names in this particular case are: ORA_CIT_RMON, ORA_CIT_SMON.
When you install ORACLE 6.x, you are asked to name an SID for the instance. An SID is an instance's unique identifier. It's a one-to-size character that identifies the new instance. Oracle uses this SID in the names of the processes associated with that instance.

These names, however, don't change the way you start DAL to use ORACLE. The examples in the Installation Guide used the name DEMO, but you can use any SID you like.

On the VAX, you still use "idal" to try a connection to the ORACLE demonstration database.

The example you saw in the Installation Guide shows you how to check for ORACLE DBMS status. No matter what your SID name is, you still use the $ SHOW SYS command. These four processes should be in the list output by SHOW SYS.

If this doesn't work, access these tables using ORACLE's SQLPlus to see if it works. If it doesn't, check your ORACLE installation, startup procedure, and privileges of the account you are using.

By the way, DAL 1.2 and 1.3 have problems with Oracle 6.0.33 (6.0.32 and before are OK) because ORACLE stops defining the logical name SYS$ORACLE, which we need for DAL to work. To get around this, you can define the logical name for them in the MSAD$LOGICALS file. You should define SYS$ORACLE to be the value "ORA_RDBMS" and then things should work.

The symptom for this is subtle. You can open up the DBMS, but any attempt to open up a database causes the connection to go away. So it looks like it might be a networking or AppleTalk for VMS problem. It's actually the DAL server dying, because it assumes that value exists when it doesn't.
Published Date: Feb 18, 2012