home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Beijing Paradise BBS Backup
/
PARADISE.ISO
/
software
/
BBSDOORW
/
BBSDOOR2.ARJ
/
RASIS202.ZIP
/
RSU10.ZIP
/
RSU.DOC
next >
Wrap
Text File
|
1995-08-26
|
44KB
|
943 lines
┌──────────┐ ┌─────────┐ ┌────┐ ┌────┐
─══└┐ ┌───┐ │══════│ ┌────┐ │═════└┐ ┌┘═└┐ ┌┘════─
─══│ │ │ │══════│ │════└─┘══════│ │═══│ │═══─
─═│ └───┘ │══════│ └──────┐══════│ │═══│ │═─ Version 1.0
─══│ ┌┐ ┌──┘══════└──────┐ │══════│ │═══│ │══─
─═══│ │└┐ └┐════════┌─┐════│ │══════│ │═══│ │════─
─═┌┘ └┐└┐ └─┐══════│ └────┘ │══════│ └───┘ │══─
└────┘ └───┘ └─────────┘ └─────────┘
RemoteAccess Sysop Utilities
(c)Copyright 1995, Rand Nowell/RaLin Enterprises
"Putting Bits Together" (tm)
More Cowboy Software!
"A Companion Program to RASIS"
(RASIS REQUIRED)
TABLE OF CONTENTS
Legal Note........................1
Authors Note......................1
In General........................1
System Requirements...............2
Utility Modules Available.........2
Screen Display....................3
RSU Call Signs....................4
Set User Flags : SETFLAG........4
Password Requirements: PWMOD....5
Kill 1 Time Callers: KILLOT.....6
Modify Security Levels: SETSEC..8
Pack Conferences: PACKRTC.......9
Locate Files: LOCATE...........10
User Uploads: WHATFILES........11
Pack Msg/File: PACKFM..........12
Swap Name/Handle: SWAPHANDLE...12
Change Uploader Name: UPLOADER.14
RSU For You Making A Few Sysop Chores Easier To Do! Page 1
──═══════════════════════════════════════════════════════════════════════───
Legal Note
──═══════════════════════════════════════════════════════════════════════───
RSU is a part of RASIS, and falls under the same statements found
in the Legal and Distribution Sections of RASIS.DOC
──═══════════════════════════════════════════════════════════════════════───
Authors Note
──═══════════════════════════════════════════════════════════════════════───
During the Development Stage of RSU, the only copy available is
one that uses the same support files as does RASIS. Thus there
is much information that is not required, and causes a program
size larger than it should be.
Once the initial version of RSU has been released, and a few
more functions are added, a STANDALONE copy will be produced.
This will use its own configuration, and will NOT require that
RASIS, and its configuration be present. That version will
allow RA sysops who do NOT run RASIS, to also have a copy.
Users who register RASIS, and consequently DO have a "Registered"
RSU, will receive a RSU registration code at no charge, should
this be required.
This is all a rather MESSY way to do this, I realize, but
using the RASIS configuration file, was the easiest way to
develop RSU. But I do wish to make RSU available in a standalone
version, so other sysops, not just RASIS users, may use it. So
some major changes will have to take place.
But never fear!! My RASIS registered users WILL be take care of!!
──═══════════════════════════════════════════════════════════════════════───
In General
──═══════════════════════════════════════════════════════════════════════───
RSU stands for RA Sysop Utilities.
This particular version is a part of the RASIS program package.
Future versions will be available as a stand alone program, but
registration WILL be included with that of RASIS.
RSU reads RASIS.CFG and gathers important information, along
with your Registered status.
Some modules in RSU are not available unless you ARE a registered
user of RASIS. They are noted with {+}
Module HELP screens ARE available to unregistered users.
*CAUTION:
RSU contains options that MODIFY FILES!
When you are first learning how to use the modules, its
wise to make BACKUPS of the system files that will be modified.
RSU For You Making A Few Sysop Chores Easier To Do! Page 2
Some changes are easy to correct, others not so.
= You HAVE been warned! =
──═══════════════════════════════════════════════════════════════════════───
System Requirements
──═══════════════════════════════════════════════════════════════════════───
RSU requires 200kb minimum of memory available at runtime.
This may become lower, at a later date, depending on new features
added, and further optimization methods.
You need RASIS 2.0 or greater, and RemoteAccess 2.0 or greater.
No testing has been done on earlier versions of RA.
And WILL NOT work with RASIS version prior to 2.0
──═══════════════════════════════════════════════════════════════════════───
Utility Modules Available
──═══════════════════════════════════════════════════════════════════════───
Currently RSU contains the following Utility Modules.
o Set User Flag (SETFLAG)
Allows you to set a user flag to ON or OFF.
May be run on ALL users, or those with
a specified Security Level.
This function can be very helpful in numerous ways.
o Password Change Requirements (PWMOD) {+}
Two functions are implemented here.
One will set the value in CONFIG.RA for
OPTIONS -> SYSTEM -> Pwd Change, which is the
number of calls a user makes before a change of
password is required.
The other sets the "Pwd change" field in USERS.BBS for
the user,this is the number of calls since they last did a
password change.
Between the two options, which MAY be run together, you
can change requirements at will, and very quickly!
o Kill One Time Callers (KILLOT)
Allows you to mark as deleted, any user having not called
within a day range you supply. ie: If they have not called
in the last 120 days, mark them as deleted. You can also
have another program, such as RAUSER.EXE run after the
module has completed it's work.
o Modify Security (SETSEC)
You can change the security for one user,
Modify a specific level, changing to the new level,
ADD specific number to current level.
RSU For You Making A Few Sysop Chores Easier To Do! Page 3
Adding and changing can operate on ALL or SOME users.
User name is validated.
o Pack RTC File (PACKRTC) {+}
For Pro Versions - When a Real Time Conference is deleted
from RA, the record is left in the CONF.BBS file. This
module will remove those deleted conferences, "PACKing"
the file into a smaller size.
o File Locator (LOCATE)
You can search the File Database for any file, or
filespec. DOS Wildcards are fully supported. It searches
areas defined in FILES.RA that are active. It searches
ALL filepaths listed, this allows easy duplicate
detection.
o User Uploads (WHATFILES)
This will tell you which files a specific user has
uploaded, listing filenames and sizes. Also gives total
number of files, and size. Can be also sent to a text
file.
o Pack MESSAGES.RA or FILES.RA (PACKFM) {+}
This will remove UNUSED areas from one or both of these
files. Any renumbering of areas is handled properly.
Support for RA 2.5x is available.
NOT YET AVAILABLE TO PUBLIC
o Swap User Handle<>Name as Uploader. (SWAPHANDLE) {+}
Lets you place a users handle in the uploader field in
the file database. Can be run on ALL areas, or may be
limited to ONE area.
o Modify Uploader Name(s) (UPLOADER)
Replace blank entries, replace one type name with another,
ie: ALLFIX with 'Sysop' or your name. Can be run on one
specific Data File (FDB) or all files.
──═══════════════════════════════════════════════════════════════════════───
Screen Display
──═══════════════════════════════════════════════════════════════════════───
When RSU is fired up, it displays a Program Header at the top
of the screen. In this header is the following information.
PROGRAM NAME VERSION
COMPILED DATE/TIME
MODE {+} or {N/R}
copyright notice
Most of it is obvious, the MODE field displays what module is
loaded, and what it does. And of course the legend at the far
RSU For You Making A Few Sysop Chores Easier To Do! Page 4
right displays whether its running in Registered or UnRegistered
mode.
The screen area underneath the Header is where all messages,
filenames, lists etc. are displayed. Screen listings are done in
a "window" so the Header does not scroll off the screen during
program runtime.
RSU will determine your current video mode, ie: if running in
43/50 line mode, and set its display to same.
The screen display window for output, is set to 2 rows less than
your current screen height, so nothing will scroll off the screen
at program end..... theoretically. This allows for the prompt,
and perhaps another programs "Type EXIT to return" line to be
written at the bottom, without scrolling off RSU's display.
──═══════════════════════════════════════════════════════════════════════───
RSU Call Signs
──═══════════════════════════════════════════════════════════════════════───
The internal utility modules are run by supplying a "Call Sign"
as the first item in the command line. The call sign is
followed by any required switches for that particular module.
We will cover the Call Signs, and each modules switches in this
manual, and they are also available in the Main Help screen.
(RSU ?)
The call signs, and switches may be supplied in either Upper or
lower case. Some modules require that parameters/switches be in
a specific order, and some do not. Any value shown in angle
brackets <> is a required one, if shown in square brackets []
it is an optional one.
An EXAMPLE command line would be RSU SETFLAG <sw> <sw> [sw]
*MODULE HELP SCREENS:
In command line mode, a help screen for a particular module, may
be displayed by calling the module with it's Call Sign, followed
by a question mark (?). To display the help screen for the
FlagSet module, you would type RSU SETFLAG ?
──═══════════════════════════════════════════════════════════════════════───
Set User Flag - SETFLAG
──═══════════════════════════════════════════════════════════════════════───
SETFLAG [USER FLAGS] - The call "SETFLAG" loads and runs the
Flag Setting module, accepting the following switches and values
as its instructions. The values for FlagSet MUST be in the
RSU For You Making A Few Sysop Chores Easier To Do! Page 5
proper order!
To set a flag for the users, you need to supply the FLAG, the
setting: ON/OFF and optionally the security level to act upon.
Values for FlagSet do NOT need any preceding - or / before them.
If no security level is given, then ALL users are affected.
Flags and Security levels are checked for validity, if the item
is wrong, or in the wrong order, the program will abort with an
error message.
Flags are presented in the same manner as you would think of
them, or say them, ie: A3 - D4 - B7 and so on.
On or Off is self explanatory...
The security level determines WHICH user's flag will be changed,
if you supply a security level of 100, then only users with that
security level will have their Flag changed.
The security level can be any value from 1 to 65535. Any more, or
any less and RSU will abort with an error message.
Error messages will show you what item caused the error.
Example Commands:
RSU setflag b7 on - will set flag B7 ON for ALL users.
RSU setflag a5 off - will set flag A5 OFF for ALL users.
RSU setflag d6 on 150 - will set flag D6 ON for any user with
a security level of 150.
Fairly simple, and it happens fast!
──═══════════════════════════════════════════════════════════════════════───
Password Change Requirements - PWMOD
──═══════════════════════════════════════════════════════════════════════───
PWMOD [PASSWORD] - The call "PWMOD" loads and runs the Password
Change module, accepting the following switches and variables as
its runtime commands.
SWITCHES:
All switches for the Password Requirement options must be
preceded by either the minus (-) or the slash (/) character.
Immediately following the switch, there must be a colon (:) then
the value to be passed to the module. Example: -E:6
-E This switch tells RSU to set the number of calls between
required password changes, in CONFIG.RA The value
supplied may be from 1 to 65535 and is supplied in this
format: -E:DAYS, where DAYS is the number.
The -E may be used alone, or in conjunction with the commands to
modify the user's record. If so, this portion will run
BEFORE the user records are modified.
RSU For You Making A Few Sysop Chores Easier To Do! Page 6
The following switches are used to modify the number of days
since the users LAST password change, in USERS.BBS.
Immediately following the switch, there must be a colon (:) then
the value to be passed to the module. Example: -L:6
<-L> Gives the number to place in this field, the value
supplied may be from 0 to 255 and is supplied in this
format: -L:DAYS, where DAYS is the number.
[-S] Gives the security level of the user to be modified.
If no security level is supplied, then ALL users are
affected, else only those with this same security level
are changed. The value supplied may be from 1 to 65535,
and is supplied in this format: -S:SEC, where SEC is the
Security Level to check. (Optional Item)
The -E, -L, -S, may all be run at the same time, order of
placement is not important. Upper/lower case is accepted.
──═══════════════════════════════════════════════════════════════════════───
Kill One Time Callers - KILLOT
──═══════════════════════════════════════════════════════════════════════───
KILLOT [Kill One Timers] - The Call "KILLOT" loads the module
to "Kill" one time callers. What it actually does, is mark the
users record as DELETED. It does NOT actually PACK the user
file, BUT you CAN supply a program or batch file name to run upon
completion of the modules run.
The deleting of a record is done based on the number of days
since the users last call. You supply the maximum allowed span of
days. The check is based on the systems CURRENT date, and the
date of the users LAST call. If the number of days calculated,
exceeds your defined maximum, the record is marked as deleted.
You can limit the deleting to a specific SECURITY level, if you
wish.
INFORMATION DISPLAY:
If you give the NoKill command, a line will print to screen,
saying "Honoring NoKill Flag"
Then a line is displayed similar to the following:
Max Days Since Last Call <10> Security Level <20> Program:
After program will be displayed the program name given on the
command line, or "None..." if none given.
Then it displays "Scanning....."
Once completed, the module will tell you how many records were
read, and how many were marked as deleted.
During the scan, any user who is marked as deleted is listed to
RSU For You Making A Few Sysop Chores Easier To Do! Page 7
the screen as:
DELETED "User Name" (days since) where days since is how long
since the last call. If there is an invalid or empty date field
in the record, this is also noted, and the record is deleted.
See INVALID DATES below.
VERY IMPORTANT NOTE!
By default, ANY user will be deleted if they match the criteria
set by you, even those with the NoKill Flag set. But you DO have
a command that will allow those with the NoKill set, to be
skipped. You must be aware of this.... if you do NOT give the
command, explained below, a user WILL be marked as deleted, if
they exceed the maximum days, even with the flag set.
INVALID DATES:
Another quirk, if you may call it that, is if the date of the
callers last call is blank, it is considered an INVALID date, and
will be marked as Deleted. So if you have entered users who have
not yet called, and you do NOT want them deleted, you need to
either set their NoKill flag, or enter a recent date in the file.
GUEST ACCOUNTS...
If a user record is marked as a GUEST account, it is never
deleted by KILLOT, regardless of any commands given.
The following switches set the guidelines for the deletion. All
but the NoKill one require that they be preceded by a minus or
slash, ( - / ), be followed by a colon, and following the colon,
the value you wish to pass to the program.
<-D> Gives the maximum number of days allowed, since the
users last call. Calculated as the difference between
the current date, and the date of last call.
Format: -DMaxDays Range: 1 to
[-S] If you supply a Security Level, only users with this
same security will be affected by the module.
Format: -SSecurity Range: 0 to 65535
[-NoKill]
If this command is given, the module will honor the
NoKill flag in the record. ie: if set, the account will
NOT be deleted, regardless of days/security. REMEMBER!!
If you do NOT supply this, the NoKill flag is IGNORED!
[-R] This switch, followed by a filename, will RUN the
filename after the module has completed its work. This
can be a program name, or a batch file. Any spaces in
the name MUST be replaced with the UnderBar ( _ ).
See RUN PROGRAM below.
Format: -RProgram_<program switches>
RUN PROGRAM:
RSU For You Making A Few Sysop Chores Easier To Do! Page 8
What happens here is that the name you supply is STUFFED into the
keyboard buffer, along with a RETURN Keypress, upon termination
of the program module. So it's just like you typed it at the DOS
prompt.
There is a limitation of 15 characters that may be stuffed into
the buffer, and we use ONE for the Enter/Return Keypress, so that
leaves 14 characters available.
A normal 12 character filename is perfect. If the program is in
your DOS PATH, you do not need to give the extension, which
leaves room for some program switches. (Not Many)
If the program requires many switches, or does not exist in the
Dos PATH, you should create a BATCH file to run the other
program, and give the BATCH file name here. Most Sysops will
want to run RAUSER after RSU KILLOT, to pack the user file.
The minimum command would be RAUSER -P, and if you want user
names logged, you also need the -V. Using this example, and
remembering that spaces must be replaced with the underline
character, the command becomes: -RRAUSER_-P_-V
If you were to put the RAUSER commands in a batch file called
UPAK.BAT, then the command becomes -Rupak
So a full usage command line for Killing one time callers might
look like the following:
RSU killot -d10 -s20 -nokill -rrauser_-p_-v
──═══════════════════════════════════════════════════════════════════════───
Modify Security Levels - SETSEC
──═══════════════════════════════════════════════════════════════════════───
SETSEC [SECURITY] - The Call "SETSEC" loads the Security Level
module, which allows you to change security for one or more
users, quickly and easily. You can replace or add to.
SWITCHES:
All switches for the Password Requirement options must be
preceded by either the minus (-) or the slash (/) character.
Switches may be in any order or case.
Immediately following the switch, there must be a colon (:) then
the value to be passed to the module. Example: -S:50
All numeric values for Security Changes, must be in the range of
0 to 65535. Any other will generate an error.
Examples follow switch explanations.
[-N] Give a user name, only this user will have their security
changed to that which you supply. Names MUST have any
spaces replaced by the UnderBar ( _ ), they will be
removed by the module. User names are validated, if the
user does not exist, obviously no changes will be made.
RSU For You Making A Few Sysop Chores Easier To Do! Page 9
Format: -N<first_last> (Don't forget use _ for space)
<-S> New Security, whether you are assigning the new security
to a particular user or current level, or adding so much
to a particular level, this switch is always used. The
new security level follows immediately after the colon.
Format: -S<NewSec> Range: 0 to 65535
[-O] Old, or Current Security level, used when wishing to only
change users with a certain security, either by supplying
a new level with the -S or by ADDing to the current
level.
Format: -O<OldSec> Range: 0 to 65535
[-+] The PLUS sign tells the module to ADD this value to the
existing security level. It can be used with the -O to
add to only specific security levels.
When this value is added to the users current security,
the result is checked, if it is LESS or GREATER than the
allowed values, then the users current security will NOT
be changed.
Format: -+<ValueToAdd> Range: 0 to 65535
Example Commands:
RSU SETSEC -NJohn_Doe -S75
Will change John Doe's security to 75, regardless of what
it currently might be. (Notice the _ in the name)
RSU SETSEC -S30
Will set ALL users to Security Level of 30
RSU SETSEC -O30 -S40
Every user with a Security Level of 30, will be changed to
a Security Level of 40.
RSU SETSEC -+15
Will ADD 15 to every users current security. ie: If the
user has a security of 40, it will be changed to 55. One of
10 will become level 25 and so on. As mentioned earlier,
RSU will not allow a users security to be set below 0 or
over 65535.
RSU SETSEC -O40 -+10
Will ADD 10 to any security level of 40. Rather redundant,
the command -O40 -S50 would be a better method, but it
can be done this way.
──═══════════════════════════════════════════════════════════════════════───
Pack Conference (RTC) files - PACKRTC
──═══════════════════════════════════════════════════════════════════════───
PACKRTC - Removes deleted conferences from the CONF.BBS file.
This is only worth anything to users of the PRO ver.
RSU For You Making A Few Sysop Chores Easier To Do! Page 10
When you delete a conference in RA, it simply blanks out the NAME
of the conference, then the record is reused at a later time, for
a new conference. No biggie, but some Sysops don't like the file
to be any larger than needed.
PACKRTC will remove these inactive conference records from the
file. PACKRTC will make a backup of the file, in case your
system hangs/crashes during the pack operation, allowing you to
recover the information. It is DELETED after packing is done.
However, you can, if you wish, have the module KEEP the backup
file, simply use the ONE switch/command available to this module,
-BAK tells RSU to NOT delete the backup file.
The backup file is a normal dos type backup, named, you guessed
it, CONF.BAK
──═══════════════════════════════════════════════════════════════════════───
Locate Files - LOCATE
──═══════════════════════════════════════════════════════════════════════───
RSU allows you to locate files in the RA file database.
When you do a locate, all file areas that are active in FILES.RA
are searched. Full DOS wildcard support is available. You may
also, in the event of a search you KNOW is going to produce more
than a screen full of filenames, have the list of found files
written to an Ascii text file.
The locate module will not stop when it finds a match, it
searches ALL file base directories. This is done to facilitate
duplicate detection. But it works fast, so this should not be
too big a problem.
NOTE: Locate will find files that are NOT in the File Database
also, if they are in the DIRECTORY that is setup for that area.
The following SWITCHES are supported, <> indicates a required
command, and [] an optional one.
<-F> With this you supply the filename or file mask to be
searched for. The file name/mask must directly follow the colon.
[-L] If you wish to have the results also logged to a text
file, then supply a filename after the colon. You can specify a
full path+filename if you wish. If only a filename is supplied,
it will be created in whatever directory is current when RSU
runs. If the file already exists, it is ADDED to. If not, RSU
will create it. The File name/mask is written to the first line,
then the listing is simply a carbon copy of what you see on the
screen.
File Areas as well as directory names are listed to the screen
and the list file. A different format is used for wildcard
searches than is used for a single filename. Readability here is
the key, I think the methods used will suffice.
RSU For You Making A Few Sysop Chores Easier To Do! Page 11
For a single file name search:
As files are found, they will be displayed to the screen as:
Area: File Area Name
Found "Filename" in "Directory"
Area: File Area Name
Found "Filename" in "Directory
The above assumes more than one copy of the file was found.
For Wildcard searches:
As files are found, they will be displayed to the screen as:
Area: File Area Name
Found "Filename" in "Directory
Found "Filename" in "Directory
Found "Filename" in "Directory
And so on....
Examples:
-Frasis202.zip will search for only this file, one or more
copies will be found if it exists in the database File Paths.
-F*.TXT will search and find all files with the extension .TXT
-F*.ARJ -LARJ.LST will search and find all files with the
extension of .ARJ, and also list them to
the file ARJ.LST in the current directory
──═══════════════════════════════════════════════════════════════════════───
User Uploads - WHATFILES
──═══════════════════════════════════════════════════════════════════════───
WhatFiles will list all files uploaded by a particular user,
listing the File Name and Size. At end of list it will give the
total NUMBER of files, and the total FILE SIZE of the uploads.
User names are validated, if the user does not exist, WhatFiles
will abort with an error message. So you say "What about
uploaders such as ALLFIX, RADIST etc?" So we say, a switch has
been provided which allows you to list files uploaded by a FAKE
user.... such as AllFix etc.
The resulting list may also be written to a Ascii Text File.
SWITCHES/COMMANDS:
<-Uusername> Using the -U switch you supply the user
name to check. Any spaces must be
replaced with the (_) underbar.
[-Ffakename] Using the -F switch, you can supply a
RSU For You Making A Few Sysop Chores Easier To Do! Page 12
name that you know does not exist in the
user file, TIC processor names etc. No
validation is done on this name.
[-Ltextfile] If you supply a filename with the -L:
switch, output will also be written to
this file. If no path is supplied, the
file will be created in the current
directory.
Example Commands:
RSU whatfiles -urand_nowell -Lrand.upl
would find all of my uploads, listing to screen, and also to the
text file RAND.UPL, in the current directory.
RSU whatfiles -fallfix
would display all files imported by Harald Harm's AllFix program.
When WhatFiles completes its search, it will display a line
similar to the following.
USER NAME uploaded ### files, totaling ##,### kbytes.
──═══════════════════════════════════════════════════════════════════════───
Pack Messages/Files.RA - PACKFM
──═══════════════════════════════════════════════════════════════════════───
UNTIL FURTHER TESTING HAS BEEN COMPLETED, THIS MODULE IS "NOT"
AVAILABLE. HOPEFULLY IN THE NEXT RELEASE. RELEASE IS BASED MORE ON
THE ABILITY OF 3RD PARTY UTILITIES HANDLING A MODIFED RA 2.5
MESSAGES.RA AND FILES.RA........
──═══════════════════════════════════════════════════════════════════════───
Swap User Name/Handle in Uploads - SWAPHANDLE
──═══════════════════════════════════════════════════════════════════════───
This module will scan all your FDB data files, and insert the
users Handle into the Uploader name field.
The users name is first validated, ie: they must exist as a
System User. Names such as TIC, ALLFIX, ROBOT etc, unless in your
USERS.BBS, are considered NON System users, and no change is
attempted. This holds true for those occasional files that have
NO name for the Uploader. Again, no change is attempted.
Assuming that the Uploader name is a valid system user, RSU will
check the User's record, and see if they have a Handle assigned.
In order for RSU to consider the Handle a valid one, it can not
be Blank, and cannot match the Users real name. If it IS blank,
RSU For You Making A Few Sysop Chores Easier To Do! Page 13
or matches the user name, then no change is made or attempted.
There are two "switch" commands for this module. They must be
preceeded by either a "-" or a "/", and followed by the command.
SWITCHES:
-F##### where ##### represents the File Area you wish to
scan, you should NOT supply the "FDB" prefix, nor
the "HDR" extension. These will be added by RSU.
This switch will cause RSU to ONLY Swap Name<>Handle in ONE
File Area Header. This can be handy to run on a special
"UPLOADS" area, before files are moved to another permanent
area.
If this command is not used, RSU will scan ALL File Area
HDR files.
-SOff Tells RSU to NOT display a listing of filenames being
checked, and the status of each scan action.
There is no ON switch, as ON is the default.
Normally, RSU will list each filename being checked, the current
uploader name, and one of the following:
"Not a System User No changes"
"Blank Entry No Changes"
"Changed to: <user handle>"
All the above is displayed on one line. Also, the above status
messages are each displayed in their own color. Thus even if you
cannot read a line as it flashes by, just by color you can have
an idea what it just did.
And if screen display is on, (default) a header is displayed at
top of window, so you know which column of the display is what.
When a name is actually changed, RSU pauses "just a bit" so you
might read the change. Also, using your BREAK/PAUSE key along
with your Spacebar key, will let you pause the program at will,
allowing you to stop the display and read it.
If you do not wish this display, supply the -screenoff command,
and it will not list to screen.
There are two things that are displayed regardless of the switch,
at the top is displayed: Scanning Uploaders in "FDB###.HDR", and
at program end, a summary is displayed, listing how many files
were checked, and how many changes were made.
Presently there are no facilities for RSU to know if it has
already made a Name<>Handle change to a particular file. So when
it runs, it WILL check EVERY file in the FDB files. On a large
RSU For You Making A Few Sysop Chores Easier To Do! Page 14
system with thousands of files, this may take some time. This is
definitly a module that you would want to run during an OFF-PEAK
time for your system, in that case.
Of course, if you have uploads sent to a "In Transit" directory,
then you could run SwapHandle nightly on just that one area, and
it will go much quicker.
But you should run it on the complete set of database header
files at least once.
My system is rather small, less than a thousand files on it. But
to give you somewhat of a benchmark, during tests it scanned
690 files, made 46 changes, and did it in 26.5 seconds.
That was done on a 486/33 no MathCo.
That may help you gauge how long it will take to run on your
system.
The functions that SwapHandle performs are rather intense, but I
feel it goes fairly quickly, considering.
──═══════════════════════════════════════════════════════════════════════───
Change Uploader Name(s) - UPLOADER
──═══════════════════════════════════════════════════════════════════════───
Very similar to the standalone UPLOADER.EXE program that I released
a year or two ago.... this replaces it, and the standalone is no
longer available. It also is a better version. :)
Previous program required you be IN the \HDR directory to process,
this module does not. There is no "interactive" prompting in the
RSU module, it is all done on the command line.
Great for midnight maintainence runs.
SWITCHES/COMMANDS
-N<new_name>
This is the name you want placed in the uploaded by field.
Spaces in the name MUST be filled with the underbar.
-L (Literal)
This tells UPLOADER to insert the name EXACTLY as you type it.
If not used, RSU will ProperCase the name.
-B
Replace Blanks, when used, RSU will replace any BLANK uploader
name with the New_Name given. All else will be left as is.
-R<Name_To_Replace>
When this command is used, RSU will search for, and replace,
this particular name with the New_Name.
RSU For You Making A Few Sysop Chores Easier To Do! Page 15
-#<area_num>
Restrict upload name changes to one particular FileArea data file,
you should NOT supply the prefix (FDB) or the extension (.HDR)
these are added by RSU.
Example: -#102 will have RSU process File Area #102 only.
-*
Tells RSU to process ALL FDB files with the given commands.
This switch is not really needed, if you do not specify a
specific area with the -# switch, RSU will process ALL file
area HDR files by default.
NOTE: I was going to include a command to scan and count the
number of BLANK uploader names, these DO happen with
3rd party utils that import files sometimes.
But decided it was more overhead than it was worth.
If you REALLY are curious, do this:
RSU UPLOADER -nRSU_TEST -B
This will replace any BLANK names with "Rsu Test", and give you a
count of "Search and Rplace" completed. Now you know how many there
were. Then run:
RSU -nName_To_Insert -rRSU_TEST
And you can get them to be what you want.
When the uploader module completes, it will display totals for
Files Read (Area Files Processed)
Files Written (Area Files actually modified)
Search & Replace (How many names were replaced)
A Help Screen is available with - RSU uploader ?
──═══════════════════════════════════════════════════════════════════════───
<eof RSU.DOC>
──═══════════════════════════════════════════════════════════════════════───
