|
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 / \ --------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.