01-09-2013 07:29 AM
I am trying to execute a DCL using java on a remote system, regretfully I have not been able to do it.
I want to run this java into a Win7 machine, so I have neither RSH nor SSH commands on the OS (and I cannot install them).
Could you help me?
Thanks in advance.
Solved! Go to Solution.
01-11-2013 12:12 AM
>> I am trying to execute a DCL [...]
> On what?
> tcpip show version
VACDM1$ tcpip show version
HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 2
on an AlphaServer DS10 617 MHz running OpenVMS V8.3
>> [...] using java on a remote system [...]
> This was not clear to me. Are you trying to run a Java program on a
>Windows (7) system? And this program should somehow run a DCL script on
>a remote VMS system, and get the results back from that?
Exactly that, I could go on without results back (but they are desirable).
>> I want to run this java into a Win7 machine, so I have neither RSH nor
>> SSH commands on the OS (and I cannot install them).
> How much other software can you not use on the Windows system?
I would like to use no other software but java API, however I could use whatever (if it is strictly necessary), but I want to avoid non corporative software and this is barely all existing software
>> [...] regretfully I have not been able to do it.
> Perhaps because you impose too many limitations on which software can
> I know little about Java, and even less about Java on Windows, so I
>don't know how difficult it would be to write a simple rsh or ssh client
>program in Java. There may be some other RPC scheme which could be
>used, but I'd guess that rsh/ssh would be the easy way. How about
>e-mail? FTP? You could send an e-mail message to a user on the VMS
>system, where a program like Deliver could receive it, process it, and
>send a reply of some kind. Or you could use FTP to transfer a file to
>the VMS system, where some program could observe it, process it, and
>send a reply of some kind. A "reply" here could be an e-mail message,
>or a new file created on the (VMS) FTP server, which the remote program
I thought about FTP, it is not what I would like to do, but if I find no other solution it will work.
I have never eard about "Deliver", but it sounds better than FTP.
> As usual, many things may be possible, but "and I cannot install
>them" makes it sound as if there are undisclosed constraints, so it's
>hard to know which good solutions you will reject, or which poor
>solutions you may be compelled to use instead.
>> Could you help me?
> Probably not much, at least not without a better description of the
>problem, and the constraints.
I am neither a java expertise, that’s the real problem, Maybe I should look the solution on a java forum, but I supposed that it’s easier to find a VMS expertise knowing java than a java expertise knowing VMS.
At any case options you gave me are perfectly valid (undesired, but valid), so thanks anyway!!
02-04-2013 09:25 AM
I have the solution for remotely executing a shell (Unix/OpenVMS/Windows) script using Perl. Refer to:
I have the solution to execute a DCL command local to the VMS computer using Java. Refer to:
If you are not strongly dependant upon Java, you may use the first URL.
If you are strongly bound to Java, you may translate the client/server Perl code to Java.
In the hope this helps.
02-04-2013 10:48 AM
>I have the solution to execute a DCL command local to the VMS computer using Java.
Issuing DCL commands from Java using the GNV dcl.exe wrapper was shown in this forum (or the previous incarnation of it) several times: http://h30499.www3.hp.com/t5/Languages-and-Scripti
And yes, DCL.EXE in sys$system is a totally different beast from the gnv wrapper dcl.exe usually installed in
02-06-2013 02:26 PM
If you are bound to Java and do not want to use the Perl solution, instead of using of interfacing the Java code wth the GNV provided DCL.EXE which has limits for possible DCL commands you can successsfully execute, may I rather orient toward this DCL.EXE solution at http://vouters.dyndns.org/tima/OpenVMS-GNV-Alterna
Unlike the GNV DCL.EXE solution which is mailboxes based, this DCL solution is based upon coupling a TNA device (acts as a terminal) with a BG device.
The real advantage is that, because it is based upon a terminal (TNA device), you can enter any DCL command which you can't through mailboxes.
For example you can't do this DCL command through mailboxes which you can via a TNA device based DCL.EXE:
$ dcl inquire name """"What is your name ?"""" what is your name ?: vouters Process PV_40090 logged out at 17-JUN-2011 20:31:49.85
02-07-2013 07:20 AM
02-07-2013 07:59 AM
Thanks for your explanations guiding the GNV DCL wrapper development. They are indeed welcomed and add a real plus.
You are indeed correct. The GVN DCL wrapper knows SYS$INPUT, SYS$OUTPUT and SYS$ERROR mailboxes whereas the TNA based DCL.EXE only knows SYS$INPUT and SYS$OUTPUT. This last limitation comes from a TCP/IP stream (the BG device associated with the TNA device) which only owns an input and an output stream.
So up to the original developer asking in this post to see which DCL.EXE can best fit his requirements.