Am 12/30/2021 05:49 AM, dxforth schrieb:
On 30/12/2021 15:29, Martin wrote:
Am 12/30/2021 02:34 AM, dxforth schrieb:
I'm contemplating using this in my compiler instead of BDOS 34.
AFAIK BDOS 40 avoids the problem of 'sparse files' which most
file utilities can't handle anyway.
My question - what's wrong with BDOS 40 given almost nobody
appears to use it?
You zero fill the remainder of only one block.
The rest of the extent and all other extents before and after
remain sparse the same as for BDOS 34.
So this does not help in any way.
I don't want to first find out the block size of the drive in
the program I write just in order to use that BDOS call.
To add this BDOS call IMHO was a bad idea, and I would acknowledge and
respect past experience to better NOT use it.
Ok, so not much use. When you say "one block" you mean disk block
e.g. 2K, 4K etc. ? That would wipe out other records in the block?
Here is a nice introduction into BDOS expecially using and comparing
the differences between BDOS 34 and DBOS 40 (Part III):
<
https://hc-ddr.hucki.net/wiki/doku.php/cpm/sliding_into_bdos>
After you previously used that function there is no way to find out
if that "Zero's" were part of the unused part of your file.
I just tried out the example on a real CP/M 2.2 system.
To check what was really written I used ZAP.COM, a file/disk editor.
You have to configure it for your terminal once,
but then it has a very nice full screen interface.
This is the directory entry on my drive, it is the same in
both cases:
:fRANDFILE.TST
40 0052414E 4446494C 45545354 0100000D *.RANDFILETST....*
50 41000000 00000000 42000000 00000000 *A.......B.......*
G=00:00, T=3, S=1, PS=0
The first example using WRITE RANDOM:
Record 0 is written with 'A'
Record 1-15 contain garbage (the first block of the first extent)
Record 128-142 contain garbage (the second allocation block
of the second extent)
Record 143 is written with 'B'
The program modified to youe WRITE RANDOM the second time
(modified as in the article):
Record 0 is written with 'A'
Record 1-15 contain garbage (the first block of the first extent)
Record 128-142 contain *00s* (the first allocation block
of the second extent)
Record 143 is written with 'B'
On my drive the block size just happens to be 16 records so record
16-128 are not allocated and record 143 is the last record of the
block.
In the "Programmer's CP/M Handbook" by Andy Johnson-Laird there is a
hint why this function exists at all:
[Purpose
This function is an extension to the Write Random function described pre- viously. In addition to performing the Write Random, it will also fill each new allocation block with OOH's. Digital Research added this function to assist Micro-
soft with the production of its COBOL compiler-it makes the logic of the file handling code easier. It also is an economical way to completely fill a random file
with OOH's. You need only write one record *per allocation block*; the BOOS will
clear the rest of the block for you.]
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)