Conference noted::hackers_v1

If your main interest is in knowing how many people are copying
various files you've advertised, one method is to *not* set them
world-readable, but instead advertise (with MAIL or VAXNOTES conference)
something like:

	If you'd like the such-and-such file, please send me mail

Then, when they send mail you can send them the file in MAIL, and also
FILE their message as an indication of who is asking.

If the files you are interested in are .COM files, another method I've
found useful is code like this, near the *end* of the .COM file:

	$ !
	$ !	Announce existence if newly installed.
	$ !
	$ if f$search ("sys$login:blah_blah.installed") .nes. "" then -
	    goto already_installed
	$ mail nl: raynal::osman /subject = -
	    "blah_blah version ''version' installed by ''username'"
	$ create sys$login:blah_blah.installed
	
		This file indicates that you have installed the blah_blah
		procedure.   Please leave the file in place.
	
	$ already_installed:

The reason to put it near the end, is so that you receive the announcements
not from everyone that runs your tool, but everyone that *successfully*
runs it.

/Eric

FAL LOGGING CAPABILITY					Jim Krycka
							02-FEB-1981

FAL has a built-in logging capability that is useful for gathering throughput
statistics and otner information, for enabling/disabling access options,
and for diagnosing DAP related problems. This diagnostic tool was developed
to aid Development and Software Specialists; there are no plans to document
it for coustomer use.

On startup, FAL attempts to translate the logical name 'FAL$LOG'. If the
translation succeeds and the equivalence string is of the proper form,
the FAL will log results to 'SYS$OUTPUT' (which is FAL.LOG by default).
If the translation fails or the equivalence string is invalid, logging
will not occur.

For logging to work, the equivalence string for 'FAL$LOG' must be of the
form 'x' or 'x_y', where x is a hexadecimal bit mask and y is a hexadecimal
number. For FAL distributed with DECnet-VAX V2.0, the bit mask is defined
as follows:

    .	Bit 0 set enables logging of the name of the file being accessed
		and DAP error codes that are returned by FAL.
    .	Bit 1 set enables logging of throughput statistics and other DAP
		related performance information.
    .	Bit 2 set enables logging of individual DAP messages as they are
		encoded (built) or decoded (received and processed). By default
		the first 20 (14 hex) bytes of each DAP message are displayed.
		If the 'x_y' form of the logical name is specified, then y
		represents the number of bytes per message to display.
		Note that the bytes of a message are displayed in
		hexidecimal and are read from right to left!
    .	Bit 3 set enables logging of transmit and receive AST completions,
		including the number of bytes transferred. Since DAP messages
		may be blocked into packets, there is only one AST per message
		packet transferred.
    .	Bit 4 set enables logging of posting of QIO requests for the logical
		link and the associated mailbox.
    .	Bit 5 is undefined.
    .	Bit 6 set disables DAP message blocking.
    .	Bit 7 set disables file level CRC checksum generation and comparison.
    .	Bit 8 through 31 are undefined.

NOTE: The above definitions are subject to change.

'FAL$LOG' may be defined as a system-wide logical name:

	$ DEFINE/SYSTEM FAL$LOG 80	! Disable CRC checking

(or as a local name in FAL.COM (or LOGIN.COM):

   	$ DEFINE FAL$LOG 1		! Display filename
	$ RUN SYS$SYSTEM:FAL.EXE
	$ PURGE/KEEP=6 SYS$LOGIN:FAL.LOG
	$ LOGOUT/BRIEF

   	$ DEFINE FAL$LOG 3		! Display filename and statistics
	$ RUN SYS$SYSTEM:FAL.EXE
	$ PURGE/KEEP=6 SYS$LOGIN:FAL.LOG
	$ LOGOUT/BRIEF

   	$ DEFINE FAL$LOG 5_14		! Display filename and first 20 bytes
	$ RUN SYS$SYSTEM:FAL.EXE	!  of each DAP message
	$ PURGE/KEEP=6 SYS$LOGIN:FAL.LOG
	$ LOGOUT/BRIEF

   	$ DEFINE FAL$LOG 1F_50		! Display everything including first 80
	$ RUN SYS$SYSTEM:FAL.EXE	!  bytes of each DAP message
	$ PURGE/KEEP=6 SYS$LOGIN:FAL.LOG
	$ LOGOUT/BRIEF

    Are there similar logging/tracing capabilities in other components
    of DECnet?

    re: .2
    
    	This is just what I was looking for, many thanks!
    
    One more question tho.  The output doesn't appear in fal.log, it's
    in [decnet]netserver.log.  Am I doing something wrong, or is sys$output
    pointing at netserver.log by default, and if so, can I point it
    at a file?  Also, will this work if the remote user says:
    
    dir sndbox""::mumble
    
    or does that disable FAL?
    
    Willie

    Back in the stone age, every network object had its own .COM input
    and .LOG output file -- FAL.LOG, NML.LOG, PHONE.LOG ...
    
    Nowadays everything goes thru NETSERVER (performs better, I'm told)
    so in fact the documentation in .2 is simply out of date.
    
    If the remote user omits access control (node""::etc) that will not
    affect things in and of itself.  Note that if a user gives explicit
    access control (hence, has an account on your node) and has a
    LOGIN.COM, then he can do things such as run his own FAL.EXE and
    you'll never see that.  But of course if he has access control then he
    probably can already do directories of your system so that's not much
    of a consideration.   (No, it doesn't disable FAL).
    
    As far as redirecting SYS$OUTPUT goes, it is possible but you'll just
    have to play around a bit because the answers depend upon lots of
    configuration and privilege issues, as well as how far you want
    to carry this.

      John

    No biggie, if it was easy, I'd do it, or try to figger out a way
    to mung it all up into one big file and print out a synopsis every
    week, but there's not much excess verbosity in the netserver.log
    files, so I'll just collect those.  I took the purge/keep: line
    out of the netserver.com file, so I don't lose them.
    
    Many thanks for all the help!
    
    Willie

Re .3:

	If you want to get bombarded with info when you use NCP, try

		$ DEFINE NML$LOG FFFF

	I don't remember what all the bits switch on, but:

		Bit 0: shows NICE messages sent and received;

		Bit 2: shows parsing of received messages.

						TMJ

      The bit definitions for NML$LOG, FAL$LOG, and EVL$LOG are listed
      in note 21.5 in the conference BULOVA::DECNETVAX (hit KP7 to
      add it to your notebook).
      
      Dave C.