In a recent note, Dave Jones said: > Date: Tue, 31 Jul 2007 11:50:23 -0500 > > > a > > bc > > > > and: > > > > ab > > c > > > There should be identical checksums for your two example files; I > believe that the CRC algorithm is defined to work on data that is > represented by a simple string of bytes, so, yes, it should ignore > record boundaries. I don't think this reveals a weakness in PIPES CRC > stage; I think it shows that it is working as designed. > Working As Designed? Broken As Designed? It's a design that ignores the fundamental character of CMS files -- they come in records, and the placement of the record separations matters.
> If you want the two example files shown above to yield different CRC > values, one approach might be to denote the record boundaries > explicitly, e.g., adding a NL (x'15') to the end of each record before > it is passed to the CRC stage: > > ....| specs 1-* 1 x15 n | crc.... > Ummm. Hardly better. That fails to distinguish between two consecutive records and a single record consisting of the two concatenated with an intervening '15'x. I think a PACK stage would avoid that pitfall. -- gil -- StorageTek INFORMATION made POWERFUL
