Sernet Activity Log and Monthly Reporting Feature

Hi,

This question is related to Sernet Activity Log and Monthly Reporting Feature.

After reading the art S143076/KM000020625, I have the following question or doubt.

I have several instance executing on same LPAR. According to the resolution section, each instance of the started task requires its own ACTLOG dataset.

On the one hand, if I decide to share a single dataset between multiple started tasks, this will produce unpredictable results.

On the other hand, in the same art says the only reason for having multiple procs is to want to direct the report output (SERPRINT DD card) to different datasets.

It seems obvious that I want avoid unpredictable results, I must have multiple procs pointing to different datasets, I mean, if I have six or seven ZMF/ZDD procs, I will need six o seven SERALREP procs to avoid the unpredictable results.

Right up to here?

My question o doubt is the following. Since there is the PARM statement in the proc to specific the ALREPORTPROC startup parm passing parameters to SERNET, couldn't there be an option to pass the subsystem value as PARM?

Of this way, perhaps I would be able to use the same Sernet Activity proc for all instances and to direct the report output (SERPRINT DD) to different datasets serializing the name of these datasets using the subsys value.

Is this coherent?

Thanks

Regards

Manuel

Labels:

Changeman ZMF
  • Verified Answer

    Hi Manuel,

    Your assessment is not quite correct.

    You can share the same JCL proc between multiple tasks, not the same **.ACTLOG dataset. The latter must be unique for each ZMF instance. The appropriate **.ACTLOG dataset name is passed from the ZMF Server started task to the SERALREP procedure via the &PARMS symbolic at time of execution.

    In theory there is no necessity to have a separate **.SERRPTS dataset for each instance as the generated member name is suffixed with the subsystem ID. For example, member #202307W is generated for our W subsystem. If you really want to point to a separate **.SERRPTS dataset then I would think that there may be a customisation that can be achieved in the SERALREP JCL to cater for this. Let us know if that is something you are interested in and/or cannot see a way of handling.

    I hope that I have understood correctly. If I have not then, again, please let us know.

    Best regards,

    Steve

    Steve Nevin

    AMC Support | OpenText Global Technical Support

    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button

  • Please forget this issue.
    I mixed the ACTLOG data set with the library used in the DD SERPRINT of the SERALREP procedure.

    Thank you

    Regards

  • Hi Steve
    One last question.

    Can't some kind of queuing or data loss occur if the SERALREP task is called at the same time by five or six SERNET started task executing on the same LPAR?

    Thanks

  • Suggested Answer

    Hi Manuel,

    No problem – that is absolutely fine.

    Although I have never encountered it personally, I guess that there could be some kind of contention issues on the **.SERRPTS dataset if multiple tasks attempt to update it concurently. However, the *.ACTLOG data for the month should not be removed until this process has successfully completed and the SERALREP procedure should be automatically (re-)submitted when the ZMF Server task is next restarted. So, in theory at least, that should be a non-issue.

    If you (or anyone else seeing this discussion) have any experience and/or evidence to the contrary then please open a case with the Support team and we will be happy to research further.

    Best regards,

    Steve

    Steve Nevin

    AMC Support | OpenText Global Technical Support

    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button

  • Hi Steve,

    Thank you for the clarifications.

    Regards

    Manuel