At 12:17 PM 1/16/2002 +0100, Nico.Baggus@mail.ing.nl wrote: >> Try (assuming your file is named foo.dat): >> >> $ set file foo.dat/attributes=rfm:stmlf >> > >This may actually make thing WORSE...... >please try to Convert files which will keep the implied CC (carriage Control) >as close as possibleconvert from Fixed with Impled CC -> Stream LF will insert >linefeeds >f.e. > >the set file will just set the bits in the header. Yes, but I think it also tells the stat() function to work harder to find out the file size and the number it comes up with turns out to be the same as the number of bytes that will be transmitted when you send the file as a stream of data through a socket. BTW, if doing a binary ftp transfer to a Windows box, I think you'd want stmcr instead of stmlf, though I get easily confused about the line ending characters on all the different platforms. >to be considered are the Record Format (rfm:) >and the implied CC .... > >Stream formats will allways give the currect filesize in stat() >Fixed 512, without implied CC will give the actual size in stat() (allways) >Fixed 512, with implied CC is 514 bytes / record. OK, but remember the problem is not to determine the actual size of the file from a VMS perspective but rather the perceived size that a remote machine will see on the receiving end of a file transfer. >These are easy, now the variable record sizes.... > >There are: >VAR, 2 bytes at start of record, all odd records are aligned by adding a '\0' >byte at the end >(not counted in the record length), record with length -1 = EOF record. >PFC, Print file control: 4 byte record header, same alignement as above. The >first 2 bytes the content size > one byte for specifying the # of linefeed before the line etc one byte >giving the number of lines to skip after > the line. >VFC, Like PFC but now contains a word (2 bytes telling how large the extra data >is) this data is on disk with every record > but will not be visible when typing the file etc. >UDF, user defined what you want it to be > >Then there are the Index Sequential Files, the records are stored in buckets >(just like oracle DB files) with >B+ trees on indexes tells where every is left in the file. > >The size of a file for VMS is the size as occupied on disk, expressed in blocks, >rounded up to the clustersize. >The First Free Byte gives the EOF position where new data can be allocated. (if >needed by growing the file....) > >I hope this helped a little >regards, >Nico Baggus Excellent summary. I'll keep this in mind if I ever have to calculate the size for one of the stranger types.Thread Previous | Thread Next