DUMPER v532 27-Aug-85
This list indicates changes in behaviour from DUMPER v407. It is quite
long, but a number of changes that you should be aware of are listed here.
You should especially keep this file for reference if you change Releases
of DUMPER or the Monitor or customise DUMPER in any way (including and
especially changing the feature test switches).
IMPORTANT NOTE on CREATE
DUMPER can be compiled to run under release 5 or 6 by setting FTVERS
to the proper value (5,6) and compiling DUMPER. The version distributed is
built for version 6. It uses a number of features that only exist in the
Release 6 Monitor, and running this DUMPER causes an immediate error
message under Release 5.
However, while DUMPER built for 5 can run under either release 5 or 6,
care must then be taken when restoring tapes written under a release 6
monitor, with CREATE mode on for both SAVE and RESTORE. A DUMPER compiled
for release 5 will write tapes that do not contain proper encryption data.
Nor can it Create directories with encryption properly set, even if the
tape was written by a Release 6 system with DUMPER built for Release 6.
Further, DUMPER built for release 5 will not issue any error messages
when it creates directories from tape that have encrypted paswords.
However, DUMPER built for release 6 will properly handle tapes
containing encrypted passwords and un-encrypted passwords. It will also
handle specially the case of attempting to creating directories with
encrypted passwords to a non-encrypted structure, or other cases that could
cause a password to be permanently LOST. When it detects such an error, it
will type a long error message and EXIT. You can continue if you want files
restored in any case, regardless of the consequences to the passwords.
In other words, you can no more bring a tape written under a Release 6
monitor with encryption IF IT CONTAINS DIRECTORY INFORMATION (ie, written
with CREATE and restored with CREATE) than you can bring a disk from an
encrypted, Release 6 system to a Release 5 system. The cases are identical.
Do NOT specify the CREATE command on a RESTORE unless you are aware of the
ramifications of WHERE the tape was written, under WHICH DUMPER and
TOPS-20, and TO WHAT you are restoring it. ALWAYS make sure a newly-created
directory has been restored with the correct password before logging out
jobs.
Of course, there is no problem with doing a RESTORE with CREATE on the
same system that SAVE was done on if the version of DUMPER and TOPS-20 have
not changed. The problems only arise when changing from release 6 to
release 5 of TOPS-20 (or bringing a tape from release 6 systems to a
release 5 system).
If you have both Release 5 and Release 6 systems, your best defense
against confusion is never to move tapes from system to system that have
been written with CREATE specified. Your second best defense if to compile
DUMPER with FTVERS set to the proper release number of the Monitor it will
run under, thus giving it the maximum amount of defensive code possible.
Other behaviour changes (other than functionality extensions) are
listed below:
1. DUMPER will write tapes that the old DUMPER may give warning messages
while reading. Also, author and last writer names associated with files may
be restored incorrectly.
There should be no other problems in using the old DUMPER
with new DUMPER tapes, unless you change certain Feature Test switches.
See the next note.
2. Some of the functions done by DUMPER, especially special services done
for Archival, are under conditional assembly. You can
turn off usage accounting in DUMPER if you don't use it, for example.
If you do change any feature test switches, you MUST mention it in any
QAR or SPR you send us.
The things that might be changed are:
FTINVI if turned off, user-requested archive files are not set
invisible after DUMPER moves them to tape.
FTUSAG if off, DUMPER does not write USAGE records when doing
Archival. This saves a small amount of runtime.
FTMONI if off, DUMPER does not test to see if it is a v6 DUMPER
running under a v5 Monitor (which fails). This test is
not needed or performed if FTVERS is 5.
FTASKR controls the behaviour of DUMPER when it discovers a file
it is RETRIEVing does not have the same name it was
archived with. This can happen (Archived files can be
renamed), but may indicate a file is being improperly
RETRIEVEd.
FTCKPN if off, will prevent the LIST file from being checkpointed
after every page of output.
*****> FTCHKS if off, has several ramifications. The most important is,
ANY TAPE WRITTEN BY A DUMPER WITH FTCHKS=0 WILL BE
UNREADABLE TO ANY DUMPER PREVIOUS TO EDIT 500. FTCHKS=0 turns
off the computation of the checksum DUMPER uses internally
to see if a record has been read properly from tape. The
checksum operation is an expensive one in terms of CPU, and
is normally performed on both write and read. If, when
reading a tape, new DUMPER discovers an incorrect checksum,
all it does is issue a warning message. Hence, some sites
will wish to turn the checksum operation off, hence getting
a faster DUMPER. But old DUMPERs will see tapes written
this way as having a bad checksum in every record, and
refuse to read the tape. Be careful. If you are sending
tapes to sites that may be running a DUMPER previous to
version 500, do not turn FTCHKS off!
3. This version of DUMPER can be built to run on a 4, 5 or 6 system.
FTVERS controls this; you would set it to 5 to run on any TOPS-20 version
5.x system. In the given version, DUMPER will notice when it has
been built for TOPS-20 v6, but the monitor is version 5. Turning off
FTMONI causes DUMPER to not bother checking the monitor version at startup.
If you are seeing illegal instruction traps at startup, you are probably
running a v6 DUMPER under a v5 Moitor with FTMONI turned off. FTVERS=6,
as mentioned, creates a DUMPER that cannot run under TOPS-20 release 5.
If you change ANY of the conditional assembly flags (FTxxxx values), you
must tell us of the fact in any SPR you send. Failure to do so
will cause us to be unable to trace any problem you are seeing.
A DUMPER BUILT FOR RELEASE 5 OF TOPS-20 CANNOT PROPERLY RESTORE ENCRYPTED
PASSWORDS (A FEATURE OF TOPS-20 RELEASE 6). See the note at the top of
this file.
4. The working of ^E is now slightly different. After ^E is typed, you
are given a prompt as always, but the available commands is a subset
of the normal list and also contains an addition - ABORT.
It is no longer possible to give a command that would interfere with
an already issued command without typing ABORT first - they simply aren't
available until ABORT is typed. Of course, ABORT aborts the interrupted
command.
Also, ^A and ^E beep (type a ^G) when they are inapplicable (they do not
type out %NO INTERRUPTABLE COMMAND... anymore). Finally, a ^E typed
just as a command finishes (and hence isn't worth interrupting) will earn
the message "INTERRUPT IGNORED".
5. Restart files (DUMPER-TAPE-IN-PROGRESS.tape) are no longer written
between reels, due to the philosophy change concerning EOT handling.
6. A few of the error and informational messages have been humanised somewhat.
DUMPER.ERR explains some of these errors.
7. The SAVE/ARCH and SAVE/MIGRATE options are invisible and
should no longer be used.
8. Saving a file that is open for thawed access by someone else will
succeed as it previously had, but also earn a warning message to the
terminal. This is for database sites who often have files opened
thawed 24 hours a day and hence cannot have any guarantee that the
saved file will be meaningful after being SAVEd and RESTOREd.
9. The argument given to a ARCHIVE, MIGRATE, or SAVE/[FULL-]INCR has a
restriction on the use of wildcards. Any field that is wild may only
consist of the string "*", ie. something like A* or B%% is no longer
legal. The only exception is DSK*:.
10. Archive/Collection/Migration savesets are now numbered in increasing
order despite interviening tape changes. IE, If archive saveset 5
has to be continued on tape 2, then the first saveset on tape 2 will
be numbered 5, and the one after that, 6. Starting a new tape starts
the saveset number at 1. This change should be invisible to the user.
11. Saves that record DDB information (ie, Incrementals) will write ALL
pertinant DDB's first, before writing ANY files to tape. This causes
DUMPER to move slightly faster and yields a better organised tape.
12. The LIST file format is slightly different.
13. The CHECK command now ignores the settings of MSINCE and friends. This
is more consistent with what the CHECK command should be doing.
14. The CHECK command does not actually check the contents of each tape file,
it now only checks the file information. Checking the File Descriptor
Block is normally enough to tell if a file has been modified. The CHECK
command also consumes less CPU this way. Also, CHECK now ignores the FILES
command, so it always only types out filenames that have disagreements with
their counterparts on disk.
15. Previous versions of DUMPER would wait forever during RETRIEVE if there
were no requests in the retrieve. The new version will give up after
several minutes, issue a warning message, and act as if QUASAR told it that
there were no more retrieval requests. The amount of time it waits
can be set to n minutes, where n is the value of WAITTM. A zero value
of WAITTM will cause DUMPER to wait until a retrieval comes along, which
is the old DUMPER's behaviour.
16. The RETRIEVE command does not automatically send mail anymore. It can,
however, write the files retrieved to a list file, if one is provided, and
this can be used with the new MAIL mechanism to send mail to users having
files retrieved (see the DUMPER.DOC file).
17. Some informational messages, usually enclosed in [brackets], have been
added. For instance, this convention is used to remind you if you have
set "screening dates" with the various SINCE or BEFORE commands, give
a SAVE command, and go on to give a second SAVE command without clearing
them (some sites have been suprised to learn they stay active until
cleared). Also, see the next point.
18. In this version, a normal SAVE command, and any kind of Incremental SAVE
command, will obey FB%NOD - that is, files with this bit lit are not saved
on tape. During Archival, Migration, and similiar types of saves, FB%NOD
is completely ignored. This helps prevents users with WHEEL from escaping
Migration policies. Other flags, that ALWAYS prevent a file from being
saved on tape, are: FB%DIR, FB%NXF, FB%NEX, FB%DEL, FB%TMP.
19. TAKE followed by a <CR> can be used to end a TAKE file and supress the
[End of filename] message otherwise typed at the end of a take file.
If you are processing a TAKE file and type ^E, commands
are taken from the terminal until you type CONTINUE. If you type
TAKE<CR> to the DUMPER>> prompt, the TAKE file currently active (if
any) will be ended at the end of the command you have interrupted.
20. Files which are Archived will now be picked up by the next SAVE/INCR
command.
21. RETRIEVE will now ignore the permanant quota of the directory it is
restoring a file into - it only checks the working quota.
22. Using REEnter to start DUMPER is like STARTing it, but first DUMPER
types out its version number and the values of the Conditional flags.