What is the difference between TaskMaster and TaskMaster Lite (TMLite)? TaskMaster is a network-centric product which includes Server-to-Server command, communications and control (data transfer and task automation), as well as multi-session, secure Remote Console support via the TMRemote DOS Client and file replication / data synchronization through the SYNC command. TaskMaster Lite is Server-centric and only capable of automating or processing tasks on a single Server autonomously (i.e., it cannot perform any communication or data transfers between Servers, does not include Remote Console support nor the SYNC command). TaskMaster Lite can be used to automate tasks on a single Server while TaskMaster (full) is used for automating tasks involving the transfer of data between Servers (typically for file replication / data synchronization using the SYNC command). ABORT Because TaskMaster's Extended Console Commands support wild cards and, in most cases, can be used recursively to traverse a subdirectory tree, there may come an occassion when it might be desireable or even necessary to want to terminate (or abort) the processing prior to completion. For that reason, one of the common commands between the TMConsole (Shell) Extended Console Command set and the Batch Processing script language is the ABORT command. Within a TaskMaster processed task (CALLed, TMRUN executed, or scheduled), the ABORT command, without any specification as to a command or task name, terminates the active task. The ABORT command can also be used, either within a task script or at the TMConsole (Shell) prompt, to terminate an active task or terminate processing for most of the Extended Console Commands. Notes: If the Extended Console Command is processing as part of a task script, first terminate the task (ABORT {task}) then terminate the command (ABORT {command}). Using this ABORT sequence insures that the task terminates immediately after the command terminates, rather than continuing to process with the next line in the task. Issuing an ABORT {command} terminates all active instances of the {command}. At this time, there is no way to terminate a specific instance of a {command}. ABORT {command} supports the following Extended Console Commands: CHMOD, CHOWN, COPY, DELTREE, FIND, FLAG, FLAGDIR, PURGE, SCOPY, SORT, SXCOPY, SYNC, TMUPDATE, XCOPY Terminating a task: To terminate an active task, use: ABORT {task} where {task} is the DOS 8.3 file name of the active task. Terminating a command: To terminate an active Extended Console Command, use: ABORT {command} where {command} is the name of a supported Extended Console Command that is in process. Current Working Directory (CWD) The TMConsole (Shell) command prompt, as well as each individually processed task, maintain their own Current Working Directory (CWD). The CWD is the default directory that is searched for any file system request which does not include a volume and path (VOL:\PATH) in the specification. The concept is similar to the default directory on a workstation with the following exceptions: Workstation: Executing a program from the workstation command line without specifying a drive and/or directory as part of the program name will result in the Current Working Directory (CWD, e.g., C:\TEMP) being searched, followed by the DOS PATH search directories. TaskMaster: Supported commands are incorporated into and processed by the TaskMaster NLM so they neither need nor support such search paths. Workstation: Attempting to open a file from within a program or as an option on the program's command line without specifying a drive and/or directory as part of the file specification typically results in the program attempting to locate the file in the directory from which the program loaded (i.e., CWD). (Note: There are numerous exceptions as many programs allow for the definition of a default data or working directory and then set the specified directory as the CWD.) TaskMaster: By default, the initial CWD for the TMConsole (Shell) prompt or an active task is the root of the SYS volume (i.e., SYS:\). However, the CWD can be changed using the CD / CHDIR Extended Console Commands. (Note: Executing the CD / CHDIR Extended Console Commands WITHOUT specifying a directory name to change to will result in the CWD being displayed, much like typing CD / CHDIR at a workstation DOS prompt.) File specifications can be relative to the CWD using .. to specify a level higher in the tree or . to represent the CWD. Examples: To change the default CWD from SYS:\ to SYS:\SYSTEM\TASKMSTR CHDIR SYSTEM\TASKMSTR CD \SYSTEM\TASKMSTR CD SYS:\SYSTEM\TASKMSTR To change the new CWD from SYS:\SYSTEM\TASKMSTR to SYS:SYSTEM CHDIR .. CD \SYSTEM CD SYS:\SYSTEM To TYPE the file SYS:\TEMP\DUMMY.TXT relative to the CWD (SYS:\) TYPE SYS:\TEMP\DUMMY.TXT TYPE .\TEMP\DUMMY.TXT TYPE TEMP\DUMMY.TXT Dynamic Variables The enhanced Batch Processor incorporated into TaskMaster / TaskMaster Lite includes a set of Dynamic Variables (i.e., blocks of memory that can be used to represent, retrieve and store data) which are supported in two formats: %0 - %9 and %VAR00% - %VAR99%. It should be noted that %0 - %9 and %VAR00% - %VAR09% represent the same set of Dynamic Variables (i.e., %0 = %VAR00%, %1 = %VAR01% ... %9 = %VAR09%). The overlap in naming is a result of backwards compatibility support for the original 10 Dynamic Variables (%0 - %9) which have since been expanded to 100 Dynamic Variables (%VAR00% - %VAR99%). These variables can be used to represent and substitute data in place of hard coded values for conditional tests, logging and display. Data can be stored in these variables using a variety of Batch Commands: Examples: Check if %0 IS NOT NULL ("") and display the contents: IF NOT "%0"=="" THEN ECHO %%0 = "%0" (i.e., it is not "" NULL)! Note:   %%0 (%%VAR00%%) substitutes the Dynamic Variable name   /   %0 (%VAR00%) substitutes the Dynamic Variable contents Store the string 'Avanti Technology' in %1 then use %1 in a greeting: DEFINE %1 Avanti Technology ECHO Good day, %1! Note: Displays 'Good day, Avanti Technology!' Combine the contents of %0 and %1 into %2 (i.e., %2 = 'Hello World'): DEFINE %0 Hello DEFINE %1 World DEFINE %2 %0 %1 Store numeric values: DEFINE %1 1 DEFINE %2 01 DEFINE %3 001 Note: The minimum width (number of significant digits) corresponds to the defined width (i.e., %1 is set to 1 digit, %2 is set to 2 digits and %3 is set to 3 digits). Store the result of a CALC (((1000 / 10) - 25) + 25) into %9: DEFINE %0 1000 DEFINE %1 10 DEFINE %2 25 CALC %9 ((%0 / %1) - %2) + 25 Increment the value of %1 by 10 then store the value of %1 minus 5 into %2: DEFINE %1 %1+=10 DEFINE %2 %1-=5 Note: TaskMaster's Batch Processor recognizes += (to increment) and -= (to decrement) the numeric contents. Parse bytes 1-128 of %0 into %1 then parse bytes 1-10, byte 20, and bytes 101-127 of %1 into %2: PARSE %1 %0 1-128 PARSE %2 %1 1-10,20,101-127 Notes: By default, PARSE will space fill any null bytes (i.e., bytes between the actual end of the source data and the length specified) if the source data is shorter than any key specifications. Append the PACK option after the key data to ignore null bytes (i.e., truncate the data transferred to the actual size of the source). Read next record in OPEN_READ file into %1 then Read bytes 1-80, and bytes 401-500 of the subsequent record into %2: READ %1 READ %2 1-80,401-500 Notes: A successful OPEN_READ must have been executed prior to any READ. The OPEN_READ file should contain only sequential ASCII data records. READ can parse data locations beyond the limitations of the destination variable's maximum length but it cannot READ a total string length that is more than the variable's maximum length. By default, READ will space fill any null bytes (i.e., bytes between the actual end of the source data and the length specified) if the source data is shorter than any key specifications. Append the PACK option after the key data to ignore null bytes (i.e., truncate the data transferred to the actual size of the source). Replace dashes (-) with dots (.) and commas (,) with colons (:) in %1: REPLACE %1 "-.,:" Note: Before '123-456-789,0' / After '123.456.789:0' Convert upper case to lower then lower case to upper in %1: TOLOWER %1 TOUPPER %1 Note: Start 'GoodBye' -> TOLOWER 'goodbye' -> TOUPPER 'GOODBYE' Assign an Alias name to a Dynamic Variable (%VAR00% - %VAR99%) VARALIAS %VAR10% %DIRCOUNT% VARALIAS %VAR11% %DIR_COUNT% VARALIAS %VAR12% %DirCount% VARALIAS %VAR13% %Dir_Count% Notes: The alias name must begin and end with a percent sign (%...%) and may contain a maximum of 15 characters (case insensitive), including the percent signs. The first character after the initial percent sign (%) may not be a numeric digit (i.e., %0...% through %9...% is not allowed). No spaces are allowed in the name (use dashes or underscores). Cannot match (duplicate) any existing Alias Variable, Dynamic Variable or Environment Variable name. Once defined, an Alias Variable can be used in all the same ways as the Dynamic Variable it replaced. For more information and examples of Alias Variable usage, refer to the VARALIAS documentation in the TaskMaster User's Guide. Notes: If the variable (%0 - %9) is to be used for mathematical purposes (CALC, +=, or -=), do not include any leading or trailing spaces in the string (numeric data only). As of TaskMaster v3, maximum string length is 255 characters. Name Space Support Multi-OS support for DOS, Long (OS2 / Windows), Macintosh OS (Apple) and NFS (Unix) Name Spaces is inherent, unless documented to the contrary with maximum combined full path (including file name and extension) lengths of up to 511 characters. For full Name Space support to be available, the appropriate Name Space support NLM must be loaded on the Server (both source and destination Servers for Server-to-Server operations): NetWare v4.x:   LONG.NAM MAC.NAM NFS.NAM   (HPFS / Long / OS/2) (Apple Mac OS) (Unix NFS) NetWare v5.x / v6.x / OES (NW):   MAC.NAM NFS.NAM   (Apple Mac OS) (Unix NFS)   Note: v4.08 and prior requires these NLMs be loaded for NW v5.x / v6.x / OES (both NSS & TFS). As of v4.09, the modules are only required for TFS Volume support. Support for non-DOS Name Spaces is similar to the support for the Long (Win32) Name Space in a DOS box under Windows 95 / 98 / NT / 2000 with the DOS Name Space as the default and spaces within a command assumed to be command line item separators. To specify a non-DOS name containing one or more spaces within a command, the entire non-DOS specification must be enclosed in double quotes (""). Examples: DIR "SYS:\Program Files\Internet Explorer\default\*.*" COPY "SYS:\Program Files\*.*" "BACKUP:\Program Files" COPY "SYS:\Program Files\*.*" BACKUP:\PROGA~1 Multi-OS support is not available without caveats, conflicts and limitations. The greatest conflicts concern the fact that each Name Space supports different standards (or rules) for constructing file names and directory paths. (As the old saying goes, "The nice thing about standards is that there are so many to choose from.") Long Name Space Issues: According to the standards (or rules) for Windows Long Name Space support (the most widely used Long Name Space implementation), directory and file names may contain up to 215 characters, including spaces but excluding the following characters: Forward slash (/), backward slash (\), colon (:), greater than sign (>), less than sign (<), vertical bar (|), double quotes ("), asterisk (*), and question mark (?). The colon (:) is reserved for use as the drive or volume (NetWare) separator while backward slashes (\) are reserved for use as the UNC or path separator. The forward slash (/) is also reserved and considered a path separator for compatibility with NetWare and Unix NFS File Systems. All of the other reserved characters serve special purposes in DOS, Windows, and Unix command line processing so they are not supported in directory or file names. Mac Name Space Issues: According to the standards (or rules) for the Macintosh File System, the only restricted character in a file or folder (directory) name is the colon (:) which is reserved for use as a path separator. Characters normally used as wild cards in other Operating Systems, such as the asterisk (*) and question mark (?), can be used within a file or folder (directory) name. Characters which have special meanings on many Operating Systems, such as greater than (>) and less than (<) signs often used for input or output redirection, or double quotes (") commonly used to enclose a specification with embedded spaces and the ampersand (&) widely used widely in internet applications as an options separator on the command line, are valid with a file and folder (directory) name. In addition, forward slashes (/) which are reserved as a path separator by both NetWare and NFS standards (or rules), as well as backward slashes (\) which are reserved as a path separator by DOS, Long (Windows), and NetWare, are allowed in Macintosh file and folder (directory) names. The only real limitation is that a file or folder (directory) name cannot contain more than 31 characters (Mac OS prior to OS/X), but a full path can exceed the 255 character DOS limitation. NetWare Specific Mac Notes: Mac extended characters are not supported with AFP. (Abridged from NetWare v6.0 SP 5 README.) Apple Filing Protocol (AFP) v2.2 (used by Mac OS v9 and earlier) limits file names to a maximum of 31 characters while AFP v3.0 (used by Mac OS/X) supports longer file names. Novell's AFPTCP NLM supports AFP v2.2. (Abridged from NetWare v6.0 SP 5 README.) Mac files that have a 0xDA special character embedded in the name can cause problems because this character is converted to a "/" by NetWare, potentially causing directory path misinterpretation. (Abridged from NetWare v6.0 SP 5 README.) (Abridged from NetWare v6.5 SP 2 README.) Any folder that contains a file or folder name that is longer than 98 characters will cause enumeration of that folder to fail. (Abridged from NetWare v6.5 SP 2 README.) NFS Name Space Issues: According to the standards (or rules) for the NFS File System, the only restricted character in a file name or path is the forward slash (/) which is reserved for use as a folder (path) separator. Characters normally used as wild cards in most Operating Systems, even for Unix commands, such as the asterisk (*) and question mark (?), can be used within a file or directory name. In addition, colons (:), which are used by DOS, Long (OS/2 / Windows), and NetWare to separate Drives/Volumes from Paths, can be used in file or directory names. NFS also allows backward slashes (\), greater than (>) and less than (<) signs, as well as double quotes (") and ampersands (&) to be used in file and directory names. Moreover, both file and directory names are handled as case sensitive, treating FILE, File, and file as three separate names. The only real limitation is a maximum of 255 characters per file or directory name allowing a full path to far exceed the 255 character DOS limitation. Every effort has been made and will continue to be undertaken to insure that TaskMaster / TaskMaster Lite can provide as comprehensive of support as possible for all the special cases of each Name Space without being limited to supporting a single Name Space (i.e., maintaining multi-OS support is the Priority). In that regard, there are likely to be some situations where file or directory names will conflict with either the NetWare APIs used or the multi-OS support logic and the entry will not be capable of being processed by TaskMaster / TaskMaster Lite until it has been renamed. To avoid potential Name Space caveats and conflicts, it is recommended that multi-OS compatible rules be implemented for file and directory naming. Ultimately, in any realm of conflict, it is often best to avoid such problems by defining rules which embrace the path of least resistance (i.e., the lowest common denominator, in this case the Long Name Space). The following simple rules should provide a reasonable compromise that also insures directories and files are fully accessible and manageable across the network: Avoid using any characters in directory or file names which may have special application in other Operating Systems or Name Spaces supported by the network, such as the asterisk (*), question mark (?), colon (:), forward slash (/), backward slash (\), less than sign (<), greater than sign (>), and ampersand (&) in particular. Being descriptive is good but remember that a good file name is also easy to remember and access so keep it brief and simple. It is also important to note that longer names consume more disk space, require more resources to process, complicate backups, waste network bandwidth, and may be incompatible with some applications. Avoid using spaces in directory and file names. While spaces within directory and file names are supported by Long, Mac, and NFS Name Spaces, such habits can create conflicts for parsers which recognize spaces as command line option separators. A more preferable method is to use the underscore (_) or a period (.) to separate words within directory or file names, such as my_file.doc. Note: While the Macintosh and NFS Operating Systems allow directory and file names to have leading spaces, not all TaskMaster / TaskMaster Lite commands (especially SxCOPY and SYNC) are able to properly process such entries due to limitations in the NetWare API set. Moreover, such names are not supported by either the DOS or Windows Operating Systems. Therefore, the use of leading spaces in directory and file names is neither fully supported nor recommended. One final suggestion, not specific to TaskMaster / TaskMaster Lite: Try to use the proper common or widely used extensions. Without a proper extension, some applications and browsers may not be able to recognize the file. Users should be advised of the importance of adhering to multi-OS compatible rules both for file system management (i.e., backup, restore, disaster recovery, maintenance, etc.) and for transportability of information between systems as networks become more and more heterogeneous. Name Space Support Caveats: Although TaskMaster's design makes extensive use of logic intended to make the use of DOS and non-DOS Names transparent for the user and task, it is important to note that there are caveats associated with Long Name support on any platform that supports more than one naming convention. These caveats are more complex, and dangerous, on NetWare Servers due to the fact that the underlying file system is DOS based and treats Long names as an alias for or extension to the DOS entry. Most of NetWare's support modules and the vast majority of utilities common to the NetWare marketplace either support DOS names only (ignoring the non-DOS names) or non-DOS names only (ignoring the DOS name). This approach further complicates the caveats, especially if the utilities are used to backup, copy, move, or update critical data files. The TaskMaster command most affected by these caveats is the SYNC command. How SYNC handles non-DOS entries is covered in the SYNC FAQ. For more information on the caveats associated with Long Name Space support, review the following document (Adobe Acrobat .PDF format): Caveats for Non-DOS Name Space Support To download Adobe's free Acrobat Reader, visit: http://www.adobe.com Output Redirection Most of the Console command extensions provided by TaskMaster support output redirection. As in DOS programs, output redirection redirects the information output to the screen by a program or command to the specified file, either in truncation mode (> create/overwrite) or append mode (>> create/append). Redirecting Screen Output To A File: To redirect the screen output from most TaskMaster commands, append the following to the command line: >vol:\path\redirect.ext         (truncates) >>vol:\path\redirect.ext        (appends) Note: The output file must reside on the local Server. The output file specification must be a valid file name (including a valid volume and path, if specified). The output file specification can be relative to the Current Working Directory (CWD). Wild cards are not supported. Examples: DIR vol:path\filespec >vol:path\dir.log Redirect the screen output from the DIR command to the specified file (vol:path\dir.log), creating or overwriting the file, if it already exists. PURGE filespec /A /N14 >>vol:path\purge.log Redirect the screen output from the PURGE command to the specified file (vol:path\purge.log), creating or appending to the file, if it already exists. SYNC vol1:src vol2:dest /a >vol1:lsync.log Process the local source directory (vol1:src) and the local destination directory (vol2:dest) adding files which exist on the source but not the destination (/a). Redirect the screen output to the specified file (>vol1:lsync.log), overwriting the contents (if it already exists). SYNC vol:src rserver/vol:dest /m >>vol:rsync.log Process the local source directory (vol:src) and the remote Server destination directory (rserver/vol:dest) updating those files existng in both directories which have a newer Last Modified date/time stamp on the source (/m). Redirect the screen output to the specified file (>vol1:rsync.log), appending to the file (if it already exists). Additional Tips: Custom headers (start date/time &/or other) and footers (finish date/time &/or other) can also be written to the output redirection file via TaskMaster script commands (example). The SYNC command supports a /L (Log) option which, when used with output redirection, writes the command line as a header record to the file preceding the redirected output. Registration / Serialization There are two quick methods to retrieve the Registration information and Serial Number associated with a loaded TaskMaster NLM: At the Server System Console prompt enter: MODULES TASKMSTR.NLM     (TMSECURE.NLM, if the TaskMaster Secure NLM is loaded) At the TMConsole (Shell) prompt enter: TMINFO TMConsole (Shell) When the TaskMaster Master Server module (TASKMSTR.NLM) or TaskMaster Lite Server module (TMLITE.NLM) is loaded, a TMConsole (Shell) screen is automatically created on the Server. The TMConsole (Shell) provides an interactive user interface to TaskMaster and the TaskMaster Console Command extensions (refer to the Console Commands chapter later in this manual). The combination of the TMConsole (Shell) interface and TaskMaster's Console Command extensions is intended to emulate a DOS command shell (or DOS box under Windows) providing direct command line management of the directories and files stored on volumes mounted on the local Server. TaskMaster's Console Command extensions also include commands for configuring and managing TaskMaster, as well as performing operations against Remote Servers which are running compatible versions of the TaskMaster NLM. Notes: The TMConsole (Shell) is not supported by the TaskMaster Secure Server module (TMSECURE.NLM). On Servers running the TaskMaster Secure Server module, Console Command extensions can only be executed as part of scheduled or submitted tasks, not via the Server Console prompt or NetWare batch files. Server-to-Server operations are not supported by TaskMaster Lite. How to Disable (Close) and Enable (Open) the TMConsole (Shell) Entering EXIT at the TMConsole (Shell) prompt will close the active screen. To re-activate an inactive TMConsole (Shell) prompt, enter TMCONSOLE at the Server System Console. Quick Access to the TMConsole (Shell) from a Server System Console Once the TaskMaster Master Server module (TASKMSTR.NLM) or TaskMaster Lite Server module (TMLITE.NLM) is loaded, the TMConsole (Shell) screen can be accessed by changing screens in the normal manner. Entering TMCONSOLE at the Server System Console prompt will change directly to the TMConsole (Shell) screen. Send Commands to the TMConsole (Shell) from the System Console or a .NCF Batch File TaskMaster Console Commands can be sent to the TMConsole (Shell) prompt from the Server's System Console or a NetWare processed .NCF batch file via the TMCONSOLE command as follows: TMCONSOLE [command_line] Example: TMCONSOLE TMRUN SUBTASK.TSK When executed either from the Server's System Console or within a NetWare .NCF batch file, the TMRUN SUBTASK.TSK command will be executed as if manually entered at the TMConsole (Shell) prompt. TMRemote DOS Remote Console Client TaskMaster includes a TMRemote DOS Client (TMREMOTE.EXE) which functions both as a Bindery / NDS-compliant, secure, and lower overhead Remote Console alternative and as a means to provide a defined group of Users with the capability to launch TaskMaster tasks and/or submit commands to the Server Console via a manually executed DOS program or integrated within a workstation batch process. TMRemote utilizes NCP Extensions (NCPE) as its method of communication with the TaskMaster NLM on the Server. By utilizing NCPE instead of SPX, TMRemote consumes less bandwidth and overhead than Novell's RCONSOLE and supports any workstation which can execute DOS programs so long as the workstation has an established NCP attachment to the Server via a Novell NetWare Client, regardless of the protocol used or whether a local or remote (WAN) connection. *** Note: TMRemote is not supported by TaskMaster Lite (TMLite) *** Initial Program Load In typical usage, the TMRemote DOS Client (TMREMOTE.EXE) loads and checks the workstation's Server Connection table to build a list of Servers that the workstation is connected to which also have the TaskMaster NLM loaded. It then displays the list of Server connections running the TaskMaster NLM from which the User can select a Server with which to initiate a session. Depending upon how the Remote Console Rights are defined (refer to the TMCONFIG Console Command extension), the User may be granted full or limited access to the remote Server (based upon the highest rights granted to User and the defined Remote Console Rights for such rights). If the User does not have any of the listed rights, the connection is denied. Defining TaskMaster Operators / TaskMaster Users A TaskMaster Operator can modify task schedules, submit commands and tasks to the Server, and may be granted full to view only Remote Console access. TaskMaster Operators are defined via the TMCONFIG Console Command extension. A TaskMaster User can submit tasks to the Server and may be granted view only Remote Console access. TaskMaster Users are defined via the TMCONFIG Console Command extension. Remote Console Access TMRemote closely emulates the Server Console and supports the same special key sequences for changing active screens as found in RCONSOLE. Up to 16 simultaneous sessions can be initiated per Server, including multiple sessions to a single Server by a single workstation with screen locking for each session. Remote Console Rights are defined via the TMCONFIG Console Command extension. Notes: While TMRemote transmits Server screen images as clear text, keyed data and all TaskMaster password or rights associated data are transmitted in encrypted form. Enable Scroll Lock to lock selected screen for each session. The following listings outline the supported Remote Console access modes that can be granted to each level of User rights: Admin/Supervisor Unrestricted Access Unrestricted Access (Require TaskMaster Password) File Server Console Operator No Access Unrestricted Access Unrestricted Access (Require TaskMaster Password) View Only Access (No Keyin Allowed) TaskMaster Operator No Access Unrestricted Access (Require TaskMaster Password) View Only Access (Require TaskMaster Password - No Keyin Allowed) View Only Access (No Keyin Allowed) Command Line Options TMRemote supports command line options which can be used as follows: To designate a specific Server to establish communications (for batch processing, to avoid selection from list box of Servers); To specify the TaskMaster password required for remote access (if defined); To submit a task file to TaskMaster for processing; To submit a command to the System Console; And, to automatically initiate a Remote Console session after submitting a task or console command, providing that the User has sufficient rights for at least View Only Access. These options allow Server task and command processing to be incorporated into workstation batch processing and a review of the Server processing. Option Summary: Server S=Server Server is a NetWare Server running the TaskMaster NLM to which the processing will be directed. C="command" Submit "command" to System Console.   (Use quotes if command contains any spaces.) Unrestricted Access rights required. T="taskfile.ext" Submit task "taskfile.ext" to TaskMaster batch processor   (Use quotes if task options specified.) Admin/Supervisor, TaskMaster Operator, or TaskMaster User rights required. Note: For security reasons, only the task file name and extension is accepted, no path allowed, and the task file must reside in the TaskMaster NLM load directory, the SYS:SYSTEM directory, or the optionally defined TaskMaster task directory. /V Initiate Remote Console session. Unrestricted Access rights required. Note: By default, TMRemote will automatically terminate after processing the C= or T= options, unless the /V option is also specified. TMSMTP (SMTP Send Mail) The most common source of the 'Unable to locate SMTP Host' error is an address or name resolution issue. To avoid such errors, make sure the following have been properly defined: SMTP Server entry exists in SYS:ETC/HOSTS Gateway / Router entry to the SMTP Server exists in SYS:ETC/GATEWAYS An entry for the Name Server exists in SYS:ETC/RESOLV.CFG In addition, the Network Database Access NLM (NETDB.NLM) should be loaded. TMUNLOAD / TMRELOAD One of the most common reasons why the Server System Console prompt will disappear is when an attempt is made to UNLOAD an NLM that has incurred a Soft ABEND. When a process generates a Soft ABEND, NetWare suspends the process to avoid further corruption and places the process in a sleep state that prevents it from being awakened even to be terminated. Thus, since an NLM cannot be unloaded until every running process has terminated, the UNLOAD command cannot complete and because the UNLOAD command cannot complete, control does not return to the Server's System Console command handler. In an attempt to prevent the loss of the Server System Console prompt, logic was added to TaskMaster v3.24 (and later) to prevent TaskMaster from being unloaded via the Server System Console UNLOAD command. To unload the TaskMaster NLM (TASKMSTR.NLM, TMSECURE.NLM, or TMLITE.NLM), execute the TaskMaster command TMUNLOAD at either the TMConsole (Shell) prompt or the Server System Console prompt. TMUNLOAD will send termination requests to all active TaskMaster commands and task processes. It will then monitor the active commands and processes until it can confirm that the NLM is in a safe state to be unloaded, at which point the NLM will automatically unload. In most cases, the NLM will unload in just a few seconds. If the NLM does not automatically unload within five (5) minutes, most likely it will be necessary to DOWN the Server to unload the NLM safely. Related TaskMaster Commands: TMRELOAD can be used to UNLOAD/LOAD (i.e., reload) the TaskMaster NLM. It works identical to TMUNLOAD except that it will try to automatically load the NLM again once it has been safely unloaded. TMRELOAD is ideally suited for reloading the TaskMaster NLM after an update has been applied. TMUPDATE can be used to automatically distribute updates between licensed Servers. It utilizes the TMRELOAD command to unload and then reload the remote Server copy of the TaskMaster NLM.   (Note: TMUPDATE is not supported by TaskMaster Lite.) AttachToFileServer() Error AttachToFileServer() errors occur when TaskMaster attempts to establish a communications route between the Servers, even before it determines if there is a compatible TaskMaster NLM loaded on the Remote Server. Such errors are usually communications related, the result of RIP/SAP or SLP problems. For TaskMaster Server-to-Server communications to work in a Pure-IP environment, SLP must be configured properly allowing the two Servers to see and communicate with each other. This status can be verified by typing 'display slp services service=nwserver' at the System Console prompt and check if the remote Server name appears in the returned known Server list. If the Remote Server name does not appear in the list of known Servers then the network is not configured optimally for communications between the Servers. This test should be tried on both Servers (i.e., the Local Server should see the Remote Server and vice versa). If either fail to appear, the problem is most likely a SLP DA or SYS:ETC\HOSTS conflict. For TaskMaster Server-to-Server communications to work in an IPX environment, be sure not to filter SAP/RIP packets from other segments. To verify that the Servers can communicate via IPX, type 'display servers' at the System Console prompt and check if the remote Server name appears in the returned known Server list. If the Remote Server name does not appear in the list of known Servers then the network is not configured optimally for communications between the Servers. This test should be tried on both Servers (i.e., the Local Server should see the Remote Server and vice versa). Once the appropriate configuration changes have been made, it may still require a bit of patience before the information fully propagates to the Known Server table of the local Server. This is a DS issue and may be hindered by DS anomalies and update conflicts. Large Directory Performance Directories with a large number of entries (12,000 or more subdirectories and files) can experience a significant performance hit due to NetWare's underlying dependency on the DOS file system and DOS' inherent limitations. Novell has an excellent Technical Information Document (TID) discussing this issue and ways to minimize the impact: Slow file system performance in a directory with excessive files - Novell TID 10021744 If the TID becomes obsolete or is updated so that it cannot be found via the provided link, try searching the Knowledgebase using the keywords: Slow File System Performance Excessive Files NSS Performance While offering many benefits over traditional volumes, NSS volumes can deliver much slower file copy speed if not configured properly. Novell has several excellent Technical Information Documents (TID) covering conflicts and performance tuning tips for NSS volumes: Monitoring NSS Performance - Novell TID 10068489 Optimizing NSS and the storage system for different usage patterns - Novell TID 10095637 Performance, Tuning and Optimization - Novell TID 10012765 Poor performance reading files from an NSS volume - Novell TID 10072922 Resolving GroupWise performance issues with NSS volumes - Novell TID 10065215 (Note: While specific to GroupWise, TaskMaster is also affected due to similar File I/O techniques.) Slow backup/restore performance tuning parms parameters for NSS - Novell TID 10093351 Pure-IP Performance The following facts and Novell Technical Information Documents (TIDs) are relevant when trying to troubleshoot performance degradation which may be encountered when using TaskMaster: Pure-IP support is slower than IPX In-house testing on NetWare v5.1 Servers configured to run Pure-IP exchanged data packets an average of 14% slower than when configured for IPX only. Relative Speed of IP vs IPX - Novell TID 2944938 Server to Server TCP/IP communication slow with certain third-party applications - Novell TID 10061174 Slow Backups related to TCP Delayed Acknowledgement - Novell TID 10068360 Write performance of IP-based NCP connection slower than using IPX-based - Novell TID 10061307 Pure-IP is sensitive to Duplex Mismatches and less forgiving than IPX Novell has published numerous TIDs which identify the source of network degradation for GroupWise and other Novell products as being Duplex mismatches. IP tends to incur more errors while supporting NCP and recovers from such errors less efficiently than IPX. Should I use Half Duplex or Full duplex - Novell TID 10023448 Troubleshooting NIC Compatibility Issues (IL State Univ.) - White Paper An excellent document on Duplex Mismatches published by Netcordia - Switch Port Duplex Mismatch TCP/IP Troubleshooting Novell has published several TIDs which provide excellent advice on resolving network degradation in a Pure-IP environment. Performance, Tuning, and Optimization - Novell TID 10012765 NetWare TCPIP Performance Troubleshooting and Tuning Guide - Novell TID 10018661 Troubleshooting TCPIP Hangs - Novell TID 10018663 Troubleshooting NIC Compatibility Issues (IL State Univ.) - White Paper Insufficient Packet Receive Buffers (PRBs) When files are being transferred between Servers, data is being streamed and disk I/O is occurring on a continuous basis. It is not unexpected for the periodic updates to disk or the odd bad packet to cause the in use Packet Receive Buffers to climb to compensate for the processing delays. That is part of the intended design and a reason why sufficient Packet Receive Buffers (PRBs) should be allocated for both the Minimum (initial) and Maximum values. Incorrect Maximum Physical Receive Packet Size Setting While it is frequently documented that the maximum legitimate packet size for Ethernet is 1514, there are some NIC drivers which rely upon buffers that are larger than the actual packet size. If the Maximum Physical Receive Packet Size is set to the absolute Maximum Transport Unit (MTU) for the protocol in use for one of these NICs, excess network errors can be expected, dramatically degrading overall performance. Intel has replaced the E100B.LAN driver - Novell TID 2953560 Conflicts With Third Party Software (One example: NSI Balancing Software for NetWare) There are some circumstances where third party products intended to improve performance can actually degrade it if not configured correctly or installed incorrectly. A documented example includes NSI Balancing Software for NetWare and ArcServe (same conflict can also affect TaskMaster). ARCserve 6.x slow throughput across network - Novell TID 2943902 General Troubleshooting Advice Novell has published several TIDs which identify Hyper-Threading as a potential source of network degradation: Information on Hyper-Threading - Novell TID 10091810 Intermittently extremely slow workstation performance - Novell TID 10089301 There is nothing within TaskMaster that needs to be or can be configured for different transport protocols. When any significant performance issues are encountered, they tend to be network related. SxCOPY / SYNC On Broadcom Gigabit Ethernet Sites have reported encountering erratic performance with SYNC and SxCOPY when using UDP on Servers which have NICs that utilize the Broadcom Gigabit Ethernet chipset (prevalent in both embedded NICs on Compaq, Dell and HP systems, as well as NICs from 3Com, Compaq, HP and others). The problem has been traced to B57.LAN and Q57.LAN drivers for the Broadcom Gigabit Ethernet chipset. It appears that drivers prior to v8.65 have a problem with corrupted checksums being generated for fragmented UDP packets that results in packets being discarded as corrupt which causes long transmission delays and/or communications time out errors. The following quick test can be performed to check the drivers in use to determine with certainty if the problem exists: Load the PING.NLM on a NetWare Server with the B57.LAN or Q57.LAN driver loaded and try to PING another Server with the same driver loaded using the following packet sizes (allow each packet size test to run for at least 15 seconds): 4460 4464 ... 4760 4764 Problem drivers will encounter dropped packets and/or a much slower response time for the 4464 and 4760 byte packets. There is no reason such packet sizes should cause problems unless the driver is not processing them correctly. In addition to these issues, some other problems have been reported with the B57.LAN and Q57.LAN drivers that do not appear to have been fully resolved until the v8.65 release... Duplicate MAC Addresses and UDP issues with Broadcom B57 and Q57 Cards - TID10076183 (last modified 20MAY2003) http://support.novell.com/cgi-bin/search/searchtid.cgi?/10076183.htm Communication problems after applying NW51 sp5 or NW6 sp2. - TID10074067 (last modified 23JUN2003) http://support.novell.com/cgi-bin/search/searchtid.cgi?/10074067.htm At last check, the Broadcom support site only has the v8.60 drivers (included in NetWare v6.5 SP3/SP4/SP5, NetWare v6.0 SP5 and NetWare v5.1 SP8). However, the following vendor specific WEB Sites have the v8.65 available: Compaq / HP B57.LAN v8.65 http://h18023.www1.hp.com/support/files/server/us/download/24046.html IBM B57.LAN v8.65 http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=ibm&lndocid=MIGR-43815 Using the /+NCP SYNC option avoids the conflict since TCP is typically the IP transport for NCP in a Pure-IP environment and packet fragmentation is managed by other than the UDP protocol. Using /+IP=#### SYNC option (where #### specifies a packet size of 4 KB or less - i.e., either 1-4 [KB] or 1024 - 4096 [bytes]) can also be used to minimize the conflict since fragmentation becomes much less of an issue. However, either option reduces throughput versus applying the updated drivers. Ultimately, the best solution is to update to the latest B57.LAN / Q57.LAN drivers (v8.65 at the minimum). SxCOPY / SYNC Performance Feature Comparison: SXCOPY / SYNC versus NCOPY & XCOPY Feature Comparison: SYNC versus RSYNC Bandwidth and Speed It is important to note that stated bandwidth speed is a theoretical maximum and not guaranteed as sustainable. In fact, sustaining anything above 60% of the stated bandwidth on Ethernet is most often considered efficient throughput due to Ethernet's design and collison avoidance overhead. Even if it were possible to consistently sustain maximum throughput on a 1 Mbit rated WAN link and use it for data transfer only (i.e., no IP packet headers, protocol IDs, acknowledgements, replies/result codes, API headers, file indentifiers, data offset pointers or CRC/Checksums), the result would be a 128 KByte / second transfer rate. That throughput would only happen IF there were NO OVERHEAD (communications or application) and 100% of the stated bandwidth could be sustained for data transfer purposes only. Of course, such a scenario would essentially be useless since there would be no overhead allowed for directing the data packets to an IP address and port nor for designating a file / offset into which the data should be stored nor any checks for data integrity or recovery from dropped packets. The ultimate scenario, though fast, provides no integrity, much less purpose. TaskMaster Server-to-Server file copy operations do more than just stream data across the link. The additional bandwidth (i.e., over that required for just the data) required to insure completeness, integrity and reliability of the file copy process is an integral part of TaskMaster's design. The DOS and non-DOS Name Space names are also synchronized, along with the Ownership, Trustees, all date/time stamps, attributes, IRMs, etc. Streaming the data is the most efficient and bandwidth consuming portion of the file copy operation but it is only part of the overall amount of information exchanged. The other packets tend to be small in nature, thus lowering bandwidth utilization and efficiency during their exchanges. In an effort to be as efficient as possible with the bandwidth available, dynamic, real-time Compression and Block (Delta Change) Update logic has been designed into TaskMaster's data transfer routines. When Compression is enabled (default), the size of the streamed data packets tend to be reduced to as little as 12% of the original data size with a fractionally larger gap in time between data streams for the compression and decompression operations. When Block (Delta Change) Update is enabled (default), the remote file is pre-read with only the CRC value for the pre-read block exchanged creating a scenario of a lot of small packets rather than streamed data. Both of these features help maximize bandwidth efficiency by minimizing the amount of data actually transferred. During SYNC operations, it is also important to note that TaskMaster must retrieve directory listings from the Remote Server to be used in determining which files need to be added, created, deleted and updated between Servers. Not only is this a different type of data transfer but time to compare the directory listings, create/open and delete the directories/files are activities affecting the data transfer rate. With these same facts in mind, it is easier to understand why TaskMaster is not likely to either achieve or sustain maximum bandwidth during data transfers. Raw speed is not an advantage that TaskMaster touts over the basic file copying capabilities built into a Client OS'. The main advantage offered by TaskMaster will always be the automation of the processing, the efficiency with which it occurs, the integrity of the data transfer, the automatic support for NetWare file attributes / ownerships / trustees / etc., and the added security provided by Server-to-Server operations versus Client based utilities. Optimized SET Parameters The following SET Parameter adjustments have been User tested and recommended to improve TaskMaster Server-to-Server file copy performance: Communications SET Largest UDP Packet Size = 32768 Note: Allows TaskMaster IP (UDP) data transfers to stream the largest data packet size supported (if also supported by the LAN/WAN link). SET Maximum Physical Receive Packet Size = 2048 Note: Conserves Server RAM in Pure-IP environments (exceeds MTU). Reference: Novell TID 2953560   &   Novell TID 10065644 Directory Caching (NW v5.0 / 5.1) Common File System (NW v6.0 / 6.5) SET Maximum Concurrent Directory Cache Writes = 500 Note: Default value is based on older, slower disk technology. Reference: Novell TID 10065644 Directory Caching (NW v5.0 / 5.1) Traditional File System (NW v6.0 / 6.5) SET Maximum Directory Cache Buffers = 4000 Reference: Novell TID 10012765   &   Novell TID 10021744 SET Minimum Directory Cache Buffers = 2000 Reference: Novell TID 10012765   &   Novell TID 10021744 SET Directory Cache Allocation Wait Time = 0.5 Sec Reference: Novell TID 10012765   &   Novell TID 10021744 Disk SET Enable Disk Read After Write Verify = OFF Note: ON forces NetWare to re-read data after each write for verification. Redundant since most Disk Drives have this feature built-in. SET Enable Hardware Write Back = ON Note: If supported by installed Disk Drive(s), this caching / performance feature can improve performance. SET Sequential Elevator Depth = 2000 Note: Default value is based on older, slower disk technology. Reference: November 2001 Novell AppNote File Caching (NW v5.0 / 5.1) Traditional File System (NW v6.0 / 6.5) SET Maximum Concurrent Disk Cache Writes = 2000 Note: Default value is based on older, slower disk technology. Reference: Novell TID 10065644 NCP SET Client File Caching Enabled = OFF Reference: Novell TID 10095627   &   Novell TID 10085688   &   Novell TID 10094172 SET Level 2 OpLocks Enabled = OFF Reference: Novell TID 10095627   &   Novell TID 10095317   &   Novell TID 10094172 SET NCP Protocol Preferences = TCP UDP Reference: Novell TID 2952266   &   Novell TID 10014475 NSS SET NSS Cache Balance Percent = 85 Reference: Novell TID 10012765   &   Novell TID 10065215 TCP SET TCP Delayed Acknowledgement = OFF (NW v5.1 SP3 & later / NW v6.x) SET TCP Delayed Ack = OFF (NW v5.1 SP2a & before / NW v5.0) Reference: July 2002 Novell AppNote   &   Novell TID 10061174   &   Novell TID 10061307   &   Novell TID 10068360 SET TCP IP Maximum Small ECBS = 65534 Reference: Novell TID 10013542   &   Novell TID 10089748 SET TCP Minshall Algorithm = OFF Reference: July 2002 Novell AppNote   &   Novell TID 10089921 SET TCP Nagle Algorithm = OFF (NW v5.1 / NW v6.x) SET TCP Nagles Algorithm = OFF (NW v5.0) Reference: July 2002 Novell AppNote   &   Novell TID 10061174   &   Novell TID 10089921 After making any of the recommended changes to the SET Parameters, always be sure to issue the FLUSH CDBE command at the Server System Console prompt to save the changes to the NetWare Registry.