Trailing-Edge
-
PDP-10 Archives
-
BB-H348C-RM_1982
-
swskit-v21/certification/cert-report-v21.mem
There are no other files named cert-report-v21.mem in the archive.
Following are the results of certification testing
performed between DECnet-20 V2.1 NFT/FAL and assorted other
Digital systems and DECnet products. First note that the
testing was performed using various TOPS-20 DECnet
implementations on various TOPS-20 monitors. Since only
NFT/FAL was under test, this was acceptable to the
certification group. Note also that the remote systems used
were often software made available by the engineer, not
software from the SDC. This was necessary because the
remote software was still under test during certification.
This has the potential for errors appearing in the released
software which were not seen during certification.
There are many "problems" transfering files between
unlike systems. Many of these problems are considered
restrictions in the products and are not bugs. They
include:
1. The inability to transfer logical records larger
than 512 bytes.
2. The transfer of a 512 byte per record ascii stream
file to a RSTS system will succeed. However,
attempts to copy it back again will fail because
RSTS/RMS will attempt to put the 512 bytes of data
and a CRLF into a 512 byte buffer and the buffer
overflows.
3. The inability to transfer image files to and from
certain systems.
4. The failure to retain unique file names when files
with long file names are copied to systems with
shorter file names.
5. The failure to retain unique file names when files
with version numbers or deciaml version numbers are
copied to systems which don't use version numbers
or use octal version numbers.
6. The ability to use all wild constructs such as *,
*A, A*, *A*, %, and ?.
DECnet-20 V2.1 NFT/FAL Certification Test Results Page 2
DECnet-20 V2.1 VS DECnet-20 V2.1
All NFT commands were tested. NFT-20 can copy any disk
resident file to or from another DECsystem-20. No problems
were encountered.
DECnet-20 V2.1 NFT/FAL Certification Test Results Page 3
DECnet-20 V2.1 VS DECnet-20 V2.0
All NFT commands were tested. NFT-20 can copy any disk
resident file to or from another DECsystem-20. The
following problems were encountered:
1. DECnet-20 V2.0 does not support print spooling.
This is a restriction.
2. DECnet-20 V2.0 implemented the checksummed transfer
of files using wildcarded file specifications
incorrectly. The architecture specifies that the
checksum is to be reset before each file transfer.
DECnet-20 V2.0 reset the checksum only before the
transfer of the first file which matches the
wildcarded specification. As a result, whenever
DECnet-20 V2.0 is used to copy more than one file
with a wildcarded specification to a DECnet-20 V2.1
or later system, or any other DECnet system, the
file transfer fails at the transfer of the second
file. This cannot be fixed. To prevent the
problem install NFT/FAL from the DECnet-20 V2.1
distribution on all DECsystem-20s in the network at
roughly the same time.
DECnet-20 V2.1 NFT/FAL Certification Test Results Page 4
DECnet-20 V2.1 VS RT (any version)
The certification group did not require a formal
certification of DECnet-20 V2.1 against the new phase III
release of RT. This is because DECnet/RT will not support
phase II compatibility. However, it should be determined
whether DECnet-20 V2.1 NFT/FAL can communicate with the
current DECnet/RT product. This also was not required by
the certification group and as a result has not been done as
part of this certification testing.
DECnet-20 V2.1 NFT/FAL Certification Test Results Page 5
DECnet-20 V2.1 VS IAS
The certification group did not require a formal
certification of DECnet-20 V2.1 against the new phase III
release of IAS. This is because a few commands were typed
one day to NFT on a DECnet-20 V2.1 system connected to a
phase III IAS system. Although some of the commands worked,
many did not. The problems, however, seem to be similar to
the problems with DECnet/M. The problems remain unsolved.
DECnet-20 V2.1 NFT/FAL Certification Test Results Page 6
DECnet-20 V2.1 VS DECnet/VAX V3.0
The following VMS DCL commands were tested: COPY,
SUBMIT/REMOTE, PRINT/REMOTE, DELETE, TYPE, DIRECTORY. VMS
can handle the transfer of local files only if they are
ASCII FIXED with implied CRLF or ASCII VARIABLE with implied
CRLF. VMS cannot handle any other local file types, such as
the output from runoff, batch log files, line numbered
files, or image files without the use of a utility program
to convert the format. VMS can only handle STREAM ASCII
files on the remote TOPS-20 system.
All NFT-20 commands were tested. TOPS-20 can handle
the following local file formats: ASCII STREAM, IMAGE
FIXED, IMAGE VARIABLE, MACY11, MACY11 FIXED, MACY11
VARIABLE, and MACY11 IMAGE. TOPS-20 can also handle the
following formats on the remote VAX system: ASCII files
with any combination of record formats of STREAM, FIXED,
VARIABLE, or VFC and record attributes of implied CRLF,
Fortran carriage control, VMS print file carriage control,
undefined, or undefined with imbedded carriage control and
IMAGE FIXED and IMAGE VARIABLE.
No unsolved problems were encountered during
certification testing.
DECnet-20 V2.1 NFT/FAL Certification Test Results Page 7
DECnet-20 V2.1 VS DECnet/E V2.0
All NFT-20 commands were tested. NFT-20 can handle the
following remote files: ASCII with any combination of the
record formats VFC, VARIABLE, FIXED, and STREAM, and the
record attributes implied CRLF, Fortran carriage control,
undefined, and imbedded and IMAGE FIXED, and IMAGE VARIABLE.
NFT-20 can handle the same local file formats as it does for
VMS.
The following RSTS NFT commands were tested: COPY,
DIRECTORY, DELETE, TYPE, PRINT, APPEND, and SUBMIT. RSTS
NFT can handle most local ASCII files but cannot handle
image files at all. RSTS NFT can only handle remote stream
ascii files. Note that every transfer to or from the
TOPS-20 system requires the /NATIVE switch. Without this
switch the transfer will fail.
There were two unsolved problems with RSTS:
1. An append command issued from RSTS NFT hangs.
2. A SUBMIT A=B command, i.e., one which first copies
a control file and then queues it, copies the file
successfully, but fails to queue it.
DECnet-20 V2.1 NFT/FAL Certification Test Results Page 8
DECnet-20 V2.1 VS DECnet/M V3.0
Although DECnet/M V3.1 is currently under development,
we could not certify against V3.1 because the engineers
could not provide us with an RSX11M system which didn't
crash during DECnet transfers. As a result we performed the
certification tests against the field image RSX11M DECnet
product.
All NFT-20 commands were tested. NFT-20 can handle the
same remote and local file formats as it does for VMS.
The following RSX11M NFT switches were tested:
/BR,/LI,/FU,/DE, /SB,/EX,/SP, and no switches. RSX NFT
requires the /AS switch with all transfers to or from
TOPS-20. RSX NFT can handle many local ASCII files, no
local image files and remote ASCII stream files.
The following problems were found during certification
with RSX11M:
1. When using the /SB switch to RSX NFT the file was
copied correctly, but not queued.
2. The TYPE command to NFT-20 gives the error message
"?File is not ASCII" when used on an RSX file with
variable records and no record attributes in which
the carriage control is imbedded. Runoff creates
such files. RSX fails to believe the record
attributes initially passed by NFT-20.
3. If two transfers are attempted one after the other
during the same link connection the second transfer
fails. Currently, the /OSTYPE:RSX switch to NFT-20
causes the link to be broken between each transfer.
This solves the problem, but makes performance
poor.
4. RSX FAL does not accept FOP bits in the access
complete message. NFT-20 now sends the FOP bits in
the access message to circumvent the problem.
5. When wildcard file specifications are used with the
PRINT command RSX FAL hangs.
6. When a single file is SUBMITTed, RSX FAL responds
correctly, but the file is not queued. When a
wildcard specification is SUBMITTed, an error
message is typed by NFT-20, but the files are
correctly queued.