UniVerse on RHEL 7 : Global Catalog and command line parameters

I have encountered a weird behaviour of UniVerse 11.3.3 on RHEL .

If I run a globally cataloged command and supply command line parameters the command processor does not attempt to run the program at all.

As an example I have referenced an existing subroutine in the global catalog, just to prove that the code does get run without parameters.

>*SYSFILE_CRT
Cannot RUN a subroutine that has arguments.
>*SYSFILE_CRT HELLO WORLD
>

I have tested this on UniVerse 11.2.5 on RHEL 7 and had the same result.

Is there a known issue with global catalog code not running if command line parameters are supplied?

------------------------------
Gregor Scott
Software Architect
Pentana Solutions Pty Ltd
Mount Waverley VIC AU
------------------------------

And just to confirm that the non-execution has nothing to do with the cataloged code, I tried this

>SELECT GLOBAL.CATDIR '*GCTEST'

0 record(s) selected to SELECT list #0.
"*GCTEST" not found.
>*GCTEST
"*GCTEST" is not in the CATALOG space.
[ENOENT] No such file or directory
>*GCTEST PARAM1
>

So there is something weird happing in the command processor when command line parameters are added to what should be a globally cataloged verb.

------------------------------
Gregor Scott
Software Architect
Pentana Solutions Pty Ltd
Mount Waverley VIC AU
------------------------------

And just to confirm that the non-execution has nothing to do with the cataloged code, I tried this

>SELECT GLOBAL.CATDIR '*GCTEST'

0 record(s) selected to SELECT list #0.
"*GCTEST" not found.
>*GCTEST
"*GCTEST" is not in the CATALOG space.
[ENOENT] No such file or directory
>*GCTEST PARAM1
>

So there is something weird happing in the command processor when command line parameters are added to what should be a globally cataloged verb.

------------------------------
Gregor Scott
Software Architect
Pentana Solutions Pty Ltd
Mount Waverley VIC AU
------------------------------

Hi Gregor,
I looked into this behavior and what I found is that the command line is being treated as a comment. If only the single argument is specified such as *GCTEST, the command processor will attempt to treat it as a globally cataloged program. However, if the command line begins with an asterisk and contains more than one argument, the command processor treats it as a comment. Which explains why it does not execute at all. As far as I can tell, this is long standing behavior and most likely related to processing commands in a paragraph where comments would not be unexpected. To distinguish between a comment and a globally cataloged program with arguments, the command processor would need to recognize the first argument was a globally cataloged program. I hope that explains the current behavior.
Thanks,
Neil

------------------------------
Neil Morris
Universe Advanced Technical Support
Rocket Software
------------------------------

And just to confirm that the non-execution has nothing to do with the cataloged code, I tried this

>SELECT GLOBAL.CATDIR '*GCTEST'

0 record(s) selected to SELECT list #0.
"*GCTEST" not found.
>*GCTEST
"*GCTEST" is not in the CATALOG space.
[ENOENT] No such file or directory
>*GCTEST PARAM1
>

So there is something weird happing in the command processor when command line parameters are added to what should be a globally cataloged verb.

------------------------------
Gregor Scott
Software Architect
Pentana Solutions Pty Ltd
Mount Waverley VIC AU
------------------------------

From Rocket UniVerse BASIC User Guide Version 11.3.1

Note: Because the command processor interprets any line beginning with an asterisk and
containing blanks as a comment, you cannot use command parameters when you invoke a
globally cataloged program. That is, you can use the following command to run the globally
catalog program *GLOBAL, but you cannot include arguments in the command line:

>*GLOBAL

------------------------------
Tyrel Marak
Technical Support Manager
Aptron Corporation
Florham Park NJ US
------------------------------

I have encountered a weird behaviour of UniVerse 11.3.3 on RHEL .

If I run a globally cataloged command and supply command line parameters the command processor does not attempt to run the program at all.

As an example I have referenced an existing subroutine in the global catalog, just to prove that the code does get run without parameters.

>*SYSFILE_CRT
Cannot RUN a subroutine that has arguments.
>*SYSFILE_CRT HELLO WORLD
>

I have tested this on UniVerse 11.2.5 on RHEL 7 and had the same result.

Is there a known issue with global catalog code not running if command line parameters are supplied?

------------------------------
Gregor Scott
Software Architect
Pentana Solutions Pty Ltd
Mount Waverley VIC AU
------------------------------

Why do you need to supply the command in this form?
Can you not have a VOC entry that is a verb, defining this *Sysfile_Crt as just Sysfile_Crt without the asterisk?
And then run that at the command line?

I have a globally catalogued verb VIEW, that is
001 V
002 *VIEW
003 B
004 BN

you can see that it's globally cataloged with the asterisk as expected

When I say
VIEW VOC A
it does work

....

------------------------------
Will Johnson
Systems Analyst
Rocket Forum Shared Account
------------------------------

