Google
 

Trailing-Edge - PDP-10 Archives - decnet_mcb_cusps_703a - 10,7/dcncsp/nft.man
There are 3 other files named nft.man in the archive. Click here to see a list.
                                   Document: RDH-80-002-00-S

                                   Date: 15-AUG-85

                                   Project: NFT-10

                                   Charge Number: 18-07155

                                   Product ID:

                     





                     FUNCTIONAL SPECIFICATION FOR

                     NFT-10 NIP/FAL/TSC Executive







                                                          
Issued By:      Robert Houk
NFT-10 NIP/FAL/TSC Executive                                    Page 2
                                                             12-Jan-84




                          

















COPYRIGHT (c) DIGITAL EQUIPMENT CORPORATION 1984,1986. ALL RIGHTS RESERVED.

THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE INCLUSION
OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER COPIES
THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY OTHER
PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY TRANSFERRED.

THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE 
AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT 
CORPORATION.

DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.

NFT-10 NIP/FAL/TSC Executive                                    Page 3
Product Overview                                             12-Jan-84



1.0 Product Overview


1.1 Product Abstract

NFT-10 is a user-mode system  utility designed to provide  distributed
file manipulation capabilities to TOPS-10 users.

NFT-10 provides  facilities with  which users  may copy,  change,  and
delete data files residing anywhere within a DECnet computer network.

NFT-10 also provides the File Access Listener (FAL) which enables  re-
mote systems to access files within the local TOPS-10 file system.

The NFT-10 command  language will  be similar to  other TOPS-10  CUSPs
such as DIRECT, PIP, and the languages.

1.2 Markets

See the DECnet-10 product plan.

1.3 Competitive Analysis

Not Applicable.

1.4 Product Audience

NFT-10 is aimed at the TOPS-10 user who must deal with data files in a
distributed computer network.
NFT-10 NIP/FAL/TSC Executive                                    Page 4
Product Goals                                                12-Jan-84



2.0 Product Goals


2.1 Environments

NFT-10 will run under TOPS-10 7.02 or later monitors with DECnet  net-
works.

NFT-10 has no explicit environmental requirements.

2.2 Reliability Goals

Since NFT-10 is  the major  data file access  mechanism supplied  with
DECnet-10 it must be of the utmost reliability.

It is a specific goal that NFT-10 will NEVER claim to have successful-
ly copied a data  file when it  has not in fact  done so. NFT-10  will
have  many  internal  redundancy  checks  on  both  internal   program
operation and overall data integrity.

2.3 Non-Goals

It is not a goal that NFT-10 should replace PIP-10.

NFT-10 will not provide "OPR" control over FAL operations.

NFT-10 will not provide a queued network file spooling mechanism.

NFT-10 will not provide user accounting/logging information.

NFT-10 will not support non-sequential file access.
NFT-10 NIP/FAL/TSC Executive                                    Page 5
General Functional/Operational Definition                    12-Jan-84



3.0 General Functional/Operational Definition

NFT-10 (NIP/FAL/TSC Executive) is a user-mode system utility which can
manipulate (copy, rename, delete, execute) data files in a distributed
(network) computer  system environment  in response  to user  commands
either typed in from a command terminal or from a pre-defined commands
file.

NFT accepts commands in a  "verb" mode compatible with native  TOPS-10
command syntax. NFT command syntax is of the form:

        <command> [[<arg>]] <eol>

Where <command> is the name of a valid NFT command function; and <arg>
is/are any required and/or optional  arguments needed to complete  the
command. All commands must be  terminated by an End-Of-Line  condition
(typically a carriage-return line-feed sequence).

Appendix A lists a syntactical  definition of the command language  in
general, and of "file specification"s in particular.

Command-specific switches are  listed with  each command  description;
general non-command-specific switches  are listed with  each NFT  mode
section; the "standard" file-specific switches are listed in  Appendix
B.

The NFT program operates in one of three modes: NIP, FAL, or TSC. Each
operational mode is both conceptually and pragmatically distinct  from
the others. In  effect each NFT  operational mode can  be viewed as  a
separate program, replete with  its own prompt,  set of commands,  and
operational philosophy.
NFT-10 NIP/FAL/TSC Executive                                    Page 6
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation


3.1 NIP Mode Operation

NIP (Network Interchange Process) is the default operational mode  for
NFT, and is the mode in which NFT always starts.

NIP mode provides the  interactive file manipulation facilities  which
constitute the major visible portion of NFT as a whole.

NIP commands are:

