topic Re: spawned processes in Operating System - OpenVMS

spawned processes

Gregg Parmentier — Thu, 18 Dec 2008 20:44:21 GMT

I have a program that's started using "run /detach". In it I call conv$convert and lib$spawn. It's worked fine under version 7.1, but under 7.2-2 and 7.3-2 neither the conv$convert nor the lib$spawn work properly. The lib$spawn returns a status of 1409916.

If I run the program from DCL, both the conv$convert and lib$spawn work.

Looks like an issue with spawned processes and/or sub-processes, but I can't figure out what might have changed.

Any ideas?

Re: spawned processes

Hein van den Heuvel — Thu, 18 Dec 2008 21:14:43 GMT

Right... LIB$SPAWN requires help from DCL.

To get DCL in a detached process you first run LOGINOUT, NOT your image, and then make that do whatever you need to do.

I'm sure GOOGLE and OpenVMS FAQs have further details on that.

hth,
Hein

Re: spawned processes

Gregg Parmentier — Thu, 18 Dec 2008 22:06:55 GMT

So, run/detach LOGINOUT with the procedure as the input, rather than the image directly.

I'll give it a shot.

Strange that it works as is with 7.1.

Re: spawned processes

Hein van den Heuvel — Thu, 18 Dec 2008 22:24:21 GMT

Hmm, you indeed already mentioned that it worked under 7.1.
I had sort of thought/hoped that remark applied to CONV$CONVERT.
I seem to remember that the LIB$SPAWN restriction was 'day-1'. Maybe not.

It is exactly documented.. online down to 7.3:

http://h71000.www7.hp.com/doc/73final/5932/5932pro_042.html#spawn

"This routine is supported for use only with the DCL command language interpreter. If used when the current CLI is MCR, the error status LIB$_NOCLI is returned. "

For CONV$CONVERT there have been some changes, with respect to temp file handling. Whether a directory entry is mode or not. I did not have the time/desire to find that back. You may want to check CONVWORK and SYS$SCRATCH settings, notably if it is called for an indexed file verus just to copy an simple file.

Hein.

Re: spawned processes

Jess Goodman — Fri, 19 Dec 2008 00:19:41 GMT

LIB$SPAWN calls have never, ever, worked from an image that was run directly using a "RUN /DETACHED image..." command.

Re: spawned processes

Steven Schweda — Fri, 19 Dec 2008 00:33:03 GMT

For the record:

alp $ exit 1409916
%LIB-F-NOCLI, no CLI present to perform function

Some potentially useful info is emitted by:

help /mess /faci = lib NOCLI

Re: spawned processes

Gregg Parmentier — Fri, 19 Dec 2008 17:36:06 GMT

I got the damned thing working.

For those interested, I'll go through the whole process.

The original program was run detached and used conv$convert for the file copy (it also runs lib$spawn for other things and I'll need to see if those parts ever worked correctly.) This worked with 7.1. Under 7.3-2 conv$convert was creating the new file, but not copying the contents.

I created a free-standing program to just call conv$convert do the copy, and it worked when run from dcl. I changed the code in the original program to use lib$spawn to run this new free-standing program. This also worked from dcl, but not run detached, but this time I didn't even get the file create. This was the same whether I ran the free-standing program directly with lib$spawn or if I ran a script that ran the program.

This is where I asked my question here.

I changed the start script to use loginout. Now the version that used lib$spawn to run the free-standing program worked identically to the original version that called conv$convert directly: file created, but no data copy.

What finally worked was using lib$spawn in the program to run a script to use loginout to run the free-standing copy program.

Whew!

Re: spawned processes

Hein van den Heuvel — Fri, 19 Dec 2008 18:13:38 GMT

I'm glad you got it working, but I hope you are not offended if I call your baby ugly.
Very ugly.

CONV$CONVERT can and will work from a detacht process. Directly. We just have to figure out where it went wrong.

File access AUDITING is probably the most expedient way to do this.
This is bound to be a logical name and/or protection environmental issue. I'm sure the code was fine.

Please consider poking a little more at this problem.

Cheers,
Hein.

Re: spawned processes

Gregg Parmentier — Fri, 19 Dec 2008 19:33:09 GMT

I wouldn't have posted that "solution" here if I hadn't thought it was ugly, myself.

I plan to look at it some more, but even running it with a fully privileged system account I get the same effect.

Re: spawned processes

John Gillings — Sun, 21 Dec 2008 22:19:54 GMT

>I plan to look at it some more, but even
>running it with a fully privileged system
>account I get the same effect.

Beware! SORT, and by it's use of SORT, CONVERT have a curious property where they can sometimes fail from a privileged process with a NOPRIV error, where a non-privileged repeat of the same command will succeed.

This may have been fixed recently, but I'm fairly sure it was still there in V7.3-*.

The SORTWORK files are created with a peculiar protection mask (S,O:RWED,G,W). If SORTWORK files are created in a directory not owned by the current process, the file creation rules mean a SYSPRV process will create the file owned by the owner of the directory. When it comes to deleting the file, the SYSPRV process accesses the file via the SYSTEM protection mask, which denies DELETE access. This makes SORT fail with a NOPRIV error. In contrast, if the non-privileged process has write access to the directory, the owner of the file will be the current process, which accesses the file via the OWNER mask, and therefore succeeds.

Re: spawned processes

Gregg Parmentier — Mon, 22 Dec 2008 15:04:45 GMT

I checked the account used to run the job, and it had its privs jacked up.

All I had to do was define sys$scratch to point to a directory owned by that account (not sure why it wasn't already pointing there.)

So apparently the sortmerge problem with privileged accounts appeared some time after VMS 7.1 and before or at 7.2-2.

Re: spawned processes

Hein van den Heuvel — Wed, 24 Dec 2008 18:04:36 GMT

>> All I had to do was define sys$scratch to point to a directory owned by that account (

Just like I suggested in my second, ( 0 points = please do not bother next time :-) reply.

Cheers,
and best wishes for the New Year,
Hein.