12 Jan
2006
12 Jan
'06
12:28 a.m.
Thanks Jerome for this information.
I did know what the WRITE PROT button does :-), but the fact
that you can run RT-11 with that button ON was new to me,
as long as you don't need to write to the pack, of course.
Very handy if you make any copy from the system disk to an
other disk. An error in the entry line (DL0 <-> DL1: swapped)
will not be harmful to the system disk with the WRITE PROT
button ON. I used your tip yesterday!
I did notice however, that I became a little less "on guard",
because I was thinking "I'am safe" :-)
BTW, as you can guess, my problems with the RL drives that
would not boot are solved. The drive(s), cables and the pack
are all fine, the RL11 controller developed a fault.
I have tagged the board with a label that describes the
symptoms and put it aside ... for days when I have more time
to do some fault finding on the board; when I'm retired :-).
- Henk, PA8PDP.
Jerome Fine replies:
Tony is correct. The boot block does start with 240 for the
RL02. If you know the approximate version of RT-11 and the
flavour of the monitor (RT11FB, RT11XM, etc.), most of the
rest of the boot block at block zero can be described. Of
course, if you did that, you also would have read the RL02 pack!
One method of making sure that the RL02 pack is not changed
is to WRITE PROTECT the pack so that it can't be changed -
PERIOD! While some operating systems can't run, RT-11 is
PERFECTLY happy using this method of making sure that the
system disk (or any other for that matter) is not altered.
Of course, you also can't save any new files. BUT, you can
turn off the WRITE PROTECT at any time and save one file at a
time when you actually have something to save. NOTE that
RT-11 must also write first to the directory, so if you use
this method, best to use VM: and copy the file in one
operation using PIP after the file is complete.
Sincerely yours,
Jerome Fine
This message and attachment(s) are intended solely for the use of the addressee and may
contain information that is privileged, confidential or otherwise exempt from disclosure
under applicable law.
If you are not the intended recipient or agent thereof responsible for delivering this
message to the intended recipient, you are hereby notified that any dissemination,
distribution, or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the sender immediately by
telephone and with a "reply" message.
Thank you for your cooperation.
15 Jan
15 Jan
7:18 p.m.
Probably the primary reason I always run with all drives on WRITE PROT
is that I frequently make modifications to the operating system or
device drivers.
As most individuals can appreciate, who run under RT-11, there is absolutely
no protection even when running a user program, although it might be a
bit less
likely to cause a random write to a disk drive. But when the operating
system
(or a device driver) is being modified, really strange things can
(although very
rarely) occur which could result in the disk drive being corrupted. If
you see
an annoying error message about the SWAP file when using WRITE PROT, then:
SET EXIT NOSWAP
In addition, I have found a number of bugs in the operating system which
cause
RT-11 to crash. When I was fixing the code which caused the problems,
it was
frequently necessary to run the bug to completion so that I understood
exactly
what takes place and identify the specific instructions that lead to the
crash.
PLUS, I also modified the USR to allow a PH(X).SYS pseudo Path
device Handler which PHn => dnA, dnB, dnC, etc. which acts like the
symbolic name list in VMS or the PATH NAME in DOS. All of the
above code changes had their share of problems during development
and I was always grateful when I crashed RT-11 during the debug phase
that the disk drive was in WRITE PROT, although not quite as pleased
when I had not yet saved the latest source to be tested - early on I
learned to at least save the modified source file.
Fortunately, the bugs which cause RT-11 to crash rarely occur. And since
no one at either DEC and now Mentec ever seemed interested enough to
want to fix the bugs when I used to have conversations, I never bothered
to submit to the one-way SPR route without any feedback.
Even the RT-11 Bug List at:
http://www.classiccmp.org/PDP-11/RT-11/
has not resulted in any feedback in over 3 years since the first version
and more
than 2 years after the second. Eventually, I will release a PAX.SYS device
driver to fix the bug in RT11XM.SYS and RT11ZM.SYS since otherwise a
SYSGEN would be required. However, as I have indicated, I am attempting
to calculate li for prime numbers (try Google) when x is large (x up to
10**100)
which is providing an interesting challenge. Also, when I release
PAX.SYS, I
want to include the ability to intercept Application Keypad ESC
sequences which
include lower case letters and prevent conversion to upper case during
typeahead
if that is selected by the user (SET PA KEYPAD=[NO]ESC or something
similar).
I was working on that additional feature when I became distracted by li(x).
A decade ago, I thought it might still be possible to sell bug fixes.
The Y2K bug
was also high on my list and that was a big flop. Now, I can't even
seem to find
anyone interested enough in RT-11 to want the bugs fixed for free. At
one point,
there seemed to be a bit of interest in a Y2K version of V05.03 of
RT-11, but
naturally only from hobby users. I did fix 95% of V05.04G to be Y2K,
but the
time I spent (about 3 months) was not very rewarding. The ONLY feedback
I received from QA at the company it was sold to was that:
DATE 31-Feb-2005
is allowed - I forgot that 31-Feb-99 was also allowed as late as V05.06
of RT-11
and no one had bothered to provide a list of the non-Y2K bugs to be
fixed. In
point of fact, even in V05.07 of RT-11, I understand that it is possible
to enter:
DATE 31-Feb-2005
and NOT receive an error message. ONLY when the command "DATE" is entered
does an invalid date message appear. Now that is sloppy implementation
as far as
I am concerned. Naturally this could be regarded as a "feature" such
that V05.07
is compatible with prior versions where no error message is provided when an
invalid date is used when the date is being set. Sorry - not my cup of
tea!!!!!!!!!!
I will be really surprised if there is any feedback from this
post!!!!!!!!!!!!!!!!!!!!
Jerome Fine
Gooijen, Henk wrote:
Thanks Jerome for this information.
I did know what the WRITE PROT button does :-), but the fact
that you can run RT-11 with that button ON was new to me,
as long as you don't need to write to the pack, of course.
Very handy if you make any copy from the system disk to an
other disk. An error in the entry line (DL0 <-> DL1: swapped)
will not be harmful to the system disk with the WRITE PROT
button ON. I used your tip yesterday!
I did notice however, that I became a little less "on guard",
because I was thinking "I'am safe" :-)
BTW, as you can guess, my problems with the RL drives that
would not boot are solved. The drive(s), cables and the pack
are all fine, the RL11 controller developed a fault.
I have tagged the board with a label that describes the
symptoms and put it aside ... for days when I have more time
to do some fault finding on the board; when I'm retired :-).
- Henk, PA8PDP.
>Jerome Fine replies:
>
>Tony is correct. The boot block does start with 240 for the
>RL02. If you know the approximate version of RT-11 and the
>flavour of the monitor (RT11FB, RT11XM, etc.), most of the
>rest of the boot block at block zero can be described. Of
>course, if you did that, you also would have read the RL02 pack!
>
>One method of making sure that the RL02 pack is not changed
>is to WRITE PROTECT the pack so that it can't be changed -
>PERIOD! While some operating systems can't run, RT-11 is
>PERFECTLY happy using this method of making sure that the
>system disk (or any other for that matter) is not altered.
>Of course, you also can't save any new files. BUT, you can
>turn off the WRITE PROTECT at any time and save one file at a
>time when you actually have something to save. NOTE that
>RT-11 must also write first to the directory, so if you use
>this method, best to use VM: and copy the file in one
>operation using PIP after the file is complete.
>
>Sincerely yours,
>
>Jerome Fine
>
16 Jan
16 Jan
12:33 a.m.
Fortunately, the bugs which cause RT-11 to crash
rarely occur. And since
no one at either DEC and now Mentec ever seemed interested enough to
want to fix the bugs when I used to have conversations, I never bothered
to submit to the one-way SPR route without any feedback.
Even the RT-11 Bug List at:
http://www.classiccmp.org/PDP-11/RT-11/
has not resulted in any feedback in over 3 years since the first version
and more
than 2 years after the second. Eventually, I will release a PAX.SYS
device
I've never really come across any of the bugs on the list
A decade ago, I thought it might still be possible to
sell bug fixes.
The Y2K bug
was also high on my list and that was a big flop. Now, I can't even
seem to find
anyone interested enough in RT-11 to want the bugs fixed for free. At
one point,
there seemed to be a bit of interest in a Y2K version of V05.03 of
RT-11, but
naturally only from hobby users.
If I can help bang on some of the fixed code, or contribute in any way,
let me know.
Gordon.
6868
days inactive
6872
days old
2 comments
3 participants
participants (3)
-
gordonjcp＠gjcp.net -
henk.gooijen＠oce.com -
jhfinedp3k＠compsys.to