This all started when I decided to make UNZIPZ utilize named directories since help indicates the program support DU:. Currently the code gets the drive from location 0x5C (default FCB, dfcb) for the input file and at location 0x6C (alternate FCB, afcb) for the output file. The user #s are obtained from locations 0x69(dfcb+13) and 0x79 (afcb+13) respectively. So UNZIPZ was obviously letting ZCPR3x parse the command line! While running some tests, I also noticed an issue with UNZIPZ where it failed to find the input file even though it obviously existed. So I decided to investigate how ZCPR34 parses the command line so Iissued the following command (system prompt included) where ROOT: is C0.
C0:ROOT>ddt root:bpbn.img
and got the following response
DDT VERS 2.2
NEXT PC
2D80 0100
- Wow it actually found BPBN.IMG and loaded it. Then I dumped the FCB
-d50 6f
0050 FF FF FF FF FF FF FF FF FF FF FF 00 03 42 50 42 .............BPB
0060 4E 20 20 20 20 49 4D 47 00 80 80 59 E8 00 E9 00 N IMG...Y....
Ok the drive is at 0x5C and 0x69 is 80 which indicates the default user #.
Then I tried the following where BIN: is C15 and GAMES: is D1
C0:ROOT>DDT bin:file1.com games:file2.com
DDT VERS 2.2
? -d50 7f
0050 FF FF FF FF FF FF FF FF FF FF FF 00 03 46 49 4C .............FIL
0060 45 31 20 20 20 43 4F 4D 00 80 00 00 04 46 49 4C E1 COM.....FIL
0070 45 32 20 20 20 43 4F 4D 00 01 00 00 00 0B 00 00 E2 COM........
- Drives are at 0x5C and 0x6C and user # for file2.com is at 0x79 but 0x69 contains 80 not 0F as expected. This appears to bug in ZCPR34! Just to confirm there was a bug, I tried
C0:ROOT>ddt c15:file1.com d1:file2.com
DDT VERS 2.2
? -d50 7f
0050 FF FF FF FF FF FF FF FF FF FF FF 00 03 46 49 4C .............FIL
0060 45 31 20 20 20 43 4F 4D 00 80 00 00 04 46 49 4C E1 COM.....FIL
0070 45 32 20 20 20 43 4F 4D 00 01 00 00 00 0B 00 00 E2 COM........
- Again the user number for file1.com was wrong. I am running BPBios so tried running NZCOM in case the CPR in BPBios was corrupt. Unfortunately I got the same results. I don't have ZCPR30. Can anyone with ZCPR30 try this experiment? Found several other examples programs the assumed 0x69 contained the user #.

On Saturday, May 15, 2021 at 10:01:12 AM UTC-4, Lawrence Nelson wrote:
> This all started when I decided to make UNZIPZ utilize named directories since help indicates the program support DU:. Currently the code gets the drive from location 0x5C (default FCB, dfcb) for the input file and at location 0x6C (alternate FCB, afcb) for the output file. The user #s are obtained from locations 0x69(dfcb+13) and 0x79 (afcb+13) respectively. So UNZIPZ was obviously letting ZCPR3x parse the command line! While running some tests, I also noticed an issue with UNZIPZ where it failed to find the input file even though it obviously existed. So I decided to investigate how ZCPR34 parses the command line so Iissued the following command (system prompt included) where ROOT: is C0.
> C0:ROOT>ddt root:bpbn.img
> and got the following response
> DDT VERS 2.2
> NEXT PC
> 2D80 0100
> -
> Wow it actually found BPBN.IMG and loaded it. Then I dumped the FCB
> -d50 6f
> 0050 FF FF FF FF FF FF FF FF FF FF FF 00 03 42 50 42 .............BPB
> 0060 4E 20 20 20 20 49 4D 47 00 80 80 59 E8 00 E9 00 N IMG...Y....
> Ok the drive is at 0x5C and 0x69 is 80 which indicates the default user #..
> Then I tried the following where BIN: is C15 and GAMES: is D1
> C0:ROOT>DDT bin:file1.com games:file2.com
> DDT VERS 2.2
> ?
> -d50 7f
> 0050 FF FF FF FF FF FF FF FF FF FF FF 00 03 46 49 4C .............FIL
> 0060 45 31 20 20 20 43 4F 4D 00 80 00 00 04 46 49 4C E1 COM.....FIL
> 0070 45 32 20 20 20 43 4F 4D 00 01 00 00 00 0B 00 00 E2 COM........
> -
> Drives are at 0x5C and 0x6C and user # for file2.com is at 0x79 but 0x69 contains 80 not 0F as expected. This appears to bug in ZCPR34! Just to confirm there was a bug, I tried
> C0:ROOT>ddt c15:file1.com d1:file2.com
> DDT VERS 2.2
> ?
> -d50 7f
> 0050 FF FF FF FF FF FF FF FF FF FF FF 00 03 46 49 4C .............FIL
> 0060 45 31 20 20 20 43 4F 4D 00 80 00 00 04 46 49 4C E1 COM.....FIL
> 0070 45 32 20 20 20 43 4F 4D 00 01 00 00 00 0B 00 00 E2 COM........
> -
> Again the user number for file1.com was wrong. I am running BPBios so tried running NZCOM in case the CPR in BPBios was corrupt. Unfortunately I got the same results. I don't have ZCPR30. Can anyone with ZCPR30 try this experiment? Found several other examples programs the assumed 0x69 contained the user #.