1.   COPY - Make new copies of selected files
2.   DDT - Call  DDT if  it is  loaded (force  an "unsolicited  break-
     point")
3.   DELETE - Delete selected files
4.   DIRECTORY - List selected files
5.   EXIT - Terminate program execution; return to monitor mode
6.   HELP - Provide help on NIP operation
7.   NETWORK - Display information about network nodes
8.   PRINT - Queue selected files to line printer spooler
9.   RENAME - Change the names and/or attributes of selected file(s)
10.  SUBMIT - Submit selected files to batch command processor
11.  TLINK - Cross-connect ("link") two terminals
12.  TYPE - Type the selected files on controlling terminal
13.  DDELETE - DAP-mode DELETE command
14.  DDIRECTORY - DAP-mode DIRECTORY command
15.  DRENAME - DAP-mode RENAME command
16.  DSUBMIT - DAP-mode SUBMIT command
17.  FAL - Enter FAL mode
18.  TSC - Enter TSC mode

The general NIP command switches are:

/[NO]MOAN      Do [not] issue general warning complaints.

               The /MOAN switch is used to instruct NIP to issue warn-
               ings when a dubious condition is encountered, typically
               requiring NIP to  make some  "wild" guess  (e.g., in  a
               file copy operation, the data  type or data byte  size)
               in order to  compete the command.  The default is  /NO-
               MOAN.

/[NO]OKERROR   Do [not] abort on execution errors.

               The /[NO]OKERROR  switch controls  whether or  not  NIP
               will abort  the command  if an  error occurs.  /OKERROR
               directs NIP to  ignore file  access and  I/O errors  as
               appropriate, issuing warning  messages. /NOOKERROR  in-
               structs NIP to abort the  current command on the  first
               occurence of a  file access or  I/O error. The  default
               setting is /NOOKERROR.

/TOTALS[:lst]  Explicitly control the totals summary.

               The /TOTALS switch controls the totals summary  printed
               at the end of the command execution. The various totals
NFT-10 NIP/FAL/TSC Executive                                    Page 7
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation


               quantities (files,  errors, etc.)  may be  individually
               controlled by specifying  the totals  quantities to  be
               listed as the ":lst" value  to the switch. All  /TOTALS
               quantities are "additive" in that the specification  of
               one quantity does not affect  any other quantity. If  a
               quantity-name is preceded with a "NO" then that quanti-
               ty will not  be listed.  If more that  one quantity  is
               specified then the individual quantities must be separ-
               ated with  commas, and  the entire  list enclosed  with
               parenthesis. /TOTALS  or  /TOTALS:ALL  directs  NIP  to
               print a totals summary of all applicable quantities  at
               the completion (successful or otherwise) of the current
               command. /TOTALS:NONE instructs NIP to not print a  to-
               tals summary. The /TOTALS quantitites are:

               1.   BITS - List the total number of data bits
               2.   BYTES - List the total number of data bytes
               3.   WORDS - List the total number of 36-bit words
               4.   RECORDS - List the total number of records
               5.   BLOCKS - List the total number of 128-word blocks
               6.   PAGES - List the total number of 512-word pages
               7.   FILES - List the total number of files
               8.   BAUD - List the effective data transfer rate (bits
                    per second)
               9.   ERRORS - List the total number of execution errors


               Inappropriate items (e.g., DELETE/TOTALS:BAUD) are  ig-
               nored.



3.1.1 COPY command

The COPY command is  used to copy one  or more data files,  optionally
providing limited manipulation of the data being copied.

The COPY command syntax is:

        COPY [<out-fil> "="] <in-fil-expr> <eol>

Where <out-fil> is  the simple output  or destination file  specifica-
tion; and  <in-fil-expr> is  the input  or source  file  specification
expression.

Although by definition  an output  file is required,  the output  file
specification is optional. If no output file specification is provided
then the  output file  specification is  defaulted completely  as  de-
scribed below. Output file defaults are:

1.   Node - Local host
2.   Device - DSK: if local host, none if a remote node
3.   Path - [] (no explicit path selected)
4.   File Name - * (filled in from matching input file name)
5.   File Type - * (filled in from matching input file type)
NFT-10 NIP/FAL/TSC Executive                                    Page 8
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - COPY command



6.   /IOMODE - determined by data type from input file

The input file specification expression  is required and is  defaulted
as specified below:

1.   Node - Local host
2.   Device - DSK: if local host, none if a remote node
3.   Path - [] (no explicit path selected)
4.   File Name - *
5.   File Type - *
6.   /IOMODE - determined by file creation mode, default is ASCII

By default, the COPY command will make exact copies of the files being
copied. NIP can provide some elementary data manipulation.

The COPY command-specific switches are:

/[NO]ARROW     Do [not] print in "up-arrow" format.

               The /[NO]ARROW  switch controls  whether or  not  ASCII
               control characters will  be "printed"  literally or  in
               "up-arrow" form. /ARROW directs NIP to convert all con-
               trol characters except tab, carriage-return, line-feed,
               and form-feed into the corresponding arrow form. /NOAR-
               ROW directs NIP to not convert control characters  into
               arrow form. The default is /NOARROW.

/[NO]BAUD      Do [not] print the baud rate in the totals summary.

               The /[NO]BAUD switch controls whether or not the totals
               summary will include the baud (bits per second) rate of
               the data transfer. /BAUD  will always include the  baud
               rate in the totals summary. /NOBAUD will never  include
               the baud  rate in  the  totals summary.  The  /[NO]BAUD
               switch is merely a  "shorthand" way of controlling  the
               printing of the baud rate  without having to specify  a
               complete /TOTALS switch. The default for network trans-
               fers is /BAUD, and /NOBAUD otherwise.

/[NO]CONCAT    Do [not] concatenate input files.

               The /CONCATENATE switch controls whether or not  multi-
               ple input files are concatenated into one single output
               file or kept as  separate distinct output files.  /CON-
               CATENATE directs NIP  to combine  multiple input  files
               into a single output  file. /NOCONCATENATE directs  NIP
               to keep  the input  files distinct  in separate  output
               files. The default is /NOCONCATENATE.

/CRLF:nnn      Issue free carriage-return line-feeds.

               The  /CRLF  switch  controls  the  generation  of  free
               carriage-return line-feeds if the ASCII line width  ex-
               ceeds "nnn" columns. /CRLF:nnn  directs NIP to start  a
NFT-10 NIP/FAL/TSC Executive                                    Page 9
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - COPY command



               new line (issue  a free  carriage-return line-feed)  if
               the accumulated line width of the current line  exceeds
               "nnn" characters. If "nnn" is 0 then no free  carriage-
               return line-feeds will be issued. The default is /CRLF:
               0.

/[NO]CSN       Do [not] generate card sequence numbers.

               The /CSN switch controls the generation or  suppression
               of card sequence  numbers. /CSN directs  NIP to  supply
               incremental card sequence numbers  to each line  ("rec-
               ord") within the file  data stream. /NOCSN directs  NIP
               to suppress  card sequence  numbers. The  default is  /
               NOCSN.

/CSNCOL:nnn    Sets the starting column for CSNs.

               The /CSNCOLUMN switch is used in conjunction with the /
               CSN switch to control  the generation of card  sequence
               numbers. /CSNCOLUMN:nnn specifies  the starting  column
               for the generation  of card sequence  numbers. The  de-
               fault is /CSNCOLUMN:72.

/CSNINC:nnn    Sets the CSN incremental value.

               The /CSNINCREMENT switch  is used  in conjunction  with
               the /CSN  switch  to  control the  generation  of  card
               sequence numbers. /CSNINCREMENT:nnn  specifies the  in-
               cremental value to be added to each succesive card  se-
               quence number (the  "nnn" is  also the  first card  se-
               quence number). The default is /CSNINCREMENT:1.

/CSNWID:nnn    Sets the width of the CSNs.

               The /CSNWIDTH switch is used in conjunction with the  /
               CSN switch to control  the generation of card  sequence
               numbers. /CSNWIDTH:nnn specifies  the width (number  of
               digits) of each card sequence number. The default is  /
               CSNWIDTH:8.

/[NO]EBCDIC    Indicates that the character data is [not] EBCDIC.

               The /EBCDIC switch is  used to control the  translation
               of ASCII  data to  or from  EBCDIC data  (depending  on
               whether the /EBCDIC  switch is  used on  the output  or
               input file respectively). /EBCDIC indicates that  ASCII
               data should be translated in EBCDIC data. /NOEBCDIC in-
               dicates that no translation  of ASCII data into  EBCDIC
               data should  be  performed. If  any  character-oriented
               processing of the data is to be performed (such as man-
               ipulating "CSN's",  "WRAPping"  of  lines,  etc.)  then
               EBCDIC data must first  be translated into ASCII  data.
               The default is /NOEBCDIC.
NFT-10 NIP/FAL/TSC Executive                                   Page 10
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - COPY command



/FLAG:(UP-     Flag upper or lower case characters.
PER,LOWER)
               The /FLAG switch controls the "flagging" of certain AS-
               CII characters. /FLAG:UPPER directs  NIP to flag  upper
               case alphabetic ASCII  characters. /FLAG:LOWER  directs
               NIP to flag lower  case alphabetic ASCII characters.  A
               character is "flagged" by preceding the character  with
               a single quote character  ("'"). The default is  /FLAG:
               NONE.

/[NO]LSN       Do [not] generate ASCII line sequence numbers.

               The /LSN switch controls the generation or  suppression
               of line sequence  numbers. /LSN directs  NIP to  supply
               incremental line sequence numbers  to each line  ("rec-
               ord") within the file  data stream. /NOLSN directs  NIP
               to suppress  line sequence  numbers. The  default is  /
               NOLSN.

/[NO]LSNCON    Do [not] reset LSNs on page boundry.

               The /LSNCONTINUOUS switch is  used in conjunction  with
               the /LSN  switch  to  control the  generation  of  line
               sequence numbers. /LSNCONTINUOUS directs NIP to  ignore
               page boundries in ASCII  files, and just increment  the
               line sequence number continuously  for each ASCII  line
               of text. /NOLSNCONTINUOUS directs NIP to reset the line
               sequence number at each ASCII page boundry. The default
               is /NOLSNCONTINUOUS.

/LSNINC:nnn    Sets the LSN incremental value.

               The /LSNINCREMENT switch  is used  in conjunction  with
               the /LSN switch to control  the generation of line  se-
               quence numbers. /LSNINCREMENT:nnn sets the increment to
               be added to each  successive line sequence number  (the
               "nnn" is also the first line sequence number). The  de-
               fault is /LSNINCREMENT:10.

/[NO]NULLS     Do [not] preserve ASCII nulls.

               The /NULLS switch controls whether or not NIP will sup-
               press or preserve ASCII null characters. /NULLS directs
               NIP to preserve  ASCII nulls. /NONULLS  directs NIP  to
               suppress ASCII nulls. The default is /NONULLS.

/[NO]SPACES    Do [not] convert tabs into spaces.

               The /SPACES switch controls whether or not NIP converts
               ASCII tab  characters  into  multiple  spaces.  /SPACES
               directs NIP to  replace ASCII tab  characters with  the
               corresponding number of space characters. /NOSPACES di-
               rects NIP to not convert tabs into spaces. The  default
               is /NOSPACES.
NFT-10 NIP/FAL/TSC Executive                                   Page 11
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - COPY command



/[NO]TABS      Do [not] convert spaces into tabs.

               The /TABS switch controls  whether or not NIP  converts
               multiple ASCII space  characters into  tabs. /TABS  di-
               rects NIP to convert (and compress) multiple spaces in-
               to the corresponding  number of  tabs. /NOTABS  directs
               NIP to not convert spaces  into tabs. The default is  /
               NOTABS.

/[NO]TRUNCA    Do [not] truncate trailing blanks.

               The /TRUNCATE switch controls  whether or not  trailing
               ASCII blanks are  suppressed (or truncated).  /TRUNCATE
               directs NIP  to  suppress or  truncate  trailing  ASCII
               blanks (i.e., spaces and/or tabs). /NOTRUNCATE  directs
               NIP to not supppess trailing  blanks. The default is  /
               NOTRUNCATE.

/WRAP:nnn      Word-wrap ASCII line after "nnn" columns.

               The /WRAP switch controls the ASCII word-wrapper mecha-
               nism. /WRAP:nnn directs NIP  to issue a free  carriage-
               return line-feed  at the  first blank  character  after
               "nnn" columns  of text.  If "nnn"  is 0  then no  word-
               wrapping is performed. The default is WRAP:0.



3.1.2 DDT Command

The DDT command is used to enter DDT if it is loaded.

The DDT command syntax is:

        DDT <eol>

DDT is the  program debugger,  and is  typically not  loaded with  the
standard system NFT, but only with  a "private debugging" NFT. To  re-
turn from DDT-mode to NFT command mode, type <ESC>P (i.e., the  normal
breakpoint procede command).

There are no DDT command-specific switches.


3.1.3 DELETE Command

The DELETE  command is  used to  delete or  destroy one  or more  data
files.

The DELETE command syntax is:

        DELETE <in-fil-expr> <eol>

Where <in-fil-expr> is the input or source file specification  expres-
NFT-10 NIP/FAL/TSC Executive                                   Page 12
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - DELETE Command



sion which identifies the files to be deleted.

The input file specification expression  is required and is  defaulted
as specified below:

1.   Node - Local host
2.   Device - DSK: if local host, none if a remote node
3.   Path - [] (no explicit path selected)
4.   File Name - not defaulted - must be explicitly specified
5.   File Type - not defaulted - must be explicitly specified

There are no DELETE command-specific switches.


3.1.4 DIRECT Command

The DIRECT command  is used to  obtain a directory  listing of one  or
more files.

The DIRECT command syntax is:

        DIRECT [<out-fil> "="] <in-fil-expr> <eol>

Where <out-fil> is  the simple  output or  listing file  specification
(i.e., where the directory listing is made); and <in-fil-expr> is  the
input or source file specification expression identifying those  files
for whom a directory listing is desired.

Although by definition a  listing file is  required, the listing  file
specification is optional. If no listing file specification is provid-
ed  then  the  directory  listing  will  be  directed  to  the   job's
controlling terminal. Listing file defaults are:

1.   Node - Local host
2.   Device - TTY: if no listing file is specified, DSK: otherwise
3.   Path - [] (no explicit path selected)
4.   File Name - a unique name will be generated
5.   File Type - DIR
6.   /IOMODE - ASCII

The input file specification expression  is required and is  defaulted
as specified below:

1.   Node - Local host
2.   Device - DSK: if local host, none if a remote node
3.   Path - [] (no explicit path selected)
4.   File Name - *
5.   File Type - *

There are no DIRECT command-specific switches.


3.1.5 EXIT Command
NFT-10 NIP/FAL/TSC Executive                                   Page 13
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - EXIT Command



The EXIT command is  used to terminate  NFT/NIP program execution  and
return to monitor level.

The EXIT command syntax is:

        EXIT <eol>

The EXIT command takes no command arguments.

There are no EXIT command-specific switches.


3.1.6 HELP Command

The HELP command is used  to obtain helpful information pertaining  to
the NIP-mode operation of NFT.

The HELP command syntax is:

        HELP [<command> [<switch>]] <eol>

Where <command> is a  valid NIP mode command  name; and <switch> is  a
valid command switch for the specified command name.

If no <command> is provided, then  a general terse description of  NIP
operation is given, followed by a listing of each command available.

If <command> is given then a general terse description of the specific
command operation  is given,  followed by  a listing  of each  command
switch available.

If <command> <switch> is given then a general terse description of the
specific command switch is  given, possibly followed  by a listing  of
legal command switch arguments if appropriate.

There are no HELP command-specific switches.
                            
                                 Note

     The  HELP  command  does  not  yet  accept  the   [<command>
     [<switch>] ] construction.



3.1.7 NETWORK Command

The NETWORK  command  is used  to  display information  about  network
nodes.

The NETWORK command syntax is:

        NETWORK<in-fil-expr> <eol>

Where <in-fil-expr>  is the  input node  specification. Although  full
NFT-10 NIP/FAL/TSC Executive                                   Page 14
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - NETWORK Command



file expressions are accepted, only the node name(s) has any  semantic
meaning to the NETWORK command.

There are no NETWORK command-specific switches.


3.1.8 PRINT Command

The PRINT command is used to print  files onto a line printer via  the
system line printer spooling facilities.

The PRINT command syntax is:

        PRINT  <in-fil-expr> <eol>

Where <in-fil-expr> is the input or source file specification  expres-
sion.

The actual operation of the PRINT  command is dependent on the  actual
operating system which executes the command, and has no intrinsic  re-
lation to the system from which the command was issued. For either the
TOPS-10 or TOPS-20 operating system, the PRINT command passes the  se-
lected file(s) to the  line printer spooler for  execution as a  print
job exactly as if PRINTed normally from the account specified in the /
USERID switch.

The input file specification expression  is required and is  defaulted
as specified below:

1.   Node - Local host
2.   Device - DSK: if local host, none if a remote node
3.   Path - [] (no explicit path selected)
4.   File Name - *
5.   File Type - none

There are no PRINT command-specific switches.


3.1.9 RENAME Command

The RENAME command is used to change the name or attribute information
of one or more files.

The RENAME command syntax is:

        RENAME <out-fil> "=" <in-fil-expr> <eol>

Where <out-fil> is the  simple output or  new file specification;  and
<in-fil-expr> is the input or old file specification expression  which
identifies the files to be renamed.

The output or new file defaults are:
NFT-10 NIP/FAL/TSC Executive                                   Page 15
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - RENAME Command



1.   Node - unchanged
2.   Device - unchanged
3.   Path - unchanged
4.   File Name - unchanged
5.   File Type - unchanged

The input file specification expression  is required and is  defaulted
as specified below:

1.   Node - Local host
2.   Device - DSK: if local host, none if a remote node
3.   Path - [] (no explicit path selected)
4.   File Name - *
5.   File Type - *

There are no RENAME command-specific switches.


3.1.10 SUBMIT Command

The SUBMIT command  is used  to execute  command files  via a  command
interpreter or batch processing facility.

The SUBMIT command syntax is:

        SUBMIT <in-fil-expr> <eol>

Where  <in-fil-expr>  is  the  input  or  source  file   specification
expression.

The actual operation of the SUBMIT command is dependent on the  actual
operating system which executes the command, and has no intrinsic  re-
lation to the system from which the command was issued. For either the
TOPS-10 or TOPS-20  operating system,  the SUBMIT  command passes  the
selected file(s) to the batch  processing facility for execution as  a
batch job exactly as if submitted normally from the account  specified
in the /USERID switch  (SUBMIT is normally illegal  if no /USERID  has
been given).

There is no output file specification, any "log" files or the like are
generated in accordance with whatever rules  are in effect on the  re-
mote system which "executes" the SUBMIT command.

The input file specification expression  is required and is  defaulted
as specified below:

1.   Node - Local host
2.   Device - DSK: if local host, none if a remote node
3.   Path - [] (no explicit path selected)
4.   File Name - *
5.   File Type - CTL

There are no SUBMIT command-specific switches.
NFT-10 NIP/FAL/TSC Executive                                   Page 16
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - TLINK Command



3.1.11 TLINK Command

The TLINK command is used to  establish a terminal to terminal  "link"
for the exchange of ASCII characters.

The TLINK command syntax is:

        TLINK [<out-fil> "="] <in-fil-expr> <eol>

Where <out-fil> is the simple output or destination terminal  specifi-
cation;  and   <in-fil-expr>  is   the   input  or   source   terminal
specification expression.

The TLINK command is  identical to a TSC  command, followed by a  TSC-
mode TLINK command (see  section 3.4.3 for  a detailed description  of
the TLINK command).  It is  provided in NIP  mode solely  as a  conve-
nience.


3.1.12 TYPE Command

The TYPE command  is used  to type  or print  one or  more files  onto
[typically] the job's controlling terminal.

The TYPE command syntax is:

        TYPE [<out-fil> "="] <in-fil-expr> <eol>

Where <out-fil> is  the simple output  or destination file  specifica-
tion; and  <in-fil-expr> is  the input  or source  file  specification
expression.

Although by definition  an output  file is required,  the output  file
specification is optional. If no output file specification is provided
then the  output file  specification is  defaulted completely  as  de-
scribed below. Output file defaults are:

1.   Node - Local host
2.   Device - TTY:
3.   Path - [] (no explicit path selected)
4.   File Name - * (filled in from matching input file name)
5.   File Type - * (filled in from matching input file type)
6.   /IOMODE - ASCII
7.   Switches - /ARROW/BYTESIZE:7/NOTOTALS

The input file specification expression  is required and is  defaulted
as specified below:

1.   Node - Local host
2.   Device - DSK: if local host, none if a remote node
3.   Path - [] (no explicit path selected)
4.   File Name - *
5.   File Type - *
6.   /IOMODE - ASCII
NFT-10 NIP/FAL/TSC Executive                                   Page 17
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - TYPE Command



The TYPE command is essentially equivilent to a COPY command to device
TTY:, with a default of /ASCII/ARROW/BYTESIZE:7/NOTOTALS.

The TYPE command-specific switches are the  same as for the COPY  com-
mand.


3.1.13 DDELETE Command

The DDELETE command is a special DAP-mode variant of the more  general
DELETE command.

The DDELETE command syntax is:

        DDELETE <in-fil> <eol>

Where <in-fil> is the simple input file specification.

The DDELETE command may  be used in place  of the DELETE command  when
exactly one simple file specification is used, and exactly one  remote
node is specified (no node wildcards). Under these circumstances  (for
the time being) the DDELETE command  may execute much faster than  the
more general DELETE command.


3.1.14 DDIRECT Command

The DDIRECT command is a special DAP-mode variant of the more  general
DIRECT command.

The DDIRECT command syntax is:

        DDIRECT [<out-fil> "="] <in-fil> <eol>

Where <out-fil> is the simple output file specification; and  <in-fil>
is the simple input file specification.

The DDIRECT command may  be used in place  of the DIRECT command  when
exactly one simple input file  specification is used, and exactly  one
remote node  is specified  (no node  wildcards). Under  these  circum-
stances (for  the time  being) the  DDIRECT command  may execute  much
faster than the more general DIRECT command.


3.1.15 DRENAME Command

The DRENAME command is a special DAP-mode variant of the more  general
RENAME command.

The DRENAME command syntax is:

        DRENAME [<out-fil> "="] <in-fil> <eol>

Where <out-fil> is the simple output file specification; and  <in-fil>
NFT-10 NIP/FAL/TSC Executive                                   Page 18
General Functional/Operational Definition                    12-Jan-84
NIP Mode Operation - DRENAME Command



is the simple input file specification.

The DRENAME command may  be used in place  of the RENAME command  when
exactly one simple input file  specification is used, and exactly  one
remote  node   is  specified   (no   node  wildcards).   Under   these
circumstances (for the  time being)  the DRENAME  command may  execute
much faster than the more general RENAME command.


3.1.16 DSUBMIT Command

The DSUBMIT command is a special DAP-mode variant of the more  general
SUBMIT command.

The DSUBMIT command syntax is:

        DSUBMIT <in-fil> <eol>

Where <in-fil> is the simple input file specification.

The DSUBMIT command may  be used in place  of the SUBMIT command  when
exactly one simple file specification is used, and exactly one  remote
node is specified (no node wildcards). Under these circumstances  (for
the time being) the DSUBMIT command  may execute much faster than  the
more general SUBMIT command.


3.1.17 FAL Command

The FAL command switches NFT into FAL mode.

The FAL command syntax is:

        FAL <eol>

See section 3.2 for a description of FAL operation.

There are no FAL command-specific switches.


3.1.18 TSC Command

The TSC command switches NFT into TSC mode.

The TSC command syntax is:

        TSC <eol>

See section 3.3 for a description of TSC operation.

There are no TSC command-specific switches.
NFT-10 NIP/FAL/TSC Executive                                   Page 19
General Functional/Operational Definition                    12-Jan-84
FAL Mode Operation


3.2 FAL Mode Operation

FAL (File Access Listener)  is the NFT mode  which provides the  slave
processing which enables  remote network processes  to gain access  to
the local TOPS-10 file system.

At least one FAL process must be running on each network node in order
for that node's  file system  to be accessible  from the  rest of  the
distributed network.

FAL mode is entered via  the "FAL" command to NFT.  FAL must run as  a
system-privileged process (i.e., as the OPR account).

FAL commands are:

1.   HELP - provide helpful text on FAL operation
2.   NETPPN - set default "NETPPN"
3.   REJECT - reject incoming requests from specified nodes
4.   START - start FAL I/O streams
5.   NIP - enter NIP mode
6.   TSC - enter TSC mode



3.2.1 HELP Command

The HELP command is used  to obtain helpful information pertaining  to
the FAL-mode operation of NFT.

The HELP command syntax is:

        HELP [<command>] <eol>

Where <command> is a valid FAL mode command name.

If no <command> is provided, then  a general terse description of  FAL
operation is given, followed by a listing of each command available.

If <command> is given then a general terse description of the specific
command operation  is given,  followed by  a listing  of each  command
switch available.

There are no HELP command-specific switches.
                            
                                 Note

     The  HELP  command  does  not  yet  accept  the   [<command>
     [<switch>] ] construction.



3.2.2 NETPPN Command

The NETPPN command is used to set the default network access ppn.
NFT-10 NIP/FAL/TSC Executive                                   Page 20
General Functional/Operational Definition                    12-Jan-84
FAL Mode Operation - NETPPN Command



The NETPPN command syntax is:

        NETPPN <ppn> <eol>

Where <ppn> specifies the project-programmer number.

The default network access ppn is used by FAL for file access  valida-
tion when the remote accessor does not specify a USERID. This facility
allows remote accessors  to gain some  degree of access  to the  local
file system without requiring a  valid account (to, e.g., read  suffi-
ciently unprotected files). If <ppn>  is blank then no default  access
ppn is provided and  only valid accounts may  gain access to the  file
system.


3.2.3 REJECT Command

The REJECT command is used to specify nodes and/or accounts which will
not be accepted by FAL.

The REJECT command syntax is:

        REJECT <in-fil-list> <eol>

Where <in-file-list> is the list  of nodes and/or accounts which  will
always be rejected by FAL.

The REJECT command allows for the selective unconditional rejection of
"undesirable" remote file access requests  based on the remote  USERID
and/or remote node. The  <in-fil-list> is a  list of "file  specifica-
tions" of which only the node  and directory (ppn) names have a  valid
semantic meaning (i.e., the  file name, while syntactically  accepted,
is ignored). If  only a node  is specified, then  all access  requests
from that  node  will  be  rejected; if  only  a  directory  (ppn)  is
specified then all access requests whose USERID matches the  directory
will be rejected; if both a node and directory are specified then  all
access requests by the specified USERID on the specified node will  be
rejected (but that USERID is still valid from other nodes).
                            
                                 Note

     Currently, only one REJECT  command is allowed, all  desired
     rejection specifications must be  specified in the same  RE-
     JECT command.  A second  (or  further) REJECT  command  will
     override any previous REJECT command in effect.



3.2.4 START Command

The START command is used to startup FAL's I/O streams to allow remote
file access.

The START command syntax is:
NFT-10 NIP/FAL/TSC Executive                                   Page 21
General Functional/Operational Definition                    12-Jan-84
FAL Mode Operation - START Command




        START <ntyp> <eol>

Where <ntyp> is either "ANF" or "DECNET".

The START command directs FAL to start "FALling", i.e., to initiate  a
quiescent I/O stream so that remote file accessors may gain entry into
the local file system. The START  command does not actually start  any
I/O, it merely enables the FAL process to receive and act upon  remote
file access requests.


3.2.5 NIP Command

The NIP command switches NFT into NIP mode.

The NIP command syntax is:

        NIP <eol>

The NIP command is illegal if any I/O streams are outstanding.

See section 3.1 for a description of NIP operation.


3.2.6 TSC Command

The TSC command switches NFT into TSC mode.

The TSC command syntax is:

        TSC <eol>

The TSC command is illegal if any I/O streams are outstanding.

See section 3.4 for a description of TSC operation.
NFT-10 NIP/FAL/TSC Executive                                   Page 22
General Functional/Operational Definition                    12-Jan-84
TSC Mode Operation


3.3 TSC Mode Operation

TSC (Terminal Service Controller) mode  provides a data link using  an
asychronous terminal line.

TSC provides a  data path  analguous to  a network  logical link,  but
using a regular 8-bit asychronous communications line (a "TTY") rather
than a formal network  link. TSC provides  all network management  for
the async link.

The async link can be used either as a terminal line or as a file data
path into the remote system.

When the async link is being used  as a terminal line the user's  con-
trolling terminal is effectively routed directly into the async line -
TSC (and the TOPS-10 monitor) act solely as an expensive null modem.

When the async link  is being used  as a file data  path the user  can
transfer, rename, and delete data files on the remote computer system,
as well as obtaining directory listings  of files resident on the  re-
mote system.

The async link can be used as a file data path only with other TOPS-10
or TOPS-20 operating systems.

TSC commands are:

1.   BOOT - bootstrap a TSC file server to the remote system
2.   HANGUP - hangup and terminate dataset terminal link
3.   HELP - provide helpful text on TSC operation
4.   TLINK - establish a terminal link
5.   TTY - enter into terminal dialoge mode
6.   NIP - enter NIP mode
7.   FAL - enter FAL mode
                            

                                 Note

     The "file mode" usage  of TSC is  not yet implemented,  only
     the "terminal mode" commands work.



3.3.1 HANGUP Command

The HANGUP command is used to  terminate the dataset terminal link  by
"hanging up" the phone.

The HANGUP command syntax is:

        HANGUP <eol>

The HANGUP command causes the phone to hangup, thereby terminating the
dataset terminal link. After  the HANGUP command  has been issued  the
dataset terminal is released.
NFT-10 NIP/FAL/TSC Executive                                   Page 23
General Functional/Operational Definition                    12-Jan-84
TSC Mode Operation - HANGUP Command



3.3.2 HELP Command

The HELP command is used  to obtain helpful information pertaining  to
the TSC-mode operation of NFT.

The HELP command syntax is:

        HELP [<command>] <eol>

Where <command> is a valid TSC mode command name.

If no <command> is provided, then  a general terse description of  TSC
operation is given, followed by a listing of each command available.

If <command> is given then a general terse description of the specific
command operation  is given,  followed by  a listing  of each  command
switch available.

There are no HELP command-specific switches.
                            
                                 Note

     The  HELP  command  does  not  yet  accept  the   [<command>
     [<switch>] ] construction.



3.3.3 TLINK Command

The TLINK command is used to establish a [dataset] terminal link  with
another computer system.

The TLINK command syntax is:

        TLINK [<out-fil> "="] <in-fil-expr> <eol>

Where <out-fil> is the simple output or destination terminal  specifi-
cation; and <in-fil-expr> is the  input or source terminal  specifica-
tion expression.

The <in-fil> file specification is required. A terminal must be speci-
fied as  the  device. Any  directory,  file  name, or  file  type  are
ignored.

The TLINK command OPENs the specified terminal in special "packed  im-
age mode" I/O data mode. The TLINK command does not itself perform any
terminal I/O, it merely establishes the terminal link. Actual terminal
I/O must be initiated via further TSC commands.

If the terminal is a dataset terminal with dialout capability, and the
user supplied a /DIAL:nnn switch with the <in-fil> specification, then
TSC will place an  outgoing call on the  dataset phone. When the  call
completes successfully control is returned  to TSC ready for  terminal
I/O. If the call  does not complete successfully  then the dataset  is
NFT-10 NIP/FAL/TSC Executive                                   Page 24
General Functional/Operational Definition                    12-Jan-84
TSC Mode Operation - TLINK Command



released before returning control to TSC.


3.3.4 TTY Command

The TTY command places TSC into terminal dialoge mode using the  async
terminal link.

The TTY command syntax is:

        TTY <eol>

The TTY command  is valid only  after a terminal  link has been  esta-
blished with a "remote system".

Terminal dialoge mode effectively  links the user's terminal  directly
into the async  terminal link path,  providing a transparent  terminal
connection to the remote system.

All characters except ^S, ^Q, and  ^\ are sent directly to the  remote
terminal line; all characters received  from the remote terminal  line
are sent directly to the users terminal.

The XOFF/XON (^S/^Q)  protocol is  obeyed with respect  to the  user's
command terminal.

The ^\ character is the escape  character which will return to  normal
command mode.


3.3.5 NIP Command

The NIP command switches NFT into NIP mode.

The NIP command syntax is:

        NIP <eol>

The NIP command  is illegal if  a dataset terminal  link is  currently
active.

See section 3.1 for a description of NIP operation.


3.3.6 FAL Command

The FAL command switches NFT into FAL mode.

The FAL command syntax is:

        FAL <eol>

The FAL command  is illegal if  a dataset terminal  link is  currently
active.
NFT-10 NIP/FAL/TSC Executive                                   Page 25
General Functional/Operational Definition                    12-Jan-84
TSC Mode Operation - FAL Command




See section 3.2 for a description of FAL operation.
NFT-10 NIP/FAL/TSC Executive                                   Page 26
Compatibility                                                12-Jan-84



4.0 Compatibility


4.1 Where Compatible

NFT will be generally compatible  with native TOPS-10 command  syntax,
and command conventions such as SWITCH.INI options defaulting.

NFT will be compatible with all TOPS-10 file formats.

NFT will be  compatible with all  Digital Equipment Corporation  ASCII
file formats.

NFT will be compatible with DECnet DAP 6.0.

4.2 Where Incompatible

The command  syntax used  by NFT  is not  necessarily compatible  with
corresponding command syntax used in the local operating and file sys-
tems implicitly  accessed  by  NFT.  In  particular,  the  syntactical
definition of a file specification accepted by NFT may not match  that
of the various non-TOPS-10 file systems.

The command syntax used by NFT  is not compatible with DCLS (DEC  Com-
mand Language Standard).
NFT-10 NIP/FAL/TSC Executive                                   Page 27
Packaging and System Generation                              12-Jan-84



5.0 Packaging and System Generation

NFT-10 will be bundled with DECnet-10.


6.0 References

DECnet Product Plan

DAP 6.0 Functional Specification
NFT-10 NIP/FAL/TSC Executive                                  Page A-1
Appendix A: Syntax                                           12-Jan-84




                              Appendix A
                                Syntax




This section formally defines the command  syntax for NFT as a  whole,
and for "canonical" file specifications in particular.


A.1.0 Description

The following syntactical definition is a variation of the traditional
"BNF" construction, as follows:

   Construct                   Meaning
                
   ASCII-ooo   The ASCII character whose octal representation  in
               the ASCII collating sequence is "ooo". This is the
               axiomatic foundation  of  the  entire  syntactical
               definition.

               A blank space has no intrinsic meaning to the syn-
               tactical definition, it is used merely to make the
               definition more readable.

    " xxx "    The construction "xxx" enclosed within the  quotes
               is to be taken literally as specified.

    < xxx >    The enclosed construction "xxx" is a single  "ele-
               mentary" syntactical item. If the construction  is
               in lower case then the item is generic in  nature.
               If the construction is in upper case then the item
               is specific in nature.

    [ xxx ]    The enclosed construction  "xxx" is optional.  The
               construction may be omitted,  or it may be  speci-
               fied exactly once.

   [[ xxx ]]   The enclosed construction  "xxx" is optional,  and
               may be iterated indefinitely.

 n * [[ xxx ]] The enclosed construction  "xxx" is optional,  and
               may be iterated up to "n" times.

       |       The exclusive-or operator; "|" is used to separate
               two or  more constructions  of which  exactly  one
               must be choosen.

       +       The inclusive-or operator; "+" is used to separate
               two or more constructions of which any combination
               may be chosen (the exact order is not relevant).
NFT-10 NIP/FAL/TSC Executive                                  Page A-2
Appendix A: Syntax                                           12-Jan-84
Formal Syntactical Definition



A.2.0 Formal Syntactical Definition

<ctlchr> ::=   ASCII-000 | ASCII-001 | ASCII-002 | ASCII-003 |
               ASCII-004 | ASCII-005 | ASCII-006 | ASCII-007 |
               ASCII-010 | ASCII-011 | ASCII-012 | ASCII-013 |
               ASCII-014 | ASCII-015 | ASCII-016 | ASCII-017 |
               ASCII-020 | ASCII-021 | ASCII-022 | ASCII-023 |
               ASCII-024 | ASCII-025 | ASCII-026 | ASCII-027 |
               ASCII-030 | ASCII-031 | ASCII-032 | ASCII-033 |
               ASCII-034 | ASCII-035 | ASCII-036 | ASCII-037 |
               ASCII-177

<prtchr> ::=   ASCII-040 | ASCII-041 | ASCII-042 | ASCII-043 |
               ASCII-044 | ASCII-045 | ASCII-046 | ASCII-047 |
               ASCII-050 | ASCII-051 | ASCII-052 | ASCII-053 |
               ASCII-054 | ASCII-055 | ASCII-056 | ASCII-057 |
               ASCII-060 | ASCII-061 | ASCII-062 | ASCII-063 |
               ASCII-064 | ASCII-065 | ASCII-066 | ASCII-067 |
               ASCII-070 | ASCII-071 | ASCII-072 | ASCII-073 |
               ASCII-074 | ASCII-075 | ASCII-076 | ASCII-077 |
               ASCII-100 | ASCII-101 | ASCII-102 | ASCII-103 |
               ASCII-104 | ASCII-105 | ASCII-106 | ASCII-107 |
               ASCII-110 | ASCII-111 | ASCII-112 | ASCII-113 |
               ASCII-114 | ASCII-115 | ASCII-116 | ASCII-117 |
               ASCII-120 | ASCII-121 | ASCII-122 | ASCII-123 |
               ASCII-124 | ASCII-125 | ASCII-126 | ASCII-127 |
               ASCII-130 | ASCII-131 | ASCII-132 | ASCII-133 |
               ASCII-134 | ASCII-135 | ASCII-136 | ASCII-137 |
               ASCII-140 | ASCII-141 | ASCII-142 | ASCII-143 |
               ASCII-144 | ASCII-145 | ASCII-146 | ASCII-147 |
               ASCII-150 | ASCII-151 | ASCII-152 | ASCII-153 |
               ASCII-154 | ASCII-155 | ASCII-156 | ASCII-157 |
               ASCII-160 | ASCII-161 | ASCII-162 | ASCII-163 |
               ASCII-164 | ASCII-165 | ASCII-166 | ASCII-167 |
               ASCII-170 | ASCII-171 | ASCII-172 | ASCII-173 |
               ASCII-174 | ASCII-175 | ASCII-176

<char> ::=     <ctlchr> | <prtchr>

<TAB> ::=      ASCII-011

<LF> ::=       ASCII-012

<VT> ::=       ASCII-013

<FF> ::=       ASCII-014

<CR> ::=       ASCII-015

<XON> ::=      ASCII-021

<XOFF> ::=     ASCII-023

<CTRL-V> ::=   ASCII-026
NFT-10 NIP/FAL/TSC Executive                                  Page A-3
Appendix A: Syntax                                           12-Jan-84
Formal Syntactical Definition




<CTRL-Z> ::=   ASCII-032

<ESC> ::=      ASCII-033

<SPACE> ::=    ASCII-040

<QUOTE> ::=    ASCII-042

<blank> ::=    (<SPACE> | <TAB>) [[<SPACE> | <TAB>]]

<eol> ::=      <LF> | <VT> | <FF> | <CTRL-Z> | <ESC>

<letter> ::=   "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
               "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
               "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
               "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f" |
               "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" |
               "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" |
               "w" | "x" | "y" | "z"

<digit> ::=    "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
               "8" | "9"

<octdgt> ::=   "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7"

<decdgt> ::=   <octdgt> | "8" | "9"

<hexdgt> ::=   <decdgt> | "A" | "B" | "C" | "D" | "E" | "F"

<sign> ::=     "  | "-"

<comment> ::=  (";" | "!") [[<prtchr>]]

<cmdlin> ::=   [[ [<cmdnam> [[<arg>]] [["-" [<comment>] <eol>]]
               [[<arg>]] [<comment>] ] ]] <eol>

<arg> ::=      <prtchr>[[<prtchr>]]

<octnum> ::=   <octdgt>[[<octdgt>]]

<decnum> ::=   <decdgt>[[<decdgt>]]

<hexnum> ::=   <hexdgt>[[<hexdgt>]]

<octval> ::=   [<sign>]<octnum>

<decval> ::=   [<sign>]<decnum>

<hexval> ::=   [<sign>]<hexnum>

<namchr> ::=   <letter> | <digit> | "-" | <CTRL-V><prtchr>

<name> ::=     (<namchr>[[<namchr>]]) |
NFT-10 NIP/FAL/TSC Executive                                  Page A-4
Appendix A: Syntax                                           12-Jan-84
Formal Syntactical Definition



               (<QUOTE><prtchr>[[<prtchr>]]<QUOTE>)

<cmdnam> ::=   <name>

<nodnam> ::=   <name>

<devnam> ::=   <name>

<dirnam> ::=   <name>

<projno> ::=   <octnum>

<progno> ::=   <octnum>

<filnam> ::=   <name>

<typnam> ::=   <name>

<genval> ::=   <decval>

<swtnam> ::=   <name>

<swtarg> ::=   <arg>

<nod-spec> ::= <nodnam>("::" | "_")

<dev-spec> ::= <devnam>":"

<dir-spec> ::= "[" (<dirnam>[[("."|",")<dirnam>]]) |
               ([<projno>]","[<progno>][[("."|",")<dirnam>]]) "]"

<nam-spec> ::= <filnam>

<typ-spec> ::= "."<typnam>[<gen-spec>]

<gen-spec> ::= "."<genval>

<swt-spec> ::= "/"<swtnam>[":"<swtarg>]

<filopr> ::=   "'AND'" | "'OR'" | "'NOT'" | "'IFAND'" | "'IFNOT'" |
               "'IFSAME'" | "'IFDIFFERENT'" | "'IFOLDER'" |
               "'IFNEWER'" | "'IFSMALLER'" | "'IFBIGGER'"

<naked-file-spec> ::= <nod-spec> + <dev-spec> + <dir-spec> +
               <nam-spec> + <typ-spec> + <gen-spec>

<file-spec> ::= <naked-file-spec> + [[<swt-spec>]]

<file-expr> ::= <file-spec> [[<filopr><file-spec>]]

<file-expr-list> ::= <file-expr> [[","<file-expr>]]
NFT-10 NIP/FAL/TSC Executive                                  Page A-5
Appendix A: Syntax                                           12-Jan-84
Commands



A.3.0 Commands

The command syntax used by NFT, in all modes, is:

<command> ::= <cmdnam> [[<arg>]] <eol>

The command is read from the command input stream, which by default is
initially the user's command terminal. The user can redirect the  com-
mand input to  any file system  device which can  provide ASCII  input
data. This action is  called command indirection,  and the file  which
contains the redirected ASCII input data is called a command file.

Command indirection has two different modes of operation, depending on
how the user invokes the command file. In both cases a command file is
invoked by  specifiying  an  atsign ("@"  character)  in  the  command
stream, followed by the command file specification. Formally:

<cmdfil> ::= "@" <naked-file-spec>

A command file may be invoked anywhere within a command string as long
as the "@"  is not  in some  way quoted. In  effect, the  "@" and  the
following naked file specification (including the final delimiter) act
as a macro  and are  simply replaced verbatim  with the  corresponding
text (or "macro definition"). The "@" does however delimit the current
name or "field" being parsed.

If the command file invocation is the first thing on the line then the
command stream is  simply switched  or "indirected"  to the  specified
file(s), and command processing procedes normally.

If the command file invocation  follows the command name then  command
processing enters locked mode,  wherein the specified command  becomes
locked and all subsequent command stream input up to and including the
end of the invoked  command file is  considered to be  part of one  or
more iterations of arguments to the locked command.

This allows a list of files (contained in a command file) to be  mani-
pulated as a whole  rather than requiring a  command to be present  on
each separate line within the  command file. For example, assume  that
the  command  file  "FILE.CCL"  contains  the  text  "FILE.1,  FILE.2,
FILE.3". The sequence of commands:

  RENAME *.*/PROTECTION:155 = @FILE.CCL
  COPY MYCOPY.* = @FILE.CCL
  DELETE @FILE.CCL

would: first) protect  the three  files so  that they  could be  read;
second) copy the files; and third) delete the original files.
NFT-10 NIP/FAL/TSC Executive                                  Page B-1
Appendix B: Standard File Switches                           12-Jan-84




                              Appendix B
                        Standard File Switches




