About a year ago I wrote a program for TAMUNIX that allowed it to decode CARD
  DUMP format files.  The only documentation I could find at the time was the
  source for CARD itself; and there was no summary description enclosed there.
 
After completing the program, I placed the following comments inside it so that
  I wouldn't have to repeat all my work at some later date.  It turns out that
  it is a very simple and effective scheme.
 
I've included those comments here.  There is a chance that I have missed
  something, but this reflects what one working program does to decode
  CARD DUMP.
 
Regards,
         David Lippke
 
------------------------------------------------------
 
CARD DUMP FORMAT description
 
  A CARD DUMP file is expected to contain one or more subfiles.
    Each subfile is preceded by an eighty byte header.  The first eight
    bytes always contain the EBCDIC string 'CARD:   '.  This is followed
    by the subfile's CMS FST entry.
 
  CARD DUMP subfiles are decoded by first expanding the blank/null
    run lengths.  After this has been accomplished, the subfile's records
    are present in length-data form for variable recfm or a raw stream
    of data in the case of fixed recfm.
 
  -----
 
  Blank and Null encoding:  CARD DUMP subfiles can be thought of as a
    forward linked chain of pointer bytes that are optionally preceded
    with run length information.  The first member of the chain is the
    first byte of each subfile.  Let's call this byte 'C'.
 
  If (C & 0x80) then it encodes a run of nulls or blanks.  The length
    of the run is (C & 0x3f) + 1.  If (C & 0x40) the run is blanks.
 
  IF (~C & 0X80) THEN C IS A POINTER BYTE THAT, WHEN INCREMENTED,
    provides a relative offset to the next member of the chain.
 
  There can be several run encoding bytes before the pointer byte. The
    rules are that an encoding byte is followed by either another encoding
    byte or a pointer byte; pointer bytes are always followed by data
    bytes.
 
  Here is an example of a valid data stream (<enc = encode byte, <ptr> =
    pointer byte, ... = data bytes):
 
         <ptr> ... <enc><enc><ptr> ... <ptr> ... <enc><ptr> ...
 
  ------
 
  I've noticed that the final chain byte is always 0xbf.  This fact is
    not needed by CARD DUMP decoding programs due to the information
    present in the subfile FST.  I don't recommend its use.
 
  ------
 
  If the file is variable recfm, each record is comprised of a two byte
    length followed by the data.  Otherwise, the data resulting from the
    above decoding only needs to be chopped up into lrecl size records.