- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- System call sys$qiow returning "SYSTEM-F-BADPARAM"...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2013 04:59 AM
тАО07-10-2013 04:59 AM
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);
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2013 05:16 AM
тАО07-10-2013 05:16 AM
Re: System call sys$qiow returning "SYSTEM-F-BADPARAM", i.e.. bad parameter value
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2013 05:25 AM
тАО07-10-2013 05:25 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2013 05:52 AM
тАО07-10-2013 05:52 AM
Re: System call sys$qiow returning "SYSTEM-F-BADPARAM", i.e.. bad parameter value
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2013 06:10 AM
тАО07-10-2013 06:10 AM
Re: System call sys$qiow returning "SYSTEM-F-BADPARAM", i.e.. bad parameter value
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2013 07:28 AM
тАО07-10-2013 07:28 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2013 08:49 AM
тАО07-10-2013 08:49 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2013 10:39 PM
тАО07-10-2013 10:39 PM
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-10-2013 11:03 PM
тАО07-10-2013 11:03 PM
Re: System call sys$qiow returning "SYSTEM-F-BADPARAM", i.e.. bad parameter value
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-11-2013 06:40 AM
тАО07-11-2013 06:40 AM
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