This  appendix  describes  the  individual  "standard"   file-specific
switches supported by NFT-10.

Basically, a file-specific switch is a switch which is associated with
one particular  file specification  rather than  with a  command as  a
whole. File-specific switches are broken  down into two classes:  Con-
trol, and Qualifying.
NFT-10 NIP/FAL/TSC Executive                                  Page B-2
Appendix B: Standard File Switches                           12-Jan-84
Control Switches



B.1.0 Control Switches

Control switches govern or control file access. Control switches allow
the user to  specify or modify  aspects of file  access which are  not
normally used.

Control switches are:

B.1.1 /ALLOCATE:size

The /ALLOCATE switch is used to specify the physical file allocation.

/ALLOCATE accepts a single mandatory argument "size" which is the file
allocation in physical device blocks, expressed as a positive  decimal
integer.

The /ALLOCATE switch indicates that the resultant file is to be  guar-
anteed a  specified minimum  allocation on  the device  media. If  the
specified allocation is not available then an error indication is giv-
en.  Any  "extra"  blocks  allocated  at  file  close  time  are   not
deallocated.

/ALLOCATE is meaningless on input files.

See also the /CONTIGUOUS and /ESTIMATE switches.


B.1.2 /[NO]APPEND

The /APPEND switch is  used to specify  that an output  file is to  be
appended to its extant predecessor.

