Where is the difference between ALPHA and IA64 version of OpenVMS?

[Dolezel Vaclav]

Hello,

On Alpha OpenVMS 7.3-2 this syntax is working:

HPA1:SYSTEM> run smhpa1::SYS$COMMON:[SYSEXE]mail.exe

You have 5 new messages.

MAIL>

On Itanium OpenVMS V8.3-1H1 is not working:

CZU1:SYSTEM> run smczu1::SYS$COMMON:[SYSEXE]mail.exe
%DCL-W-ACTIMAGE, error activating image SMCZU1::SYS$COMMON:[SYSEXE]MAIL.EXE
-CLI-E-IMGNAME, image file SMCZU1::SYS$COMMON:[SYSEXE]MAIL.EXE;1
-SYSTEM-E-INVFILFOROP, invalid file specification for operation

Why? Thanks for help.

[Jan van den Ende]

Vaclav,

firstly:

WELCOME to the VMS forum!

Your command:

>>>
run smhpa1::SYS$COMMON:[SYSEXE]mail.exe
<<<

is a request to run an image, which is present at the remote (DECnet) node SMCZU1

Obviously, SMCZU1 is an Alpha system, like the (7.3-2) node on which you are executing the command successfully.

Now, if you try yhis from an Itanium system, effectively you are trying to run an Alpha image on your Itanium system.
And while the command structure (and most other things) are very similar, the ==instruction set== (the hardware level instructions directly executable) is VERY different. And therefor, an Vax image does NOT run on Alpha nor Itanium, (in ANY combination of machine code and hardware).
That you can run the (well, almost) same program on the different hardwares, is because the different compilers generate VERY different executables!.

But, back to your underlying question:
If you want to run MAIL, why do you use the executable that is located at another node?
Why not simple use the local copy of MAIL.EXE? And even more, why not simple use the DCL MAIL command?
I -can- think of reasons, but in those cases I would expect you not to need to ask this question....

So, just do
$ MAIL
or, if you somehow redefined or disabled that and REALLY want ro RUN the .EXE directly,

$ RUN SYS$SYSTEM:MAIL

hth

Proost.

Have one on me.

jpe

[Karl Rohwedder]

Jan,

from the DCL prompt I would conclude he is trying to run the image from the local node via DECnet. And when trying to run an image from another architecture, the error message should be IMGACT-F-NOTNATIVE.

Perhaps SMCZU1 is a logical name?

regards Kalle

[Wim Van den Wyngaert]

Don't have Itanium over here but the ";1" in the error message could indicate that it found the exe but could not activate it.

Wim

[Jan van den Ende]

Kalle,

thank you, I missed that!

So, if it DOES work from Alpha, but not from IA64, the Invalid file spec seems to indicate that either DECnet is not running, or SMCZU1 is not (or not correctly) defined on the IA64; or the network is not functioning fully as expected....

But my previous answer still retains its value.

Proost.

Have one on me.

jpe

[Dolezel Vaclav]

Hi all,

DECnet on SMCZU1 is working well. The reason why i'm asking is, that i have a script which is correctly running on ALPHA and on IA64 is making this error. I'm starting image from specific place through sysman on several nodes. Not all nodes defined in sysman environment are in cluster.So the question is, why it's working on ALPHA and not on IA64. And of course IA64 image i'm trying to start on IA64 platform and ALPHA image on ALPHA platform. I just take mail.exe like example.

[Robert Gezelter]

Dolezel,

Running images over DECnet works, within certain limitations. While I am careful, I would be unsurprised if those limitations included issues such as layered products, similar versions (for privileged code), and others.

While I see that MAIL is just an example, my first question is: "Why run the image over DECnet?"

As to Itanium and Alpha, for the same versions, the behavior should be essentially identical. As I understand it (not having direct access to the master packs [smile]), both binaries are built from the same sources, with the exception of architecture dependent modules.

That said, more information about the environment would be helpful.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

And the ;1 is in the message ?

The sysman stuff is not related because you have the problem when you do run at the prompt and can simulate it ?

Wim

[Wim Van den Wyngaert]

