Exact file sizes in CP/M Plus

DOS Plus, CP/M 3 and some CP/M 2 clones (specifically, DOS+2.5) support exact file sizes. The following system calls support them:

BDOS function 15 - open a file Entered with DE=address of File Control Block, C=15 (0Fh) If the byte at FCB+32 (FCB+20h) is 255 (0FFh) then on return from this function the byte will contain the Last Record Byte Count. Remember to reset this byte to zero before attempting sequential I/O. BDOS function 17 - search for first Entered with DE=address of File Control Block, C=17 (11h) Returns a pointer to the file's directory entry. The byte at ENTRY+13 (ENTRY+0Dh) contains the Last Record Byte Count. BDOS function 18 - search for next Entered with C=18 (12h) Returns a pointer to the file's directory entry. The byte at ENTRY+13 (ENTRY+0Dh) contains the Last Record Byte Count. BDOS function 30 - set file attributes Entered with DE=address of File Control Block, C=30 (1Eh) To set the Last Record Byte Count, store the required value at FCB+32 (FCB+20h), and set bit 7 of FCB+6. What is the Last Record Byte Count? From CP/M's point of view, it's just a number from 0-255 associated with the file which programs can use for any purpose whatever. The documentation defines no interpretation for it. If we want programs to be able to share files with exact lengths, then there had better be some sort of agreement on what the numbers mean. They must satisfy: If the number is zero, the file uses every byte in its disc image (for compatibility with earlier versions). It must be possible to find the number of bytes in the last record exactly. Unfortunately, this still leaves two plausible systems: The number is the number of unused bytes in the last record. The number is the number of bytes used in the last record; since this ranges from 1-128, 0 is not a valid value and we know it means 128. The only programs I have seen using the system are Tilmann Reh's MSDOS, my MSODBALL and PIP under DOS Plus; all of these adopt the second interpretation.
Letzte Änderung: 4.Juni 2004
++++++++++++++++++++++++++++++++

Exakte Dateilänge unter CP/M Plus

DOS Plus, CP/M 3 und einige CP/M 2 Nachbauten (speziell DOS+2.5) unterstützen die exakte Dateiläge. Die folgenden aufgelisteten Systemaufrufe unterstützen dies:

BDOS Funktion 15 - Öffnen einer Datei

Aufruf mit DE=Adresse des File Control Blocks, C=15 (0Fh)

Wenn das Byte in FCB+32 (FCB+20h) 255 (0FFh) ist, dann wird dieser Wert nach Auruf der Funktion das Byte im letzten Rekord (Last Record Byte Count) enthalten. Vor dem Zugriff mit sequentieller Ein-/Ausgabe muss das Byte auf 0 gesetzt werden.

BDOS Funktion 17 - Suche nach erster Datei

Aufruf mit DE=Adresse des File Control Blocks, C=17 (11h)

Returns a pointer to the file's directory entry. The byte at ENTRY+13 (ENTRY+0Dh) contains the Last Record Byte Count.

BDOS Funktion 18 - Suche nach nächster Datei

Aufruf mit C=18 (12h)

Returns a pointer to the file's directory entry. The byte at ENTRY+13 (ENTRY+0Dh) contains the Last Record Byte Count.

BDOS Funktion 30 - Setzen eines Dateiattributes

Aufruf mit DE=Adresse des File Control Blocks, C=30 (1Eh)

To set the Last Record Byte Count, store the required value at FCB+32 (FCB+20h), and set bit 7 of FCB+6.

What is the Last Record Byte Count?

From CP/M's point of view, it's just a number from 0-255 associated with the file which programs can use for any purpose whatever. The documentation defines no interpretation for it.

If we want programs to be able to share files with exact lengths, then there had better be some sort of agreement on what the numbers mean. They must satisfy: If the number is zero, the file uses every byte in its disc image (for compatibility with earlier versions). It must be possible to find the number of bytes in the last record exactly.

Unfortunately, this still leaves two plausible systems:

The number is the number of unused bytes in the last record. The number is the number of bytes used in the last record; since this ranges from 1-128, 0 is not a valid value and we know it means 128.

The only programs I have seen using the system are Tilmann Reh's MSDOS, my MSODBALL and PIP under DOS Plus; all of these adopt the second interpretation.