Why do you need to supply the command in this form?
Can you not have a VOC entry that is a verb, defining this *Sysfile_Crt as just Sysfile_Crt without the asterisk?
And then run that at the command line?

I have a globally catalogued verb VIEW, that is
001 V
002 *VIEW
003 B
004 BN

you can see that it's globally cataloged with the asterisk as expected

When I say
VIEW VOC A
it does work

....

------------------------------
Will Johnson
Systems Analyst
Rocket Forum Shared Account
------------------------------

Because he doesn't want to or can't rely on each and every VOC on a client site.

------------------------------
Tyrel Marak
Technical Support Manager
Aptron Corporation
Florham Park NJ US
------------------------------

Because he doesn't want to or can't rely on each and every VOC on a client site.

------------------------------
Tyrel Marak
Technical Support Manager
Aptron Corporation
Florham Park NJ US
------------------------------

You don't have to rely on it being persent.  You can create a VOC entry yourself.
Problem solved.  Takes three seconds.

You don't have to rely on it being persent.  You can create a VOC entry yourself.
Problem solved.  Takes three seconds.

Actually, based on permissions, that's not always possible.  But you're correct, in many cases, you can just "fix" the VOC on the fly.

------------------------------
Tyrel Marak
Technical Support Manager
Aptron Corporation
Florham Park NJ US
------------------------------

Hi Gregor,
I looked into this behavior and what I found is that the command line is being treated as a comment. If only the single argument is specified such as *GCTEST, the command processor will attempt to treat it as a globally cataloged program. However, if the command line begins with an asterisk and contains more than one argument, the command processor treats it as a comment. Which explains why it does not execute at all. As far as I can tell, this is long standing behavior and most likely related to processing commands in a paragraph where comments would not be unexpected. To distinguish between a comment and a globally cataloged program with arguments, the command processor would need to recognize the first argument was a globally cataloged program. I hope that explains the current behavior.
Thanks,
Neil

------------------------------
Neil Morris
Universe Advanced Technical Support
Rocket Software
------------------------------

Thanks @Neil Morris and @Tyrel Marak,

Looking up documentation on the PAragraph comments in the 11.3.2 User Reference it shows as

Use * (asterisk) in a paragraph to indicate that the following text is a comment.
The comment does not affect the operation of the sentences in the paragraph. A comment line must
contain at least one space character after the asterisk ( * ) to distinguish it from a cataloged BASIC
program name.
​
The BASIC User Guide, as @Tyrel Marak highlighted, does phrase this differently - dropping the reference to the need for at least 1 space after the asterisk.

So I think this is actually either
a long-standing bug in the command processor where it fails to correctly detect comments as being "lines that begin with an asterisk and at least one space",
or
it is a long-standing documentation error in the PAragraph comments description (because it differs to the description given for Global Cataloging in the BASIC User Guide).​​

------------------------------
Gregor Scott
Software Architect
Pentana Solutions Pty Ltd
Mount Waverley VIC AU
------------------------------

Thanks @Neil Morris and @Tyrel Marak,

Looking up documentation on the PAragraph comments in the 11.3.2 User Reference it shows as

Use * (asterisk) in a paragraph to indicate that the following text is a comment.
The comment does not affect the operation of the sentences in the paragraph. A comment line must
contain at least one space character after the asterisk ( * ) to distinguish it from a cataloged BASIC
program name.
​
The BASIC User Guide, as @Tyrel Marak highlighted, does phrase this differently - dropping the reference to the need for at least 1 space after the asterisk.

So I think this is actually either
a long-standing bug in the command processor where it fails to correctly detect comments as being "lines that begin with an asterisk and at least one space",
or
it is a long-standing documentation error in the PAragraph comments description (because it differs to the description given for Global Cataloging in the BASIC User Guide).​​

------------------------------
Gregor Scott
Software Architect
Pentana Solutions Pty Ltd
Mount Waverley VIC AU
------------------------------

Interesting. One could interpret the two different pieces of documentation as describing the same thing given the PAragraph reference did not specify the space character was "immediately" after the asterisk character. Although one would expect that was the intention. But I can't see how the current behavior could be altered to match the behavior implied by the PAragraph documentation without potentially breaking existing paragraphs.

------------------------------
Neil Morris
Universe Advanced Technical Support
Rocket Software
------------------------------

Interesting. One could interpret the two different pieces of documentation as describing the same thing given the PAragraph reference did not specify the space character was "immediately" after the asterisk character. Although one would expect that was the intention. But I can't see how the current behavior could be altered to match the behavior implied by the PAragraph documentation without potentially breaking existing paragraphs.

------------------------------
Neil Morris
Universe Advanced Technical Support
Rocket Software
------------------------------

That kind of change would disrupt a potentially large collection of
established code.

A tunable or setting at the user or account or system level would be
required. While this behavior is in the command processor, user settings
exist now for users in BASIC such as ASSIGN {0|1} to SYSTEM (1017).