The /APPEND switch accepts no arguments.

/APPEND indicates that the output file  data is to be appended to  any
extant file of the same name rather than to overwrite or supersede the
"old" file. /NOAPPEND indicates that the output file data is not to be
appended to any extant file of the same name.

The /APPEND switch is meaningless for input files.

See also the /SUPERSEDE and /UPDATE switches.
                            
                                 Note

     The /APPEND switch is not yet implemented.



B.1.3 /BLKSIZE:size

The /BLKSIZE switch is  used to specify the  physical device I/O  data
blocksize, which in turn specifies the minimum I/O buffer size.
NFT-10 NIP/FAL/TSC Executive                                  Page B-3
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/BLKSIZE:size


/BLKSIZE accepts a single mandatory  argument "size" which is the  de-
vice blocksize, expressed in terms  of physical frame bytes (see  also
the /FRAMESIZE switch).

The I/O  data blocksize  is the  size of  a single  physical block  or
record of data resident within the I/O device. A physical block has no
relation to a logical data record, it  is solely a product of how  the
device stores and retrieves data from  its media. Actual I/O is  ulti-
mately based on the physical device blocksize, as a physical block  is
the minimum "unit" for an I/O operation (i.e., any read or write  must
deal with at least one full block). As such, specifying the  blocksize
also specifies a minimum I/O buffer size.

Generally, larger blocksizes provide more efficient utilization of the
device media, but with  a corresponding cost  of requiring larger  I/O
buffers. Not all devices  support variable blocksizes  - DEC disks  in
particular typically have a fixed blocksize. Other devices don't real-
ly have a  blocksize at  all - typical  interactive command  terminals
(such as a VT52 or VT100  for example) deal only with individual  data
bytes.


B.1.4 /BUFFERS:count

The /BUFFERS switch is  used to specify the  number of I/O buffers  to
use for input and/or output from/to the I/O device.

/BUFFERS accepts  a single  mandatory argument  "count" which  is  the
number of buffers  to use  for I/O,  expressed as  a positive  decimal
integer.

Generally, specifying more buffers allows the file system to more  ef-
ficiently read/write the device  media by "batching" several  distinct
device blocks into one "scatter/gather" I/O operation.


B.1.5 /BYTESIZE:bits

The /BYTESIZE switch is used to specify the logical data bytesize.

/BYTESIZE accepts a single mandatory argument "bits" which is the size
of an individual logical  data byte in bits,  expressed as a  positive
decimal integer.

The /BYTESIZE switch is used to explicitly select the size of an indi-
vidual logical data byte independently of the file data mode, the file
I/O mode, and the physical frame size.

A logical data byte is the actual unit data element being manipulated.
For ASCII character data a logical  data byte is one ASCII  character,
typically 7  bits in  size, but  may be  8 bits,  or even  36 bits.  A
logical data byte  is contained within  a physical frame  byte (see  /
FRAMESIZE). The logical data byte should not be larger than the  frame
size since information may be lost  (the highorder bits will be  trun-
NFT-10 NIP/FAL/TSC Executive                                  Page B-4
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/BYTESIZE:bits


cated to fit the framesize).

See also /DATAMODE, /FRAMESIZE, and /IOMODE.


B.1.6 /[NO]CONTIGUOUS

The /CONTIGUOUS  switch is  used to  specify that  the file  is to  be
created contiguously on its media.

The /CONTIGUOUS switch accepts no arguments.

/CONTIGUOUS indicates that the  file to be  created should be  created
contiguously on the device media - the file may not be fragmented  nor
may the file allocation cross a volume boundary. If the file cannot be
created contiguously then an error indication is given.  /NOCONTIGUOUS
indicates that the file  does not need to  be created contiguously  on
the media  (although it  does  not prevent  the  file system  from  so
doing).

/CONTIGUOUS is meaningless for input files.

See also /ALLOCATE and /ESTIMATE.


B.1.7 /DATAMODE:mode

The /DATAMODE switch is used to specify the type of data being manipu-
lated.

/DATAMODE accepts a single  mandatory argument "mode" which  specifies
the type of data which  makes up the file  I/O stream. The legal  data
types are:

1.   ASCII
2.   BINARY
3.   IMAGE

The /DATAMODE switch  is used to  specify the actual  data type  which
constitutes the file  I/O stream independently  of the data  bytesize,
framesize, and I/O mode selected.

See also the /BYTESIZE, /FRAMESIZE, and /IOMODE switches.


B.1.8 /[NO]DELETE

The /[NO]DELETE switch is used to [not] delete the specified file when
the file is logically CLOSEd.

The /DELETE switch accepts no arguments

/DELETE says to delete  the file when the  file is CLOSEd (i.e.,  when
the access of the file is completed, be it a read or write operation);
NFT-10 NIP/FAL/TSC Executive                                  Page B-5
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/[NO]DELETE


/NODELETE says to not delete the file when the file is CLOSEd.

See also the /PRINT and /SUBMIT switches.


B.1.9 /DENSITY:bpi

The /DENSITY switch is used to specify the tape density to be used for
magnetic tapes.

The /DENSITY switch accepts a single mandatory argument "bpi" which is
the recording density in "bits per inch", expressed as a keyword.  The
legal tape densitys are:

1.   200 - NRZI; 200 bits per inch
2.   556 - NRZI; 556 bits per inch
3.   800 - NRZI; 800 bits per inch
4.   1600 - PE; 1600 bits per inch
5.   6250 - PE; 6250 bits per inch
6.   INSTALLATION - system default density

Although the tape density may be  specified for both input and  output
files, some tape drives will  automatically select the "correct"  tape
density for reading based on the tape itself, effectively ignoring any
explicit selection by the user.

See also the /PARITY switch.


B.1.10 /ERSUPERSEDE

The /ERSUPERSEDE switch is used to prevent the superseding of an exis-
tant data file.

The /ERSUPERSEDE switch accepts no arguments.

/ERSUPERSEDE indicates that an error indication is to be given and the
file creation aborted when a file create operation would supersede  an
extant file  of the  same  name. /ERSUPERSEDE  is equivilent  to  /SU-
PERSEDE:NEVER.

/ERSUPERSEDE is meaningless on input files.

See also the /APPEND, /OKSUPERSEDE, and /SUPERSEDE switches.


B.1.11 /ESTIMATE:size

The /ESTIMATE switch  is used  to specify an  initial file  allocation
guideline.

/ESTIMATE accepts a single mandatory argument "size" which is the file
allocation in physical device blocks, expressed as a positive  decimal
integer.
NFT-10 NIP/FAL/TSC Executive                                  Page B-6
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/ESTIMATE:size



/ESTIMATE is  useful for  indicating the  approximate size  of a  file
without committing the  file to that  size. If the  resultant file  is
smaller then any unused blocks will be deallocated at file close time;
if the resultant file is larger then extra blocks will be allocated as
they are needed. /ESTIMATE  merely gives the file  system a chance  to
optimize the  placement and  allocation of  the file  on the  physical
media.

/ESTIMATE is meaningless on input files.

See also /ALLOCATE and /CONTIGUOUS.


B.1.12 /FIXED

The /FIXED switch  is used  to specify  fixed length  records, and  is
shorthand for (identical to) /RECFORMAT:FIXED.

See also the /RECFORMAT, /RECSIZE, and /VARIABLE switches.


B.1.13 /FRAMESIZE:bits

The /FRAMESIZE switch is  used to specify how  logical data bytes  are
packed within physical I/O bytes.

/FRAMESIZE accepts a  single mandatory  argument "bits"  which is  the
size of  the frame  byte  in bits,  expressed  as a  positive  decimal
integer, which contains a single logical data byte.

The /FRAMESIZE switch is used  to explicitly specify how logical  data
bytes are  packed within  the file  I/O stream,  independently of  the
actual data bytesize, data mode,  and I/O mode selected. Logical  data
bytes are packed  right-justified one per  physical frame "byte".  For
most cases /BYTESIZE and /FRAMESIZE are the same.

/FRAMESIZE in no way affects the physical organization of the file I/O
bit stream on the device media.

See also the /BYTESIZE, /DATAMODE, and /IOMODE switches.


B.1.14 /IOMODE:mode

The /IOMODE switch is used to specify  the device I/O mode to be  used
for the file I/O stream.

/IOMODE accepts a single mandatory argument "mode" which specifies the
device I/O mode to be used. The legal I/O modes supported are:

1.   ASCII
2.   BINARY
3.   BYTE
NFT-10 NIP/FAL/TSC Executive                                  Page B-7
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/IOMODE:mode


4.   IMAGE
5.   IBINARY
6.   PIM

Not all file systems necessarily support all listed /IOMODES.

/IOMODE is used to explicitly specify  the device I/O mode to be  used
for a file data stream independently  of the selected data byte  size,
data type, and framesize.

See also the /BYTESIZE, /DATAMODE, and /FRAMESIZE switches.


B.1.15 /[NO]LIB

The /LIB switch is used to  control searching of any "libraries" on  a
file open operation.

The /LIB switch accepts no arguments.

/LIB indicates  that  user-  and/or system-defined  libraries  may  be
searched in order to find  the specified file. /[NO]LIB indicates  the
no libraries are to be searched looking for the file - if the file  is
not found as specified an error indication is to be given.

Not all file systems support automatic library searching.

/LIB is meaningless on output files.

See also the /NEW, /SCAN, /STRS, and /SYS switches.
                            
                                 Note

     The /LIB switch is not yet implemented.



B.1.16 /[NO]MACY11

The /[NO]MACY11 switch is  used to control  reading and/or writing  of
files in "MACY11" mode.

The /MACY11 switch accepts no arguments.

MACY11 mode (in honor of the PDP-11 cross assembler of the same  name)
is a record-formatted 8-bit-byte binary file access mode wherein 8-bit
data (such as used for PDP-11s, VAXii, and the like) is stored in  36-
bit words,  preserving record-length  information as  required by  the
various 8-bit minicomputers.

/MACY11 forces /BYTESIZE:8, /BINARY, and ignores completely /RECFORMAT
and /RECSIZE.
NFT-10 NIP/FAL/TSC Executive                                  Page B-8
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/[NO]MECY11


B.1.17 /[NO]MECY11

The /[NO]MECY11 switch is used like the /MACY11 switch.

The /MECY11 switch accepts no arguments.

/MECY11 behaves exactly like /MACY11  except that in writing  "MACY11"
formatted files the "PDP-11 words" will always be aligned into  PDP-10
halfwords for ease of looking at the file with (e.g.,) FILDDT.
                            
                                 Note

     The MACY11  cross-assembler  (and thus  the  /MACY11  switch
     which mimics same) writes 6 null filler bytes between  logi-
     cal records. This results in every other record being  half-
     word-aligned, with  the  interspersed  records  being  split
     across halfwords.



B.1.18 /[NO]NEW

The /NEW switch is used to control searching the system  "experimental
library" when the system device "SYS" is specified.

The /NEW switch accepts no arguments.

