Added Joblog monitoring function

[hisham-sid]

Added new data source, job logs, which can be polled at user intervals. Also cleaned up some CRLF/LF line endings

[hisham-sid]

Remnant of testing phase, where job was specified. Needs to be modified to return current job

[ThePrez]

Apart from user experience, what benefits does this approach have compared to the existing WCH support?

[ThePrez]

Apart from user experience, what benefits does this approach have compared to the existing WCH support?

Adding on to this question, the watch support allows for wildcarding by the use of *ALL. For instance, one can do WCHJOB(MYJOBNAME/*ALL/*ALL).
This is an important feature.

In today's usage of Manzan, it would be quite rare that an admin would know the exact job qualifier of a job. However, it would be quite common for them to know the job name of interest. So, this feature would be much more useful if the jobs could allow for specification of the job name alone (dynamically detect if no / is provided on input and assume it to mean a fully qualified job name). And since the existing watch functionality supports this, it would be good to have here as well, if we ship this feature. Knowledge of a specific job identifier will, however, be more useful in a future where this stuff is driven by AI.

[ThePrez]

Apart from user experience, what benefits does this approach have compared to the existing WCH support?

Adding some possible answers to this question I can think of:

• This approach will not require *SERVICE special authority (which I think will be a big deal at some point)
• This approach also enables use of the QIBM_ACCESS_ALLOBJ_JOBLOG function usage identifier
• Overall easier to use, as the existing watch-based stuff requires some knowledge of STRWCH

Meanwhile, advantages of the existing support:

• closer to real-time action
• can get final messages of jobs before they end (whereas the SQL approach might miss a few messages once the job ends)

In any event, the doc should be clear that some data may be harvested with multiple approaches and explain some of the cases where one may be more beneficial than the other.

Overall, I like the feature and like that you're coming up with new uses !

[hisham-sid]

Thanks for the detailed insight! Yes, I did come up with this implementation mainly keeping ease of use for the user in mind, without having to deal with managing STRWCH sessions. But knowing the job qualifier fully is a current limitation, I'll definitely be looking into having the job name dynamic search be a part of this feature, and that will allow an easier entry into the feature itself.
I'll update the documentation to reflect this discussion, thanks again!