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

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.