/NEW indicates that whenever the system device "SYS" is specified  the
file system should look first on the system experimental library "NEW"
before using the  standard system library.  /NONEW indicates that  the
system experimental library "NEW" should not be searched when  search-
ing the standard system library.

Not all file systems support the "NEW" concept.

/NEW is meaningless on output files.

See also the /LIB, /SCAN, /STRS and /SYS switches.
                            
                                 Note

     The /NEW switch is not yet implemented.



B.1.19 /OKSUPERSEDE

The /OKSUPERSEDE switch is used  to control the superseding of  extant
data files.

The /OKSUPERSEDE switch accepts no arguments.

/OKSUPERSEDE indicates that a file create operation may supersede  any
already-existing file of the same name. /OKSUPERSEDE is equivilent  to
NFT-10 NIP/FAL/TSC Executive                                  Page B-9
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/OKSUPERSEDE


/SUPERSEDE:ALWAYS.

/OKSUPERSEDE is meaningless for input files.

See also the /APPEND, /ERSUPERSEDE, and /SUPERSEDE switches.


B.1.20 /PARITY:par

The /PARITY switch is used to select the data parity used for magnetic
tapes.

/PARITY accepts a  single mandatory argument  "par" which selects  the
resultant tape parity. Legal arguments are:

1.   EVEN - read/write even parity
2.   ODD - read/write odd parity

Although /PARITY is legal  for both input  and output file  specifica-
tions, some tape  drives may automatically  select the "correct"  read
parity based on the physical tape, ignoring any explicit specification
by the user.

See also the /DENSITY switch.


B.1.21 /PASSWORD[:psw]

The /PASSWORD switch is used to specify the password necessary to gain
access to a protected file.

/PASSWORD accepts a single argument  "psw" which is the password,  ex-
pressed as a possibly-quoted character  string, needed to gain  access
to the specified file. If no argument is explicitly provided then  the
user will be asked for the password at the time of the file access.

The /PASSWORD  switch  enables access  to  a specific  file  which  is
normally protected such that  the file access  would otherwise be  de-
nied.

/PASSWORD is valid only for a remote network file access operation, it
is meaningless for a local file access.

The exact behaviour of /PASSWORD is dependent on the remote file  sys-
tem being accessed.  In particular, not  all file systems  necessarily
support password access. Further, it is unspecified whether or not the
password is verified before the file access is attempted (i.e., if the
file is not protected then the  password might be ignored, even if  it
is invalid).
                            
                                 Note

     The /PASSWORD switch is  completely independent of (and  has
     absolutely nothing to do with)  the /USERID switch -  /PASS-
NFT-10 NIP/FAL/TSC Executive                                 Page B-10
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/PASSWORD[:psw]


     WORD specifies  a  file-specific password,  whereas  /USERID
     governs access to a remote node, without regard to the  file
     access operation. The password for the /USERID is  specified
     only with the  /USERID switch,  and NOT  with the  /PASSWORD
     switch.



B.1.22 /[NO]PHYSICAL

The /PHYSICAL switch  controls usage  of logical  device name  defini-
tions.

/PHYSICAL accepts no arguments.

/PHYSICAL indicates that  the file  system should  ignore any  logical
device definitions and use only system physical device definitions  to
select a device. /[NO]PHYSICAL  indicates that logical device  defini-
tions are acceptable.


B.1.22.1 /[NO]PRINT
The /[NO]PRINT switch is  used to cause the  file to [not] be  printed
when the file is CLOSEd.

The /PRINT switch accepts no arguments.

/PRINT specifies that the file is to be printed (i.e., "queued" to the
system line printer spooler facility to be printed on a line  printer)
when the file is CLOSEd; /NOPRINT specifies that the file is not to be
printed when the file is CLOSEd.

See also the /DELETE and /SUBMIT switches.


B.1.23 /PROTECTION:prot

The /PROTECTION switch is  used to specify  the access protection  at-
tributes of a file.

/PROTECTION accepts a  single mandatory argument  "prot" which is  the
file access  protection code,  expressed as  an octal  integer in  the
range 1 to 777. A protection code of 0 selects the default  protection
for the job/system.

/PROTECTION is meaningless for input files.


B.1.24 /QUERY[:nta]

The /QUERY switch is used to selectively accept or reject  [presumably
wildcarded] file operations.

/QUERY accepts a single  argument "nta" specifying  the type of  query
NFT-10 NIP/FAL/TSC Executive                                 Page B-11
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/QUERY[:nta]


processing requested. The types of query processing available are:

1.   NEVER - no processing
2.   TELL - just list the file(s) selected
3.   ASK - confirm operation with user

The default if no  argument is supplied is  "ASK" (many commands  will
default to /QUERY:TELL if no explicit /QUERY is specified).

B.1.24.1 /QUERY:NEVER
/QUERY:NEVER indicates that all query processing should be suppressed.


B.1.24.2 /QUERY:TELL
/QUERY:TELL indicates that each file selected should be listed on  the
command output device.

B.1.24.3 /QUERY:ASK
/QUERY:ASK indicates that each file  selected should be listed on  the
command output device.

The user is then prompted to either accept or reject the file selected
by typing either  "YES" or  "NO". This  answer ALWAYS  comes from  the
command input terminal  even if  the original file  access command  is
from a command file. A "blank" answer (i.e., carriage return) defaults
to either  "YES"  or  "NO"  as  appropriate;  any  other  answer  will
reprompt.

If the prompt is "[Y/N]" then the  default is "YES"; if the prompt  is
"[N/Y]" then the default is "NO".


B.1.25 /RECFORMAT:format

The /RECFORMAT switch  is used to  specify the type  of record  format
associated with a file I/O stream.

/RECFORMAT accepts the record format type, expressed as a single  key-
word which defines the record structure  used by the file I/O  stream.
The record formats are:

1.   NONE - no record formatting
2.   FIXED - fixed length records
3.   VARIABLE - variable length records
4.   VFC - variable length records with fixed length header
5.   36PACK - bizarre packing of 36-bit words into 8-bit bytes

Not all file  systems necessarily  support any  or all  of the  listed
record format types.

The /RECFORMAT switch allows the user to explicitly specify the struc-
ture of the  file data records  which constitute the  file I/O  stream
independently of the data and I/O modes employed.
NFT-10 NIP/FAL/TSC Executive                                 Page B-12
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/RECFORMAT:format


See also the /FIXED, /RECSIZE, and /VARIABLE switches. The 36PACK rec-
ord format  controls the  "funny" packing  of 36-bit  data into  8-bit
bytes in such a manner  that 36-bit data is able  to be stored on  and
retrieved from 8-bit systems  such as RSX or  VAX. The 36-bit data  is
stored in 4.5 consecutive 8-bit bytes (or consecutive pairs of  36-bit
words are stored  in 9 consecutive  8-bit bytes) as  per the DAP  bit-
packing specification:

               7    4 3    0
               -------------
  Byte 0/      |  28 - 35  |
               -------------
  Byte 1/      |  20 - 27  |
               -------------
  Byte 2/      |  12 - 19  |
               -------------
  Byte 3/      |  04 - 11  |
               -------------
  Byte 4/      |00-03:32-35|
               -------------
  Byte 5/      |  24 - 31  |
               -------------
  Byte 6/      |  16 - 23  |
               -------------
  Byte 7/      |  08 - 15  |
               -------------
  Byte 8/      |  00 - 07  |
               -------------


B.1.26 /RECSIZE:size

The /RECSIZE  switch is  used to  specify the  size of  the file  data
records which constitute the file I/O stream.

/RECSIZE accepts a single mandatory argument "size" which is the  size
of the  file data  records, expressed  in  terms of  data bytes  as  a
positive decimal integer.

The /RECSIZE switch is used to explicitly specify the file data record
size for the  file I/O  stream. The  record size  includes any  record
header associated with the record. For fixed length records the record
size specifies the size  of all records.  For variable length  records
the record size specifies the  maximum record size allowable -  actual
records may well be much smaller.

See also the /RECFORMAT switch.


B.1.27 /[NO]SCAN

The /SCAN switch is used to control directory tree scanning on a  file
access operation.
NFT-10 NIP/FAL/TSC Executive                                 Page B-13
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/[NO]SCAN


The /SCAN switch accepts no arguments.

/SCAN indicates that the file system should scan the specified  direc-
tory tree looking for the specified file  if the file is not found  in
the specified directory. /NOSCAN  indicates that directory tree  scan-
ning should not be performed.

Not all file systems support directory tree scanning.

/SCAN is meaningless on output files.

See also the /LIB, /NEW, /STRS, and /SYS switches.
                            
                                 Note

     The /SCAN switch is not yet implemented.



B.1.28 /[NO]SUBMIT

The /[NO]SUBMIT switch is used to cause the file to [not] be SUBMITted
when the file is CLOSEd.

The /SUBMIT switch accepts no arguments.

/SUBMIT specifies that the file is to be SUBMITted (i.e., "queued"  to
the system batch processor facility) when the file is CLOSEd;  /NOSUB-
MIT specifies that the file  is not to be  submitted when the file  is
CLOSEd.

See also the /DELETE and /PRINT switches.


B.1.29 /SUPERSEDE:cond

The /SUPERSEDE switch controls the superseding of extant files.

/SUPERSEDE accepts a  single argument "cond",  expressed as a  keyword
name, which specifies the conditions  under which the extant file  may
be superseded. The keywords are:

1.   NEVER - never supersede an extant file
2.   OLDER - supersede only if extant file is older
3.   NEWER - supersede only if extant file is newer
4.   ALWAYS - always supersede extant file

/SUPERSEDE:NEVER is equivilent  to /ERSUPERSEDE; /SUPERSEDE:ALWAYS  is
equivilent to /OKSUPERSEDE.
                            
                                 Note

     The /SUPERSEDE switch is not yet implemented.
NFT-10 NIP/FAL/TSC Executive                                 Page B-14
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/SUPERSEDE:cond


B.1.30 /[NO]SYS

The /SYS switch is used to control system library searching on a  file
access operation.

The /SYS switch accepts no arguments.

/SYS indicates that the file  system should search the system  library
area (as further controlled by the /NEW switch) if the specified  file
is not found. /NOSYS indicates that  the system library should not  be
searched if the file is not found.

Not all file systems support system library searching.

/SYS is meaningless for output files.

See also the /LIB, /NEW, /SCAN, and /STRS switches.
                            
                                 Note

     The /SYS switch is not yet implemented.



B.1.31 /[NO]UPDATE

The /UPDATE switch is  used to specify  that an output  file is to  be
overwritten rather than superseded (or appended).

The /UPDATE switch accepts no arguments.

/UPDATE indicates that the output file data is to overwrite any extant
file of the  same name rather  than to supersede  or append the  "old"
file. /NOUPDATE indicates that the file is not to be overwritten.

/UPDATE is meaningless for input files.

See also the /APPEND and /SUPERSEDE switches.
                            
                                 Note

     The /UPDATE switch is not yet implemented.



B.1.32 /USERID[:[uid][:[act][:psw]]]

The /USERID  switch  is  used to  specify  the  "on-behalf-of"  access
verification and accounting for file access operations.

/USERID accepts  up  to three  optional  arguments "uid",  "act",  and
"psw", each of which is a possibly-quoted ASCII character string.  The
"uid" argument string may additionally contain the directory  bracket-
ting characters "[", "]",  "<", ">", as well  as the comma (","),  dot
NFT-10 NIP/FAL/TSC Executive                                 Page B-15
Appendix B: Standard File Switches                           12-Jan-84
Control Switches
/USERID[:[uid][:[act][:psw]]]


("."), and underscore ("_") characters.

The /USERID switch is used to identify file access requests with  user
accounting and access verification mechanisms associated with the file
system. The "uid" argument is the  "userid" (or user name or user  ac-
count or user ppn) to be used  by the remote for the file access;  the
"act" is any optional accounting information associated with the spec-
ified userid; and "psw" is the password associated with the  specified
userid (and typically used to verify the userid file access rights).

/USERID is valid only for a  remote network file access operation;  it
is meaningless for local file access.

Basically, /USERID is  used to  identify yourself to  the remote  file
system (and operating system) as a known "local" user. This allows the
file system  to grant  file access  in terms  of local  users  without
having to deal with non-secure  network interfaces. It further  allows
for more detailed accounting operations to be performed, charging  the
file access to a known account.

The actual operation of /USERID is dependent on the remote file system
selected - not all file systems necessarily support the /USERID  func-
tionality, or even require that a /USERID be supplied by the accessor.

For use with NFT, the various arguments may be left blank and NFT will
prompt for the three fields at program runtime as the file  specifica-
tion is actually being used.


B.1.33 /VARIABLE

The /VARIABLE switch is used  to specify variable length records,  and
is shorthand for (identical to) /RECFORMAT:VARIABLE.

See also the /FIXED, /RECFORMAT, and /RECSIZE switches.


B.1.34 /VERSION:ver

The /VERSION switch is used to specify the file's "version" attribute.

/VERSION accepts a  single mandatory  argument "ver",  expressed as  a
standard TOPS-10 version  string, which  is to be  the file's  created
version.

Not all file systems necessarily support the version attribute.

/VERSION is meaningless for input files.
NFT-10 NIP/FAL/TSC Executive                                 Page B-16
Appendix B: Standard File Switches                           12-Jan-84
Qualifying Switches



B.2.0 Qualifying Switches

Qualifying switches are used to "qualify" or constrain the naked  file
specification insofar as the actual  selection of a resultant file  is
concerned. In  effect, qualifying  switches act  as implicit  wildcard
operations, accepting or rejecting files based on some specified  con-
straint.

Qualifying switches are:

B.2.1 /ABEFORE:datime

The /ABEFORE switch restricts file  selection to those files  accessed
before the specified date/time.

/ABEFORE accepts a  single mandatory argument  "datime", expressed  as
either an absolute date and  time or as a  period of time relative  to
the present, which specifies the file selection constraint.

/ABEFORE is used to allow only  files which have been accessed  (i.e.,
read, written, or updated) before a specifed date/time. Any file which
fails the specified /ABEFORE constraint is considered to not match the
file specification, and will not be used.

/ABEFORE is meaningless for output files.

See also the /ASINCE, /BEFORE, /SINCE, /PBEFORE, and /PSINCE switches.



B.2.2 /ANYDEV

The /ANYDEV switch is used to  specify whether or not any device  type
is acceptable.

The /ANYDEV switch accepts no arguments.

/ANYDEV indicates  that any  device type  is acceptable  for the  file
specification (i.e., impose no  constraints on device selection).  For
input files, the device types searched include disks, magnetic  tapes,
DECtapes, line  printers,  card  readers,  card  punches,  paper  tape
readers, paper tape punches, plotters, and terminals. For output files
no device constraints will be applied. /ANYDEV implies /TTYDEV  (refer
to the /TTYDEV switch below).

See also /DSKONLY and /TTYDEV.


B.2.3 /ASINCE:datime

The /ASINCE switch  restricts file selection  to those files  accessed
since the specified date/time.

/ASINCE accepts  a single  mandatory argument  "datime", expressed  as
NFT-10 NIP/FAL/TSC Executive                                 Page B-17
Appendix B: Standard File Switches                           12-Jan-84
Qualifying Switches
/ASINCE:datime


either an absolute date and  time or as a  period of time relative  to
the present, which specifies the file selection constraint.

/ASINCE is  used to  allow only  files which  have not  been  accessed
(i.e., read, written, or updated) since a specifed date/time. Any file
which fails  the specified  /ASINCE constraint  is considered  to  not
match the file specification, and will not be used.

