UniVerse LPTR keyword

The 11.3 user reference keyword section shows LPTR [n]. Most occurrences of appropriate command section instances only show the keyword LPTR. I guess you need to find the keyword section to know there is an optional printer channel number. Recently updated commands like LIST.INDEX, however, show the optional printer number. Does this mean that the documentation is going to evolve for all commands that allow LPTR will also show the optional printer channel?

As an experiment, get into UniVerse, and immediately issue the command LIST VOC LPTR 3. It sends the output to the spooler. My recollection is that the command would complain about channel 3 not set up. Of course that recollection goes back over 30 years. Is the behavior to use print channel 0 if the requested one is not set up?

Speaking of LIST.INDEX, "-INFORMME"? A curious choice for a command line option beyond -INFORM. Is the hyphen a signal that the INFORMME will not be found as a keyword in the VOC file? Unless this is a new addition beyond 11.3.1.6022, no VOC entry keyword would make it difficult to internationalize...

------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------

Based on my testing, the allowed printer channels (0 thru 255) will have default settings when starting a UV session. And these can also be changed by using the SETPTR.DEFAULT command. So the command LIST VOC LPTR 3 will use the standard default settings or whatever may have been changed with SETPTR.DEFAULT. If an invalid print channel is used, an error will be generated.

>LIST VOC LPTR 300
LPTR unit number specification "300" is out of range (0 to 255).
>

A little research indicates the "-INFORM" and "-INFORMME" options were included in the event a conflict existed where an index in a file happened to be named INFORM.  So the standard practice would be to use the INFORM keyword which would not impact internationalization.

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

Based on my testing, the allowed printer channels (0 thru 255) will have default settings when starting a UV session. And these can also be changed by using the SETPTR.DEFAULT command. So the command LIST VOC LPTR 3 will use the standard default settings or whatever may have been changed with SETPTR.DEFAULT. If an invalid print channel is used, an error will be generated.

>LIST VOC LPTR 300
LPTR unit number specification "300" is out of range (0 to 255).
>

A little research indicates the "-INFORM" and "-INFORMME" options were included in the event a conflict existed where an index in a file happened to be named INFORM.  So the standard practice would be to use the INFORM keyword which would not impact internationalization.

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

It still is tricky to work with an index named INFORM. The parser in uvhome/BP/LIST.INDEX scans first for keywords, and remaining words are considered for index names. LIST.INDEX could have used INDICES() on the file pointer (after identifying the file, which would mean the file name would need to appear prior to keywords or index names) to get index names and then the leftovers could be checked for keywords.

You can still get the information about an index name of INFORM, but it takes some work (blank lines removed). It cannot be supplied on the command line:

>LIST.INDEX VOC INFORM -INFORM
Index name(s): INFORM
Alternate Keys for VOC
Index path: /home/mark/accounts/newacc/I_VOC
File Index
INDEX.003 INFORM

Oddly, using INFORM does not provide the INFORM format, even though the command parser eats the INFORM keyword:

>LIST.INDEX VOC INFORM
Index name(s): INFORM
Alternate Key Index Summary for file VOC
File........... VOC
Indices........ 1 (0 A-type, 0 C-type, 1 D-type, 0 I-type, 0 SQL, 0 S-type)
Index Updates.. Enabled, No updates pending
Index name Type Build Nulls In DICT S/M Just Unique Field num/I-type
INFORM D Not Reqd Yes Yes S L N 1

Although, this does:

>LIST.INDEX VOC -INFORM
Index name(s): INFORM
Alternate Keys for VOC
Index path: /home/mark/accounts/newacc/I_VOC
File Index
INDEX.003 INFORM

So, it is a little quirky, but still a halfway measure. It does not address handling an index names of other keywords for the command, such as DETAIL, STATS, STATISTICS, or even LPTR, ALL, DICT or NO.PAGE for that matter.

Even if the parser gave first priority to index names, it would introduce a restriction that the file name appears first:

>LIST.INDEX @ID VOC
Alternate Key Index Summary for file VOC
File........... VOC
Indices........ 1 (0 A-type, 0 C-type, 1 D-type, 0 I-type, 0 SQL, 0 S-type)
Index Updates.. Enabled, No updates pending

Index name Type Build Nulls In DICT S/M Just Unique Field num/I-type
@ID D Not Reqd Yes Yes S L N 0



------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------

It still is tricky to work with an index named INFORM. The parser in uvhome/BP/LIST.INDEX scans first for keywords, and remaining words are considered for index names. LIST.INDEX could have used INDICES() on the file pointer (after identifying the file, which would mean the file name would need to appear prior to keywords or index names) to get index names and then the leftovers could be checked for keywords.

You can still get the information about an index name of INFORM, but it takes some work (blank lines removed). It cannot be supplied on the command line:

>LIST.INDEX VOC INFORM -INFORM
Index name(s): INFORM
Alternate Keys for VOC
Index path: /home/mark/accounts/newacc/I_VOC
File Index
INDEX.003 INFORM

Oddly, using INFORM does not provide the INFORM format, even though the command parser eats the INFORM keyword:

>LIST.INDEX VOC INFORM
Index name(s): INFORM
Alternate Key Index Summary for file VOC
File........... VOC
Indices........ 1 (0 A-type, 0 C-type, 1 D-type, 0 I-type, 0 SQL, 0 S-type)
Index Updates.. Enabled, No updates pending
Index name Type Build Nulls In DICT S/M Just Unique Field num/I-type
INFORM D Not Reqd Yes Yes S L N 1

Although, this does:

>LIST.INDEX VOC -INFORM
Index name(s): INFORM
Alternate Keys for VOC
Index path: /home/mark/accounts/newacc/I_VOC
File Index
INDEX.003 INFORM

So, it is a little quirky, but still a halfway measure. It does not address handling an index names of other keywords for the command, such as DETAIL, STATS, STATISTICS, or even LPTR, ALL, DICT or NO.PAGE for that matter.

Even if the parser gave first priority to index names, it would introduce a restriction that the file name appears first:

>LIST.INDEX @ID VOC
Alternate Key Index Summary for file VOC
File........... VOC
Indices........ 1 (0 A-type, 0 C-type, 1 D-type, 0 I-type, 0 SQL, 0 S-type)
Index Updates.. Enabled, No updates pending

Index name Type Build Nulls In DICT S/M Just Unique Field num/I-type
@ID D Not Reqd Yes Yes S L N 0



------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------

I noticed this behavior as well when doing some testing. The INFORM keyword was added to LIST.INDEX to provide the additional details on an index. I'm not sure I was aware of the other arguments until reviewing the documentation ticket this morning. As you observed, whatever changes were made were not intended to handle every possible conflict between index names and keywords. I suspect the coding related to INFORM was done as it was a "new" keyword for LIST.INDEX and "might" impact a user who already had an index named INFORM?  Any conflicts between the other keywords and index names would likely have been handled in some manner already. I will check with the developer regarding the current behavior with an index named INFORM.

Thanks,

Neil

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