You can only create such records with a Basic program. WRITE doesn't check the ID, it takes whatever the program provides, and if that is null or contains non-printable characters including attribute-, value- or subvalue marks, it just assumes the programmer knows what he or she is doing and intends to write such a record for whatever reason. And one such reason could actually be to stop people from editing such records. So yes, it is a feature in so far, as it doesn't limit our choices as developers (even if they don't seem to make sense), and yes, it is a bug, but not a bug in the Basic run-time but in the application software. Marc Harbeson wrote:
I'm not sure you want to use this "feature" - as I believe Indexing may not behave as expected when using it. :-) I'm speaking from memory, so it's been a while since I've seen this. But if I recall correctly, the index stops indexing after it encounters this record. (or something like that) It could have been something funky with the SELECT - but none the less, I've seen this cause issues with selecting records (regular records not "hidden" ones) I wish UDT would forbid the CHAR(0) - at least convert it to ^0 so you can see it - as this is quite an ugly issue to find as you well know now. (And quite difficult to eliminate once found) Another way to scrub them out is to SELECT then COPY FROM X TO Y records (Hint here: Do not use COPY FROM X TO Y ALL as this will copy "hidden records" as well) :-) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dan McGrath Sent: Thursday, April 30, 2009 1:27 AM To: [email protected] Subject: RE: [U2] Interest results on VOC file Unfortunately that method wouldn't work. Also, I don't believe we have ALLOWMARKS in UD. I viewed the VOC file itself outside of Unidata to see what was actually stored as the record ID, that way I could use a program to delete the record. Funnily, it contained Char(0)... I can read and delete the record now with ID = "23":CHAR(0):"3;":CHAR(0):"-6" ID<-1> = CHAR(27) ID<-1> = "1":CHAR(32):CHAR(25) READ REC FROM VOC,ID THEN CRT REC ELSE CRT "Not found" DELETE VOC, ID After viewing what the record contained, I worked out it was from at least 5 years ago well before my time. ? Best of all, the "feature" of allowing us to place nulls in record ID's allows us to hide data in files now... <pseudo> WRITE "DECOY" ON FILE,RECORD WRITE "HIDDEN" ON FILE,RECORD:CHAR(0) ... :LIST FILE RECORD RECORD 2 records listed :ED FILE * 2 record(s) selected. < 1 > Top of RECORD in FILE 001: DECOY Bottom. *--: Q Quit RECORD in file FILE unchanged. < 2 > Top of RECORD in FILE 001: DECOY Bottom. *--: Q Quit RECORD in file FILE unchanged. ... READ HIDDEN FROM FILE,RECORD:CHAR(0) ELSE STOP CRT HIDDEN "HIDDEN" -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Charles Stevenson Sent: Wednesday, 29 April 2009 5:12 PM To: [email protected] Subject: Re: [U2] Interest results on VOC file This I-descriptor or EVAL should help you: LIST VOC _ WITH EVAL "CONVERT( @AM:@VM:@SM:@TM, 'avst', @id )" # @ID _ ID.SUP EVAL "CONVERT( @AM:@VM:@SM:@TM, 'avst', @id )" (To be rigorous, char(247 thru 250) are also treated as system delimiters. You might test for them, too.) Is ALLOWMARKS set to 1 or 0 in uvconfig? My guess is "1", or at least that it used to be "1". This means system delimiters are allowed to be embedded in IDs. So if you have an id with a field-mark (aka attribute-mark, char(254), @AM, @FM) in it -- let's call it ABC^254DEF -- then if that is part of an active select list, it will be processed as ABC then DEF. That is, 2 ids that are probably not in the file at all. Moral of the story: ALLOWMARKS 0 is better than 1. Did you look at what NSELECT's 2 supposed ids are? Try pinning them together with system delimIters and reading with basic read statement. Or LIST.ITEM VOC should show them to you., too. I am not sure what happens if uvconfig is set to 1 after such records are already in your files. That param was introduced a few years ago, after many systems were already up & running. Another source is data ported from other MV platforms. Has anyone seen this before? When I select everything from VOC and immediately do a NSELECT on VOC, it returns 2 records. :SELECT VOC 14315 records selected to list 0. NSELECT VOC 2 record(s) selected. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ######################################################################## ################### The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files with the permission of IMB. ######################################################################## ################### ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
