[Info-vax] %PCSIUI-E-PRIVCLASS1 when using PRODUCT with PIPE

[Stephen Hoffman]

On 2018-12-07 13:18:03 +0000, Jairo Alves said:

Here is the thread from 2002 that this is in reply to:

https://groups.google.com/d/msg/comp.os.vms/1p-RuxToEQY/YXKd5FrTh_wJ


> I'm seeing the same behaviour.
> 
> $ pipe product show product > sys$login:prod_show_prod.txt
> 
> %PCSIUI-E-PRIVCLASS1, operation requires SYSLCK privilege
> %PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition
> 
> One extra bit of information: if run under system or sysadmin accounts 
> the same pipe works. But this is not a pipe fault. product command is 
> the one asking for the privilega.
> 
> One possible way to "solve" this:
> UAF> modi <user> /priv=SYSLCK
> 
> And then it didn't even had to be clearly "enabled", just adding to the 
> authorizes privs list was enough to make it work.

PIPE and various DCL commands don't always play well together.   
(There's much missing around the implementation of piping on OpenVMS.  
Many of the DCL commands don't optionally offer to produce 
pipe-friendly output, akin to what's possible with various shell 
commands on other platforms.  That and object-based piping and UTF-8 
support and such are all fodder for another discussion or three, 
though.)

PCSI expects full privileges lit and—until fairly recently—accepted 
only a subset of the valid filename and directory path syntax.  Use of 
the SYSTEM username or another fully-privileged user is expected.  This 
is one of those murky areas of the OpenVMS documentation, though.  (The 
concept of disabling access to SYSTEM akin to what's happening with 
root user access on some other Unix systems is an interesting topic to 
ponder for the future of OpenVMS, too.  But I digress.)

OpenVMS has long lacked a standard, non-privileged package installer.  
This has caused folks problems going back years, too.

If you're solely looking for output from the command as part of a 
software inventory or equivalent, then the following longstanding DCL 
hackery will get you output from commands—such as this POLYCENTER 
PRODUCT command—that lack an /OUTPUT qualifier:

$ @TT:/OUTPUT=file
$ {command}
^Z

Wrapping commands in DCL, and using @procedure-name/OUTPUT=file also works.

But maybe PCSI eventually sprouts some additional qualifiers, and some 
other updates?

Given the scale and scope involved with bringing the OpenVMS software 
packaging and installation environment forward to what's common on 
other platforms, I'd eventually expect a wholesale replacement for PCSI 
will arrive.  This for connecting to VSI for notifications, and for 
acquiring kits and certificates and other updates from the hypothetical 
VSI software server, among other details.  In deference to 
compatibility, any replacement installer would preferably also accept 
and process most PCSI kits, and/or a way to migrate the PCSI product 
description files (PDF, yes, really) and product text files (PTF) and 
the kit contents into the replacement environment.  Accepting VMSINSTAL 
kits, not so much. Though I could see automating and translating a 
subset of what VMSINSTAL kits can do, VMSINSTAL kits tend to get 
"creative" with their contents.




-- 
Pure Personal Opinion | HoffmanLabs LLC