RE: ALCOBJ shared folder object?

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: david@midrange.com
+---