20-Mar-89 20:02:32-GMT,3192;000000000005
Return-Path: <BRIAN@uoft02.utoledo.edu>
Received: from uoft02.utoledo.edu ([131.183.1.4]) by watsun.cc.columbia.edu (4.0/SMI-4.0)
	id AA17015; Mon, 20 Mar 89 15:02:23 EST
Message-Id: <8903202002.AA17015@watsun.cc.columbia.edu>
Date: Mon, 20 Mar 89 14:34 EDT
From: Brian Nelson <BRIAN@uoft02.utoledo.edu>
Subject: attributes in kermit-11
To: fdc@watsun.cc.columbia.edu, jrd@usu.bitnet, buda%vmsspt.dec@decwrl.dec.com
X-Vms-To: 
 IN%"fdc@watsun.cc.columbia.edu",IN%"jrd@usu",IN%"buda%vmsspt.dec@decwrl.dec.com"

>Brian, when you put system-dependent parameters into the Kermit-11 file
>attribute packet, what did you do about fitting them in?  I assume that a
>FAB (or whatever it's called) can be longer than a Kermit packet data field.
>Also, I assume it can contain nonprintable characters.  How did you get
>around that?  Unfortunately, the Kermit spec (I plead guilty) says that
>data fields of Attribute packets are not encoded, and most other Kermit
>programs that do Attributes do, indeed, skip the encoding and decoding of
>Attribute packets.  The problem is that if the system-dependent stuff is
>binary, it HAS to be encoded and decoded, but then the other stuff in the
>Attribute packet will be misinterpreted by the receiver if it contains any
>Kermit prefixes like #, &, or ~.  What was your approach?  - Frank

Well, actually it was quite straight forward. The data structure in
question is called an IFAB in RMS-11 terms. This is nothing more than
a copy of the files attribute entry in its directory entry on disk.
What I did was simply to pull out the info from the internal rms structure
and encode the binary info into an octal string, and send that. This assumes
that the receiver must know where to find the data in fixed fields, as in:

 Name .Typ    Size    Prot   Access     Date      Time   Clu  RTS    Pos 
 A     .A         1    < 60> 01-May-84 01-May-84 10:17 AM   4 ...RSX  3493
 RF:VAR=132 FO:SEQ   USED:1:98       RECSI:46       CC:IMP

Results in:

SPACK -   Length   78   Type  A    Paknum    3                       
0001002 000056 000000 000001 000000 000001 000142 000000 000204 000000 000000 


Later, subfields were added to the sys dep packets, for example, sending
date info in rms format. I made no attempt to honor any settings for max
packet size, which perhaps was a mistake, but at the time (like 4 years
ago) it did not seem to be a problem. K11 is capable of processing A
packets while reading D packets, but I feel its a good idea to get all of
the attribute stuff resolved before creating any files, for example, RT11
has no way to extend a file after creation. The appropiate checks are made
for compatible exec's, ie, K11 will reject any sys dependant packets if the
sender is not a PDP11.

Lastly, the beauty of using rms-11's internal ifab is that if one stuffs
that structure with the desired file attributes right before closing the
file, RMS-11 will gladly accept the values and update the directory entry
accordingly.

For vms, this would be more difficult, as one would have to build up all
the xab's needed to describe the file (unless one wants to resort to
the acp qio level, and directly modify the file's directory info).

Brian