We need to find the correct record ID for deletion.
SELECT reports one record, yet SAVE.LIST saves two. Any work with the SELECT list is working with the wrong ID.
SELECT CONTROL WITH @ID LIKE EVAL "'...':CHAR(009):'...'"
... : CHAR ( 009 ) : ...
1 record(s) selected to SELECT list #0.
>>.X5
05 SL SUE.BADR
2 record(s) SAVEd to SELECT list "SUE.BADR".
That suggests you have a CHAR(10) or CHAR(254) in the record ID. The SELECT list is breaking the ID at the mark character. The ID that is saved would get split at the newline by the O/S in &SAVEDLISTS& or UVTEMP/select000.... I would not expect you managed to insert a CHAR(255), because that would probably just make it appear truncated. Normally, you cannot get a CHAR(242) without uvconfig ALLOWMARKS=1. It is likely a newline,
Ways to find the right ID:
After SELECT CONTROL WITH @ID LIKE EVAL "'...':CHAR(009):'...'", if you enter "SELECT CONTROL", do you get any records selected, or does it say it cannot find the ID? I would expect the select list as it lives in UVTEMP with select0000.... may already be split into those two pieces, but it will let you see where the newline or fieldmark should be in the ID.
You could also examine the saved list with "od -xc SUE.BADR", or cat "SUE.BADR". This would let you see where to insert the offending mark character or newline. Or you could LIST CONTROL WITH @ID LIKE EVAL "'...':CHAR(009):'...'" ID.ONLY and see where the ID is split into two records. Issue the command with COMO ON SUE; SELECT...; COMO OFF. ED &COMO& SUE, in up-arrow mode with ^ at the ED command prompt, will let you see control characters. The output may split the ID in two, which would hide which character is the problem.
A CONTROL file probably has a limited number of records, even if they are crucial. You could run a uvfixtool or filepeek with verbosity/debugging level 4 trace, which would display all of the ID. If you prefix the command with "typescript filename" (assuming a UNIX variant) and at the end an "exit" command, the filename will contain all of the literal output characters. When you know where it is, the output can be smaller by limiting the range to one group.
A more UniVerse friendly way would be GROUP.STAT.DETAIL, again wrapped with COMO. This will tell you which group hold the errant record.
When you identify the correct ID for the record, your program should be able to delete it.
------------------------------
Mark A Baldridge
Principal Consultant
Thought Mirror
Nacogdoches, Texas United States
------------------------------
Original Message:
Sent: 02-03-2023 21:09
From: Susan Chandler
Subject: CHAR(9) in record ID
Thanks so much for the suggestions. After all my TCL tricks failed months ago, I wrote a simple program to try to delete the record, but that method didn't work. I'm guessing the file header is what's actually messed up. I tried every method posted here, along with a RESIZE for good measure, but it's still showing up.
In my program, I tried creating the @ID in a variable using every Control character I could think of that could cause similar symptoms, along with the CHAR(9)'s I know are there. I worked on an issue on another server when a co-worker had a program go from 1600 lines to 43 or so. I eventually found that a vendor code upgrade process wrote a bunch of CHAR(255)'s. I was only able to fix that because code is in a type 19 directory. This acts a lot like that did.
After the SELECT, there is 1 record selected, but SAVE.LIST breaks the ID after about 70 characters and writes out 2 lines.
SELECT CONTROL WITH @ID LIKE EVAL "'...':CHAR(009):'...'"
... : CHAR ( 009 ) : ...
1 record(s) selected to SELECT list #0.
>>.X5
05 SL SUE.BADR
2 record(s) SAVEd to SELECT list "SUE.BADR".
Any additional suggestions would be great. Thanks
------------------------------
Susan Chandler
Consultant
Rocket Forum Shared Account
Original Message:
Sent: 02-03-2023 11:26
From: Matthew Van Amburg
Subject: CHAR(9) in record ID
I use EVAL for this sort of thing. In fact I found a VOC record in my test environment that has a tab in the ID running this test.
>SELECT VOC WITH @ID LIKE EVAL "'...':CHAR(9):'...'"... : CHAR ( 9 ) : ...1 record(s) selected to SELECT list #0.>>
You can then delete it as you would any other record.
------------------------------
Matthew Van Amburg
Full Stack Developer
Burkhart Dental Supply
Tacoma WA US
Original Message:
Sent: 02-02-2023 19:10
From: Susan Chandler
Subject: CHAR(9) in record ID
I accidentally created an invalid record(s) in a uv 11.2.5 file that I can't get rid of. The file is CONTROL and the record "@ID" contains multiple CHAR(9)'s. Because CONTROL is open to every process and I can't take the system down, I'm hesitant to try commands that might cause issues. My last resort will be to create a new file, copy the valid records and replace the existing, but there has to be a fix that doesn't require taking the system down.
I've tried to manually select and delete the record(s). I also wrote a program when that failed. I've tried multiple things in the program, using SELECT statements and creating the ID, but the READ statement hits the ELSE clause because it's not valid. The info below demonstrates that a single record selected is handled as 2 records when I edit them.
>SELECT CONTROL = "[19791 ]"
1 record(s) selected to SELECT list #0.
>>AE CONTROL
< 1 > Top of New "LAST.DMD.NEW.DAILY^009* Date of last NEW demand history load" in "CONTROL".
*--: EX
Quit "LAST.DMD.NEW.DAILY^009* Date of last NEW demand history load" in file "CONTROL" not created.
< 2 > Top of New "^00919791 |grep '*'" in "CONTROL".
*--: EX
Quit "^00919791 |grep '*'" in file "CONTROL" not created.
>
------------------------------
Susan Chandler
Consultant
Rocket Forum Shared Account
------------------------------