System call sys$qiow returning "SYSTEM-F-BADPARAM", i.e.. bad parameter value (1300 Views)
Reply
Frequent Advisor
allin-in-one
Posts: 57
Registered: ‎10-21-2012
Message 1 of 19 (1,300 Views)

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

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);

Trusted Contributor
abrsvc
Posts: 367
Registered: ‎06-08-2010
Message 2 of 19 (1,296 Views)

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

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
Frequent Advisor
allin-in-one
Posts: 57
Registered: ‎10-21-2012
Message 3 of 19 (1,293 Views)

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

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

 

Honored Contributor
Steven Schweda
Posts: 9,096
Registered: ‎02-23-2005
Message 4 of 19 (1,285 Views)

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

Trusted Contributor
abrsvc
Posts: 367
Registered: ‎06-08-2010
Message 5 of 19 (1,276 Views)

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

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
Honored Contributor
Richard Brodie_1
Posts: 583
Registered: ‎10-09-2003
Message 6 of 19 (1,262 Views)

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

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.

Honored Contributor
Hein van den Heuvel
Posts: 6,588
Registered: ‎05-19-2003
Message 7 of 19 (1,243 Views)

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

 

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

 

 

Trusted Contributor
John McL
Posts: 280
Registered: ‎02-24-2008
Message 8 of 19 (1,216 Views)

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

Richard, I agree. 

 

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

Honored Contributor
Steven Schweda
Posts: 9,096
Registered: ‎02-23-2005
Message 9 of 19 (1,212 Views)

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

Honored Contributor
Hein van den Heuvel
Posts: 6,588
Registered: ‎05-19-2003
Message 10 of 19 (1,176 Views)

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

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

 

 

 

 

 

Trusted Contributor
abrsvc
Posts: 367
Registered: ‎06-08-2010
Message 11 of 19 (1,168 Views)

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

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

Frequent Advisor
allin-in-one
Posts: 57
Registered: ‎10-21-2012
Message 12 of 19 (1,152 Views)

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

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.

 

Trusted Contributor
abrsvc
Posts: 367
Registered: ‎06-08-2010
Message 13 of 19 (1,147 Views)

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

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
Honored Contributor
Steven Schweda
Posts: 9,096
Registered: ‎02-23-2005
Message 14 of 19 (1,136 Views)

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

Honored Contributor
Steven Schweda
Posts: 9,096
Registered: ‎02-23-2005
Message 15 of 19 (1,111 Views)

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

Trusted Contributor
John McL
Posts: 280
Registered: ‎02-24-2008
Message 16 of 19 (1,109 Views)

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

>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.

 

Respected Contributor
Jur van der Burg
Posts: 198
Registered: ‎09-06-2006
Message 17 of 19 (1,085 Views)

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

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.

 

 
Frequent Advisor
allin-in-one
Posts: 57
Registered: ‎10-21-2012
Message 18 of 19 (1,082 Views)

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

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.

Respected Contributor
Brad McCusker
Posts: 285
Registered: ‎05-01-2003
Message 19 of 19 (1,064 Views)

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

>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

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.