Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!apollo!apollo.hp.com!mishkin From: mishkin@apollo.HP.COM (Nathaniel Mishkin) Newsgroups: comp.sys.apollo Subject: Re: ms_$mapl and fseek/fread Message-ID: <46712455.20b6d@apollo.HP.COM> Date: 25 Oct 89 17:31:00 GMT References: <8910241926.AA14629@umix.cc.umich.edu> Sender: root@apollo.HP.COM Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 31 In article <8910241926.AA14629@umix.cc.umich.edu>, SRFERGU@ERENJ.BITNET (Scott Ferguson) writes: > > Actually, I should have mentioned that I create the file prior to > ms_$mapl by using creat, write, and close. Then I append it by > using ms_$mapl. Therefore, the file is of type 'uasc' and has the > 32-byte header. I guess, though, that the header is different than > it should be still. I think I'll skip this whole thing and go back to > using stdio functions for portability. First, let me make one thing clear: At sr10.0 and later, files of type "nil", or any other "managerless type" (i.e. a type listed by "lty", but with no type manager in "/sys/mgrs" or built in to "/lib/streams") is treated as having the type "unstruct" and can thus be read using stream I/O operations (stdio, read/write, ios_$, etc.). The "unstruct" type is basically just an uninterpreted bag of bytes -- no "header" in the front or other "meta-data" is presumed. At sr9.7 and later, the type "unstruct" is supported. This is the type of file you should create if you want to then access the file via mapping operations. (Note also that at sr10 and later, you can use the bsd mmap calls instead of the ms_$ calls.) In general, unless you really know what you're doing, you don't want to access via mapping other types of files. Note also that if you create a file via the ms_$ calls, its type will be "nil" and at sr10 and later, it can be accessed using stream I/O calls. -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com