Date   : Tue, 13 Dec 1983 18:51:00 MST
From   : Kevin Kenny <Kenny%his-phoenix-multics.arpa@BRL.ARPA>
Subject: Re: CP/M media compatibility

(1) -- 32 lines

Date:  Tuesday, 13 December 1983 18:40 mst
From:  Network_Server.Multics
Subject:  Unable to deliver mail from Kenny.OSNI@HIS-PHOENIX-MULTICS.ARPA
To:  Kenny.OSNI at HIS-PHOENIX-MULTICS

Recipient INFO-CPM@BRL-VGR.ARPA at CISL-SERVICE-MULTICS.ARPA failed because
The requested action was not performed. No known path.

******************** Failed message follows. ********************

Date:  Tue, 13 Dec 83 18:37 MST
From:  Kevin Kenny <Kenny@HIS-PHOENIX-MULTICS.ARPA>
Subject:  Re: CP/M Media Compatibility
Reply-To:  Kenny%PCO@CISL-SERVICE-MULTICS.ARPA
To:  INFO-CPM@BRL-VGR.ARPA
Message-ID:  <831214013735.338020@HIS-PHOENIX-MULTICS.ARPA>

Resent-Message-ID:  <831213005740.664514@HIS-PHOENIX-MULTICS.ARPA>

In fact, Tony Li's a little conservative about CP/M-MP/M-CCP/M media
exchange.  The XFCB's (extended file control blocks) look like files in
nonexistent user areas (above 16).  In fact, though, they're set up so
that if all you use is date/time stamping and the protection attributes,
you won't actually get in trouble.  The second 16 bytes of the XFCB is
reserved for encrypted password, and will be zero if the file is
unpassworded, meaning that the ``file'' won't look as if it's using any
space on the disc, and CP/M-80 won't get confused.

In short, you can exchange discs freely back and forth between CP/M-80
and the newer systems, *provided* that the files are unpassworded, even
if XFCB's are used.

Some of the public domain programs may get confused by the XFCB's, so be
careful.  I know that SAP and DUU work.  SD reports some garbage
information for the additional directory entries.

/k**2