1748204 Members
3080 Online
108759 Solutions
New Discussion юеВ

Re: spawned processes

 
SOLVED
Go to solution
Gregg Parmentier
Frequent Advisor

spawned processes


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?
11 REPLIES 11
Hein van den Heuvel
Honored Contributor

Re: spawned processes

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

Gregg Parmentier
Frequent Advisor

Re: spawned processes


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.
Hein van den Heuvel
Honored Contributor

Re: spawned processes



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.
Jess Goodman
Esteemed Contributor

Re: spawned processes

LIB$SPAWN calls have never, ever, worked from an image that was run directly using a "RUN /DETACHED image..." command.
I have one, but it's personal.
Steven Schweda
Honored Contributor

Re: spawned processes

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
Gregg Parmentier
Frequent Advisor

Re: spawned processes


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!
Hein van den Heuvel
Honored Contributor

Re: spawned processes

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.
Gregg Parmentier
Frequent Advisor

Re: spawned processes


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.
John Gillings
Honored Contributor
Solution

Re: spawned processes

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

A crucible of informative mistakes