|
<Hans> 1) For the ON-ERROR clauses, identify specifically the exceptions you're looking for. That way, unexpected errors don't fall through. (You can always add a catch-all ON-ERROR at the end of the MONITOR group to catch the genuinely unexpected exceptions.) 2) For the second MONITOR group, since you're specifically watching for a failure of "qtmhRdStin", just that call should be wrapped in the MONITOR group. (Note that an exception on creating the user space will also yield the message "Error reading Standard Input".) </Hans> I think the first MONITOR will work just fine. If _anything_ goes wrong in getting the content length then I want to set contentLength to 0. I have changed it to also direct an error message to Standard Ouput. On the second - I was doing that because the whole sub proc is related to reading from standard input, so if any of it failed then I wanted to relay that message. I guess I could put the MONITOR around the whole sub proc then, but it seems to fit where it is. I have added the name of the sub proc where the error occurred so it is easier to know where errors are thrown from. >3) On the subject of checking the success of the call to "qtmhRdStin", shouldn't you be checking "ErrorDs"? Yep, I will change that. >4) All of the 9B0 variables should really be 10I0. (There's really no good reason any more for using binary decimal variables.) I ran into some problems when I used 10I0 vs 9B0 so that is why I am cautious of using 10I0. I definitely like 10I0 much better. This may be a wives tale, but I heard that if an API uses 4B0 it should convert to 5I0 and if it uses 9B0 it should convert to 10I0. Is this true or can I use 10I0 for everything in relation to 9B0 and 4B0? >5) Hmmm, I know this is unlikely, but after the "qtmhRdStin", what if "bytesRead" does not have the same value as "contentLength"? I knew somebody would ask this:-) In my earlier testing I was getting "bytesRead" sometimes and sometimes not - and the times that I didn't get "bytesRead" back it still read in from standard input successfully. I am pretty sure it was with the "qtmhRdStin" api that I was having this problem, but it may have been the "qzbhCgiParse" api. It might have been because I was using pointers incorrectly and now that mess is cleaned up:-) I ran it through debug a couple times now and I am getting "bytesRead" every time. . . Latest version: http://mowyourlawn.com/temp/CGI_readToFile.txt Aaron Bartell
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.