DECnet COPY problems

[Robert Manning_2]

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

[Robert_Boyd]

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

[Richard Whalen]

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

[Robert Gezelter]

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]

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]

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

[Steven Schweda]

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

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]

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

Wim

[Robert Manning_2]

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

[Wim Van den Wyngaert]

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

[Steven Schweda]

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

[Ian Miller.]

You may find FTSV of interest

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

[Robert Manning_2]

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

[Wim Van den Wyngaert · Accepted solution]

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

[Robert Manning_2]

Ian,

Thanks - I'll check it out...

Bob

[Robert Manning_2]

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

[Robert Gezelter]

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

[Wim Van den Wyngaert]

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

[Robert Manning_2]

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

[Robert Manning_2]

Okay, I think we've done as much with this as we'll be able to for now.

To summarise, the user was attempting to copy files from a remote UNIX server to his VMS system using RCP in a self-resubmitting batch process.

However, while his command worked when run interactively, it failed when submitted as a batch.

Forum feedback suggested that the syntax used was not that of TCPIP RCP, and that a search for symbols and executables across all locations might reveal something. It in fact highlighted an executable called RCP in a location created by the external suppliers (AEC) of the equipment. The symbol was set in interactive mode but not in batch, which seemed to explain why the script failed when submitted.

Declaring the symbol in the batch script before the copy command resolved the problem.

Residual issues regarding the environment setup have been been passed to the owner of the system to pursue with his supplier.

Thanks to all who assisted - as always, the help was invaluable and much appreciated.

Bob