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/
