NFT Commands Summarized

NFT commands fall into several different, overlapping groups, based on their scope of operation, their filetransfer roles, and how they are processed during execution.

General and Storage-Defaulted Commands

Most NFT commands are general in scope and apply to any (secure) hosts that NFT serves, including (but not limited to) STORAGE. DIR (to list files) and CP (to copy or transfer them between machines) are examples of general NFT commands.

Some NFT commands are dedicated by default, however, to transferring files to or from STORAGE (such as PUT) or manipulating stored files (such as LN). The storage-defaulted commands exist because STORAGE is the primary file-transfer target for many NFT users and many NFT executions. These special NFT commands

  • do not accept (or need) the NFT prefix syntax to specify the location of files to be processed (locations are specified by argument position, as with FTP), and
  • can only be used for nonSTORAGE file transfers if you precede their use with an OPEN command. NFT's OPEN somewhat mimics FTP's OPEN, but unlike FTP it is not required for most NFT file-transfer operations (and is never required for storage-only operations). Even when you use OPEN, some commands are still limited to storage-only use (as the table below shows).

This table lists the NFT commands by their default scope. Each command has a detailed explanation in the NFT Command Dictionary.

General NFT Commands *

Storage-Defaulted Commands +

cp, delete, ren

get

dir, ls, pwd

put

cd, cdup, lcd

ln

mkdir, rmdir

chown

abt, rpt, clr

 

block, group, endgr

open, close

help, quit, source, time

chmod, chgrp

source, time

* For additional commands (mostly toggles) that control the NFT file-transfer environment, see the next section.

+ Using OPEN lets you "generalize" GET and PUT to other remote hosts, but most hosts other than STORAGE do not allow LN remotely. CHOWN can never be generalized to any host except STORAGE (even after you use OPEN).


Environment-Variable Settings

NFT provides several (pairs of) commands that do not directly perform file transfers or directory changes but rather let you control the file-transfer environment by toggling between alternative states. For each pair, one environment setting is NFT's default, as indicated in the table below (and the most noteworthy default, NOCLOBBER, prevents NFT from overwriting any file with a transferred file of the same name). The STATUS command reports the current settings. Two related environment commands also listed here support many-way choices (not just two-way toggles) among verbosity levels and NFT session numbers. Each command has a detailed explanation in the NFT command dictionary.

NFT Environment Variables

Toggle Commands

Specify how multiple commands execute

sync (default, serially)
async

Resolve file-name conflicts (overwriting)

noclobber (default, no overwrite)
clobber

Display NFT output messages

term (default, show)
noterm

Log all NFT input and output

clog (default, no log)
log filename

Use login-node jumbo frames

routing (default, routes)
norouting

Store multiples of mission critical files

nodualcopy (default)
dualcopy

Specify HPSS class of service

setcos nnn

Specify verbosity of output

verbose mask

Change NFT session

session nn|new

Report current NFT environment

status


Synchronous and Asynchronous Command Modes

The SYNC and ASYNC pair of commands overtly toggles NFT between two modes of executing multiple requests or "jobs," but other ways to change command-execution modes also exist.

By default, NFT commands (and jobs) execute serially (in SYNC or synchronous mode). While commands such as DIR and CD generally use so few resources as to execute (almost) at once, actual file transfers (copies with CP) may be delayed by resource unavailability on the server or client machines. Because it is obviously desirable to make or change directories before starting file transfers that depend on those moves (for example), serial (SYNC) execution is generally quite appropriate.

NFT supports three exceptions to or exemptions from SYNC mode, however, in increasing order of scope:

  1. GET/PUT: When you use the storage-defaulted commands GET and PUT with file filters (* or ?) or with file lists, NFT always processes the resulting multiple file-transfer requests in parallel (asynchronously), regardless of the current SYNC/ASYNC mode setting.
  2. GROUP/ENDGR: While remaining in SYNC mode, you can specify a subset of commands to process in parallel (asynchronously among themselves) by preceding them with GROUP and following them with ENDGR. To force all subsequent commands to wait until everything within such a GROUP has executed, use BLOCK after ENDGR and before the next command. For example, the following NFT command sequence first creates directory TEST3, then ASYNCHRONOUSLY copies three files into that directory (since arrival order is often unimportant), then, and only after all three have arrived (BLOCK), issues a report (RPT).
     

mkdir test3
cd test3
group
      cp yana:file1 :file1
      cp atlas:file2 :file2
      cp lucy:file3 :file3
endgr
block
rpt -a
  1. ASYNC: The ASYNC command should be used with caution. Results may not be as expected. The most general way to allow parallel NFT jobs is to use the ASYNC command. ASYNC cancels the default SYNC mode and makes NFT execute ALL subsequent commands in parallel (asynchronously), as soon as resources for them are available. BLOCK has no effect in ASYNC mode. When you run NFT asynchronously, jobs are scheduled based on availability of the system resources needed to perform them. They may not all start or run immediately. The point of this scheduling is to prevent overloading the NFT server and its network connections. Most NFT jobs, such as directory listings, directory creation, or reports, require few resources and receive immediate attention. Load balancing really becomes an issue only when you transfer files between machines. Here the NFT scheduling algorithm is quite complex, but it is based on these factors:
  • The number of current transfers from the donating host.
  • The number of current transfers by the requesting user.
  • The size of the file(s) being transferred.
  • The supply of resources (e.g., disk space) at the source and sink of each file transfer. 

Local, Immediate, and Job Commands

NFT distinguishes between those commands executed locally, by your NFT client, and those executed remotely, by the NFT server. Furthermore, among the server commands, NFT distinguishes between those commands executed immediately and those ("job" commands) queued for persistent, numbered, monitored execution.

Local (Client) Commands

Local (client) commands are those that are executed completely by the NFT client that you run. Because the client, not the server, executes them, local commands have no NFT job numbers assigned to them. The NFT local commands are:

  • async

 

  • close+

 

  • help

 

  • norouting

 

  • quit

 

  • status
  • block *

 

  • dualcopy

 

  • log

 

  • noterm

 

  • routing

 

  • sync
  • clobber

 

  • endgr *

 

  • noclobber

 

  • open +

 

  • setcos

 

  • term
  • clog

 

  • group

 

  • nodualcopy

 

  • pwd

 

  • source

 

  • time

* These commands do require communication with the server and use job numbers, but the numbers are never seen by the user and no BEGIN, DONE, ERROR, or ACCEPTED messages are returned for them.

+ The NEXT job (server-executed) command actually and persistently makes the connection requested by an OPEN or CLOSE local command that precedes it.


Server Commands

Immediate Commands

NFT immediate commands execute as soon as the NFT server receives them. They are not placed on the standard job-execution queues as the regular job commands (next section) are. Any job subsequently submitted to the server is affected by the previous immediate commands, but jobs submitted prior to an immediate command will never be affected by it. The immediate server commands are:

  • abt

 

  • session+
  • clr

 

  • verbose
  • rpt

Job Commands

NFT job commands are server-executed commands each assigned a unique job number that you may use to get information about the job or to abort the job later. These commands are automatically retried by the NFT server when a temporary failure occurs because of network, host, or communication problems. The NFT job commands are:

  • cd

 

  • chgrp

 

  • chown

 

  • get

 

  • ls

 

  • rename
  • cdup

 

  • chkrouting

 

  • delete

 

  • lcd

 

  • mkdir

 

  • rmdir
  • cp

 

  • chmod

 

  • dir

 

  • ln

 

  • put