search

OCamlPro / gnucobol

A clone of the sourceforge GnuCOBOL compiler from COBOL to C.
https://get-superbol.com
GNU Lesser General Public License v3.0
16 stars 20 forks source link

Support for JOR files #141

Open lefessan opened 4 months ago

lefessan commented 4 months ago

JOR files are journals of COBOL executions. This commit implements minimalist support for JOR files with the following features:

Currently, the JOR file contains the arguments, the execution start and stop times and per-file statistics of opens, reads, writes, starts and closes operations.

GitMensch commented 4 months ago

What do you think of moving the stats to be only/mostly set on save_status as per Ron's implementation https://github.com/OCamlPro/gnucobol4/commit/4a61f7cab2bb4a3e8f3a5971cb3cd67fc8290775 https://github.com/OCamlPro/gnucobol4/commit/24a3751e47fdec140be50e445a4fb80c3223385d?

What about merging the fileio stats (only active for programs that are compiled with tracing) to GC 3.3 (that would also include https://github.com/OCamlPro/gnucobol4/commit/980d0b41829de8952157c8264ec61d497e504497)?

lefessan commented 4 months ago

The idea behind this PR is to be able to get a minimal trace of the execution, in production mode. This is not possible with standard tracing options that are too expensive. You can imagine a batch failing during the night, people might want to understand what happened exactly during the run, and maybe to preceding steps, without running them again in trace mode. Also, you get information like the time spent, the IO stats, and probably more in the future.

There are maybe other solutions, but I think it's worth investigating this mode.

And yes, there needs to be some program that will translate these binary files into json or something like that...

By the way, I am not really targeting 3.3, ideally, it's something that could land in 4.0 once 3.3 has been released.

GitMensch commented 4 months ago

By the way, I am not really targeting 3.3, ideally, it's something that could land in 4.0 once 3.3 has been released.

Ah, then please edit the PR to have that based on master then. Still, it would be useful to check the review comments, including the question to do it at the same place: savestatus and in 4.x consider to provide the option to disable/enable the file recording by file (using the IO options, see referenced commits).

This is not possible with standard tracing options that are too expensive.

We still can consider to use these as basis -> check for a new trace value "binary" and in this case do the tracing you currently do.

In any case I suggest to write a plan (which includes your binary format), then send that to the developer mailing list for additional input - especially when you target trunk.