If you copy the mail.exe file to the node on which you do the run and then run that image, does it work ?

Wim

[Jan van den Ende]

Vaclav,

Ah, MAIL is just an example.

Well, try my first suggestion: do the RUN without DECnet specifiaction. If necessary, (outside cluster) COPY the image over to the specified location. And in case of Alpha - Itanium, _DO_ compile the source on each platform!.

--- if MAIL was just an example, was SYS$COMMON:[SYSEXE] also "just an example"? Is the specified directory also valid over DECnet?
Try a
$ DIR SMCZU1::
Do you see the intended image, or also an error message?

Proost.

Have one on me.

jpe

[Willem Grooters]

'smczu1::' suggests you run the image over DECNet, and as other suggested already, it's not needed. Or even invalidated for certain situations.
What I can think of: is the node you specify (smhpa1 on Alpha, smczu1 on Itanium) the local machine? If not, it may hold such a clue.

Why messing around with normally available functionality like MAIL? Just $ MAIL will do the same witthout the problem.

What does SYS$COMMON refer to in yout Itanium configuration? What about SYS$LOGIN and SYS$DISK? Is there a file MAIL.MAI The error:

SYSTEM-E-INVFILFOROP, invalid file specification for operation

tells something is not right here. IIRC, VMSMAIL will look for a file MAIL.MAI in your login directory (SYS$LOGIN:):

MAIL.MAI;1 File ID: (31823,37,0)
Size: 36/36 Owner: [,]
Created: 29-JUN-2007 13:56:45.70
Revised: 17-OCT-2007 08:14:38.53 (7)
Expires:
Backup: 21-AUG-2008 19:20:11.96
Effective:
Recording:
File organization: Indexed, Prolog: 3, Using 2 keys
In 3 areas
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 36, Extend: 15, Maximum bucket size: 5, Global buffer count: 0, Version limit: 10
Contiguous best try
Record format: Variable length, maximum 2048 bytes, longest 0 bytes
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RW, Owner:RW, Group:, World:
Access Cntrl List: None
Client attributes: None

Total of 1 file, 36/36 blocks.

(Allocation and real size will vary, as will user UIC)

[x2084 · Accepted solution]

Yes, there is a difference. On Alpha it is allowed to activate an image which is on a remote node - via DECnet, on I64 this is not supported.

[Dolezel Vaclav]

To Hartmut Becker:

Is it official information which i can find somewhere in OpenVMS documentation?

[x2084]

Sorry, nothing "official".

For 8.3-1H1, this was supposed to be included in the DCL dictionary, but it was too late to get it in. As an alternative it was planned to have a note in the documentation-related release notes, but I can't find it, so I suspect it didn't make it.

New in 8.3-1H1 is the nice error message INVFILFOROP, the previous error messages on I64 were NOTFILEDEV and very often ACCVIO.

This "feature" was never supported on I64.
And, before you try it: running an I64 image from a tape is also not supported.

[Willem Grooters]

Hartmuth,

I'm not sure how many will use the possibility, it's quite neat to have an executable reside on one machine and run it from the other, even outside a cluster.
But is has been used before - given the original question.
What is the background of the removal?

[John Gillings]

>it's quite neat to have an executable
>reside on one machine and run it from the
>other, even outside a cluster.

It might be "neat" but it's a hideously inefficient way to activate an image, and there are numerous things that just plain don't work. For example, RUN/DEBUG has never, and most likely will never work for a remote image on any platform.

Consider also that read only code pages in a local image are directly mapped from the disk, so they can be paged in, rather than read. That's non-trivial for a remote image. Do you really want to do paging I/O across a network?

Support for activation of an images over DECnet has only ever been marginal, at best. It's a cute trick, but in a real production environment it's just plain silly. From a performance perspective you would be MUCH better off making a local copy of the image and executing it locally. Even if it's just a temporary copy. Incur the network overheads ONCE, rather than for every pagefault.

As images get larger and more complex, and DECnet fades into history, the engineering effort required to make network activation work could be much better spent improving more critical parts of OpenVMS.

