Java version from script

[Attila Fekete_1]

Hi,

I would like to write a script which collect the Java version from other alpha nodes. To get TCP/IP version and other things I used rsh and it works. But with Java it doesn't put anything in the log file or it puts something strange.
I tried to put a com file on the node and run it with rsh, but it generated false output - other than run localy.
Does someone know a solution for that?

Thanks,
Attila

[Karl Rohwedder]

Since multiple versions may be installed, I fear there is no easy answer.

1. PROD SHO PROD JAVA* (via RSH) and parse the output

2. dir 'node'::sys$common:<000000>java$*.dir
(or F$SEARCH), but this assumes JAVA is installed in default directory

3. ana/ima/sele=ident -
'node'::SYS$COMMON:[JAVA$*.bin]java$java
and parse the output

[Attila Fekete_1]

Yeah, there are more version installed. Bevause of that I tried to run "java -version" and that's what doesn't work on remote node.

[Bojan Nemec]

Attila,

I try java - version and see that the version is written on sys$error. So you must do something like this:

$ define/user sys$error tmpfile
$ java -version
$ type tmpfile

or

$ define/user sys$error sys$output
$ java -version

to get the version on yours sys$output

Bojan

[Attila Fekete_1]

That's the problem. Here's the output runing that script localy:
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition
Fast VM (build 1.3.1-5, build J2SDK.v.1.3.1:11/21/2002-13:37, native threads, jit_131)
And runing from other node:
duna4$dka0:[sys0.syscommon.][sysexe]java.exe;1 version "1.1.8-5"

Duna4 is the node where I want to know the Java version. But the 1.1.8-5 Java is installed only on a third Alpha.

[Karl Rohwedder]

JAVA 1.1.8 was a sort of default version, installed in SYS$SYSTEM and activated via a DCL verb.
The newer version are installed in their separate subdirs of SYS$COMMON and are activated by specific JAVA-Setup procedures which define a lot of DCL symbols.

So just calling JAVA -version may give you an answer, but that is always 1.1.8 and it does not tell you what other versions are installed.

[Attila Fekete_1]

That's not the case Java 1.1 was never installed on Duna4. It was installed on another node, on our main server.

[Jan van den Ende · Accepted solution]

Attila,

that is what clustering is!
(assuming single system disk - multiple SD is somewhat more complex)
You --install-- the software ON THE SYSTEM DISK, from --any-- node, and then the software is available from ALL nodes; for installations that modify DCLTABLES (like Java 1.1.8 did, contrary to all other versions) the relevant verb(s) are active CLUSTERWIDE
(minor details:
-- only for processes logging in after the modification, or having done an explicit SET COMMAND;
-- only for the nodes using the same System Disk)

All other JAVA versions need to execute JAVA$SETUP to get the Java commands available - as SYMBOLS, NOT as COMMANDS.

And as long as the commands in DCLTABLES have not been explicitly removed or overwritten, THOSE are still active, with THEIR meaning, for any process that did NOT execute SETUP.

If you can get your inquiring programm to execute @SYS$STARTUP:JAVA$STARTUP on the target machine, you are home.


-- I hope this explains something.

Proost.

Have one on me.

Jan

[Attila Fekete_1]

This is not a cluster, all servers are standalone. (DunaX servers are test servers, Venus is our main server.)
The java startup file is run from the login script. I also tried to run it in the script file that is copied to the Alpha, but the result is the same.

[Willem Grooters]

The problem is that

$ java -version

will just return the THEN valid version of Java, wich has been set by running the appropiate JAVA setup script. vor 1.1.8, is was SYS$MANAGER:JAVA$SETUP.com, later version include the version in the name.
That means you'll need a commandprocedure to be executed by rsh to run this procedure AND the java command.

The easy way (well, easy) is indeed to scan SYS$SYSTEM for JAVA*.DIR, assuming it has been installed on the default location. You _may_ chech SYS$MANAGER for JAVA*SETUP.COM files, these will surely exist no matter where Java is installed. Then, eventually, execute it after which JAVA -VERSION will give you the right version number. But since the version number is in the directory name, you have your data regardless running Java.

(For an script: do you have TOMCAT installed? The startup script scans the JAVA versions and will use the latest found!)

Another way - which may require system privileges - is to scan the output of
$ PROD SHOW PRODUCT
where each installed java will show up as the installation kit comes as a PCSI file.

Also, what Jan explained: if JAVA is installed on it's default location (VMS$COMMON:[JAVA]) and the disk is a shared one, the installation will be shared by each node so you have to run it from one node only.

Willem

[Attila Fekete_1]

Thanks, this runing this java$setup helped. The problem will be to find out which version is valid.

Thanks again,
Attila

[Attila Fekete_1]

So Java$XXXstartup.com must be run before asking the version.