Scott, If the MOVDOC fails, CPF8A13 does not tell you *why* it failed. Is the document file opened? non-existant? Locked by some other process? Damaged? Bleahh. If the application can't tell why the copy failed, there is a potential that the program could loop for eternity. Maybe I need to count the number of 10-second delays that are processed, and exit the loop after a certain number. Dan Bale IT - AS/400 Handleman Company 248-362-4400 Ext. 4952 -------------------------- Original Message -------------------------- Dan, We have an almost identical application, what we do is a MOVDOC to move the file to another folder before we do the CPYFRMPCD. We have a MONMSG on CPF8A13 and IWS1611 on the MOVDOC. For us, this also allows a temporary archival in the folder we move the files to. The archival only works if all file names are unique which ours are, we have a daily purge that removes the old ones. Our processing job runs every ten minutes so any files not moved and processed because they were in use are just picked up the next run. Scott Mildenberger > -----Original Message----- > From: D.BALE@handleman.com [mailto:D.BALE@handleman.com] > Sent: Thursday, January 04, 2001 11:01 AM > To: MIDRANGE-L@midrange.com > Subject: ALCOBJ shared folder object? > > > We had an interesting problem occur. We have a CL pgm that > does a DSPFLR > TYPE(*DOC) to an outfile to get a list of files in the > folder. Then we read > through the outfile and perform a CPYFRMPCD for each file in > the folder. The > problem is that if a file is in the process of being written > to the folder > from the source system, the CPYFRMPCD issues IWS1611 which > can be monitored. > Actually, this particular error generates: > > CPF8A80: Document DBAOSCST.SV in use in folder BALED. > IWS16B8: Error opening document DBAOSCST.SV. > IWS1611: PC document DBAOSCST.SV not copied. > >>Function check. IWS1611 unmonitored........ > > I have modified the application to monitor IWS1611 and delay > and loop back to > the CPYFRMPCD. I would rather monitor CPF8A80, which is a > more specific > error. CPF8A80 is an escape message type, and it would seem > that it should be > monitor-able. IWS1611 sounds like it could be issued for any > number of > reasons. Is it possible to see if CPF8A80 was issued when I > monitor IWS1611? > > Is there a way to allocate the shared folder object aka > ALCOBJ *EXCL? Or at > least a way to tell that the shared folder object is not > otherwise being used > without first having to use CPYFRMPCD to determine this? > > Dan Bale > IT - AS/400 > Handleman Company > 248-362-4400 Ext. 4952 +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: email@example.com +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.