In a recent note, Rob van der Heij said:
> Date: Tue, 7 Aug 2007 09:38:30 +0200
>
> On 8/6/07, Paul Gilmartin <[EMAIL PROTECTED]> wrote:
>
> > I was unaware of SPECS C2X. Mea culpa.
>
> Really, in this context "c2x" is the base-16 and takes 4 times more
> space and time than base-64. Even the most broken ASCII to EBCDIC
>
???
CMS
pipe literal wombat| 64encode | console
ppaUgoGj
Ready; T=0.01/0.01 12:56:07
pipe literal wombat| specs 1-* c2x | console
A696948281A3
Ready; T=0.01/0.01 12:56:21
.. I count that as 1.5 times more (12/8), not 4. And I was not
considering hex as a transfer medium; merely for visual inspection
of whatever digest.
> translation will not confuse the 64 code points used for base-64.
> If data is treated like a byte stream, then you may need to encode
> your record boundaries too. If you're dealing with EBCDIC text then
> there is probably room to encode the record separator, otherwise
> something like "addrdw cms" and "deblock cms" may be appropriate (or
> "pack" and "unpack" as you suggest).
>
"ADDRDW SF4" seems the safest, since it handles the longest records
and does not discard null records. Thanks for suggesting ADDRDW.
> The "digest" stage can work on a stream of bytes (ignoring record
> boundaries) or compute a digest per input record.
>
OK. So I could compute a stream of record-by-record digests, then
a digest of the digests.
BTW, is there a VMFPLC* stage? Since VMFPLCD is an exec, it could
likely be adapted as a pipeline stage. (And it would be nice
to have a "PIPE ROUTE" facility, analogous to the "VMFPLC ROUTE"
or "VMFPLCD ENV=", which would set up a default primary output
stream other than HOLE for PIPE commands issued from the terminal.)
-- gil
--
StorageTek
INFORMATION made POWERFUL
