derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (09/15/89)
Here's a hopefully basic IOS question someone can address.
I'm creating a REC type file with 4 byte records. Prior
to closing the file, I can check and verify that the records
are 4 bytes. When I reopen the file, the records are 44 bytes.
I assume I'm doing something trivially wrong. A sample
program and its output are shown below.
The file is being created correctly. A DMPF of the
file shows the length field as 8 (includes the 4
byte count field), and I can access the file as
a Pascal FILE OF INTEGER32, for example.
The data retrieved by an ios_$locate appears to have
no bearning on the data actually in the file.
---------PROGRAM-------------------------------------------
#include "/sys/ins/base.ins.c"
#include "/sys/ins/ios.ins.c"
#include "/sys/ins/error.ins.c"
#include "/sys/ins/type_uids.ins.c"
void check_status(status)
status_$t status;
{
if (status.all != status_$ok) {
error_$print(status);
}
}
main()
{
ios_$id_t file0;
status_$t status;
char name[255];
short name_len;
long four = 4;
long current_time = 12345;
char *read_buf;
/* Create record structured file */
strcpy(name, "/user_temp/file0");
name_len = strlen(name);
ios_$create(name, name_len, records_$uid, ios_$recreate_mode, ios_$write_opt, file0, status);
check_status(status);
/* Make fixed length records, 4 bytes per record */
ios_$set_rec_type(file0, ios_$f2, four, status);
check_status(status);
/* Stick in five records */
ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status);
ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status);
ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status);
ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status);
ios_$put(file0, ios_$no_put_get_opts, current_time, four, status); check_status(status);
/* Seek back */
ios_$seek(file0, ios_$absolute, ios_$rec_seek, (long)1, status);
check_status(status);
/* Check length */
printf("next length from ios_inq_cur_rec_len is %d\n", ios_$inq_cur_rec_len(file0, status));
check_status(status);
/* Clost file */
ios_$close(file0, status);
check_status(status);
/* Reopen, again seek to same location, and check length */
file0 = ios_$open("/user_temp/file0", strlen("/user_temp/file0"), ios_$no_open_options, status);
check_status(status);
ios_$seek(file0, ios_$absolute, ios_$rec_seek, (long)1, status);
check_status(status);
printf("next length from ios_inq_cur_rec_len is %d\n", ios_$inq_cur_rec_len(file0, status));
check_status(status);
printf("next length from ios_$locate is %d\n", ios_$locate(file0, ios_$no_put_get_opts, read_buf, (long) 200, status));
check_status(status);
}
---------OUTPUT-------------------------------------------
$ cc demo
No errors, no warnings, C Compiler, Rev 5.50
$ demo.bin
next length from ios_inq_cur_rec_len is 4
next length from ios_inq_cur_rec_len is 44
next length from ios_$locate is 44
-----------------------------------------------------------
Dave Erstad
Principal Design Automation Engineer
Honeywell SSEC
DERSTAD@cim-vax.honeywell.commishkin@apollo.HP.COM (Nathaniel Mishkin) (09/19/89)
In article <8909151401.AA04534@umix.cc.umich.edu> derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") writes: >Here's a hopefully basic IOS question someone can address. >I'm creating a REC type file with 4 byte records. Prior >to closing the file, I can check and verify that the records >are 4 bytes. When I reopen the file, the records are 44 bytes. > >I assume I'm doing something trivially wrong. A sample >program and its output are shown below. The offending line is: > > /* Reopen, again seek to same location, and check length */ > file0 = ios_$open("/user_temp/file0", strlen("/user_temp/file0"), ios_$no_open_options, status); The problem is that "strlen" returns a long and the 2nd param to "ios_$open" is a short. The net effect is that "ios_$open" sees a name length of 0, and opens the current working directory (please don't ask why opening the null string is treated like opening "."). It's all downhill from there. I don't know if it's an option in your case, but in general, I strongly recomment people use the ANSI/C-ized ".h" files ("<apollo/ios.h>" in this case), since they make these sorts of problem go away (or at least use of them results in the compiler telling you what wrong thing you're doing). -- -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com
derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (09/20/89)
Yes, we found the problem with the open call last night. I'm a little surprised that a 0 length file name is legal, though. The .h files, as I'm sure you are aware, aren't an option for those of us who still need to support both SR9 and SR10 systems. I expect I'll be supporting SR9 based code at least into first quarter 90. Then, I'll close my eyes and try to forget I ever knew what a std_$call was :-) Thanks for your help. It's greatly appreciated, although it's unfourtunate the hotline isn't good enough to make these kinds of questions necessary (I was originally told by the support engineer that he was "pretty sure" that a REC type file could do an ios_$f1). Of course, this ios_$open is just a dumb programming bug... I should know better. Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com
derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (09/20/89)
> Files with a 0 length name are a handy way of > having temporary working files ... you don't > have to worry about conflicts with existing > file names, and when you close the file it > just goes away. Ah, but I didn't get a file - I actually opened the directory itself, hence the size of 44 bytes (which is the size of a name_$dir_entry_t, at least at 9.7). It may be that a language open works the way you described, but ios_$open apparently doesn't. Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com