I/O error trying to include Starlet library

[meyer_d]

I'm trying to compile a program with BLISS-32 (the ALPHA program from Chapter 9 of BLISS-32 User Manual) and get the following error:

Code: Select all

%BLS32-F-ENDABORT, Fatal I/O error - compilation aborted
-RMS-E-FNF, file not found
;   0035  1     %BLISS32( LIBRARY 'SYS$LIBRARY:STARLET';)
? ERR #110      ..................1  L1:0035  L2:0035  L3:0000
  Open failure for REQUIRE or LIBRARY file
  Error occurred expanding macro-formal #1, called from macro %REMAINING, called
 from macro %BLISS32,
       called from source
%BLS32-F-TEXT,  I/O error on library file
-BLS32-F-ENDABORT, Fatal error - compilation aborted

However, SYS$LIBRARY: contains the following files named "STARLET":

Code: Select all

STARLET.MLB;2       STARLET.OLB;4       STARLET.OLB_TEMP;1  STARLET.PAS;1
STARLET.PEN;1       STARLET.REQ;1

Any idea what's wrong?

[sms]

Code: Select all

> [...] ALL is a bad idea anyaway. [...]

      Not entirely.  NOALL is useful.  Around here (for decades):

its $ show symb spp*
  SPP == "SET PROCESS /PRIVILEGE ="
  SPPN == "SET PROCESS /PRIVILEGE = (NOALL, NETMBX, TMPMBX)"

   Allowing NOALL without ALL would be worse.

[roberbrooks]

$ set proc /priv = noall probably does not do what you think.

[sms]

Code: Select all

> $ set proc /priv = noall probably does not do what you think.

   It seems to do what _I_ expect, just as it has done since I learned
about it, lo, those many years ago.

[...]
Process privileges:
 
Process rights:
[...]

   But if you have any actual information on the topic, perhaps time
spent getting it into the documentation would be more helpful than time
spent here providing vague hints about what might be probable.

[martinv]

Interesting that the HELP doesn't mention ALL, or NO. Just checked and neither does the DCL dictionary.

They're hidden in AUTORIZE's description of /DEFPRIVILEGES

A NO prefix removes a privilege from the user. By specifying the keyword [NO]ALL, you can disable or enable all user privileges.

Interestingly, the /PRIVILEGES description differs and is less complete

A NO prefix removes the privilege from the user. The keyword NOALL disables all user privileges.

[cct]

$ set proc /priv = noall probably does not do what you think.

On its own, it leaves you with your defpriv

[sms]

Code: Select all

> On its own, it leaves you with your defpriv

   At least one of us is confused.  When I tried it as SYSTEM, I got
that empty list of "Process privileges:" shown above.  As I expected.  
Perhaps you could demonstrate _your_ claim.

   "_Authorized_ privileges:" is not affected, but I would call that a
_user_ attribute, not a _process_ attribute.

[cct]

Code: Select all

> On its own, it leaves you with your defpriv

   At least one of us is confused.  When I tried it as SYSTEM, I got
that empty list of "Process privileges:" shown above.  As I expected.  
Perhaps you could demonstrate _your_ claim.

   "_Authorized_ privileges:" is not affected, but I would call that a
_user_ attribute, not a _process_ attribute.

You don't show anything above!

From user SYSTEM, I get:

Code: Select all

SYS-1> set proc/priv=(noall)
SYS-1> sh proc/priv

11-JUN-2024 15:22:42.56   User: SYSTEM           Process ID:   00000248
                          Node: VMS1             Process name: "_RTA1:"

Authorized privileges:
 ACNT         ALLSPOOL     ALTPRI       AUDIT        BUGCHK       BYPASS
 CMEXEC       CMKRNL       DIAGNOSE     DOWNGRADE    EXQUOTA      GROUP
 GRPNAM       GRPPRV       IMPERSONATE  IMPORT       LOG_IO       MOUNT
 NETMBX       OPER         PFNMAP       PHY_IO       PRMCEB       PRMGBL
 PRMMBX       PSWAPM       READALL      SECURITY     SETPRV       SHARE
 SHMEM        SYSGBL       SYSLCK       SYSNAM       SYSPRV       TMPMBX
 UPGRADE      VOLPRO       WORLD

Which I see is the same as from my account - I get to keep default privs

[sms]

Code: Select all

> You don't show anything above!

   Of course not.  "Not anything" is a precise and accurate description
of the list of "Process privileges:" after NOALL.

      https://forum.vmssoftware.com/viewtopic.php?f=16&t=9071&start=20#p21574

> [...] I get to keep default privs

   The command is "SET PROCESS", not "SET ME".  Which privileges does
your _process_ retain?

>    At least one of us is confused. [...]

   I believe that I know which of us that is.