2 Dec
2010
2 Dec
'10
3:56 p.m.
Coming a bit late into this, but anyway...
On 11/18/10 08:39, "Jerome H. Fine"<jhfinedp3k at compsys.to> wrote:
Well, yes and no.
What you actually do is:
ERfilename$_string$$EWnewfile$HPW$EC$EX$$
(assuming that all the data you are interested in are in the buffer,
otherwise include P commands in there to the appropriate amount, before
the HPW.)
If you really want to use A to append more data from the disk, you
should probably not use 9999K to dump the current buffer, but use HK
instead.
Also, if a search fails, you'll aready be at 0, so no reason for the J
command.
Not sure what SIPP is, but TECO can handle, and display, anything. It
was designed to be able to deal with any kind of information, not just text.
No. TECO works perfectly fine with any kind of binary data.
Antonio wrote:
>> >>>Having (many years ago)
recovered data from a borked RT-11
>> >>>filesystem, I can certainly confirm that.
>> >>>
> >>However, I don't understand how you can use TECO to actually
> >>repair an RT-11 filesystem. For that purpose, I can only see
> >>SIPP as being able to
> >>change or repair
> >>
>I'm pretty sure I didn't say "repair"; I merely recovered data.
>
>I don't recall exactly what went wrong, but essentially I went
>in with TECO and found the right blocks for the various source
>files I needed, loaded them into TECO and wrote them out
>to floppy. Needed some minor tidy up as I recall but that's about all.
>
>
OK!! I understand completely!! If anyone else who is interested does not
understand, please ask some questions.
If the ASCII data in question was not in the first buffer, than I assume
that
something like the TECO command:
<ASstring$:;J9999K>$$
was what you used to find the start of the file which you had lost. By the way, KED can do the same, but is limited to
devices (I assume that
you must have done a non-file-structured open, i.e. ERdev:$$) that are less
than 32768 blocks. Since I have never had occasion to edit a full MSCP
device of 65535 blocks, I just never noticed the limitation. This
restriction
for KED also applies to files. So KED can INSPECT a logical device which
is 32767 blocks or less or an RL02 device, but no physical device or file
larger than 32767 blocks in total.
TECO itself will not care, so that would be a limitation from the RT-11
point of view, in that case. TECO will serially read a file (or device)
from start to finish, and don't really care about
the file position
information as such.
>
>>Can you describe how you used TECO to recover data from a
> >>borked RT-11 filesystem (assuming that you did more than just
> >>READ the text contents
> >>of the files
> >>in the same manner that KED would also allow using a
> >>non-file-structured edit
> >>of the whole device)? Otherwise, if you just used TECO to
> >>just READ the
> >>text
> >>strings, please confirm that as well.
> >>
>I didn't fix a corrupt system back to a working system. I read
>blocks from disk into TECO (as you say, in a non-file structured
>mode), somehow found the root directory and worked out where the
>files I cared about lived, read each of those and saved them to floppy.
>Then either the disk was reformatted or it went back to whoever we
>bought it from for a replacement- I just don't remember.
>
More than likely, you just found the source ASCII text you were looking
for and wrote
that to the floppy file using something similar the the TECO command
that I suggested.
TECO is not designed nor able to show individual words of a specific
block as SIPP
is able to do. >TECO can
certainly read disk block N, and having done that it can surely
>mangle that disk block; what I'm not sure of is whether it can then
>write that block out to the required disk block.
>
I really don't think so. TECO can, as far as I know, work only with
ASCII text strings. Binary data can't be managed easily, if at all, by
TECO such as what
SIPP can do.
No. TECO handles binary data just fine.
Whenever you enter text, all characters are allowed. And by all
characters, I really mean all characters. Control characters are just as
welcome as printable ones. A few characters have special meaning in
TECO, such as ESC, ^C, and a few more. ESC can be used by instead
setting another character as the delimiter for the search string. Other
special control characters can be inserted by prefixing them with ^Q,
which means that the next character should be taken literally, and not
be interpreted. For most characters though, nothing special is needed at
all, and you can just enter them in your search string.
In the case you don't really want to type the control characters as
such, you can create the search string before using it, and then just
suck it into your search string as well.
In addition to this, you also have the powerful pattern matching of
search strings, that TECO gives you. So you can say that any character
should match at a specific position, and then match whatever comes after
more specifically as well (or any number of other potential pattern
matching schemes you can think of).
Johnny
3 Dec
3 Dec
9:34 p.m.
This answer is fairly long, so be prepared to read for a while. In
summary, the
ONLY point I disagree about with respect to TECO (based on the test of
TECO I just made under RT-11 V36 of TECO) is that TECO ignores zero
bytes when it writes out a file. Non-zero control characters are
retained, but
any binary data with 16 bit integer values less than decimal 255 will
have an
upper byte of zero. That upper byte of zero will be lost when the block of
binary data is written to a file.
I was attempting to use the MOST obvious and least difficult TECO commands.
I agree that your commands are correct and perhaps more efficient.
Agreed!
I was attempting to point out that in some cases, RT-11 KED will not work
and why.
In RT-11, SIPP.SAV is the Save Image Patch Program. SIPP is able to
access ANY word (or byte) of a file by the offset from the start of the
file - or a base value specified by the user when using a BASE VALUE
is useful.
I don't know about TECO under RSX-11, but under RT-11, both TECO
and KED ignore bytes of ZERO or NULL. I just did a short test under
RT-11. I used KED to create a file with 4 lines of "abcdefghijklmn"
each followed by <CR><LF> for a total of 64 non-zero characters.
I used the DUMP.SAV program to confirm my assumption. The
rest of the file was all zeros. I then used SIPP.SAV to zero the
"cd" characters in the first and second line. I again used DUMP.SAV
to confirm that was what had been done. That left 2 bytes of zero on
the first and second line. I then made an exact binary copy of the file
and used TECO (EBTST.TXT$$) to edit the file. As expected, I was
able to find any character on any line and display the character. However,
when I did an exit "<ESC><ESC>" from TECO (without changing
anything), the zeros in the first and second line had been ignored by
TECO and (in effect) shifted to the end of the non-zero text. KED
did the exact same thing.
Maybe I am missing something, but I would assume that most file
structures also contain any number of zero bytes which would prevent,
under RT-11, TECO from being used to correct such data. I agree
that, as per the example, when a user is searching for an ASCII file,
TECO and KED are both capable of finding the specific files in
any number of blocks by searching for specified ASCII strings.
But, RT-11 TECO at least, will not write out the data from a
corrupted file structure BYTE by BYTE when any of the BYTES
are zero. ONLY RT-11 SIPP, in my experience, can do that,
In an additional illustration, RT-11 supports READ ONLY files.
In fact, the Resident Monitor in RT-11 requires only two additional
instructions to check the READ ONLY status of a file and abort
any write requests. BUT, DEC never bothered to enhance PIP
and DIR to display and change the READ ONLY bit in the file
status word in a disk directory. On a number of rare occasions
when I needed a READ ONLY file, for testing my code, I used
SIPP to modify the status word for a file in the disk directory.
Neither TECO nor KED can even begin to easily look for the
status words in a disk directory and neither can possibly write
out the new status word even if it is correctly modified since any
zero bytes will be ignored.
I believe you are aware of this aspect of how TECO and KED
(at least for RT-11) treat zero bytes in a file, but I suggest that
you may have confused anyone else who reads this discussion.
So while both TECO and KED can definitely (and easily) search
for the strings in a file somewhere on a disk, both are then limited
to making a copy of the text that is found (ignoring any imbedded
zero bytes) and writing out the text to a device with a valid file
structure.
I really don't think so. TECO can, as far as I know, work only with
ASCII text strings.
No. TECO works perfectly fine with any kind of binary data.
Here is where we disagree. Maybe it is RT-11, but any zero bytes
are ignored and I suggest that zero bytes are included in "any kind
of binary data".
Again, we agree EXCEPT for zero bytes. This means that any binary data
with any zero bytes (and in my experience binary data almost always seems
to contain some small 16 bit integer values less than 256 - which means an
upper byte of zero) will not be written out correctly block by block. Even
one or two missing zero bytes completely changes a block of binary data.
Perhaps TECO under RSX-11 does not have this problem. Can you check?
Johnny Billquist wrote:
OK!! I
understand completely!! If anyone else who is interested
does not
understand, please ask some questions.
If the ASCII data in question was not in the first buffer, than I assume
that
something like the TECO command:
<ASstring$:;J9999K>$$
was what you used to find the start of the file which you had lost.
Well, yes and no.
What you actually do is:
ERfilename$_string$$EWnewfile$HPW$EC$EX$$
(assuming that all the data you are interested in are in the buffer,
otherwise include P commands in there to the appropriate amount,
before the HPW.)
If you really want to use A to append more data from the disk, you
should probably not use 9999K to dump the current buffer, but use HK
instead.
Also, if a search fails, you'll aready be at 0, so no reason for the J
command. By the way,
KED can do the same, but is limited to devices (I assume
that
you must have done a non-file-structured open, i.e. ERdev:$$) that
are less
than 32768 blocks. Since I have never had occasion to edit a full MSCP
device of 65535 blocks, I just never noticed the limitation. This
restriction
for KED also applies to files. So KED can INSPECT a logical device
which
is 32767 blocks or less or an RL02 device, but no physical device or
file
larger than 32767 blocks in total.
TECO itself will not care, so that would be a limitation from the
RT-11 point of view, in that case. TECO will serially read a file (or
device) from start to finish, and don't really care about the file
position information as such. More than
likely, you just found the source ASCII text you were looking
for and wrote
that to the floppy file using something similar the the TECO command
that I suggested.
TECO is not designed nor able to show individual words of a specific
block as SIPP
is able to do.
Not sure what SIPP is, but TECO can handle, and display, anything. It
was designed to be able to deal with any kind of information, not just
text. TECO can
certainly read disk block N, and having done that it can
surely
>mangle that disk block; what I'm not sure of is whether it can then
>write that block out to the required disk block. Binary data
can't be managed easily, if at all, by TECO such as what
SIPP can do.
No. TECO handles binary data just fine.
Whenever you enter text, all characters are allowed. And by all
characters, I really mean all characters. Control characters are just
as welcome as printable ones. A few characters have special meaning in
TECO, such as ESC, ^C, and a few more. ESC can be used by instead
setting another character as the delimiter for the search string.
Other special control characters can be inserted by prefixing them
with ^Q, which means that the next character should be taken
literally, and not be interpreted. For most characters though, nothing
special is needed at all, and you can just enter them in your search
string. In the case you don't really want to type the
control characters as
such, you can create the search string before using it, and then just
suck it into your search string as well.
In addition to this, you also have the powerful pattern matching of
search strings, that TECO gives you. So you can say that any character
should match at a specific position, and then match whatever comes
after more specifically as well (or any number of other potential
pattern matching schemes you can think of).
TECO is definitely MUCH more powerful than KED in respect of searching.
Indeed, on a few rare situations when I have a dozen or more of a string to
change, I use TECO.
Can you please specify if TECO under RSX-11 retains or ignores zero
bytes in a file when it exits after an initial EBTST.TXT$$ command. If
TECO under RSX-11 retains zero bytes, then I agree that TECO can then
be effectively used for patching binary data.
In addition, if RSX-11 is able to run RT-11 programs in some fashion
(as for example RSTS/E is able to run RT-11 programs under its RT-11
RTS), then you can also use SIPP to make true binary modifications to
a disk or file.
Jerome Fine
5139
days inactive
5140
days old
1 comments
2 participants
participants (2)
-
bqt＠softjar.se -
jhfinedp3k＠compsys.to