/ASINCE is meaningless for output files.

See also the /ABEFORE, /BEFORE, /SINCE, /PBEFORE, and /PSINCE  switch-
es.


B.2.4 /BEFORE:datime

The /BEFORE switch restricts file  selection to those files  logically
created before the specified date/time.

/BEFORE accepts  a single  mandatory argument  "datime", expressed  as
either an absolute date and  time or as a  period of time relative  to
the present, which specifies the file selection constraint.

/BEFORE is used to allow only files which were created before a  spec-
ifed date/time. Any file which fails the specified /BEFORE  constraint
is considered to  not match the  file specification, and  will not  be
used. /BEFORE uses the file's logical data creation date/time which is
independent of the file's  physical creation on  the device media  (in
particular, COPYing a file does not change the logical creation  date/
time but does change the new file's media creation date/time).

/BEFORE is meaningless for output files.

See also the /ABEFORE, /ASINCE, /SINCE, /PBEFORE, and /PSINCE  switch-
es.


B.2.5 /[NO]DSKONLY

The /DSKONLY switch is used to restrict input devices to disks only.

The /DSKONLY switch accepts no arguments.

/DSKONLY indicates that only disk-type devices are to be accepted, all
other devices should  be ignored/rejected.  /NODSKONLY indicates  that
the disk-only constraint is not to be applied.

See also the /ANYDEV and /TTYDEV switches.


B.2.6 /ERNONE

The /ERNONE switch controls the issuance of an error if no files match
the input request.
NFT-10 NIP/FAL/TSC Executive                                 Page B-18
Appendix B: Standard File Switches                           12-Jan-84
Qualifying Switches
/ERNONE



The /ERNONE switch accepts no arguments.

/ERNONE indicates that an error indication is to be issued if no files
are found which match the input file specification.

See also the /OKNONE switch.


B.2.7 /ERPROT

The /ERPROT switch controls  the issuance of an  error if a  potential
file is protected.

The /ERPROT switch accepts no arguments.

/ERPROT indicates that a  file protection violation (e.g.,  attempting
to read a file that is read-protected) is to cause an error indication
rather than being ignored.

See also the /OKPROT switch.


B.2.8 /LENGTH:min[:max]

The /LENGTH switch is used to specify file size constraints.

/LENGTH accepts two arguments "min" and "max"; "min" is mandatory  and
is the minimum  file size, expressed  in words as  a positive  decimal
integer; "max" is optional and is the maximum file size, expressed  in
words as a positive decimal integer.

The /LENGTH switch is used to  select input files whose data size  (as
distinct from  allocated  size)  is  greater  than  or  equal  to  the
specified minimum, and less than or  equal to the specified maximum  -
if any. Any  file whose  data size does  not meet  the specified  con-
straints is considered to not  match the file specification, and  will
not be used.

/LENGTH is meaningless on output files.


B.2.9 /OKNONE

The /OKNONE switch  controls the issuance  of an error  message if  no
files are found to match the file specification.

The /OKNONE switch accepts no arguments.

/OKNONE indicates that no error indication is to be given if no  files
are found to match the input file specification.

See also the /ERNONE switch.
NFT-10 NIP/FAL/TSC Executive                                 Page B-19
Appendix B: Standard File Switches                           12-Jan-84
Qualifying Switches
/OKPROT


B.2.10 /OKPROT

The /OKPROT switch  controls the  issuance of  an error  message if  a
potential file is protected against access.

The /OKPROT switch accepts no arguments.

/OKPROT indicates  that file  protection failures  are acceptable  and
should not cause an error indication to be given.

See also the /ERPROT switch.


B.2.11 /PBEFORE:datime

The /PBEFORE switch restricts file selection to those files physically
created before the specified date/time.

/PBEFORE accepts a  single mandatory argument  "datime", expressed  as
either an absolute date and  time or as a  period of time relative  to
the present, which specifies the file selection constraint.

/PBEFORE is used  to allow  only files which  were physically  created
before a  specifed date/time.  Any file  which fails  the specified  /
PBEFORE constraint is considered to not match the file  specification,
and will not be  used. /PBEFORE uses the  file's media creation  date/
time, which is distinct  from the file's  logical data creation  date/
time.

/PBEFORE is meaningless for output files.

See also the /ABEFORE, /ASINCE, /BEFORE, /SINCE, and /PSINCE switches.



B.2.12 /PSINCE:datime

The /PSINCE switch restricts file selection to those files  physically
created after the specified date/time.

/PSINCE accepts  a single  mandatory argument  "datime", expressed  as
either an absolute date and  time or as a  period of time relative  to
the present, which specifies the file selection constraint.

/PSINCE is  used to  allow only  files which  were physically  created
after a specifed date/time. Any file which fails the specified /PSINCE
constraint is considered to not match the file specification, and will
not be used. /PSINCE uses the file's media creation date/time which is
distinct from the file's logical data creation date/time.

/PSINCE is meaningless for output files.

See also the /ABEFORE, /ASINCE, /BEFORE, /SINCE, and /PBEFORE  switch-
es.
NFT-10 NIP/FAL/TSC Executive                                 Page B-20
Appendix B: Standard File Switches                           12-Jan-84
Qualifying Switches
/PSINCE:datime


B.2.13 /SINCE:datime

The /SINCE switch  restricts file selection  to those files  logically
created since the specified date/time.

/SINCE accepts a single mandatory argument "datime", expressed as  ei-
ther an absolute date and time or as a period of time relative to  the
present, which specifies the file selection constraint.

/SINCE is used to allow only files which were created after a specifed
date/time. Any file  which fails  the specified  /SINCE constraint  is
considered to not match the file specification, and will not be  used.
/BEFORE uses  the  file's logical  data  creation date/time  which  is
independent of the file's  physical creation on  the device media  (in
particular, COPYing a file does not change the logical creation  date/
time but does change the new file's media creation date/time).

/SINCE is meaningless for output files.

See also the /ABEFORE, /ASINCE, /BEFORE, /PBEFORE, and /PSINCE switch-
es.


B.2.14 /SCERROR:keyword

The /SCERROR switch  controls the relative  error constraints used  in
secondary wildcarding operations.

/SCERROR accepts a single  mandatory argument "keyword" which  identi-
fies the error  constraints, expressed  as a  name, to  be applied  to
secondary file  wildcarding  operations.  The  acceptable  error  con-
straints are:

1.   NEVER - no constraints imposed
2.   INSUFFICIENT - error if insufficient secondary wildcards
3.   DIFFERENT  -  error  if  primary  and  secondary  wildcards   are
     different
4.   EXCESSIVE - error if excessive secondary wildcards

See Appendix C for a detailed defintion of secondary wildcarding error
constraints.

See also the /SCWILD switch.


B.2.15 /SCWILD:mode

The /SCWILD switch controls the secondary wildcard mode employed.

/SCWILD accepts a  single mandatory argument  "mode" which  identifies
the secondary wildcarding mode, expressed as a name, to be employed in
filling out secondary wildcarded file specifications. The legal  modes
are:
NFT-10 NIP/FAL/TSC Executive                                 Page B-21
Appendix B: Standard File Switches                           12-Jan-84
Qualifying Switches
/SCWILD:mode


1.   ANY - any field wildcards acceptable
2.   FIELD - use only corresponding field wildcards
3.   DFIELD - FIELD but allow directory level shifting
4.   AFIELD - FIELD but allow any field to be chosen
5.   SAME - use only corresponding character within chosen same field
6.   DSAME - SAME but allow directory level shifting
7.   ASAME - SAME but allow any field to be chosen.

See Appendix C for a detailed definition of secondary wildcarding  op-
erations.

See also the /SCERROR switch.


B.2.16 /[NO]STRS

The /STRS switch is used to "match" multiple copies of files with  the
same name  but residing  in different  "parts" of  the specified  file
directory(s).

The /STRS switch accepts no arguments.

/STRS indicates  that any  implicit structure,  directory, or  library
wildcarding should be explicitly expanded in such a manner that  files
with multiple incarnations are  matched one at  a time. /NOSTRS  indi-
cates that any implicit  structure, directory, or library  wildcarding
should be left implicit and not expanded.

/STRS is useful to determine if multiple copies of a file exist, or if
a file implicitly  exists even  though not explicitly  matched by  the
file specification. /STRS addresses four areas: logical names,  struc-
ture "search lists", directory tree scanning, and library searching.

If the  device  specified is  a  logical name  definition  then  /STRS
explicitly expands the logical name definition into its componet spec-
ifications and  treats each  one separately,  handling directory  tree
scanning and device search lists as below, returning all file  matches
found as separate files.

If the device specified expands into a search list (e.g., device "DSK"
might be "DSKB:, DSKC:") then /STRS indicates that each device in turn
should be explicitly searched independently of any other device in the
search list, handling directory tree scanning as below, returning  all
file matches found as separate files.

If directory tree scanning  is enabled then  /STRS indicates that  the
directory tree is to  be explicitly scanned  upwards to the  top-level
directory, returning all file matches found as separate files.

Finally, if the  job has  a default library  set to  be searched  then
specifying /STRS indicates  that after the  file specification is  ex-
hausted (as above) the library  is to be searched, handling  directory
tree scanning, device  search lists, and  logical name definitions  as
above, returning all file matches found as separate files.
NFT-10 NIP/FAL/TSC Executive                                 Page B-22
Appendix B: Standard File Switches                           12-Jan-84
Qualifying Switches
/[NO]STRS



If the file specification has no explicit wildcards then /STRS acts as
an implicit wildcard operator, returning an arbitrary number of  files
as matches. If the file  specification has explicit wildcards in  only
the file name, file  type, of file generation  fields then /STRS  acts
solely to broaden the range over which the wildcard operation acts. If
the file specification has explicit wildcards in the device or  direc-
tory fields then /STRS is ignored.

Not all file systems necessarily support /STRS operation.

/STRS is meaningless on output files.

See also the /LIB, /NEW, /SCAN, and /SYS switches.
                            
                                 Note

     The  /LIB/SYS/NEW/SCAN  functions  of  /STRS  are  not   yet
     implemented.
NFT-10 NIP/FAL/TSC Executive                                  Page C-1
Appendix C: Wildcarding                                      12-Jan-84




                              Appendix C
                             Wildcarding




                            
                                 Note

     This appendix is included not as a detailed (and  supported)
     functional  specification  but  rather  as  a  philosophical
     treatise for the amusement  and possible edification of  the
     reader. Some of the described functionality is actually  im-
     plemented in extant software, and some is merely, ah, "spec-
     ulation".

Wildcarding - What is it? The  general term "wildcard" is used in  the
context of identifying some object or [sub]set of objects. A  wildcard
is used within the  specification for the  object(s) to indicate  that
something other than the wildcard itself is acceptable, and  typically
that any-and-everything is  acceptable in  the place  occupied by  the
wildcard.

There are two general classes of wildcarding: primary wildcarding  and
secondary wildcarding.
NFT-10 NIP/FAL/TSC Executive                                  Page C-2
Appendix C: Wildcarding                                      12-Jan-84
Primary Wildcarding



C.1.0 Primary Wildcarding

Primary wildcarding is the process wherein an extant set of objects is
matched against a  set of  constraints (e.g.,  a "name")  in order  to
identify (or select) a subset of objects.

For the purposes of this specification, I shall implicitly use as  the
"set of objects" a  set of files which  might exist on a  hypothetical
distributed [network] computer system, using the accepted naming  con-
vention of
   nod_dev:[pth]fil.ext.gen
as the  way  of uniquely  identifying  any specific  file  ("element")
within the set.

Further, unless explicitly stated otherwise, alphabetic case is irrel-
evant to a character  match operation - "A"  is EXACTLY equivalent  to
"a" and so on.  In particular, some file  systems such as TOPS-10  and
RSX-11 do not even allow lowercase alphabetics in file specifications.

Finally, it should be understood that not all file systems necessarily
support any or all of the following wildcard operations.

C.1.1 Basic primary wildcarding

The basic primary wildcarding functions are to match any single  char-
acter or any single group of characters.

The Asterisk character  indicates that  any character  or sequence  of
characters is to  be considered  a match  in the  position within  the
specification occupied  by the  "*". The  "*" character  even  matches
"nothing"!

The Question Mark character indicates  that any character may be  pre-
sent in the indicated character  position, with the proviso that  some
character be present (i.e., unlike the "*" construction the "?"  char-
acter does not match "nothing" - some character must be present in the
character position).

Following are some representative examples of basic primary  wildcard-
ing.

The specification "ABC"  matches one  and only  one name  - "ABC",  no
other name  in the  whole  universe matches  (remember that  "AbC"  is
EXACTLY the same as "aBc", and so on).

The specification "*" matches every name that can exist, regardless of
the number of characters in the name (a blank name - i.e., a name with
no characters at all - is  implicitly disallowed, although if a  blank
name could exist, it  too would be matched  by "*"). "A", "BC",  "DEF-
GHIJKLMNOPQRSTUVWXYZ", etc., are all matched by "*".

The specification  "AB?" matches  all names  that have  exactly  three
characters, the first two of which are "AB". "ABA", "ABB", "ABZ",  are
all matched by "AB?" while "AB" doesn't match because it only has  two
NFT-10 NIP/FAL/TSC Executive                                  Page C-3
Appendix C: Wildcarding                                      12-Jan-84
Primary Wildcarding
Basic primary wildcarding


characters, and "ABCD" doesn't match because it has four characters.

The specification "A?C"  matches all three  character names  beginning
with "A" and ending with "C", such as "AAC", "AZC", and so on.

The specification "AB*" matches all names that have at least two char-
acters, the  first  two of  which  are  "AB", such  as  "ABC",  "ABZ",
"ABCDEFGHIJKL", and so on.

The specification "AB?*" matches  all names that  have at least  three
characters, the first two of which are "AB". The names "ABC",  "ABCD",
"ABBA", and "ABCDEFGHIJKLMNOPQRSTUVWXYZ" are all matched by the speci-
fication "AB?*".

The above examples have one thing in common insofar as wildcards go  -
the "*" wildcard (whenever used) is  always the last character in  the
wildcarded specification, it  is never encased  (in particular, it  is
never followed) by any other part of the wildcarded specification. The
examples shown so far constitute simple or "elementary" primary  wild-
carding.

C.1.2 Advanced primary wildcarding

Advanced primary wildcarding takes the  ideas of simple primary  wild-
carding and expands on them,  providing more flexibility and power  in
matching names, but at  the cost of being  somewhat more difficult  to
comprehend in the "most flexible" constructions.

The simplest "advanced" construction is the embedding of the anything-
goes  "*"  wildcard  completely  within  non-wildcarded  parts  of   a
specification. The specification "A*Z" for example, matches all  names
that have at least two  characters, the first of  which is an "A"  and
the last of which is a "Z". The names "AZ", "ABZ", and "ABCDEFGHIJKLZ"
are all matched by "A*Z".

An obvious extension is multiple embedded "*"'s, such as the  specifi-
cation "A*M*Z", which  would match any  name that has  at least  three
characters, the first of which is an "A", the last of which is a  "Z",
and of which at least one of the intervening characters is an "M". The
names "AMZ",  "AMMZ", "AMMMMMZ",  "AMAZ", and  "AMAMAMAMAMAZ" are  all
matched by "A*M*Z".

