1752778 Members
5922 Online
108789 Solutions
New Discussion юеВ

DECnet COPY problems

 
SOLVED
Go to solution
Robert Manning_2
Valued Contributor

DECnet COPY problems

Hi,

I have a question:

How can I automate a DECnet COPY operation between a VMS (VAX 5.5-4) server and a UNIX (flavour unknown)box?

A user has a requirement to pull files at 0600 each day and have the process resubmit. FTP isn't an option as the UNIX system only has DECnet.

A direct copy using RCP to pull the files from the UNIX platform works fine, and we can run a script containing the command without difficulty, but the job fails when submitted to a batch queue. I haven't used RCP much but it looks as though it's only supposed to be used interactively.

If anyone can suggest the best way to proceed, I'd welcome the advice.

Thanks,

Bob
20 REPLIES 20
Robert_Boyd
Respected Contributor

Re: DECnet COPY problems

Bob,

It's difficult to respond to "the job fails" without specific details about what commands are in the job and what the specific failure(s) are.

Please provide more detail about which commands you're using in the job and what the specific error messages and/or results are.

Is the batch job running with the same privileges and quotas as the interactive user?

Robert
Master you were right about 1 thing -- the negotiations were SHORT!
Richard Whalen
Honored Contributor

Re: DECnet COPY problems

It seems pretty unusual for a Unix box to have DECnet and NOT TCP/IP.
RCP is usually a TCP/IP operation.
Robert Gezelter
Honored Contributor

Re: DECnet COPY problems

Bob,

Running a batch job at 0600 each day is not a problem. The only issue that I can see is a reasonably secure way to provide the login password for inclusion in the remote DECnet access string.

I too find it unusual to have any UNIX system without IP, particularly if RCP works.

Please confirm the identity of the UNIX system, and what OS it is running.

- Bob Gezelter, http://www.rlgsc.com
labadie_1
Honored Contributor

Re: DECnet COPY problems

Sun has the only Decnet stack I know, it used to have (Sun OS I think, not Solaris) DNI something, which was a small Decnet.

John Gillings
Honored Contributor

Re: DECnet COPY problems

>RCP much but it looks as though it's only
>supposed to be used interactively.

This is NOT the case. You can use RCP in a procedure, which can be executed in batch. The simplest way to make it work is with communication proxies between the hosts. Please post your exact RCP command, and the resulting error message.

Note that RCP is a TCPIP utility, so if it works at all, your unix system must be running TCPIP.
A crucible of informative mistakes
Steven Schweda
Honored Contributor

Re: DECnet COPY problems

> [...] DNI something [...]

SunLink DNI.

Tru64, too, I gather, but it was not included
in the Non-Commercial Tru64 package, and info
from HP seems to be pretty well hidden, so it
may be about as dead as SunLink DNI.


Note that "UNIX (flavour unknown)" is about
as useful a description of a system as "the
job fails" is a description of a problem.
And saying that some secret script fails in
only some circumstances is easy to believe,
but difficult to analyze with no information
on what's in the script or exactly how it was
"submitted to a batch queue".

Also, assuming that IP networking is actually
involved here ("rcp"), VMS V5.x could have IP
software from any of several vendors, and it
might help to know which one.

Also, I don't recall a VMS version V5.5-4.

> [...] the best way to proceed [...]

Start over with a precise, accurate
description of what you're doing, with what
you're doing it, and what happens when you do
it?
Robert Manning_2
Valued Contributor

Re: DECnet COPY problems

Okay, thanks for the replies and my apologies for the lack of detail - I was concerned more with getting my head around the concept than with the solution.

Anyway, to explain what's happening:

The VMS user AECSYS pulls a file from UNIX system DUBL01 using the user credential XXxx, renaming the file as part of the process.

This is the command:

rcp 50.300::4:/run/reports/irlstat.000 REPORTS:[SCRATCH]lsm1stat000.txt "u=XXxx" p=xxx +a

The username in this case has been masked, but does contain two uppercase and two lowercase characters as shown.

When run interactively, the command works.

When executed as part of a COM file, it works. However if submitted as a batch, it fails with the error

%DCL-W-PARMDEL, invalid parameter delimiter - check use of special characters
\:\

This, to me, would suggest a syntax problem but we were unable to track it down.

The command script and batch log are attached. The resubmit command has been commented on purpose and is reflected in the log.

And in response to your comments:

Robert B - the batch job is run under the same account that runs the interactive command, so privs and quotas will be the same.

Richard - I agree, but the user is adamant that no TCPIP services or addresses are configured on the UNIX server. It connects to the network through an AUI adapter.

Robert G - the user's happy enough to code the login password in his command, so that's okay.

The UNIX server is running something called QNX 2.0 - I hadn't heard of it before. The nodename is DUBL01, but if used in place of the DECnet address, the command fails.

On the VMS side, the OS is V5.5-2H4 running UCX V4.1-ECO10. Upgrading isn't an option, sadly.

labadie: Thanks - unfortunately I can't comment here, as I have little experience with either UNIX or DECnet...

John G: Good to know about the batch being a runner - I hope the attachment provides some clarity.

Steven: A couple of things I'd like to say, but professionalism stays my hand. Thanks for replying.

Rgds,

Bob
Wim Van den Wyngaert
Honored Contributor

Re: DECnet COPY problems

Try show symb rcp* both interactive as in batch. I guess this rcp is something your company wrote.

Wim
Wim
Robert Manning_2
Valued Contributor

Re: DECnet COPY problems

Wim,

Thanks - I've asked the user to come back to me with the results. The server's on a remote LAN I don't have network access to, so it'll be a few minutes.

I don't think it's anything we've written, though...

Rgds,

Bob