How to define the system disk logical to another one

[Song_Charles]

I have a question,
Could I define the system disk logical name to another one?
For example, after installation,the default logical name define to sys$sysdevice, could I add another logical name to system disk, such as "DRA0"?

B/R
Charles Song

[David B Sneddon · Accepted solution]

Charles,

You can define as many logicals as you wish to
point to the system disk (or any other disk).
Is this because of hard coded logicals in your
application?
Assuming that DRA0 is not a valid device on the
system then doing

$ define/system dra0 sys$sysdevice:

should work. You may also want to add /EXEC.

Dave

[Song_Charles]

Thank you,
I try and successfully.
Charles

[Mobeen_1]

Charles

Define/sys/exe dra0 sys$sysdevice:

should do the trick

By any chance if you do a mistake and need to delete the logical, then use the following

deassign/sys/exe sys$sysdevice

regards
Mobeen

[Antoniov.]

Hi Charles,
using define you can make a little joined filesystem, for example:
$ DEFINE/SYSTEM DRA0 DKA0:,DKA100:
in prior example every file accessed in DRA0 is searched in DKA0 and then in DKA100

Antonio Vigliotti

[Willem Grooters]

Mobeen


deassign/sys/exe sys$sysdevice


I wouldn't do that, for this, or any other SYS$-logical.
All these logicals are setup within the startup procedure, and I believe that quite some software relies on the existence of these logicals - and a proper definition.

There is not any proplem to make another logical (whatever one) referring to the very same device.

Willem

[Uwe Zessin]

Mobeen,

I don't think your advice is correct. With the 'define' command you create a logical name 'DRA0' in the system table with the equivalence name of 'SYS$SYSDEVICE:'. It will be the logical name translation services that first translate 'DRA0', find 'SYS$SYSDEVICE' and then translate this name unless you create a logical name with the /TRANSLATION_ATTRIBUTES=TERMINAL.

If you put a wrong equivalence string into 'DRA0', then you need to deassign this name! Or just do a new DEFINE command overwriting the previous assignment. You must not deassign the eqivalence string!!

You are lucky here, because the system will not have a logical name "SYS$SYSDEVICE:" (note the colon at the end):
$ deassign /system /executive_mode sys$sysdevice:
%SYSTEM-F-NOLOGNAM, no logical name match
$

[Jan van den Ende]

Charles,

like Willem wrote, you can define (nearly) as many logicals as you want, BUT (as David implied, but I want to stress that strongly):

Do NOT define a logical name that is also the device-name of ANY device in your system/cluster!

Willem already warned you NOT to deassign any SYS$ logical.
I would add to also NOT re-define any, unless you are VERY sure of what you are doing, and then, first do a VERY thorough testing on a system that is NOT important if it still has more consequences than you expect!

In short: SYS$ logicals are the heart of VMS, and tampering with them is like performing open-heart surgery. Leave it to specialised surgeons, or become one yourself.

Jan

[Anton van Ruitenbeek]

Charles,

I understand the question but I think you mean: How can I define another logical to the systemdisk ?
The logical SYS$SYSDEVICE cannot be moved.

AvR

[John Eerenberg]

Hi Charles,

Redefing sys$sysdevice is, as most have said, not a great idea.

Digital's naming convention is that the "$" is reserved to VMS. The "_" is reserved for us as system managers and in this case we can use it in place of the "$". So how about a
$ define/sys/exe sys_sysdevice "$1$dga101:,$1$dga102:,..."
?

The names are very similar so that is a draw back but it does adhere to naming standards for VMS.

Maybe that helps.

john

[Dima Bessonov]

Charles,

First of all: what are you going to do with that new logical? And why are you not satisfied with SYS$SYSDEVICE? Looks like you're trying to ask a rather specific question instead of asking a basic one. Are you an end user, an application programmer or a system manager? Depending on the particular situation, your question may have a LOT of answers.

Dima