The specification "AB*?" matches exactly the same set of names as  the
specification "AB?*" in  the example  above (all names  which have  at
least three characters and begin with  "AB"), but is yet distinct  be-
cause the "*" wildcard is embedded within fixed portions of the speci-
fication rather than at the end. This points out the  not-necessarily-
obvious detail that so far  as primary wildcarding has been  described
up to  this point  the only  difference is  in the  algorithm used  to
decide what names  match a given  wildcarded specification. For  basic
primary wildcarding a  very simple  algorithm can be  used, while  the
advanced primary  wildcarding  requires a  fairly  involved  recursive
matching algorithm. In particular, the  algorithm used by the  current
versions of SCAN/WILD is a  straight two-step operation regardless  of
NFT-10 NIP/FAL/TSC Executive                                  Page C-4
Appendix C: Wildcarding                                      12-Jan-84
Primary Wildcarding
Advanced primary wildcarding


the number of wildcards involved -  the candidate name is first  XORed
with the specification  name, and  then ANDed with  the wildcard  mask
(which has a "1" for each non-wild character in a wildcarded  specifi-
cation) - if the result is 0 then the candidate name is matched by the
specification (this  is why  trailing "?"  wildcards will  match  even
"nothing").

C.1.3 ^E primary wildcarding

An even more powerful  (i.e., flexible) primary wildcard  construction
is the ^E wildcard.  The ^E (Control-E)  character indicates that  the
character(s) immediately following the ^E is(are) an "extended"  wild-
card operation. The ^E wildcard  allows the specification to match  or
reject the candidate name on a  large variety of constraints, such  as
decimal digit only,  everything except alphabetic  characters, and  so
on.
                            
                                 Note

     The ^E wildcard derives from  the ^E search match  operation
     in the text editor TECO

Following are the ^E wildcard constructions:

^EA       Match any alphabetic character. ^EA matches any charac-
          ter which is a letter (regardless of case) - i.e.,  ^EA
          matches if the candidate character is an "A", "B", "C",
          ..., "Y", "Z", "a", "b", "c", ..., "y", or a "z".
^ED       Match any  decimal  digit. ^ED  matches  any  character
          which is a number. ^ED matches if the candidate charac-
          ter is a "0", "1", "2", ..., "8", "9".
^ENx      Match anything  but  "x". ^EDx  matches  any  character
          which is NOT "x" - e.g., ^ENA matches a "B", "C", etc.,
          but NOT an "A".
^EX       Match any  single  character. ^EX  matches  any  single
          character in that position. ^EX is the same as the  "?"
          wildcard - it is included merely for completeness.
^E<ddd>   Match ASCII code "ddd".  ^E<ddd> matches the  character
          whose ASCII character  code is "ddd"  where "ddd" is  a
          decimal number.  For example  ^E<65> matches  only  "A"
          (and NOT "a").
^E[x,y,z] Match either "x" or "y"  or "z". ^E[x,y,z] matches  any
          of the list entries  "x", "y", or "z",  the list is  of
          arbitrary length (it may be only two entries, or it may
          be 88 entries).

As specified above, the ^E constructions always count for exactly  one
character position in the candidate name.

The ^E constructs may also  be nested. For example, the  specification
"^EN^E[A,B,C,^ED]" accounts  for exactly  one character  position  and
matches any character  which is  NOT an "A",  "B", "C",  or a  decimal
digit.
NFT-10 NIP/FAL/TSC Executive                                  Page C-5
Appendix C: Wildcarding                                      12-Jan-84
Secondary Wildcarding



C.2.0 Secondary Wildcarding

Secondary wildcarding  is the  process whereby  a wholly  new name  is
generated based on the extant name matched in a [presumabably] related
primary wildcarded operation. For example, when one or more files  are
copied from one place to  another the copies of  the files have to  be
named something (even if the "name" is no more than a device name such
as LPT:)  - it  is  the "something"  which secondary  wildcarding  ad-
dresses.

Basically, secondary wildcarding is merely copying part of the primary
wildcarded name into the  corresponding secondary wildcarded name.  In
the COPY command
   COPY DSKB:[me]*.* = DSKC:[him]*.*
the specification "DSKC:[him]*.*" is the primary wildcarded file spec-
ification, and "DSKB:[me]*.*" is the secondary wildcarded file  speci-
fication, with the  intent of copying  all of "his"  files from  DSKC:
into "my" DSKB:.

Secondary wildcarding is broken down into three realms.

First  is  the  "error   constraints"  on  secondary  versus   primary
wildcards. The error constraints govern when an error is to be  gener-
ated based on the relative secondary versus primary wildcards. An  er-
ror may be "flagged":

1.   Never
2.   If there are more primary wildcards than secondary wildcards
3.   If the primary wildcards are  different from the secondary  wild-
     cards
4.   If there are more secondary wildcards than primary wildcards

Second is the  relative primary source  for each secondary  wildcarded
field generated.  There  are  four  basic  field  selection  modes  of
operation:

1.   Same field (device to device, SFD1 to SFD1, etc.)
2.   Same field, but allowing directories to shift one or more  entire
     levels
3.   Any field (e.g., secondary file type from primary device)
4.   None (i.e., field boundaries irrelevant)

Third is the manner in which the individual secondary name  characters
are actually generated from the appropriate primary name fields. There
are four basic character replacement modes of operation:

1.   Same exact position (first name  character to first name  charac-
     ter, etc.)
2.   In strict order of occurence, from the selected field
3.   In order of occurence, filling with non-wild characters
4.   In order of occurence, without regard to field boundaries

These three "realms"  of operation are  broken down into  two axes  of
control - SCERROR and  SCWILD. The SCWILD  control is essentially  the
NFT-10 NIP/FAL/TSC Executive                                  Page C-6
Appendix C: Wildcarding                                      12-Jan-84
Secondary Wildcarding



combination of  the field  selection modes  and character  replacement
modes as described immediately above. SCERROR and SCWILD operate  more
or less independently of each other, with some interaction.

SCERROR governs basically  when a syntax  error is to  be issued.  The
four modes for SCERROR are NEVER, INSUFFICIENT, DIFFERENT, and  EXCES-
SIVE.

1.   SCERROR:NEVER indicates that any combination of primary and  sec-
     ondary  wildcards  is  acceptable,  regardless  of  the  possible
     conflicts which might arise.
2.   SCERROR:INSUFFICIENT indicates that an error should be flagged if
     there are insufficient secondary  wildcards to match the  corres-
     ponding primary wildcarded fields.
3.   SCERROR:DIFFERENT indicates  an error  should be  flagged if  the
     secondary wildcards and the primary wildcards are different.
4.   SCERROR:EXCESSIVE indicates that  an error should  be flagged  if
     there are excessive secondary wildcards to match the  correspond-
     ing primary wildcarded fields.

SCWILD controls how the secondary wildcarded fields are actually  gen-
erated. The  seven modes  for  SCWILD are  ANY, FIELD,  SAME,  DFIELD,
DSAME, AFIELD, and ASAME.

1.   SCWILD:ANY indicates that the secondary wildcards are to be  gen-
     erated from any  primary wildcards available  without respect  to
     field boundaries.
2.   SCWILD:FIELD indicates that secondary wildcards are to be  gener-
     ated only from the corresponding primary wildcard fields  (device
     to device, etc.).
3.   SCWILD:SAME indicates that the secondary wildcards are to be gen-
     erated from the corresponding primary characters, without  regard
     to primary wildcards.
4.   SCWILD:DFIELD is the  same as SCWILD:FIELD  except that within  a
     directory specification, entire directory  levels may be  shifted
     about in order to match secondary and primary wildcards.
5.   SCWILD:DSAME is  the same  as SCWILD:SAME  except that  within  a
     directory specification, entire directory  levels may be  shifted
     about in order to match secondary and primary wildcards.
6.   SCWILD:AFIELD is  the same  as  SCWILD:FIELD except  that  entire
     fields may be shifted about in order to match secondary and  pri-
     mary wildcards.
7.   SCWILD:ASAME is the same as SCWILD:SAME except that entire fields
     may be  shifted about  in order  to match  secondary and  primary
     wildcards.

To translate some of  the above, The SCWILD  ANY mode pretty much  ig-
nores field boundries and  simply generates secondary characters  from
the "first" primary wildcard found, regardless of field boundries. The
results of SCWILD:ANY can be very bizarre indeed!

The relative ordering of fields (names) within a specification is node
name, device name, directory name level one (TOPS-10 project  number),
directory name level two  (TOPS-10 programmer number), directory  name
NFT-10 NIP/FAL/TSC Executive                                  Page C-7
Appendix C: Wildcarding                                      12-Jan-84
Secondary Wildcarding



level three (TOPS-10  first SFD), etc.,  directory name lowest  level,
file name, and finally file type.
                            
                                 Note

     Due to various historical  reasons, the current versions  of
     SCAN/WILD treat the project and programmer numbers as 18-bit
     fields, and NOT 6-character fields. In particular, the  sec-
     ondary wildcarding provided  by WILD  works on  a bit  basis
     rather than  on a  character basis.  This can  provide  very
     confusing results  when mixing  ppn wildcards  with  non-ppn
     wildcards.


The SCWILD FIELD modes always stick with a selected field,  generating
secondary characters from the primary field selected. As long as there
are more secondary than primary wildcards the secondary characters are
generated from the corresponding primary characters whether or not the
primary input characters  were originally wildcarded.  When there  are
the same or fewer secondary wildcards than primary wildcards then  the
secondary characters will  be generated only  from primary  wildcarded
character positions.

The SCWILD SAME modes always  stick with a selected field,  generating
secondary characters from the primary  field selected without any  re-
gard for the primary wildcards.  This means that a secondary  wildcard
in position "n" is generated  from the corresponding primary  position
"n", whether or not primary position "n" was wildcarded.

A prefix of "A"  or "D" coupled  with either the  FIELD or SAME  modes
described above indicates that field shuffling is allowed in order  to
satisfy secondary wildcard requests which  would otherwise not have  a
corresponding primary wildcard match. A  prefix of "D" indicates  that
field shifting is limited to  solely within the directory name,  while
the prefix "A" indicates that unlimited field shifting may take place.

The default secondary  wildcard operating  modes are  SCERROR:INSUFFI-
CIENT and SCWILD:FIELD.

C.2.1 Secondary wildcarding examples

Some examples are in  order which might  help clarify secondary  wild-
carding operation.

All examples will be assumed to be a command string to a COPY command,
of the form "out = in" a la standard TOPS-10 conventions.

The examples assume a TOPS-10 network environment with three hosts  in
the network - KI514, KL1026, and KS4101. The examples ignore  non-host
(non-MCR) nodes.

Each of the  three host nodes  is assumed  to contain a  set of  files
residing on disk structures, and no other files.
NFT-10 NIP/FAL/TSC Executive                                  Page C-8
Appendix C: Wildcarding                                      12-Jan-84
Secondary Wildcarding
Secondary wildcarding examples


The examples are assumed to be executed on host KL1026. As such, if  a
node name does not appear in  a file specification in an example  then
the node is implicitly KL1026.

The examples will assume the existence of the following files:

   KI514_DSKE:[1,4]AVAIL.SYS
   KI514_DSKE:[1,4]CRASH.SYS

   KL1026_DSKC:[1,4]ACCT.SYS
   KL1026_DSKC:[1,4]AUXACC.SYS
   KL1026_DSKC:[1,4]AVAIL.SYS
   KL1026_DSKC:[1,4]CRASH.SYS
   KL1026_DSKC:[1,10,KI514,SYS]ACCT.SYS
   KL1026_DSKC:[1,10,KI514,SYS]AUXACC.SYS
   KL1026_DSKC:[1,10,KI514,ACT]USAGE.BIN
   KL1026_DSKC:[1,10,KL1026,SYS]ACCT.SYS
   KL1026_DSKC:[1,10,KL1026,SYS]AUXACC.SYS
   KL1026_DSKC:[1,10,KL1026,ACT]USAGE.BIN
   KL1026_DSKC:[1,10,KS4101,SYS]ACCT.SYS
   KL1026_DSKC:[1,10,KS4101,SYS]AUXACC.SYS
   KL1026_DSKC:[1,10,KS4101,ACT]USAGE.BIN
   KL1026_DSKC:[17,341]C14ACC.T
   KL1026_DSKC:[17,341]C14AUX.ACC
   KL1026_DSKC:[17,341]B17USA.GE
   KL1026_DSKB:[226,4563]SWITCH.INI
   KL1026_DSKB:[226,4563]A0B1C2.DAT
   KL1026_DSKB:[226,4563]A3B4C5.DAT
   KL1026_DSKB:[226,4563]A6B7C8.DAT
   KL1026_DSKB:[226,4563]A9XXXX.DAT
   KL1026_DSKB:[226,4563,RDH1,RDH2]BLAH0A.FOO
   KL1026_DSKB:[226,4563,RDH1,RDH2]BLAH0B.FOO
   KL1026_DSKB:[226,4563,RDH1,RDH2]BLAH1A.FOO
   KL1026_DSKB:[226,4563,RDH1,RDH2]BLAH1B.FOO
   KL1026_DSKC:[226,4563,RDH1,RDH2]BLAH0A.FOO
   KL1026_DSKC:[226,4563,RDH1,RDH2]BLAH0B.FOO
   KL1026_DSKC:[226,4563,RDH1,RDH2]BLAH1A.FOO
   KL1026_DSKC:[226,4563,RDH1,RDH2]BLAH1B.FOO

   KS4101_DSKA:[1,4]AVAIL.SYS
   KS4101_DSKA:[1,4]CRASH.SYS

Starting off with a trivial case, consider the specification
   DSKX:[10,11]*.* = DSKC:[1,4]*.*
This case is obvious and unambiguous, and behaves in exactly the  same
manner with all secondary wildcard modes. Each file in the  DSKC:[1,4]
area is to be copied to the DSKX:[10,11] area, with the same file name
and type  (or extension).  This specification  will never  generate  a
secondary wildcarding  syntax error  since even  the most  restrictive
constraints (SCERROR:DIFFERENT) are  satisfied -  the secondary  wild-
cards match EXACTLY the primary wildcards. The end result of the  COPY
operation would be:
   DSKX:[10,11]ACCT.SYS
   DSKX:[10,11]AUXACC.SYS
NFT-10 NIP/FAL/TSC Executive                                  Page C-9
Appendix C: Wildcarding                                      12-Jan-84
Secondary Wildcarding
Secondary wildcarding examples


   DSKX:[10,11]AVAIL.SYS
   DSKX:[10,11]CRASH.SYS

A slightly ("epsilon") less obvious case is the specification
   DSKX:[10,11]*.* = DSKC:[1,4]A*.*
This case is still pretty much  obvious and unambiguous. Each file  in
the DSKC:[1,4] area which starts  with an "A" is  to be copied to  the
DSKX:[10,11] area, with the same file name and type. If SCERROR:EXCES-
SIVE had been specified then a  syntax error would result since  there
are more secondary wildcards than primary wildcards. (Strictly  speak-
ing, there  are  the same  number  or "ordinality"  of  secondary  and
primary wildcards, but the secondary  filename wildcard "*" is  bigger
than the corresponding  primary filename wildcard  "*" - specifying  a
size relationship between wildcards refers  to the cardinality of  the
wildcards, not the  ordinality.) Using  either the ANY  or the  FIELD/
DFIELD/AFIELD SCWILD replacement mode the resulting files would be:
   DSKX:[10,11]ACCT.SYS
   DSKX:[10,11]AUXACC.SYS
   DSKX:[10,11]AVAIL.SYS
