07-10-2013 04:59 AM
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 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.
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 */
fib_desc, /* P1 buffer */
name_desc, /* file name to create or superceed */
res_desc, /* result found file name */
atr, /* file attributes */
07-10-2013 05:16 AM
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.
07-10-2013 05:25 AM
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 : -1953762631,atr->cdt : 11362315,atr->edt :0 ,atr->edt: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
Language used for the above program snippet : C language
07-10-2013 06:10 AM
The "values" you posted seem to be the addresses of the variables rather than their values. For example, cdt 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.
07-10-2013 07:28 AM
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.
07-10-2013 08:49 AM
Steven> I know nothing, but I'd guess that if $QIOW itself is happy
Steven >My advice would be to supply a complete test case if you expect anyone else to debug your code.
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
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 : -1953762631,atr->cdt :
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
07-10-2013 10:39 PM
Richard, I agree.
Most likely the _desc variables are descriptors, in which case the address should be passed to $QIO (e.g. &name_desc).
07-11-2013 06:40 AM
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!
07-11-2013 07:21 AM
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.
07-11-2013 08:43 AM
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.
07-11-2013 08:53 AM
If you can create a small reproducer and post it, I will track it down.
07-11-2013 03:03 PM
>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.
07-11-2013 11:58 PM
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).
07-12-2013 12:40 AM
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.
07-12-2013 05:32 AM
>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).