Re: http_debug append

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

   Hi Sean,
   I did not intend for people to use the debug/trace files in a
   production environment... these were intended, really, as a way to
   provide the details I need when people have problems.  Before adding
   the debug/trace file tools, people would send me messages saying stuff
   like "I got a 500 error" or "The program froze", and I have absolutely
   no way to know what the problem was -- with the debug file, they can
   send me this and I'll have everything I need to know about the HTTP
   conversation.
   It was not intended to be used in production, however.   After you've
   worked the bugs out of your program, I would expect you to simply use
   http_msg() to get an error message.   (Maybe I'm wrong about that, but
   was what I was thinking.)
   Therefore, the need to append an existing debug file never occurred to
   me.  My thinking was that you would, essentially, want a new debug file
   for each time you ran HTTPAPI.
   One way to work around this is to use a debug exit proc.  With this,
   you wouldn't use HTTPAPI's routines for writing to the IFS, instead
   you'd register a subprocedure that HTTPAPI could call any time it
   wanted to write a debug message.  You could then write your own code to
   put the data into a file.  You could therefore have complete control
   over how it writes the messages, when it clears the files, etc, without
   having to make any change to HTTPAPI itself.
   To do this, you would call
        http_xproc( HTTP_POINT_DEBUG: %paddr(YourProcName));
   And your subprocedure would look like this:
   P YourProcName    B
   D                 PI
   D   data                          *   value
   D   Length                      10i 0 value
    /free
       // logic to write log goes here.
    /end-free
   P                 E
   Instead of going to an IFS file, all debugging messages would then be
   passed to that procedure (it's called automatically for each debug
   message, so will be called repeatedly during the transaction.)  You can
   write any logic you want to control which file it goes to, and any
   logic you want to determine when to re-use vs. replace any file.

   On 10/25/2013 3:53 PM, Porterfield, Sean wrote:

Is there currently a mechanism to append to the debug log instead of overwriting
 it every time?

I've been using multiple files to be able to get more detail, but that increases
 my maintenance and still has overwrite problems when I hit the same file name m
ultiple times.

I was just about to try enabling debug once and leaving it on, but I realized th
at won't work in my program.  I have a <shudder> subfile of orders that are bein
g processed, and I want one debug file for each order that is selected.  It's pe
rfectly normal to go back and select the same order again or later for another a
ction, so my current ideas don't leave me a good solution.

I'm calling something like:
BasicHttp_IWorkOrderService_setHttpDebug( *ON: '/tmp/myordernum.txt');

As I trace through, it seems to get back to http_debug( *ON:'/tmp/myordernum.txt
'); which has
callp     unlink(HTTP_DEBUG_FILE)

I think that explains the current overwrite.

I could theoretically modify HTTPAPI to prevent that, but it's not exactly at th
e top of my list of things that would be good to do.

My environment:
OS 7.1 TR 5
WSDL2RPG Ver 1.13.2 released 2011-07-15
HTTPAPI Ver 1.24beta11 released 2010-09-09
--
Sean Porterfield


This email is confidential, intended only for the named recipient(s) above and m
ay contain information that is privileged.  If you have received this message in
 error or are not the named recipient(s), please notify the sender immediately a
nd delete this email message from your computer as any and all unauthorized dist
ribution or use of this message is strictly prohibited.  Thank you.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
[1]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------

References

   1. http://www.scottklement.com/mailman/listinfo/ftpapi

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------