20-Mar-89 20:02:32-GMT,3192;000000000005 Return-Path: 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 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