Newly created IFS document not immediately available for use

[wegrace]

Hello everyone.


We've got an ongoing issue to which I have not been able to find a solution.


We've got a process that executes an sql statement that extracts data into a temp file.

The process then does a CPYTOIMPF to create a csv file on the IFS using the data in the temp file.

When that completes, another command is run to distribute the report to users.

Every so often the IFS csv file cannot be found by the report distribution command.

When I check the timestamp of the IFS csv file, it shows that it was created before the failing command (as shown by the timestamp of the failed command in the joblog).

To address this issue, I added a five second delay before calling the distribution command, and it still fails every so often (ie. no change).


Has anyone seen this sort of behavior before? What is the solution?


Thanks in advance for any insights.

Walt

[EmmanuelW1]

Yes, that seems very odd.

Three things to check: are there any authority failures around the time of the distribution failure? Is the IFS file name a variable in the program, and is it possible the wrong name is somehow being used by the distribution command? Are you up to date on PTFs?

It would be helpful to include the actual error message received by the distribution command.

Cheers,

Emmanuel

[wegrace]

Emmanuel,


Thank you for taking the time to respond.


There were no authority failures; this process runs numerous times throughout the day using the same authority and only occasionally has this issue.

Yes, the IFS file name is a variable in the program, and the same variable is used to both create the IFS file and also used with the distribution command.

I can re-process the distribution command after the failure, and it finds the file and distributes it correctly.

All PTFs are current.

We use Catapult software to distribute reports, and the error that it reports is "Message: 06:00:08:6683: Error: Network file load failed. Message: Could not find file <filename>"


As stated above, upon re-processing the distribution command, the file is sent to the user(s) as was originally intended.


The issue, as I see it, is that the IFS file is not immediately available for use, and I don't know why.

Thanks again.

Walt

[Terry Wincheste]

We used to have a similar problem using IBM's InfoPrint server process to convert spooled PRTF's to PDF documents in the IFS....ended up adding a DLYJOB for @15 seconds to allow the system to capture the closing of the IFS file. Never figured out why it happened but always suspected that it was related to the file closure processes in the IFS area...being slower to react than the standard DB2 actions related to QSYS.LIB.

[jtaylor___]

Could it be a locking issue, where the CPYTOIMPF hasn't turned loose of the file? What's the exact msg ID?

[Scott Klement]

There isn't a lot of information here, aside from "it didn't work" and "it didn't work 5 seconds later".

I think everyone is guessing that it is a timing issue, i.e. the file is created, but the CPYTOIMPF command is still writing data to it, and then your Catapult software (which I'm unframiliar with) runs, it therefore cannot send it.

Maybe it makes sense to write a program that sits and waits until the file is no longer in use? Then you could code CPYTOIMPT, Call the Sit-and-Wait-Program, Call the-Catapult-Program and you'd be good to go. The other thing you should consider is talking to whomever writes/supports the Catapult software and see if they know about this problem and can offer suggestions.

[EmmanuelW1]

From the help text of the CPYTOIMPF command:

If the from-file has the SHARE(*YES) attribute, unpredictable
results can occur. Therefore, if the from-file is defined with
SHARE(*YES), the user should make sure the file is not opened by
any process prior to the copy.

Is that a possible issue in this case?

Cheers,

Emmanuel

[wegrace]

Thank you everyone for taking the time to help me.

As an additional note, all of these program statements are in one CL and they execute/complete before continuing to the next one. The CL does not submit jobs nor does it fork threads.


@jTaylor I didn't think that it was a locking issue related to the CPYTOIMPF command because it completes successfully before executing the next command in the CL. My assumption of course is that CPYTOIMPF is completely done doing its thing when it returns control to the CL.


@Scott Yes, I believe it is a timing issue also, but I made the assumption (incorrectly?) that the IFS file was ready to be used once command CPYTOIMPF returned control to the CL. I like the idea of writing a sit-and-wait program to monitor this. I will definitely reach out to Catapult to see if they have seen this issue before.


@Emmanuel These are temporary extract tables that get created in qtemp on the fly using the sql 'create table' statement. I just executed one of the reporting sql statements to verify how the table is created, and it is created with SHARE(*NO)


@Terry I believe we are experiencing that same issue, so I will increase our delay to 15 seconds as well, unless someone chimes in with more insight on the IFS file creation piece


Thanks again everyone.

Walt