Post Script

Tried ZCPR1.0. Same results! Looked at the source code and found the following comment
; Added ZCPR3 style drive/user number to all FCB parsing.
; S1 in the FCB is used to store the user number. If S1 contains a valid
; user number, bit 7 will be set. If no user number is specified, S1 will
; contain 0.
Evident that there are two problems in the above example. First while the specified user number for file1.com is 15, 80 is stored at S1 implying that 0 is the valid user number. Second, while the specified user number for file2.com is 1, bit 7 is not set to indicate that it is correct.

Part of it appears to be DDT or BDOS changing the FCB before you get
to look at it. I wrote a quick little program in Turbo Pascal to dump
out the DFCB and AFCB blocks as the transient sees them. This was done
with ZCPR3.3.

A6:PASCAL>>PWD
PWD, Version 1.4
DU : DIR Name DU : DIR Name DU : DIR Name DU : DIR Name
---- -------- ---- -------- ---- -------- ---- --------
A 0: BASE A 1: COMM A 2: SOURCE A 3: ZCPR3
A 4: DOC A 5: LADDER A 6: PASCAL A 8: BBS
A 11: TPSRC A 14: HELP A 15: ROOT

B 2: AMPRO B 3: ASTRO B 4: NOVADOS B 5: GAMES
B 7: GSX B 8: CATCHUM B 9: VLIB B 10: CIOS
B 12: CC B 13: ZMODEM

C 2: SYSLIB C 3: Z3LIB C 4: DSLIB C 5: ZSLIB

A6:PASCAL>>dumpfcbs zslib:file1.com vlib:file2.com
DR F1 F2 F3 F4 F5 F6 F7 F8 T1 T2 T3 EX S1 S2 RC
005C 03 46 49 4C 45 31 20 20 20 43 4F 4D 00 05 00 00 .FILE1 COM....
006C 02 46 49 4C 45 32 20 20 20 43 4F 4D 00 09 00 00 .FILE2 COM....

A6:PASCAL>>dumpfcbs c5:file1.com b9:file2.com
DR F1 F2 F3 F4 F5 F6 F7 F8 T1 T2 T3 EX S1 S2 RC
005C 03 46 49 4C 45 31 20 20 20 43 4F 4D 00 05 00 00 .FILE1 COM....
006C 02 46 49 4C 45 32 20 20 20 43 4F 4D 00 09 00 00 .FILE2 COM....

As you can see, the user numbers in S1 are correct for both named and
du prefixes.

In regards the comment about bit 7 being set in S1 to indicate a
valid user number, was that in UNZIPZ itself rather than somewhere in
ZCPR? If that was in UNZIPZ, it makes sense. On a call to open a file,
ZSDOS/ZDDOS will only use the value in S1 as a user number if b7 is set
and the BDOS error mode is non-zero. As far as I remember, the only
place that the b7 check is applicable is on a ZSDOS/ZDDOS file open (but
that's just going from memory, so I could be wrong about that).

Regards,
Wayne