- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: spawned processes
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-18-2008 12:44 PM
тАО12-18-2008 12:44 PM
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-18-2008 01:14 PM
тАО12-18-2008 01:14 PM
Re: spawned processes
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-18-2008 02:06 PM
тАО12-18-2008 02:06 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-18-2008 02:24 PM
тАО12-18-2008 02:24 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-18-2008 04:19 PM
тАО12-18-2008 04:19 PM
Re: spawned processes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-18-2008 04:33 PM
тАО12-18-2008 04:33 PM
Re: spawned processes
alp $ exit 1409916
%LIB-F-NOCLI, no CLI present to perform function
Some potentially useful info is emitted by:
help /mess /faci = lib NOCLI
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2008 09:36 AM
тАО12-19-2008 09:36 AM
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2008 10:13 AM
тАО12-19-2008 10:13 AM
Re: spawned processes
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-19-2008 11:33 AM
тАО12-19-2008 11:33 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-21-2008 02:19 PM
тАО12-21-2008 02:19 PM
Solution>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.