RFC 122
Network specifications for UCSB's Simple-Minded File System
NETWORK SPECIFICATIONS FOR UCSB's SIMPLE-MINDED FILE SYSTEM 💖
Okay bestie, so this is RFC 122 (also NIC 5834) from the Network Working Group 🌸. James E. White wrote it at UC Santa Barbara, dated 26 April 1971. It's all about UCSB's Simple-Minded File System, aka SMFS 🎀. The header doesn't list a category or status, and it doesn't say it obsoletes or updates anything. This is part 1 of 4, so there's more coming! ✨
CONTENTS
Page
I. Preface........................................ 3
II. Implementation................................. 3
III. Login.......................................... 3
IV. Service Offered................................ 4
V. Primitive File Operations...................... 6
V.A. Allocate File (ALF)...................... 6
V.B. Update File (UDF)........................ 7
V.C. Replace File (RDF)....................... 8
V.D. Retrieve File (RTF)...................... 9
V.E. Space File (SPF)......................... 9
V.F. Delete File (DLF)........................ 10
V.G. Rename File (RNF)........................ 10
V.H. File No Operation (FNO).................. 10
V.I. No Operation (NOP)....................... 11
VI. Input Stream Format............................ 11
VII. Output Stream Format........................... 16
FIGURES
Page
Figure 1. Filename/Password Character Sets........... 5
Figure 2. Command Op Codes........................... 12
Figure 3. Defined Command Fields..................... 13
Figure 4. Definition of Command FLAGS Bits........... 14
Figure 5. Defined Command Response Fields............ 18
Figure 6. Completion Codes........................... 19I. Preface ✨
UCSB is going to provide file storage for Network users 🫶. This doc is for programmers who want to talk to SMFS, which handles all Network transactions through its NCP. The NCP runs under the Host-Host protocol of August 3, 1970.* SMFS lives at socket X'401' on site 3 🦋. No accounting parameters are REQUIRED.
II. Implementation 🍓
This part isn't essential to using SMFS, but it's kinda interesting 👀. SMFS stores user files on IBM 2316 disk packs, and each pack holds 29M 8-bit bytes. UCSB has two 2314 units with eight drives each on-line. At first, one drive is allocated for Network storage. The right pack is always mounted there, so SMFS can reach it without an operator stepping in. UCSB estimates that it'll have up to four drives it can give to Network use over the next year. The second, third, and fourth drives only get allocated when there's a need. SMFS is written to handle any number of on-line drives without changes, which is so iconic 🔥.
If it's necessary, UCSB will look into making one of the four drives a come-and-go drive. That's a drive where one of several packs can be mounted when needed. This means the storage capacity could go up, but so would the access time 🕰️.
SMFS backs up stored files to tape daily. The back-up tape(s) stay off-line and only come out if the on-line copies get destroyed 💾.
UCSB does NOT expect to become the file storage node of the Network. It just doesn't have the capacity 🙈. It is equipped, though, to make a limited amount of secondary storage immediately available to the Network community 💜.
III. Login 🔐
SMFS can serve any number of Network users at the same time, up to an assembly-parameter maximum (currently ten) 🙌. A potential user MUST establish a pair of Network connections, which is one full-duplex connection in total, to SMFS. They do this by running a standard ICP to socket X'401' on site 3. SMFS always listens on that socket.
SMFS accepts any call it gets, say from the user's receive socket 'm'. Over that connection, it sends back a 32-bit receive socket number (call it 'n'), then closes the connection. After that, SMFS issues two connection requests. One connects its receive socket 'n' with the user's send socket 'm+l'. The other connects its send socket 'n+l' with the user's receive socket 'm' ✨. Once both connections are established, the user is logged in 🎉. The only time this deviates from the Initial Connection Protocol is when SMFS or its NCP doesn't have enough resources to support another connection.
SMFS keeps its connections to the user indefinitely. It only terminates its connections to the user voluntarily if (1) a bad op code shows up in a user command (see Section VI), or (2) closing one of the connections is REQUIRED to signal end-of-data (see Section V.D.). Otherwise, the user SHOULD close their connections when they're finished, and then SMFS considers them logged out 👋.
Here are the terms we're using. The connections where the user sends and receives data are called the input and output connections. We look at this from SMFS's side, not the user's 🧠. The string of bits that goes from the user to SMFS over the input connection, during that connection's life, is the input stream. The string of bits that goes from SMFS to the user over the output connection, during that connection's life, is the output stream.
*At the time of this writing, the NCP modifications of RFC #107 have not as yet been implemented at UCSB. (This is the footnote for the asterisk in the Preface.)
IV. Service Offered 🎁
SMFS gives storage for sequential, binary files. A file's length has to be at least an assembly-parameter minimum (currently one bit) and at most an assembly-parameter maximum (currently 25 million bits). There's no restriction on what the file contents can be 💅.
Every file stored with SMFS has a filename. A filename can be any string of one to 36 8-bit characters chosen from this set: { A,...,Z,0,...9,blank } 🔤. Here's the chart:
Graphic EBCDIC Code (Hex) ASCII Code (Hex)
UC LC UC LC UC LC
A a C1 81 41 61
B b C2 82 42 62
C c C3 83 43 63
D d C4 84 44 64
E e C5 85 45 65
F f C6 86 46 66
G g C7 87 47 67
H h C8 88 48 68
I i C9 89 49 69
J j D1 91 4A 6A
K k D2 92 4B 6B
L l D3 93 4C 6C
M m D4 94 4D 6D
N n D5 95 4E 6E
O o D6 96 4F 6F
P p D7 97 50 70
Q q D8 98 51 71
R r D9 99 52 72
S s E2 A2 53 73
T t E3 A3 54 74
U u E4 A4 55 75
V v E5 A5 56 76
W w E6 A6 57 77
X x E7 A7 58 78
Y y E8 A8 59 79
Z z E9 A9 5A 7A
0 - F0 - 30 -
1 - F1 - 31 -
2 - F2 - 32 -
3 - F3 - 33 -
4 - F4 - 34 -
5 - F5 - 35 -
6 - F6 - 36 -
7 - F7 - 37 -
8 - F8 - 38 -
9 - F9 - 39 -
blank - 40 - 20 -
Figure 1
Filename/Password Character SetsFilenames can be given in either EBCDIC or ASCII (see Figure 1). The letters A,...,Z MAY be either upper- or lower-case 🔠. SMFS accepting both cases and both codes is only a convenience for the user. It doesn't increase the number of unique filenames you can make. For example, 'FILE NUMBER 1' and 'file number 1', in EBCDIC or ASCII, point to the same file 🤓.
Every file stored with SMFS MAY optionally be protected against unauthorized retrieval and/or modification 🛡️. When a file is created, the user MAY associate a modification password and/or an access password with it. After that, SMFS demands the right password before the file gets modified or retrieved, respectively. SMFS protects each file on its own against unauthorized modification and retrieval. So a group of users can get access to a file while one single person keeps the exclusive right to modify it 👑. If no password is defined for a particular kind of reference to a file, those references are unrestricted. Passwords have the same attributes as filenames, meaning the same length restrictions and the same character sets 🔑.
Because of how SMFS writes files onto secondary storage, it MUST insure that while one user is modifying a file, no other user is modifying or retrieving that same file at the same time 😤. SMFS handles this with an internal mechanism, so it's transparent to users. The one exception is that if a user tries to retrieve or modify a file that another user is currently modifying, SMFS holds that request until the current modification is complete. There's no restriction on the number of users who MAY retrieve the same file concurrently 💖.
V. Primitive File Operations 🛠️
SMFS knows how to recognize and run these primitive file operations:
V.A. Allocate File (ALF) ✨
Okay bestie, so SMFS treats reserving a filename, setting up passwords, and reserving secondary storage as a separate thing from actually sending the file's contents 💅. That whole step is called file allocation, or ALF for short. When you allocate, you tell SMFS three things: the filename you want, the access password (if you have one), and the estimated size of the file in bits. SMFS then checks that the filename doesn't duplicate an existing file, and that it has enough secondary storage for your new file 🫶. If both checks pass, it allocates the file. The filename is reserved, the storage is reserved, and the password info gets recorded 🎀.
When SMFS reserves storage, it adds its own estimate of its overhead to the size you declared. Generally you should slightly over-estimate your file's size at allocation 🌸. SMFS allocates a fixed amount based on that estimate, and that amount cannot be increased later 😭. SMFS's real overhead depends on how you send the contents. It's minimal when the file goes in a single series of operations (see Section VI), and it grows as the number of operations grows. The overhead SMFS adds to your size is the single-series version, so for multiple-series transmission, the overhead will have been underestimated 💀.
V.B. Update File (UDF) 💖
Sending part or all of the contents of an already-allocated file, for SMFS to store, is called updating the file (UDF) 🦋. You specify the filename, the modification password if one is required, how many bits of data you're adding, and then the data itself. SMFS finds the file on secondary storage, checks the password for validity if it applies, and adds your data to the file. The update is complete when either the specified number of bits has been pulled from the input stream and stored, or when you end things by closing the connection 🔥.
The data from a UDF gets concatenated onto whatever the file already has. The boundaries between updates are invisible to you when you retrieve the file 👑. For example, you could send a file's contents in two separate UDFs and later pull it all back in one RTF (see Section V.D.). Think of a stored file as a potentially super long bit string that you can send in any number of variable-length segments, and retrieve in any number of variable-length segments too 🌈. How you chop it up during retrieval is totally independent of how you chopped it up during updating 💅.
You can optionally ask SMFS to 'remember' how a file was updated. That means along with the data, it stores enough info to rebuild the segment boundaries at retrieval time 🧚. A file like this is called formatted. When you retrieve a formatted file, instead of asking for the next 'n' bits like you would with an unformatted file (see Section V.D.), you ask for the next segment, and SMFS is responsible for supplying the length of that segment 🍓. This is where the idea of a logical record comes in ✨.
Since you can format your file any way you like, you can also embed record-length info inside the data yourself, so the record structure is transparent to SMFS 🙈. But then, during retrieval, for each logical record you have to fetch the length field first, and then use that length as an operand to fetch the data itself 😩. The retrieval rate is apt to suffer in that setup. But when SMFS knows where the logical-record boundaries are, the feedback loop is effectively shortened (SMFS being closer to the file), so there's potential for an increased retrieval rate 🔥.
If you want a file to be formatted, you must say so in every update and every retrieve operation that references it 🫠. SMFS never flags a file to show that it's formatted. So if you invoke the option during retrieval without having done so when the file was stored, the results will be erroneous 💀. Also, if an update of a formatted file is terminated before the bit count for the operation is exhausted (like if you closed the connection), the retrieval results will be erroneous again 😭.
V.C. Replace File (RPF) 🌸
RPF is identical to UDF, except that the new file segment doesn't get concatenated to the existing file. It replaces the entire contents of the file 🔄. The previous contents are lost, and the new segment becomes the only segment in the file.
You can use RPF to rewrite an existing file. If the rewritten file is going to contain just a single segment, you can send that segment in one RPF operation. Otherwise, the first segment of the new file must be sent in an RPF operation, and all succeeding segments in UDF operations. Alternatively, you can insert a dummy (bit count of zero) RPF operation before the first real segment is sent, and then send all segments of the file in UDF operations 🧁.
V.D. Retrieve File (RTF) 🦋
The operation that retrieves all or part of a file's contents is called file retrieval (RTF) 📥. You specify the filename, the access password if it's required, and the amount of data in bits you want to fetch. SMFS finds the file on secondary storage, checks the password for validity (if it applies), and copies the bit count and the requested file segment into the output stream 💅. The retrieval is complete when either the requested number of bits has been placed in the output stream, or the contents of the file run out. In that second case, SMFS closes the connection to signal end-of-data to you 🚪.
Successive RTF operations referencing the same file send out successive segments of the file, as long as the operations are juxtaposed in the input stream (but NOP's can be interspersed anywhere in the input stream 🌟). When a series of RTF operations on a particular file gets broken by an operation referencing another file, or by a different type of operation involving the same file, the next RTF designating the original file will send out the first segment of that file again 🙃. How you segment a file for a series of retrieves doesn't need to match the segmentation used when the file was updated, or the segmentation used in previous retrievals 🫶.
If you elected to have your file formatted by SMFS, you should re-invoke the option in the RTF operation. Then SMFS will supply the length of the segment, and place both the length and the segment itself into the output stream 🎀.
V.E. Space File (SPF) 🧚
Files stored with SMFS are sequential in organization. That means the n+1th segment can't be retrieved without first processing the nth segment 🐢. Sometimes you might only want certain segments, though. You could retrieve every segment and flush the ones you're not concerned with, but that causes needless Network traffic 😤. So SMFS gives you a way to flush file segments locally. The operation is called spacing a file (SPF). It's identical to RTF, with the exception that transmission of data (but not bit count) is suppressed 🫧. SPF operations can be freely inserted anywhere within a series of RTF operations designating a particular file, and you'll get the desired results 👑.
V.F. Delete File (DLF) 💀
You can delete a file at any time after allocation. You specify the filename of the file to be deleted and the modification password if required. SMFS finds the file on secondary storage, checks the password for validity (if it applies), and, if the password is correct, deletes the file 🗑. The filename is made available for reassignment, and SMFS reclaims the secondary storage that was allocated to the file. The contents (if any) of the file are lost 😭.
V.G. Rename File (RNF) 🔄
A file stored with SMFS can be renamed at any time after allocation. You specify the current filename of the file to be renamed, the modification password if any, and the proposed new filename. SMFS finds the file on secondary storage, checks the password for validity (if it applies), and makes sure the proposed new filename isn't already assigned to another file. If these requirements are met, the file gets renamed, and all subsequent references to the file must use the newly-assigned filename 🏷️.
RNF is a way to protect a file that has to be rewritten in its entirety against failures in the Net, or in the sending or receiving host 🛡️. Here's the strategy:
- Allocate a new file, assigning it some temporary name.
- Transmit the revised file contents in one more UDF and/or RPF operations.
- Delete the original file, and using RNF, replace the newly-created file's temporary filename with that of the original file.
V.H. File no Operation (FNO) 🎀
FNO is a dummy operation provided for terminating a series of RTF operations. Say you want to retrieve a file's contents twice in succession. You can do that with a series of RTF/SPF operations, followed by an FNO, followed by a second series of RTF/SPF operations 🔁. Each RTF/SPF operation in the first series retrieves or flushes the next segment of the file. The first operation of the second string, since it is the first of a string, retrieves or flushes the first segment of the file (as explained in Section V.D.). The remaining operations in the second string retrieve or flush the 2nd, 3rd, and so on, segments of the file. So the contents of the file get transmitted twice. When FNO terminates such a string of operations, it effectively repositions you to the first segment of the file 🫶.
FNO may appear anywhere within the input stream ✨.
V.I. No Operation (NOP) 😴
This operation is provided solely to help you format the input stream. It gets discarded without further processing whenever it's encountered 🙌. In particular, a NOP embedded in a series of RTF operations does not terminate the string the way FNO does.
VI. Input Stream Format 🎀
The input stream shall consist of a contiguous string of commands to SMFS. A command type is defined for each of the primitive file operations of Section V. Each command has the following general format 🧾:
8 16 32
______________//______//_________//__________//_________________//__
| | | | | | | | |
| OP | | | ACCESS |MODIFICATION| NEW | | |
|CODE|FLAGS|FILENAME|PASSWORD| PASSWORD | FILENAME|BIT COUNT| DATA |The length diagram keeps going like this 🎀
|____|_____|___//___|__//____|____//______|___//____|_________|__//__|okay so the bit lengths of the fixed-length fields are written in bits, and each of FILENAME, ACCESS PASSWORD, MODIFICATION PASSWORD, and NEW FILENAME gets its own little subfields 💅
8 8*LENGTH
________________________//___
| | |
| LENGTH | FILENAME/PASSWORD |
|________|_______________//___|the LENGTH subfield is just the count of 8-bit characters in its FILENAME/PASSWORD buddy ✨
This is the general format for every SMFS command 💖 Not every command type needs all of the fields above, and each type has its own subset. Only those fields SHOULD appear, and Figure 3 shows which fields are defined for each command type 🧚
Not every defined field has to show up explicitly though, and this part is so clever 🦋 Picture SMFS keeping three accumulators, one each for filename, password, and bit count. Whenever a filename (or new filename), an access or modification password, or a bit count appears explicitly in the input stream, SMFS saves it in the matching accumulator. A null password (set by making Bits 0,3 or Bits 8,11 zero, see Figure 4) SHOULD be thought of as appearing explicitly too 🙈 The user MAY make a defined field default to whatever is currently in its accumulator by turning on the matching bit in the FLAGS field (see Figure 4). When a field defaults like that, we say it appears implicitly in the command 💜
Here are the op codes, bestie 👑
NOP 0 No operation.
FNO 1 File no operation.
ALF 2 Allocate file.
UDF 3 Update File.
RPF 4 Replace File.
RTF 5 Retrieve File.
SPF 6 Space File.
DLF 7 Delete File.
RNF 8 Rename File.
Figure 2
Command Op codesThe three accumulators start out empty, so if you try to default a field in the very first command of the input stream, you get an error indication 💀 A field of the right type MUST appear explicitly in the input stream once before its accumulator counts as defined. Also, if SMFS spots an invalid filename or password (wrong length or characters outside the allowed set), that accumulator gets emptied again 🥺
SMFS lets you interleave operations on several files in the same input stream, and each command format has room for spelling out the filename and password every time 🌈 But when a bunch of operations hit the same file back to back, you only need to let the fields default in every command after the first. No re-sending the same parameters over and over, which is so efficient it's giving main character energy 💅✨
M
O
D
I
F
I
A C
C A
C T
E I N
S O E
S N W
B
F P P F I
O I A A I T
P L S S L
F E S S E C
C L N W W N O D
O A A O O A U A
D G M R R M N T
E S E D D E T A
_____________________________________________________________
ALF X X X X X X
_____________________________________________________________
UDF X X X X X X
_____________________________________________________________
RPF X X X X X X
_____________________________________________________________
RTF X X X X X
_____________________________________________________________
SPF X X X X X
_____________________________________________________________
DLF X X X X
_____________________________________________________________
RNF X X X X X
_____________________________________________________________
FNO X
_____________________________________________________________
NOP X
_____________________________________________________________
Figure 3
Defined Command FieldsNote: command fields marked with an 'X' are defined 🍓
Now the FLAGS bits, which are the real secret sauce 🔥
0 ACCESS PASSWORD The access password for this
DEFAULTS operation defaults to the access
or modification password which
appeared explicitly most
recently in the input stream;
hence, it does not appear
explicitly in the current
command.
1 BIT COUNT DEFAULTS The bit count for this operation
defaults to that which appeared
explicitly most recently in the
input stream; hence it does not
appear explicitly in the current
command.
2 FILENAME DEFAULTS The filename for this operation
defaults to the filename or new
filename which appeared explicitly
most recently in the input stream;
hence it does not appear
explicitly in the current command.
3 ACCESS PASSWORD The access password for this
APPEARS EXPLICITLY operation appears explicitly in
the current command. (Bits 0,
3 = 0 indicates that no access
password was/is-to-be defined
for the file.)
4 ECHO OP CODE SMFS SHALL echo the op code and
AND FILENAME filename (whether it appears
explicitly or not) by copying
them into the output stream
ahead of any other response to
the current command.
5-7 undefined Not examined; SHOULD be zeros.
8 MODIFICATION Same as Bit 0, but applied to
PASSWORD DEFAULTS the modification password, rather
than the access password.
Figure 4
Definition of Command FLAGS Bits
9 FILE FORMATTED FOR UDF/RTF: this segment is part
of a formatted file; hence SMFS
SHOULD record the bit count. For
RTF/SPF: the referenced file is
formatted; hence the bit count
does not appear explicitly in the
current command
10 NEW FILENAME same as Bit 2, but applied
DEFAULTS to the new filename, rather
than the filename.
11 MODIFICATION PASSWORD Same as Bit 3, but applied to
APPEARS EXPLICITLY the modification password,
rather than the access
password.
12-15 undefined Not examined; SHOULD be zeros.
Figure 4(continued)
Definition of Command FLAGS BitsQuick note for the bit numbers: the sixteen bits of FLAGS are numbered 0-15 from left to right 🦋
Now the good stuff ✨ When a bunch of RTF/SPF operations on the same file sit next to each other in the input stream (see Section V.D.), SMFS only sends the next segments of the file if both filename and access password default (Bits 0,2 = 1) in those follow-up operations. A null password is fine here too 🫶 If you explicitly type either one in the series, even if it's the same value that would've defaulted, SMFS calls the series over, as if an FNO showed up, and the command in question flushes the first segment of the file 💀 Letting both defaults happen in RTF/SPF and UDF series also makes SMFS work faster, since it does file location and password verification once at the start of the series instead of for every single operation. That means better transmission rates are possible 🚀 And in a series of UDF/RPF operations, SMFS can save secondary storage by gluing file segments together before writing them out 💾
Whenever SMFS aborts a command (say the filename is bad or the password is wrong), it flushes the whole command 😭 Imagine a UDF hitting a file that was never allocated, and its data field is huge. SMFS might notice the file doesn't exist before you've even sent the data. In that case it still accepts and flushes everything left of the aborted command, including that massive data field, until it gets to where the next command starts, and then it processes that one normally 🧚 SMFS will still tell you the command got aborted by dropping an indicator into the output stream, and it does that as soon as it spots the problem, so before the bad command has been flushed. That gives you the option to stop everything by closing the connection 🔥
SMFS treats a command with an invalid op code as an especially severe error 🚨 It has no way to find where the next command starts, so it puts a special character (X'FF') in the output stream, follows it with the invalid op code, and then closes its connections to the user 💀
VII. Output Stream Format 📤
Okay bestie, so SMFS is gonna respond to every command it pulls out of the input stream 💅. That's every command except FNO and NOP, which get no reply 🙈. Each response gets dropped into the output stream as a command response ✨. Every response follows this general shape 🎀:
8 8 32
_________//___________________________//____
| OP | | CMPL | | |
|CODE | FILENAME | CODE |BIT COUNT| DATA |
|_____|___//_____|______|_________|____//____|Those 8s and 32s are the fixed-length fields, measured in bits 🧚.
The FILENAME field is its own little mini-format 🌸. It has two subfields, LENGTH and then FILENAME itself. The LENGTH subfield tells you how many 8-bit characters are in the FILENAME subfield, so it's giving self-describing 💜.
8 8*LENGTH
_______________//______
| | |
| LENGTH | FILENAME |
|________|______//______|This is the general format for SMFS command responses, but ngl, not every field shows up in every response 🙈. Each type of command response gets its own subset of fields, and no other fields will appear. The defined fields for each response type are in Figure 5, so check out that table, it's giving serious main character energy 🦋.
The OP CODE and FILENAME fields are the op code and filename SMFS pulled from the input stream, and SMFS echoes them back out in the output stream 🔁. The filename is always echoed explicitly, even if it was only implied in the input 🫶. But if Bit 4 of the FLAGS field of the corresponding command is set to 0, then OP CODE and FILENAME get suppressed and don't show up in the response at all 👻.
CMPL CODE tells you the outcome of the operation 👑. If the operation succeeded, CMPL CODE holds a value equal to the op code of the command that ran. So if echoing OP CODE isn't suppressed, the operation was successful if and only if OP CODE and CMPL CODE are identical, periodt 💅. If the operation was unsuccessful, CMPL CODE holds the error SMFS ran into while processing the command instead. The completion codes are summarized in Figure 6 💖.
C
O
M
P
L
E
F T B
I I I
O L O T
P E N
C
C N C O D
O A O U A
D M D N T
E E E T A
_____________________________________________________
NOP
_____________________________________________________
FNO
_____________________________________________________
ALF X X X
_____________________________________________________
UDF X X X
_____________________________________________________
RPF X X X
_____________________________________________________
RTF X X X X X
_____________________________________________________
SPF X X X X
_____________________________________________________
DLF X X X
_____________________________________________________
RNF X X X
_____________________________________________________
Figure 5
Defined Command Response FieldsNote: Command response fields marked with an 'X' are defined.
Heads up 😭: an invalid op code in the input stream is its own special type of error 🙈. SMFS builds a special command response for it. That response is X'FF' in an eight-bit field, followed by the erroneous op code, also in an eight-bit field. The command response goes into the output stream, and then the connections to the user get closed 💀.
Here's the full lineup of completion codes in Figure 6, bestie 👑✨:
2 ALLOCATION SUCCESSFUL The file was successfully allocated.
3 UPDATE SUCCESSFUL The file was successfully updated.
4 REPLACE SUCCESSFUL The file was successfully replaced.
5 RETRIEVE SUCCESSFUL The file segment was successfully
retrieved.
6 SPACE SUCCESSFUL The file segment was successfully
flushed.
7 DELETION SUCCESSFUL The file was successfully deleted.
8 RENAME SUCCESSFUL The file was successfully renamed.
20 NO DEFAULT FILENAME The user attempted to default the
filename (or new filename), and the
filename accumulator was empty.
21 ZERO-LENGTH FILENAME The length of the filename (or new
filename) was specified as zero.
22 FILENAME TOO LONG The length of the filename (or new
filename) exceeded 36 characters.
23 INVALID FILENAME The filename (or new filename)
contained character(s) that do not
appear in the character set.
24 NO DEFAULT PASSWORD The user attempted to default either
the access or modification password,
and the password accumulator was empty.
25 ZERO-LENGTH PASSWORD The length of either the access of
modification password was specified as
zero.
Figure 6
Completion Codes 26 PASSWORD TOO LONG The length of either the access or
modification password exceeded 36
characters.
27 NO DEFAULT BIT COUNT The user attempted to default the bit
count, and the bit-count accumulator
was empty.
28 INVALID PASSWORD Either the access or modification
password contained character(s) that do
not appear in the character set.
29 DUPLICATE FILENAME Either the filename (in an ALF
operation) or new filename (in a RNF
operation) is already assigned to
another file.
30 INSUFFICIENT SPACE (In an ALF operation) The requested
amount of secondary storage is
unavailable.
31 ALLOCATION I/O ERROR (In an ALF operation) An irrecoverable
I/O error was encountered by SMFS while
attempting to allocate the file.
32 FILE NOT FOUND The referenced file does not exist.
33 SEARCH I/O ERROR An irrecoverable I/O error was
encountered by SMFS while attempting to
locate the referenced file.
34 FILE FULL (In a UDF/RPF operation) The secondary
storage allocated to the file has been
exhausted.
35 INCORRECT PASSWORD The access or modification password
supplied by the user does not match
that declared when the file was
allocated.
36 FILE SIZE TOO SMALL (In an ALF operation) The bit count
specified is less than the minimum file
size accepted by SMFS.
Figure 6 (continued)
Completion Codes 37 FILE SIZE TOO BIG (In an ALF operation) The bit count
specified exceeded the maximum file
size accepted by SMFS.
38 WRITE I/O ERROR An irrecoverable I/O error as
encountered by SMFS. (In an ALF
operation) SMFS was attempting to
record password information, or (in a
UDF/RPF operation) SMFS as attempting
to add data to the file.
39 READ I/O ERROR An irrecoverable I/O error was
encountered by SMFS attempting to
retrieve either password information or
data.
40 RENAME I/O ERROR An irrecoverable I/O error was
encountered by SMFS while attempting to
rename the file.
41 DELETE I/O ERROR (In a DLF operation) An irrecoverable
I/O error was encountered by SMFS while
attempting to delete the file.
42 END-OF-DATA (In a RTF/SPR operation) The end of the
file was reached before the requested
segment had been transmitted/flushed.
Figure 6 (continued)
Completion Codes [ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Gottfried Janik 2/98 ]📦 where this page comes from
- ietf: rfc122 1971-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms