SRFERGU@ERENJ.BITNET (Scott Ferguson) (10/24/89)
I am using ms_$mapl to create a giant file (a collation of 300-800 image files, each approximately 512x320 in size, two bytes per pixel) for later tomographic inversion (CT-scan stuff). Now, like a smartass, I want to read the file using standard fseek and fread calls. I want to do this because we have an Ardent on the network which does blinding FFT's and has NFS. When I do fseek, I get "no problem" back from the OS, but fread returns a value of 0 bytes read. Then, I call perror to get the file error, and it gives me a zero error also. SO, there's no error condition, but I didn't get any bytes. Is what I'm trying feasible, or do I have to create the file with stdio calls in order to read it back? Thanks in advance, Scott Ferguson ferguson@erenj.bitnet Exxon Research & Engineering Annandale, NJ 08801 (201) 730-2339
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (10/24/89)
The MS calls will create a file with a type-UID of "NIL". The Unix system I/O calls all use the stream I/O system, ie. files with types of UASC, UNSTRUCT, REC, etc. They can't read a NIL file because they don't know how to extract the data from the file (does the file have a header? does it have a record structure? etc.). What you probably want to do is to use either IOS_$CREATE or one of the Unix calls to create an UNSTRUCT file, (which is a stream I/O system file which has neither a header nor a record structure embedded in the file) close the file, and then re-open it with MS_$MAPL or with the Unix mapped-segment calls. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
SRFERGU@ERENJ.BITNET (Scott Ferguson) (10/25/89)
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. Scott
mishkin@apollo.HP.COM (Nathaniel Mishkin) (10/26/89)
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
lampi@pnet02.gryphon.com (Michael Lampi) (10/26/89)
The problem with trying to read a file created via ms_$mapl calls using fseek
and fread calls is that the file type is 'nil', and the streams manager/IOS
doesn't know quite what to do with the fseek or fread call. I suggest that you
either create the file with stdio calls or re-implement fseek/fread so they
can read both nil and 'normal' filetypes. (This is not as hard as it seems on
Apollo systems, since you can layer calls atop the system libraries and call
a user-written routine that decides whether or not to call the system routine.
See the -INLIB option switch of the binder for further info, or give me a
call.)
Michael Lampi
MDL Corporation (213) 782-7888
UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!lampi
INET: lampi@pnet02.gryphon.com