Is there a LOG-ENTRY-TYPE to make an AppServer agent redirec

The logentrytypes have nothing to do with where the output goes, only what information is output.  And if you're using System.Console.WriteLine from the ABL, this has nothing to do with the standard logging mechanism.  Or is that your point - that it should?

But you say that this works from an batch ABL client.  Really? Where does the output go?  I cannot get it to go anywhere.  I don't see it in the command shell. OUTPUT TO in the code doesn't do it, nor does using -clientlog.  

Hi Laura, just run the following scratch.p in bach mode this way from a proenv

 /* scratch.p */

MESSAGE "poney alert-box message"  VIEW-AS ALERT-BOX.

System.Console:WriteLine("poney Standard output WriteLine()").

System.Console:Error:WriteLine("poney Error output WriteLine()").

pro -b -p scratch.p

 or

prowin32 -b -p scratch.p >stsout.log 2>errorout.log

Now, to answer your first point, yes I believe we might need a new log-manager entry-type to handle the standard-output and the error-output so there would be a way to catch this type of info in an AppServer  (for example)

.Net also allows a lot a things with log4net, but it would be good to behave well with the standard output and error output.  Practically, we had issues recently with some .Net code invoked directly from the ABL, for both interactive sessions, or AppServers .  In case of problem, that code was doing a standard .Net ShowMessage, that was blocking an AppServer without anything in its log (at startup time, it keeps the agent in STARTING state for ever, and an ABL client trying to connect to it never hits a timeout).  So we were looking for a smarter way to message something to some log, then I found this issue with System.Console:WriteLine()

Ah, I see.  Though again, logentrytypes is not meant to control where output goes, just what is output.  This would have to be done a different way.  

And of course, there are other ways to write to a file, e.g., OUTPUT TO or since you're using .NET, use a System.IO.StreamWriter, etc.  Or to avoid having to have an object instance, you can use the static method:  System.IO.File.WriteAllText("C:\TestFolder\WriteText.txt", text);  This will open the file, write and close the file.

Sandra, my point is not to alter where the standard output and the error output go.  The idea is to provide one or two new log-entry-type(s) so the LOG-MANAGER can intercept and log what is going to these two outputs in order to keep one single powerful ABL log..  In other words, we want to avoid yet-another-log that you seem to suggest (people can also use log4net...)

I believe it might be possible to do that (I recall the Actional days with interceptors...)

Sandra?

I wasn't suggesting that this is a bad idea.  I was just giving you work-arounds for now.  

Ooops, sorry Laura.  Thank you for your posts.  So to summary he situation, at the time of writing, there is no log-entry-type yet to intercept the process standard output and error output.   I can consider this thread as answered

I should enter a new product idea to achieve it.  It can be very useful to trouble shoot issues with .Net code invoked from the ABL in both interactive sessions and AppServer sessions  (for batch sessions, we can redirect these output to log files, but this is not as handy as a unified log-manager log).

At last, in C#, it is possible to intercept Console output:

https://stackoverflow.com/questions/6024172/is-it-possible-to-intercept-console-output

Though you can already log anything you want to the current log file via a MESSAGE statement using the 4GLMessages entry type.  So I’m not sure why you need to use .Net methods to try and write log messages.  Don’t know why I didn’t say this in the first place!

Laura, I am not looking for yet another way to issue a message in an ABL log.  We develop some .Net stuff that can be used *outisde* of the ABL world (at least when we test it in stand-alone mode, or when the ABL is not yet in the picture, or in some other cases...)

Now, when something goes wrong with that .Net code in an ABL process, we would like to see those logs.  So far, we can manage to redirect the standard output for a simple ABL batch process, but NOT for an AppServer, hence the request.

On Friday, I entered a new Enhancement Request asking for a new log-entry-type to intercept the standard output and the error output.  Perhaps we should also extend it to support standard logging mechanisms like log4net.  The idea is to keep on single central smart log file (with variable config, rotation etc...) as opposed to deal painful multiple logs to configure, gather, correlate etc... (when you're happy to know about there existence)

Does this make more sense to you now?

That all being said, I like the ability of being able to send a message to the Error output with System.Console:Error:WriteLine()  so a script that calls an ABL process has now the ability to get some details when something fails.  In that case, we should quit an ABL session by calling the Environment.Exit(<intExitCode>) .Net method (I have not tested for an AppServer), that leads me to that missing bit I have been struggling for ages with the ABL: the ability to provide an optional exitCode for the native QUIT Statement.

Yes, it makes sense.  Though not sure how many people it would be useful for.  Others can chime in on that.

You now CAN provide an optional exit code via the ABL.  We added that in 11.7.3.  You can set the exit code via SESSION:EXIT-CODE and then when you QUIT, that is the code that will be returned from the process.

I follow Sebastians argumentation. I think it would make lot's of sense. But simple System.Console.WriteLine and log4net.

Laura, at the beginning, OO and .Net invocation from the ABL was introduced to support WinForms (in OE10 it was limited to GUI clients and the support for .Net in Headless AppServers came in OE11).  On our side, we have not adopted WinForms but WPF with MVVM (we develop our own DLL's and use them from the ABL).

As things go, I tend to believe the main advantage of mixing the ABL and .Net goes beyond technical and the support a modern UI : keep developers in our dev teams.  So everything that helps that mix is actually pretty strategic.

I'm very glad the SESSION:EXIT-CODE was introduced in 11.7.3