topic Re: DECnet COPY problems in Operating System - OpenVMS

DECnet COPY problems

Robert Manning_2 — Tue, 29 May 2007 09:06:16 GMT

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

Re: DECnet COPY problems

Robert_Boyd — Tue, 29 May 2007 09:24:55 GMT

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

Re: DECnet COPY problems

Richard Whalen — Tue, 29 May 2007 09:40:59 GMT

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

Re: DECnet COPY problems

Robert Gezelter — Tue, 29 May 2007 16:07:21 GMT

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

Re: DECnet COPY problems

labadie_1 — Tue, 29 May 2007 16:10:32 GMT

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.

Re: DECnet COPY problems

John Gillings — Tue, 29 May 2007 19:48:42 GMT

>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.

Re: DECnet COPY problems

Steven Schweda — Tue, 29 May 2007 21:54:23 GMT

> [...] 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?

Re: DECnet COPY problems

Robert Manning_2 — Wed, 30 May 2007 08:55:27 GMT

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

Re: DECnet COPY problems

Wim Van den Wyngaert — Wed, 30 May 2007 09:15:47 GMT

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

Wim

Re: DECnet COPY problems

Robert Manning_2 — Wed, 30 May 2007 09:39:23 GMT

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

Re: DECnet COPY problems

Wim Van den Wyngaert — Wed, 30 May 2007 10:23:10 GMT

Robert,

The syntax of your rcp reveils that it's not tcpip rcp as we know it today.

The address is x.y which is decnet syntax.
You use "-U" and other unix like syntaxes (+a) which are not VMS like. So, it could be an old (TCP+)decnet implementation or an rcp running on top of decnet that was existing 20 years ago. Wollongong ???

If it's not a symbol it can still be a command. Also try to find all *rcp*.exe files on all your disks. This might help.

Wim

Re: DECnet COPY problems

Steven Schweda — Wed, 30 May 2007 10:36:00 GMT

> [...] professionalism stays my hand.

It didn't stop you from posting an
ill-formed question. Sorry if I hurt your
feelings.

> I hope the attachment provides some clarity.

Attaching a Microsoft Word document instead
of plain text is probably not the best way to
get information to VMS users.

> [...] %DCL-W-PARMDEL [...]

Could also be that the batch job doesn't have
RCP defined the same way as your interactive
job. SHOW SYMBOL RCP* (in both situations)
sounds like a good plan to me.

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

Perhaps not, but it didn't come with VMS.
There's probably one in UCX, however, but
that one won't be looking for a DECnet address.

Re: DECnet COPY problems

Ian Miller. — Wed, 30 May 2007 10:38:10 GMT

You may find FTSV of interest

http://h71000.www7.hp.com/freeware/freeware70/ftsv/

Re: DECnet COPY problems

Robert Manning_2 — Wed, 30 May 2007 10:41:49 GMT

Wim,

You could be onto something here - I got the user to check for the symbol RCP as you suggested, and sure enough it showed up interactively but not in the batch.

RCP == "$AEC$DIR_EXE:RCP"

Following the logical AEC$DIR_EXE, we found the file DISK$AP:[EXE]RCP.EXE, which appears to be owned by the AEC process, a third-party object.

So if I'm correct, this would mean that the interactive command is using RCP as defined by the symbol but the batch job isn't.

I'll try adding the symbol in the batch and see how it goes, although I wonder if it'll be that simple?

Bob

Re: DECnet COPY problems

Wim Van den Wyngaert — Wed, 30 May 2007 10:50:53 GMT

Check your login.com : there must be a test on interactive/batch that is not ok.

Even Google doesn't know this product.
May be these guys ? http://www.aec.com/profile.htm

Wim

Re: DECnet COPY problems

Robert Manning_2 — Wed, 30 May 2007 10:51:39 GMT

Ian,

Thanks - I'll check it out...

Bob

Re: DECnet COPY problems

Robert Manning_2 — Wed, 30 May 2007 11:03:04 GMT

Wim,

That was it - a missing symbol.

I got my colleague to declare the symbol in the batch file and submit it, and the job ran perfectly.

I've no idea who wrote the application; it would have been custom-designed for our setup (automated postal sorting) by an external supplier and I think anyone originally associated with it is long retired.

I take your point about the possibility of a problem with the login, but I think leaving the symbol in the script will be just as effective.

We'll let it run for a couple of days and see how it does.

Thanks for the solution!

Rgds,

Bob

Re: DECnet COPY problems

Robert Gezelter — Wed, 30 May 2007 13:51:57 GMT

Bob,

I would also agree that it (the symbol definition) should be in the Login script, without conditionalization.

There is every possibility that there are other situations where this problem may appear. Fixing the login script will take care of all of them.

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

Re: DECnet COPY problems

Wim Van den Wyngaert — Thu, 31 May 2007 01:07:50 GMT

I would search for the source of the program. It could be on one of your machines.
If not, search for the producer. You have to know who supports it in case you run into problems.

Wim

Re: DECnet COPY problems

Robert Manning_2 — Thu, 31 May 2007 04:46:11 GMT

Gentlemen,

Yes - I've since examined the login script and two simailar files and it looks as though there may be problems. The setup's kind of complicated so I won't go into it here, but suffice to say contractual issues prevent us from making changes to the third-party setup.

I've made the owners aware of the potential problems and urged them to follow it up with their supplier.

Thanks again,

Bob