RE: [U2] Longstanding aversion to CNAME?
With UV at least, CNAME is a Unix executable, hence able to handle the renaming of very large sequential files and the like... Unlike a UV BASIC program, the UV line editor or the UV COPY verb (the latter two being UV BASIC programs). So it, can come in very handy! Regards, David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Snyder Sent: Friday, 23 July 2004 3:10 PM To: [EMAIL PROTECTED] Subject: Re: [U2] Longstanding aversion to CNAME? Wendy Smoak wrote on 07/22/2004 07:26:59 PM: From a UniBasic program, why would you open a file, read a record, write it back to the same file under a different key, then delete the original record, when you could just: X.CMD = CNAME filename :X.ID:',':X.NEW.ID EXECUTE X.CMD The overhead of the execute would be greater than if you did it programmatically. CNAME will be doing everything you'd be doing, but there will also be the overhead of the execute. If you're doing it once within a program, the difference will be negligible. But don't think about doing it in a loop. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Longstanding aversion to CNAME?
Probably doesn't apply in this case but there's a trap to beware of If the file is type 1/19 and the record contains binary data, a simple read/write will corrupt it. On reads from a type 1/19, newlines are replaced by field marks. On write the opposite translation happens. For a normal text type database record this is fine, however, if you store bitmapped data (e.g. scanned images) in a type 1/19 file they will be damaged by this process. This was a long standing problem in COPY in UV but was fixed some time ago. The fix uses an (undocumented?) mode flag: ASSIGN 1 TO SYSTEM(1017)to turn off character translation and ASSIGN 0 TO SYSTEM(1017)to turn it on again Until this morning, I thought that CNAME had also been fixed but it seems that I am wrong (though the system I tried it on is still using 9.6.1.2). To demonstrate this problem, compile a one line program that prints -2. Use CNAME to change the name of the object record and the program prints -62963. I can't imagine that many users rename their object files but it shows the effect. I know of one very big UV site where they decided to save time by copying the object code from a test system to the live system using COPY rather than recompiling. This neatly destroyed every program along the way. A favourite variant on this problem was for users who went home from system adminstration courses and decided that GLOBAL.CATDIR might be better as a type 19 file instead of type 1. Yes, RESIZE used to have the same bug. The only way to get going again was to rebuild the catalog. Thankfully, this one has been fixed. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Longstanding aversion to CNAME?
This is from Universe 10.2 RUN BP A -2 CNAME BP.O A,V Changed record A to V in file BP.O. RUN BP V -246 Same problem except I get -246 not -6293 !! Bob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Martin Phillips Sent: 23 July 2004 09:11 To: [EMAIL PROTECTED] Subject: Re: [U2] Longstanding aversion to CNAME? Probably doesn't apply in this case but there's a trap to beware of If the file is type 1/19 and the record contains binary data, a simple read/write will corrupt it. On reads from a type 1/19, newlines are replaced by field marks. On write the opposite translation happens. For a normal text type database record this is fine, however, if you store bitmapped data (e.g. scanned images) in a type 1/19 file they will be damaged by this process. This was a long standing problem in COPY in UV but was fixed some time ago. The fix uses an (undocumented?) mode flag: ASSIGN 1 TO SYSTEM(1017)to turn off character translation and ASSIGN 0 TO SYSTEM(1017)to turn it on again Until this morning, I thought that CNAME had also been fixed but it seems that I am wrong (though the system I tried it on is still using 9.6.1.2). To demonstrate this problem, compile a one line program that prints -2. Use CNAME to change the name of the object record and the program prints -62963. I can't imagine that many users rename their object files but it shows the effect. I know of one very big UV site where they decided to save time by copying the object code from a test system to the live system using COPY rather than recompiling. This neatly destroyed every program along the way. A favourite variant on this problem was for users who went home from system adminstration courses and decided that GLOBAL.CATDIR might be better as a type 19 file instead of type 1. Yes, RESIZE used to have the same bug. The only way to get going again was to rebuild the catalog. Thankfully, this one has been fixed. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- 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 __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Longstanding aversion to CNAME?
In the old Prime Information days (where I believe CNAME came from) the runtime engine would actually block an attempt to do a CNAME from anywhere other than the colon (TCL) prompt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 23 July 2004 13:45 To: [EMAIL PROTECTED] Subject: [U2] Longstanding aversion to CNAME? Wendy Smoak wrote on: Thu, 22 Jul 2004 17:26:59 -0700 It seems that CNAME is not a popular UniBasic command. Is there some history here I'm not aware of, maybe it was unreliable? From a UniBasic program, why would you open a file, read a record, write it back to the same file under a different key, then delete the original record, when you could just: X.CMD = CNAME filename :X.ID:',':X.NEW.ID EXECUTE X.CMD Two reasons for me: 1) I learned MV under Pick, where CNAME wasn't available. As previously stated, you had to use the COPY command (with the (D option) and DATA the destination. I've only been using UniData for about 3 years under SB+, so I'm still learning some of the non-Pick syntax options. 2) Crash safety net :- If the system were to crash during the CNAME operation, I wouldn't know for certain where the record was, and it could be completely lost. If it crashed during the WRITE/DELETE sequence, I would either have just the original, just the new, or possibly both. --Tom Pellitieri Century Equipment --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone +44 (0)20 7896 0011 and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Markets Limited and IG Index Plc are authorised and regulated by the Financial Services Authority and, in Australia, by the Australian Securities and Investments Commission. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Longstanding aversion to CNAME?
UV10 STILL DOES NOT UPDATE INDEXES if the index is part of the ID. From: Norman, David (SAAS) In UV9.4 CNAME didn't update secondary indexes, which left a bit of a mess behind. This has now been fixed, probably from 9.6. Example. A 2-part id: [internal-date]*[something] indexed on date ( @ID['*',1,1] or FIELD(@ID,'*',1) ) Changing a 0 to a 1 in a date in a particular id: CNAME file 13350*ABC,13351*ABC will leave old, nonexistant id 13350*ABC indexed under date 13350 and will not add the new id to 13351. IBM knows this (probably forwarded from the Vmark days), but resolutely will not fix it because the underlying i/o routines used by CNAME are different from the norm and won't easily support the change. This list's archives will support that claim. One could reasonably restate that as, It's too hard to fix, so just live with the inherent data integrity vulnerability. Or even, Help, help we're being oppressed. Come see the vulnerability inherent in the system. Chuck Stevenson P.S. As for speed, for type-1 -19 CNAME is faster than other read/write/delete schemes one could program. I *believe* it invokes a unix mv command which simply repoints the inode without actually moving any files. Similar on MS. P.P.S. I recall CNAME was originally a PRIMOS command similar to unix mv. Information just borrowed the name and handled type-1 ( UFDs (UserFileDirectories) ) with the primos mechanism, and used its own mechanism for hashed records. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Longstanding aversion to CNAME?
Wendy Smoak wrote: It seems that CNAME is not a popular UniBasic command. [snip, rearrange] X.CMD = CNAME filename :X.ID:',':X.NEW.ID EXECUTE X.CMD Its an ECL verb isn't it Wendy? Is there some history here I'm not aware of, maybe it was unreliable? I don't think so. I think it is just a Prime thing that non-primates tend to distrust. The PICK TCL syntax for the same action requires a DATA statement if you want to execute it from BASIC so you wouldn't normally do it: DATA X.NEW.ID EXECUTE COPY filename :X.ID What happens if you get filename wrong? or something else happens, the new key you've just put on the DATA stack might be taken to mean something else. It simply isn't a good programatic solution. Cheers, Ken --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Longstanding aversion to CNAME?
hashing location of the new id is probably not the same as the old id, so the record will still have to be removed/deleted from the original group before writing it to new group. Roger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Wendy Smoak Sent: Thursday, July 22, 2004 8:27 PM To: [EMAIL PROTECTED] Subject: [U2] Longstanding aversion to CNAME? It seems that CNAME is not a popular UniBasic command. Is there some history here I'm not aware of, maybe it was unreliable? From a UniBasic program, why would you open a file, read a record, write it back to the same file under a different key, then delete the original record, when you could just: X.CMD = CNAME filename :X.ID:',':X.NEW.ID EXECUTE X.CMD No changes to the data are required. For example, if a bunch of records get written with the wrong date embedded in the key. This situation came up on info-datatel. Here, it happens so rarely that it's barely worth worrying about-- I'm just curious. --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
