Re: More CPYFRMIMPF question - Monitor for bad path...

Hello Richard,

You wrote:
>So, I guess my real question is:
>is there an equivelent to CHKOBJ for a file in the IFS?

Yes.  It's an API called access and it's described in the Unix API manual.

However, CPYFRMIMPF is supposed to send CPF2817 when a failure occurs.
That message has a CHAR(7) subsitution value which will contain the
message ID of the diagnostic message which indicates the real problem.
You can either use the message ID in the substitution data or issue a
RCVMSG for the message prior to the escape message to determine the
problem.

Or at least that's is how it is supposed to work!  But as you've
discovered (and I see on my 440 system) it is broken.  Read on ...

>If I enter an invalid path, and look at my job log, the following
>messages are gen'd:

>Ownership of object QCPIMTEMPS in QTEMP type *USRSPC changed.
>Ownership of object QACPTEMP01 in QTEMP type *USRSPC changed.
>Member MYFILE file MYFILE in MYLIB cleared.
>File QACP296636 created in library QRECOVERY.
>Member QACP296636 added to file QACP296636 in QRECOVERY.
>File QACP296636 in library QRECOVERY was created.

The above stuff is indicating that a copy of the file was created so the
command can recover in case of errors.  Oops, it cleared the target file
before it copied it to QRECOVERY.  APAR!

>Object not found.

This is the error that indicates the stream file was not found.

>Ownership of object FRCP296636 in QRECOVERY type *USRSPC changed.
>Ownership of object TOCP296636 in BAIRDR type *USRSPC changed.
>0 records copied from member QACP296636.

Yeah, thanks!  There was data in that fiel before the command cleared it.
See above. APAR!

>Object QACP296636 in QRECOVERY type *FILE deleted.
>File QACP296636 in library QRECOVERY was created.

Cleaning up ...

>So, it looks like it doesn't care if the file exists in the specified
>FRMSTMF path.  it clears the destination file (if *replace is spec'd) and
>copys zero records.

The copy of zero records is the flawed recovery code.  APAR!

>I also tried to monitor for 'Object not found' (CPFA0A9) but it is a
>diagnostic, not an escape message.

Exactly.  See above for how this is supposed to work.  It should be
verifying ALL parameters before it starts the copy.  Losing your data due
to a missing file is inexcusable!

>you would think an invalid path would make the command bomb, whouldn't
>you?

It does.  Just not how it should bomb. APAR!

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------