Subject: DUP Problem with RT-11

From: "Jerome H. Fine" <[email-masked]>
Date: Wed Mar 12 14:11:00 2003

I have been attempting for some to to write ALL 65536 blocks
from one RT-11 partition to a second RT-11 partition.  Does
anyone know of what is wrong with what I am doing?  I am
using V5.03 of RT-11 under the Supnik emulator and I do the
command:

COPY/DEVICE/NOQU   DU0:/START:0./END:65535.  DU1:/START:0.

However, ONLY 65535 blocks are transferred.  On the other hand,
If I do the command:

COPY/DEVICE/NOQU  DU0:/START:65524./END:65535. DU1:/START:0.

then TWO blocks are transferred (I put 2 non-zero blocks into DU1:
first),
so I know that that it is possible to read block 65535 from DU0:, but
there
seems no reason why block 65535 is not written to DU1: via the very
first command - especially when there is not even a warning message.

Please do not reply that an RT-11 partition is ONLY 65535 blocks and
that the last legal block is 65534.  I have already proven that I can
read
block 65535 from DU0: when I use DUP.SAV, thus so as long as block 65535

can be read, there is absolutely NO reason that DUP.SAV should not allow

me to write the same block into DU1:, but DUP.SAV does not seem to be
able
to do that and moreover does not even provide a warning message that
DUP.SAV will ignore block 65535 when I explicitly direct that block
65535
be written to DU1:   In addition, just in case anyone feels that DUP.SAV

really ought not to provide at least a warning message, then try the
command:

COPY/DEVICE/NOQU   DU0:/START:1./END:65535.   DU1:/START:1.

which does provide the warning message that I suggest is essential so
long
as DUP.SAV prohibits the user from writing block 65535 onto DU1: after
block 65535 has been read from DU0:, even though, in my opinion there
is NOTHING wrong with the command and DUP.SAV should do what the
user has specified.

Can anyone help?  Any suggestions other than going into the DUP.SAV
program and fixing this bug?

Sincerely yours,

Jerome Fine
--
To obtain the original e-mail address, please remove
the ten characters which immediately follow the 'at'.
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.

---

From: Megan <[email-masked]>
Date: Thu Mar 13 22:20:00 2003

>using V5.03 of RT-11 under the Supnik emulator and I do the

As you know, some devices supported by RT are variable-sized,
like DL, DM and DU.  In order for RT to know the size of
a volume on these devices, the handlers have to support the
special function 373, which gets the volume size.

In most cases, this is not a problem since the volume sizes
don't approach the 16-bit limit of 65535.  But for DU volumes,
this size can be exceeded.  And since you cannot return a
volume size of 65536 as it would require 17 bits, the maximum
size returned is pegged at 65535, with one block specifically
designated as unused (but reachable using other special function
calls in the DU handler).  The reason for the one unused block
is so that the calculations for start of a partition are simple
(since it is a truncation by discarding the low-order 16 bits of
block number).

Now, since the DU handler reports 65535 as the largest size,
the directory structure is established such that the blocks
which are accessible are 0 through 65534 (a total of 65535
blocks).

It would be a kludge and a hack (a bad one) to play games in the
driver to make it report 0 and have it mean 65536 even if
a reported size of zero makes no sense (actually, a reported
size of less than 9 makes no sense since that is the MINIMUM
number of blocks required on an RT volume to be able to store
a minimum of one block of data).  It would also mean changing
DUP and any other program which uses VARSZ$.

Personally, I would suggest that time is better spent with
other things in RT... just live with one block not directly
accessible per 65536, or write your own programs (without
mucking with the OS itself) to get at the final block... I
would say it is a case of truly diminished returns.

					Megan Gentry
					Former RT-11 Developer

+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL   | email: mbg at world.std.com         |
|                                |                                     |
| "this space                    |             (s/ at /@/)             |
|  unavoidably left blank"       | URL:     http://world.std.com/~mbg/ | 
|                                | "pdp-11 programmer - some assembler |
|                  (DEC '77-'98) |  required." - mbg            KB1FCA |
+--------------------------------+-------------------------------------+

---

From: "Jerome H. Fine" <[email-masked]>
Date: Sat Mar 15 21:23:00 2003

>"Jerome H. Fine" wrote:

> then TWO blocks are transferred.
>

Jerome Fine replies:

After 10 years, I finally (by accident) just tried the correct combination.
But it
still takes TWO commands to do what should be done with just ONE command:

COPY/DEVICE/NOQU   DU0:   DU1:
which results in the following command:
COPY/DEVICE/NOQU   DU0:/START:0./END:65534.   DU1:/START:0.

I then followed with this EXPLICIT command (just thought I should try it
today
and found that it works):
COPY/DEVICE   DU0:/START:65535./END:65535.   DU1:/START:65535.

After that I checked the result (actually before and after the previous
command):
DIFF/BINARY   DU0:/START:0./END:65535.   DU1:/START:0.

and found that the last ONE block COPY command had indeed worked.  If
you actually read this far and you would like a copy of an enhanced BINCOM,
let me know via an e-mail and after I have fixed a few bugs, I will release
it
for hobby use.  The DEC distributed version of BINCOM does NOT have the
ability to read block 65535.

Sincerely yours,

Jerome Fine