Skip to main content
I have several servers with UV 11.3.1.6022 installed and, on one, I'm getting a very odd behavior on selects. This is only happening on our development server, but it's in multiple accounts and the configuration is the same as other servers.

If I create a list with only one item in it and then do a "GET-LIST list_name". The system shows zero records selected and will not list the item. It behaves the same if I'm using &SAVEDLISTS& or another file for storing the lists.

>CT MLISTS WNB710_20180101.WBP_TEST 

     WNB710_20180101.WBP_TEST

0001 TEST.FNCODESGET

>GET-LIST MLISTS WNB710_20180101.WBP_TEST

Zero records SELECTed.  SELECT list number 0 cleared.

If I create a list with multiple items and then do a "GET-LIST list_name", the selected count will consistently show one less item than is in the list. However, if I do the "GET-LIST" and then list the file for the items, all are shown...

>CT MLISTS WNB710_20180101.BLBP

      WNB710_20180101.BLBP

0001 FNCODESGET

0002 FNCODESGETPARAMS

0003 FNNEXTAVAILABLE

0004 FNSUBSTITUTIONS

0005 SETPROMPT

>GET-LIST MLISTS WNB710_20180101.BLBP

 4 record(s) selected to SELECT list #0.

If I get the list and list the item, all are shown:

>GET-LIST MLISTS WNB710_20180101.BLBP

 4 record(s) selected to SELECT list #0.

>>LIST BLBP

 LIST BLBP 11:06:22am  22 Jun 2021  PAGE    1

BLBP................

 FNCODESGET

FNCODESGETPARAMS

FNNEXTAVAILABLE

FNSUBSTITUTIONS

SETPROMPT

 5 records listed.

> 

Color me puzzled...





------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
I have several servers with UV 11.3.1.6022 installed and, on one, I'm getting a very odd behavior on selects. This is only happening on our development server, but it's in multiple accounts and the configuration is the same as other servers.

If I create a list with only one item in it and then do a "GET-LIST list_name". The system shows zero records selected and will not list the item. It behaves the same if I'm using &SAVEDLISTS& or another file for storing the lists.

>CT MLISTS WNB710_20180101.WBP_TEST 

     WNB710_20180101.WBP_TEST

0001 TEST.FNCODESGET

>GET-LIST MLISTS WNB710_20180101.WBP_TEST

Zero records SELECTed.  SELECT list number 0 cleared.

If I create a list with multiple items and then do a "GET-LIST list_name", the selected count will consistently show one less item than is in the list. However, if I do the "GET-LIST" and then list the file for the items, all are shown...

>CT MLISTS WNB710_20180101.BLBP

      WNB710_20180101.BLBP

0001 FNCODESGET

0002 FNCODESGETPARAMS

0003 FNNEXTAVAILABLE

0004 FNSUBSTITUTIONS

0005 SETPROMPT

>GET-LIST MLISTS WNB710_20180101.BLBP

 4 record(s) selected to SELECT list #0.

If I get the list and list the item, all are shown:

>GET-LIST MLISTS WNB710_20180101.BLBP

 4 record(s) selected to SELECT list #0.

>>LIST BLBP

 LIST BLBP 11:06:22am  22 Jun 2021  PAGE    1

BLBP................

 FNCODESGET

FNCODESGETPARAMS

FNNEXTAVAILABLE

FNSUBSTITUTIONS

SETPROMPT

 5 records listed.

> 

Color me puzzled...





------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
Jeff,

That does sound odd, but since this is your development server, and it is only failing on some accounts, could one of your developers tried to overload the GET.LIST command?

Take a look at the VOC item for GET.LIST on an account where this is working and compare to an account where it is not working.


------------------------------
Michael Rajkowski
Rocket Software
------------------------------
Jeff,

That does sound odd, but since this is your development server, and it is only failing on some accounts, could one of your developers tried to overload the GET.LIST command?

Take a look at the VOC item for GET.LIST on an account where this is working and compare to an account where it is not working.


------------------------------
Michael Rajkowski
Rocket Software
------------------------------
Thanks, Mike, for the quick reply. I checked both the goofy server and one that's behaving normally  and the 'GET.LIST' command is the same on both:
>CT VOC GET.LIST
GET.LIST
0001 V
0002 GET.LIST
0003 I
0004 GHKX
0005
0006 PICK.FORMAT

It's behaving the same on all accounts for that server, so I'm thinking environment or uvconfig... We love challenges!

------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
Jeff,

That does sound odd, but since this is your development server, and it is only failing on some accounts, could one of your developers tried to overload the GET.LIST command?

Take a look at the VOC item for GET.LIST on an account where this is working and compare to an account where it is not working.


------------------------------
Michael Rajkowski
Rocket Software
------------------------------
The mystery is (sort of) solved on this. The lists that are showing the short number of items were created in VSCode and saved directly to Type 19 files. However, if I edit one of those items, add a character at the end and then trim it (to force a write), the number of items is correct. One of our developers pointed me to that and apparently, when written via a text editor outside of UniVerse, the end-of-file mark is not being written. Have not found a setting to force that in the VSCode editor.... if the list is written via VSCode with a null last line, it works as expected...


------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
Thanks, Mike, for the quick reply. I checked both the goofy server and one that's behaving normally  and the 'GET.LIST' command is the same on both:
>CT VOC GET.LIST
GET.LIST
0001 V
0002 GET.LIST
0003 I
0004 GHKX
0005
0006 PICK.FORMAT

It's behaving the same on all accounts for that server, so I'm thinking environment or uvconfig... We love challenges!

------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
Some thoughts:
Check the file type for &SAVEDLISTS&, they may have changed it to a hashed file... I'm not sure what would happen if that's the case.  I can even see someone having created a type 1 file then tried to manually modify the file to a type 19 file (hint, at Unix, in the directory type "ls -la *" and look for the .Type1 record.
Also check the permissions of the file and the records in the file.
If it were a large you would definitely get an error so I would be surprised if it was a config issue.

------------------------------
Thomas Whitmore
Sr Programmer
------------------------------
Terms & ConditionsAccessibility statement