[Dolezel Vaclav]

Thank you all for your time.

[x2084]

John said it all.

Add to it, that I64 aka Elf (object and) image files are not simple sequential files. There is an entry into the internal structure, the Elf header, which must be at the beginning of the file. Any other Elf structure or image data is pointed to and can be anywhere within the file.

Given the fact that this is only the second report on this "feature" I guess it is not very important for most customers.

Also, remote image activation is in a gray area. It "works" but - as far asI know - it was never officially listed as supported. And for those cases where it does/can not work it very likely will not be "fixed".

[Wim Van den Wyngaert]

Is a run of an exe on a NFS drive still supported ?

Wim

[x2084]

That looks more like a question for the vendor of the NFS client software.

On the client side an NFS served directory looks like a local disk. On VMS it is just an ODS2 or ODS5 disk. There is nothing special for the image activator, here. If something doesn't work, then either the NFS client lacks an Files11 feature or the NFS server can't handle a client request (or whatever the right term in that environment is).

[Hoff]

Wim, the NFS I/O path is very different from the DECnet File Access Listener (FAL) path. I'd tend to expect NFS to work here, as the NFS I/O path is different from the DECnet FAL path. That written, there exist no shortage weirdnesses in the NFS path; do try it.

Typical and standard virtual I/O operations should be able to read an image header or any other structure anywhere in the file, locally or remotely. (This is the basis for remote file access using DECnet FAL, and that works.) This accordingly looks to be a case of a particular I/O function or modifier that is being used in the OpenVMS I/O activation path, and particularly some operation that is incompatible with DECnet FAL.

You might be able to spot the particular operation with a SET FILE /WATCH FILE command.

[Wim Van den Wyngaert]

I would say that all the arguments against running remote images (John G.) also apply to NFS. Why not disable that too ?

BTW : it works under 7.3 even with debug (but didn't try features of it).

Wim

[x2084]

$ sh sys/full/noproc
OpenVMS V7.3-2 on node MYNODE 27-AUG-2008 13:31:29.95 Uptime 1 03:53:35
Digital Personal WorkStation
$ cc hello/deb
$ link hello/deb
$ copy hello.exe node.sub.sub.net"user password"::
$ run node.sub.sub.net"user password"::hello
%DEBUG-F-CANTGETMAINFID, cannot get file-id for the main image file opened on ch
annel 32
-SYSTEM-F-ACCVIO, access violation, reason mask=B0, virtual address=000000000000
001B, PC=0000000000000006, PS=00002604
%DEBUG-F-INITERR, an error has occurred during debugger initialization, unable t
o continue this session.
$

I can't explain what the debugger is up to. But in the image file the debug records are after the image sections and the image activator will only "place" the image sections into your process memory.

"Place" means, when activating from a local disk, depending on the type it tries to *map* a file based process section. In case of a remote (or tape) activation it *reads* all image sections into memory. Reading the image that way into memory is not implemented on I64.

[John Gillings]

re Wim,

>I would say that all the arguments against
>running remote images (John G.) also apply
>to NFS. Why not disable that too ?

Not quite. Yes, the performance argument still applies, you would be better off making a local copy and running from there, but the mechanism argument does not apply at all.

It's not a case of "disabling" anything - the exact opposite. It takes work to "enable" DECnet remote execution. NFS looks like a disk to OpenVMS, so anything that works on a disk works on NFS. There's no additional effort required to make image activation work, it just falls out of the mechanism. The only difference is in the performance of the I/O operations. If you're silly enough to execute an image from an NFS volume, you have to accept performance consequences.

In contrast, DECnet remote access does NOT look like a disk. It's more like a tape drive. Although you can wind backwards and forwards, it's not quite as simple as accessing a disk. Remote access of indexed files works (also subject to performance hits when rereading across the network), but in the IA64 case image activation isn't quite as simple, as Hartmut has outlined.

On VAX you could execute an image directly off a tape drive. Just because you "can" doesn't mean it's a sensible or desirable thing to do. It also doesn't mean VMS engineering should spend its limited resources making it work on Alpha and/or IA64.