In one of my MICS complexes, when I run private queries and specify the 'hold query output', I see in my joblog that it uses my personal userid.prefix.UER.DTF.INDEX datasets.

After reviewing the output in my BSTAGE catalog, I try to delete the output and get the error message below.

This error is pointing to the Product Shared DTF.INDEX datasets, not my private one.

Data Set Error
An error occurred while attempting to update the shared CSV directory data set. Either the data set was not cataloged or your user ID does not have the required authority to update this data set. The message displayed with this panel indicates the specific problem encountered. The error was encountered while attempting to update the shared CSV directory data set with information about your CSV files. This process makes your files known and available to the CSV download application. CSV directory DSNAME: MIC00F.MIC6.DTF.INDEX Press ENTER to bypass the CSV directory update.

Release:
Component: MICS

Examined the customer's user tables and only the members ICFINQA1 and ISPERROR are corrupted in the table dataset, not even IBM's table utility can open it. ICFINQAn members are just "temporary" tables used when editing an inquiry; the real inquiries are stored in [email protected]* members.

Suggested backing up the original table dataset, then removing the ICFINQA* members and then try to edit the inquiry in MICF again, all of which resolved the problem. MICF query is working again.

When a batch inquiry is executed which contains a CSV, the sharedprefix.DTF.INDEX is updated together with the user DTF.INDEX. So, if the dataset sharedprefix.DTF.INDEX doesn't exist, you also get the error when attempting to delete an inquiry output.

If you don't want to use the sharedprefix.DTF.INDEX dataset, you can set, on panel 5.0.2 "Global Parameters for ISPF Applications", the option "Update shared DTF index" to NO, and then batch inquiry execution and BSTAGE catalog deletion will completely ignore the sharedprefix.DTF.INDEX dataset.