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

[abrsvc]

I believe that the root problem is that the parameters are passed incorrectly.  In Hein's example the name_desc is listed as follows: &name_desc.  In the initially posted snippet, the same parameter is passed as: name_desc.  Please note the lack of the & character in the parameter definition.  The & indicates to pass the argument by reference.  In other words, the adderss of name_desc is passed to the QIO rather than the value of name_desc. Using this as an example, I suspect that one or more of the variables passed to the QIO should have been an address rather than a value.

I would check that first.

Dan

[allin-in-one]

Have ever heard about the product called "all-in-one" or "file cabinet server" on the OpenVMS ?  What is your experience in OpenVMS ?  for your information GBC (Global buffer count ) is not the variable causing the file creation error.

Can you answer me when IOSB ( one of the argument to sys$qiow )will return SYSTEM-F-BADPARAM ?

I think it is simple and straight forward question those who are familiar with OpenVMS.

[abrsvc]

A QIO will return that value when the passed parameter is invalid. Depending upon the recipient of the IO request, parameters are checked in different ways. Without knowing which of the parameters is causing the problem, I can't provide more details.


If you can create a small reproducer and post it, I will track it down.

Dan

[John McL]

>Have ever heard about the product called "all-in-one" or "file cabinet server" on the OpenVMS ?  What is your experience >in OpenVMS ?  for your information GBC (Global buffer count ) is not the variable causing the file creation error.

Yes, it was an office automation package that dates from the late 1970s.  So what?

> Can you answer me when IOSB ( one of the argument to sys$qiow )will return SYSTEM-F-BADPARAM ?

As you have been told, it is when a parameter is acceptable to the $QIO routine but not to something it calls.  As you have been told, those _desc variables probably should be &xxx_desc because an address muct be passed.  (We cannot be certain because despite repeated requested you have still not posted your code or an extract from it that shows the definition of the variables, how they are set and how they are used in the call. 

> I think it is simple and straight forward question those who are familiar with OpenVMS.

Many of us are very familiar with VMS, we are not however clairvoyant.  We cannot see what your code is doing because and you haven't posted it.

[Jur van der Burg]

Your parameters look bad, just what the return status says. fib_desc, name_desc, res_desc and atr need addresses of descriptors so they all need to have an & in front of them (unless they are pointers already), but given the naming and normal practices it is unlikely. Posting the real code would help.

And make sure that rlen is declared as a word (short) and not an int to prevent surprises.

And what about this:

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

That should be the pointer to a quadword. If it's declared as unsigned short then the 3 words that follow it will be overwritten with possible nasty surpirses.

From the doc:

The following are the device- or function-dependent arguments for IO$_ACCESS:

    P1--The address of the file information block (FIB) descriptor.
    P2--The address of the file name string descriptor (optional).
    P3--The address of the word that is to receive the length of the resultant file name string (optional).
    P4--The address of a descriptor for a buffer that is to receive the resultant file name string (optional).
    P5--The address of a list of attribute descriptors (optional).

Fwiw,

Jur.

[allin-in-one]

Thank you all for help.

The problem is in  P1--The address of the file information block (FIB) descriptor. Where variable "fib->fib$w_verlimit" is greater than 32767.

Once again Thank you.

[Brad McCusker]

>What is your experience in OpenVMS ?

Wow.  Someone comes to this forum asking for help and then starts to question the qualifications of those trying to provide that help?  I find that behavior to be obnoxiously arrogant.

For your information Mr/s. All-in-One, at least three of the people trying to help you in this very thread are known to me to have their names in the code found on the OpenVMS Masterpack.   That's right, the folks trying to help you here are the people who have written or maintained OpenVMS itself.  Don't worry about the quaifications of the folks trying to help here, you are getting some of the best OpenVMS consulting available on the planet right here in this forum (for free).

Brad McCusker