Multiple reports inside a single file...

[Justin Derrick]

I have a strange situation where a customer is generating a half dozen reports, then concatenating them, and transferring them to CMOD to be loaded.  (This is a migration from FileNet Image Services, which apparently used to support this feature.)

Has anyone managed to load this type of file, and still keep the Application definitions intact?  It appears that the reports all have the same format, so it should be possible to re-use the ACIF defintions -- but I'm not sure how to capture the report name and have it populated in the AppID field, so that it's available to the end user as a pop-up menu in the CMOD client (or via ICN).

Any insight would be greatly appreciated.

-JD.

[Frederick Tybalt]

We had a similar requirement for one of my previous customer, but the report names and count are fixed.

So we captured the report name/ID as one of the index . The report names/IDs are also populated in the Database mapping field so that the report names are listed in the search box and the user can choose the report and do a search.

Hope this helps.

[Justin Derrick]

Interesting.  I'll have to play with this.  I think the snag here is that I get the pop-up field that I want, but it's not ACTUALLY using the Application ID field, just a standard index. 

Thanks Fred!

[ewirtz]

Hi Justin,
if you take the report from the indexes you have a new level in in your architecture: application group, application and report. This is OK but you have to look for possible problems p.e. regarding retention management.

regards

Egon

[Justin Derrick]

This is OK but you have to look for possible problems p.e. regarding retention management.

Yeah, this is my biggest concern.  I know it CAN be done, now the question is...  Should it be done?  I'll report back with the final decision & rationale.

-JD.

[Alessandro Perucchi]

In that case, in order to have a better control of retention management, to choose an expiration type of "Document" instead of "Load" would be better, so you can choose it per document in case in the future something needs to be defined differently...

not optimal, but maybe that's an alternative.

[ewirtz]

Hi Alessandro,
as far as I remeber enhanced retention management needs the configuration on load level. By programm holds and releasing them you can install some processes on document level.
Because of special deletion rules like 10 years counting from the end of the year and different retention periods for different reports in the same application, we have done our own retention management.

regards


Egon

[Alessandro Perucchi]

Hello Erwitz,

I've never talk about ERM, and in that case you are speaking, yes, you are right.

There are many ways to do retention management.

-> Do it yourself
-> Use the standard tools from CMOD (arsmaint + expiration types)
-> ERM + some custom rules

Each has some positive and negative aspects.

I was just telling Justin, one way to use a standard function of CMOD without relying on ERM... because ERM is a paying function, and sometimes it is not needed... sometimes only :-D

Regards,
Alessandro

[Justin Derrick]

Yup, I appreciate any and all input -- I did know about the ERM prerequisite that AGs be configured for load expiration. 

Thanks guys! 

-JD.

[Nolan]

We had a similar issue on Z/OS where batches of reports were being sent via one sysout.   

We used two solutions,
1)  We created a proc to split out the output in to different sysouts.  This was updated in the source JCL's to split out the reports using keys from a sysin (not simple but it worked)
2)  We setup a double pass of OnDemand.  First pass we would archive the whole sysout and index on the report ids, then using ODF distribute back to OnDemand individual reports to be archived using specific keys.   Moving the large sysout to tape right away reduced any extra dasd usage.