Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

			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.