PS And if you're a novice sysmgr, please be reasonably cautious and don't follow all advices in a moment.

[Willem Grooters]

Dmitry,

I don't know why but a reason could be using JAVA (or other Unix-based code) that is allergic for "$" in a filename.
I run into the same problem.
Even as an end-user I may want this. No problem to put it in the proces- or jobtable.

Willem

[Jan van den Ende]

Willem,

you got a BIG issue there!

Not pretending to have found the Holy Grail in one try, but....

Maybe, just maybe, we could work towards a more stuctural solution from here.

Proposal (Version 1.0; feasability study!)

( I think it requires to be adopted OR shot down by the Unix Portability people)

- Upon installing ANY ported software an inventarisation of ALL SYS$xxx logicals in aALL tables in LNM$SYSTEM_DIRECTORY is made.
- for all those logical names every "$" is replaced by "_"
- the value so achieved is tested; if it is NOT yet a logical name in its original table,
then it is checked for any "$" in the equivalence name, replacing those with "_" as well.
- this new name & translation get defined IN THE SAME TABLE.

-Upon starting ported software (or at login maybe.. needs evaluation) the same procedure for Process & Job lagical name tables.


Currently I see the following potential problems:
- devices with nodename$ or $alloclass$ prefix
- logical names with different translations in different tables (eg, Group & System table), where the rules above specify 1 to get its "$"-free analog, and the other does not. That MIGHT lead to different meanings being used, depending upon "$"-using or "_"-using translation.

At the job/process level: how about redefines after login?


Is there someone out there with enough knowledge, and, if positive, influence, to give this some deeper consideration?


-- just some friday afternoon philosofy --


Jan

[Willem Grooters]

Jan,

IMHO the BEST structural solution is to 'virtualize' OS-specific functionality so it will NOT be incorporated inside the code. That there will be incomptabilities is inavoidable, but this way you can limit them - or even bypass and take apporiate action. I'm in the process of thinking about a specification, it has been discussed in this forum in an earlier thread as well (foirgive me I didn't look it up but anyone is able to do that by themselves).

The biggest challenge will be to have the OS community adapt this. As we discussed yesterday, this will take a LOOOOOONG time - for several reasons.

(for the "outside" world: We are both a member of the Dutch Interex VMS-Sig and we had a meeting yesterday on Unix portability where these issues have been discussed as well)

What dows this have to do with the topic: Just THAT. As long as there is no 'common interest' we WILL have to take measures to overcome these difficulties. VMS is flexible enough to faciliate that without compromising the system itself (how lucky you can be!). But indeed, it should be solved in a more generic way.

Willem

[Antoniov.]

Hi Willem,

I don't know why but a reason could be using JAVA (or other Unix-based code) that is allergic for "$" in a filename.

unix people are allergic to "$" in filename simply because $ means macro substitution in various unix shell; same as '' in DCL.

Antonio Vigliotti

[Willem Grooters]

I know, Antonio.
But Unix is "allergic" to single quote as well.

Willem

[Lawrence Czlapinski]

Charels, I would be reluctant to use DRA0 even if it is not currently a valid device on your system. If the software ever gets moved to a system with a Raid Controler, DRA0 would become a valid device which could create confusion.
Lawrence

[Aleksander Sinigoj]

Yes, you can do this by

$ define/system/exec dra0 sys$sysdevice

or to define a logical to the device physical name of sys$sysdevice

$ define/system/exec dra0 'f$trnlnm("sys$sysdevice")'

[Jan van den Ende]

Aleksander,

That's playing with fire!
Firstly, any protected code wil NOT function, because it will not take into account any logical names in unsufficiently priviliged mod, ie, USERmode and SUPERVISOR mode logicala are NOT used.
Secondly, any concealed devices derived from SYS$SYSDEVICE (or its hardware name) will not function properly, if they function at all.

It will function for most software though, which makes the non-functioning stuff all the more surprising. And "surprises" are what we usually do NOT want...


Jan