For this  particular example,  using the  SAME/DSAME/ASAME SCWILD  re-
placement modes would have the  same results, since for every  primary
wildcard there is an EXACT matching secondary wildcard.

The specification
   DSKX:[10,11]*.* = DSKB:[226,4563]A?B?C?.*
behaves in the same way - each file in the DSKB:[226,4563] area  which
matches the  primary specification  is  copied into  the  DSKX:[10,11]
area, with the same file name and type. The resulting files would be:
   DSKX:[10,11]A0B1C2.DAT
   DSKX:[10,11]A3B4C5.DAT
   DSKX:[10,11]A6D7B8.DAT

In essentially the same way, the specification
   DSKX:[10,11]A?B?C?.* = DSKB:[226,4563]A?B?C?.*
would generate exactly the same resulting files:
   DSKX:[10,11]A0B1C2.DAT
   DSKX:[10,11]A3B4C5.DAT
   DSKX:[10,11]A6D7B8.DAT
Note however that unlike the immediately preceding example (for  which
SCERROR:EXCESSIVE will cause  a syntax error  because there were  more
secondary wildcards  than primary  wildcards) this  example can  never
cause a syntax error because  the secondary wildcards again match  EX-
ACTLY the primary wildcards.

The above examples were all  really straightforward, with the  desired
results being quite "obvious" (and  the same regardless of the  secon-
dary wildcarding mode  used). Now, consider  the following three  not-
quite-so-obvious specifications
   DSKX:[10,11]?X?Y?Z.DAT = DSKB:[226,4563]A?B?C?.DAT
   DSKX:[10,11]XYZ???.DAT = DSKB:[226,4563]A?B?C?.DAT
   DSKX:[10,11]???XYZ.DAT = DSKB:[226,4563]A?B?C?.DAT
It is at this  point that the various  SCWILD replacement modes  start
showing their differences. The ANY and FIELD/DFIELD/AFIELD modes still
generate the  same results  since the  total number  of secondary  and
NFT-10 NIP/FAL/TSC Executive                                 Page C-10
Appendix C: Wildcarding                                      12-Jan-84
Secondary Wildcarding
Secondary wildcarding examples


primary wildcards  per field  is the  same, but  the  SAME/DSAME/ASAME
modes are different since the relative placement of the secondary  and
primary wildcards differ.  The SAME/DSAME/ASAME  modes would  generate
the files:
   DSKX:[10,11]AXBYCZ.DAT / XYZ1C2.DAT / A0BXYZ.DAT
   DSKX:[10,11]AXBYCZ.DAT / XYZ4C5.DAT / A3BXYZ.DAT
   DSKX:[10,11]AXBYCZ.DAT / XYZ7C8.DAT / A6BXYZ.DAT
for the three  specifications respectively. The  ANY or  FIELD/DFIELD/
AFIELD modes however would generate the files:
   DSKX:[10,11]0X1Y2Z.DAT / XYZ012.DAT / 012XYZ.DAT
   DSKX:[10,11]3X4Y5Z.DAT / XYZ345.DAT / 345XYZ.DAT
   DSKX:[10,11]6X7Y8Z.DAT / XYZ678.DAT / 678XYZ.DAT
for the three  specifications respectively. This  demonstrates one  of
the two major "flexibilities" of the ANY or FIELD/DFIELD/AFIELD  modes
- the ability to shift the primary-wildcard-matched characters  around
in order to fill out scattered secondary wildcards. Finally, the  only
error constraints which  would fail these  examples is again  SCERROR:
DIFFERENT because, even though the total number of secondary and  pri-
mary wildcards are the same for each field, the relative placement  of
the wildcards is different.

From the preceding examples, the two specifications
   DSKX:[10,11]Q*.DAT = DSKB:[226,4563]A*.DAT
   DSKX:[10,11]Q*.DAT = DSKB:[226,4563]A?B?C?.DAT
would always result in:
   DSKX:[10,11]Q0B1C2.DAT
   DSKX:[10,11]Q3B4C5.DAT
   DSKX:[10,11]Q6B7C8.DAT
   DSKX:[10,11]Q9XXXX.DAT (first specification only)
No syntax errors are possible  with the first specification since  the
primary and secondary wildcards EXACTLY match, but either one of  DIF-
FERENT or EXCESSIVE  would fail the  second specification since  there
are more secondary wildcards than primary wildcards. (As an aside, the
construction SCERROR:(INSUFFICIENT,EXCESSIVE) may be used to guarantee
the same number of secondary  and primary wildcards without  requiring
that the wildcards match EXACTLY.)

Likewise, the two specifications
   DSKX:[10,11]Q???.DAT = DSKB:[226,4563]A*.DAT
   DSKX:[10,11]Q???.DAT = DSKB:[226,4563]A?B?C?.DAT
would, if using the SAME/DSAME/ASAME modes, result in:
   DSKX:[10,11]Q0B1.DAT
   DSKX:[10,11]Q3B4.DAT
   DSKX:[10,11]Q6B7.DAT
   DSKX:[10,11]Q9XX.DAT (first specification only)
for the two  specifications respectively. If,  however, either of  the
ANY or FIELD/DFIELD/AFIELD modes were used, the results would be  dif-
ferent for the two specifications, as follows:
   DSKX:[10,11]Q0B1.DAT / Q012.DAT
   DSKX:[10,11]Q3B4.DAT / Q345.DAT
   DSKX:[10,11]Q6B7.DAT / Q678.DAT
   DSKX:[10,11]Q9XX.DAT (first specification only)
SCERROR:INSUFFICIENT  would  cause  a  syntax  error  for  the   first
specification only, while SCERROR:DIFFERENT would cause a syntax error
NFT-10 NIP/FAL/TSC Executive                                 Page C-11
Appendix C: Wildcarding                                      12-Jan-84
Secondary Wildcarding
Secondary wildcarding examples


for both specifications.

Finally, for this set of examples, consider the specification
   DSKX:[10,11]HOHUM?.BAR = DSKB:[226,4563,RDH1,RDH2]BLAH??.FOO
The files generated  by this  specification using  FIELD/DFIELD/AFIELD
modes would be:
   DSKX:[10,11]HOHUM0.BAR
   DSKX:[10,11]HOHUM0.BAR
   DSKX:[10,11]HOHUM1.BAR
   DSKX:[10,11]HOHUM1.BAR
or, if using the SAME/DSAME/ASAME modes:
   DSKX:[10,11]HOHUMA.BAR
   DSKX:[10,11]HOHUMB.BAR
   DSKX:[10,11]HOHUMA.BAR
   DSKX:[10,11]HOHUMB.BAR
This example  demonstrates why  SCERROR:INSUFFICIENT is  the  default,
since the above  example ends up  superseding its very  own brand  new
files, leaving only two instead of four new files. However, this  very
operation can be desired if,  for example, /APPEND had been  specified
as part of the  output file specification, for  in that case the  copy
operation would have  been essentially  one of  grouping together  and
combining [presumably] related files. This action borders on the  eso-
teric, but starts to give some  idea of the flexibility available  for
manipulating files.

So far, all  of the examples  shown have avoided  "field shifting"  in
generating the secondary  outputs. Field shifting  adds another  whole
dimension to the secondary wildcarding process.

Consider the fairly straight-forward Kinkyness
   DSKX:[10,11,COPY,*,*]*.* = DSKB:[226,4563,*,*]*.*
From the examples above, it might seem that the resultant files  would
be:
   DSKX:[10,11,COPY]RDH1.SFD
   DSKX:[10,11,COPY]RDH2.SFD
   DSKX:[10,11,COPY,RDH2]BLAH0A.FOO
   DSKX:[10,11,COPY,RDH2]BLAH0B.FOO
   DSKX:[10,11,COPY,RDH2]BLAH1A.FOO
   DSKX:[10,11,COPY,RDH2]BLAH1B.FOO
which is exactly what  would happen in either  SAME or FIELD mode.  If
DSAME or DFIELD  mode is  used (or for  that matter,  ASAME or  AFIELD
mode, for this example they  are equivalent) then the secondary  wild-
card processor has  another option  available. As the  same number  of
secondary and primary  wildcards were specified  within the  directory
field but in  different relative  positions (in  this case,  different
subfields), the relative positions of the secondary and primary  wild-
cards can  be shifted  in order  to  re-align them,  in this  case  by
shifting the  primary directory  SFD wildcards  "right" one  directory
level. The resulting files are then:
   DSKX:[10,11,COPY]RDH1.SFD
   DSKX:[10,11,COPY,RDH1]RDH2.SFD
   DSKX:[10,11,COPY,RDH1,RDH2]BLAH0A.FOO
   DSKX:[10,11,COPY,RDH1,RDH2]BLAH0B.FOO
   DSKX:[10,11,COPY,RDH1,RDH2]BLAH1A.FOO
NFT-10 NIP/FAL/TSC Executive                                 Page C-12
Appendix C: Wildcarding                                      12-Jan-84
Secondary Wildcarding
Secondary wildcarding examples


   DSKX:[10,11,COPY,RDH1,RDH2]BLAH1B.FOO

Moving along on the path to Extreme Kinkyness is the specification
   DSKX:[10,11,COPY,*,*,*]*.* = *:[226,4563,*,*]*.*
If either FIELD or SAME modes were used then the results would be  the
same as in the first  list of the example  above. If either DFIELD  or
DSAME modes were used  then the results  would be the  same as in  the
second list of the  example above. But if  AFIELD or ASAME were  used,
allowing field  shifting to/from  any field,  then a  new output  list
would be generated:
   DSKX:[10,11,COPY,DSKB]RDH1.SFD
   DSKX:[10,11,COPY,DSKB,RDH1]RDH2.SFD
   DSKX:[10,11,COPY,DSKB,RDH1,RDH2]BLAH0A.FOO
   DSKX:[10,11,COPY,DSKB,RDH1,RDH2]BLAH0B.FOO
   DSKX:[10,11,COPY,DSKB,RDH1,RDH2]BLAH1A.FOO
   DSKX:[10,11,COPY,DSKB,RDH1,RDH2]BLAH1B.FOO
   DSKX:[10,11,COPY,DSKC]RDH1.SFD
   DSKX:[10,11,COPY,DSKC,RDH1]RDH2.SFD
   DSKX:[10,11,COPY,DSKC,RDH1,RDH2]BLAH0A.FOO
   DSKX:[10,11,COPY,DSKC,RDH1,RDH2]BLAH0B.FOO
   DSKX:[10,11,COPY,DSKC,RDH1,RDH2]BLAH1A.FOO
   DSKX:[10,11,COPY,DSKC,RDH1,RDH2]BLAH1B.FOO

Similarly, in a networking environment, the specification
   DSKX:[10,11,*,*]13JUN. = *_SYS:*.SYS
would, using  ANY  or  AFIELD/ASAME  mode,  gather  all  (.e.g,  "this
weeks'")  scattered   (throughout   the   network)   AVAIL.SYSes   and
CRASH.SYSes together into sorted-by-name subdirectories under  [10,11]
as so:
   DSKX:[10,11,KI514,AVAIL]13JUN.
   DSKX:[10,11,KI514,CRASH]13JUN.
   DSKX:[10,11,KL1026,AVAIL]13JUN.
   DSKX:[10,11,KL1026,CRASH]13JUN.
   DSKX:[10,11,KS4101,AVAIL]13JUN.
   DSKX:[10,11,KS4101,CRASH]13JUN.

As can  be readily  seen from  the above  results, secondary  wildcard
processing can  indeed be  flexible in  gathering "dispersed"  primary
fields and gathering them together in order to fill out closely relat-
ed secondary fields. The processing is symmetric - it can take closely
related primary fields and  scatter them all  over the secondary  file
specification, as in
   *_*:*.* = DSKC:[1,10,*,*]*.*
The results of the  above specification, using  either ANY or  AFIELD/
ASAME mode, would be:
   KI514_SYS:[0,0]ACCT.SYS
   KI514_SYS:[0,0]AUXACC.SYS
   KI514_ACT:[0,0]USAGE.BIN
   KL1026_SYS:[0,0]ACCT.SYS
   KL1026_SYS:[0,0]AUXACC.SYS
   KL1026_ACT:[0,0]USAGE.BIN
   KS4101_SYS:[0,0]ACCT.SYS
   KS4101_SYS:[0,0]AUXACC.SYS
   KS4101_ACT:[0,0]USAGE.BIN
NFT-10 NIP/FAL/TSC Executive                                 Page C-13
Appendix C: Wildcarding                                      12-Jan-84
Secondary Wildcarding
Secondary wildcarding examples


It should be noted that, although "SYS:[0,0]" and "ACT:[0,0]" are  the
actual device and directory fields  generated, which might well  cause
problems if talking to a VAX  system, the TOPS-10 monitor treats  them
as (essentially) "SSL:[1,4]" and "SSL:[1,7]" respectively. This  beha-
viour, like most obscure behaviours, can be very advantageously put to
use by the enterprising user . . .

And penultimatly, Penultimate Kinkyness: consider the specification
   DSK?:[?,?]??????.SYS = DSKC:[17,341]*.*
Using the ANY mode, the resulting files would be:
   DSKC:[1,4]ACCT.SYS
   DSKC:[1,4]AUXACC.SYS
   DSKB:[1,7]USAGE.SYS
If one looks closely at  the algorithm used in  ANY mode it is  really
quite simple - starting at the "left" and working to the "right"  each
secondary wildcard character position encountered is simply filled  by
the next-in-line primary wildcarded character position, without regard
to field boundries.

The SCERROR  constraints, when  field shifting  is occurring,  "shift"
along with the fields. The three specifications
   DSKX:[10,11,COPY,*,*]*.* = DSKC:[226,4563,????,*]*.*
   DSKX:[10,11,COPY,????,*]*.* = DSKC:[226,4563,*,*]*.*
   DSKX:[10,11,COPY,*,*,*,*]*.* = DSKC:[1,4,*,*,*,*,*]*.*
all have different secondary  and primary wildcards.  SCERROR:INSUFFI-
CIENT (the default) would pass the first (it would map "*,*]*.*"  from
"????,*]*.*",  which  has  sufficient  secondary  wildcards  for  each
primary wildcarded  field) but  fail  both the  second (it  would  map
"????,*]*.*" from "*,*]*.*",  which has  insufficient secondary  wild-
cards in the very  first matched wildcarded field)  and the third  (it
would map "*,*,*,*]*.*"  from "*,*,*,*,*]*.*", which  using DFIELD  or
DSAME modes has one too many primary wildcarded directory name fields,
or using AFIELD or ASAME has  one too many primary wildcarded  fields,
or using ANY has 6 (TOPS-10) too many primary wildcarded  characters).
Similarly, SCERROR:EXCESSIVE would pass  the second specification  but
fail the first and third specifications. SCERROR:DIFFERENT would  fail
all three  specifications since  the  first two  have a  "????"  field
mapped to/from a  "*" field,  and the  third has  a nonexistent  field
mapped from a "*" field.

Up until this  point all  of the secondary  wildcarding examples  have
been restricted to  the simple  or "basic"  wildcard constructions  as
defined in the previous section on primary wildcarding. As such,

Finally, for Ultimate Kinkyness, consider:
   DSKX:[10,11]X*Y*Z.BAR = DSKB:[226,4563,RDH1,RDH2]B*A?^EDB.FOO

The interaction of secondary and advanced wildcarding is not supported
and will cause an error indication.