System call sys$qiow returning "SYSTEM-F-BADPARAM", i.e.. bad parameter value

[allin-in-one]

System call sys$qiow returning "SYSTEM-F-BADPARAM", i.e.. bad parameter value.

I am creating file using sys$qiow as below. The return value from function sys$qiow is 1.

Where as the value in the iosb[0] is 20 , i.e. -SYSTEM-F-BADPARAM, bad parameter value.

Please let me know how to find which argument for the function sys$qiow is causing this problem.

I have tried to print values of fib_desc,name_desc,res_desc and atr.

But with the print statements I couldn't find cause of the problem.

Please advise.

stat = sys$qiow(0,            /* Event flag */

                chan,    /* Channel number */

                IO$_CREATE | IO$M_CREATE | IO$M_ACCESS,    /* I/O function */

               (unsigned short *) iosb,   /* I/O status block */

                0,

                0,

                fib_desc,    /* P1 buffer */

                name_desc,       /* file name to create or superceed */

                &rlen,

                res_desc,               /* result found file name */

                atr,            /* file attributes */

                0);

[abrsvc]

Please provide additional information as listed below. There is not enough context here to allow us to answer effectivly.

OpenVMS version and hardware system being used.
Variable definitions for: Fib_desc,name_desc,Res_disc,atr and their values.
Language used for the above program snippet.

Thanks,
Dan

[allin-in-one]

OpenVMS version and hardware system : OpenVMS V8.4 Alpha

Variable definitions for: Fib_desc : file information block

name_desc : Name of the file

Res_disc : If file exists then returned file name ,

atr : File attributes

Values :  atr->cdt[0] : -1953762631,atr->cdt[1] : 11362315,atr->edt[0] :0 ,atr->edt[1]:0, atr->bdt : 2854792,atr->uic :65540 ,atr->pro :40960
 fat->fat_b_rtype: ,fat->fat_b_rattrib:, fat->fat_w_rsize:32767, fat->fat_l_efblk :3 ,fat->fat_w_ffbyte :180
 fat->fat_b_bktsize:
 fat->fat_fill[0]:0,fat->fat_fill[1]:0,fat->fat_fill[2]:0,fat->fill:0,fat->fat_w_verlimit:32767
 fib->fib$r_acctl_overlay.fib$l_acctl :0 

Language used for the above program snippet : C language

[abrsvc]

Sorry about the ambiguous request. For the variable definitions I need to know how they are defined in the language as differing variable types will be passed differently. For example: In FORTRAN, character variables are passed by descriptor where integer and floating variables are passed by reference.


The "values" you posted seem to be the addresses of the variables rather than their values. For example, cdt[0] is lsited as -1953762631 which in hex is 8B8BF2B9. This appears to be a system space address? Can you attach a small C program that shows this problem? I have an Alpha with V8.4 that I can use to provide you with more info.

Thanks,
Dan

[Richard Brodie_1]

If the descs are structure types rather than pointers to them, you need to pass them by reference. Your code could  be right but &foo_desc is probably what you want.

[Hein van den Heuvel]

Steven> I know nothing, but I'd guess that if $QIOW itself is happy

Yes.

Steven >My advice would be to supply a complete test case if you expect anyone else to debug your code.

Yes.

Steven > Are you still trying to set an absurd value for the global buffer count?

Probably... He's just trying to faihfully trying to recreate a file with 'odd' attributes.

Steven> (And you thought that starting a new thread for the same problem
was a good idea?) http://h30499.www3.hp.com/t5/x/x/m-p/6129533

Agreed. Silly

Steven, echoing hein> Why would anyone ever want to creaate a file with SYS$QIO(w) ? .. Info-ZIP UnZip does it.

Right. Fine answer. For the ZIP's and Backup tools like 'allin-in-one' is poking at, it is reasonably

Allin-in-one>> Values :  atr->cdt[0] : -1953762631,atr->cdt[1] :

Ok... so where are you setting the global buffer value? Should be atr->fat$l_gbc32

In the other topic I pointed you to the relevant documentation. 

Btw... RMS also give access to this field in XAB's

Working sample program attached.

$ dele hein.tmp;*
$ mcr sys$login:QIO_CREATE sys$login:hein.tmp 3217014719
$ dir/full sys$login:hein.tmp;

:

File attributes: Allocation: 0, Extend: 0, Global buffer count: 3217014719, No version limit

Enjoy,

Hein

[John McL]

Richard, I agree. 

Most likely the _desc variables are descriptors, in which case the address should be passed to $QIO (e.g.  &name_desc).

[Hein van den Heuvel]

Steven>> Don't mind me. I'm easily annoyed by extremely lame problem descriptions.

We noticed.  :-). I am sure many agreee (me for starters), but see the futility of the fight to educate the ignorant masses.

Steven>> Web search for keywords like, say: qiow io$_create would find some likely-to-work example code.

I attached a a working example in an earlier reply.

My understanding was that mr or mrs allin-in-one ( I'm easily annoyed by lame name's and lack of signatures.) has existing code possibly working for decades. Now that code stumbled into a 'bad file' or rather a file with invalid attributes, the most obvious of which, but probably not the only one,  is a ridicoulous Global Buffer value. Apparently 'ali' does not have the balls to ask the customer why this file is so odd and whether it is useful, or simply tell the end customer that this is a 'gigo' situation. I guess there are support cycles to burn to try create the garbage output.

Anyway, ramblings aside, while my example shows the an odd useless high GBC32 value does not cause a 'badparam' I suspect other bad attributes may cause this. I therefor suggest him/her to go back to a working example, and start adding more and more odd attributes back in untill it breaks. And oh... please do report back!

Cheers,

Hein