|
Hi all, A client of ours installed Cumpack C4077520. After this cumpack, the backup took 12 hours instead of 10 previously. Installing cumpack C4244520 didn't solve the problem. ( I don't know which version of Hipers and DB cumpack are currently installed ) The customer himself already performed following command suggested to him : DSPFD FILE(*ALL/*ALL) TYPE(*MBRLIST) OUTPUT(*OUTFILE) FILEATR(*PF *LF) + OUTFILE(LCOMFIL/FDMBRL) OUTMBR(FDMBRL *REPLACE)) JOB(DSPFDMBRL) JOBQ(QSYSNOMAX) The backup gained 1 hour, still leaving an increase of 1 hour compared with before. In the joblog of the save, I saw following messages ( notice the strange file names ) : CPD3238 Diagnostic 10 QDBCNVFT QSYS 0F4B QDBCRTFI QSYS 0A3C Message . . . . : A new format was created for file Q009 ?=u in *N. Cause . . . . . : File Q009 ?=u in library *N was requested to use format KEMPMVR from file CEMPMVP in library AAFSDATA on ASP 1. However, format KEMPMVR from file CEMPMVP is not available to be used for reason code 4. The reason codes are as follows: 4 - The format was shared and the CCSID value was changed,or multiple logical files shared this format, and their based on physical files were different. CPF3226 Diagnostic 40 QDBCRTFI QSYS 37B4 QDBCNVFI QSYS 04CA Message . . . . : Logical field ETNCCD not found in physical record format CEMPT3R. Cause . . . . . : A logical file field, which was being created, is based on the physical record format CEMPT3R. However, the physical file field referred to by the logical file field is not found in the field level entries in the data description specifications for record format CEMPT3R. Recovery . . . : Change the field name to the name of a field in the based-on physical record format or specify the RENAME keyword. Then try your request again. CPF3205 Diagnostic 40 QDBCRTFI QSYS 34CD QDBCNVFI QSYS 04CA Message . . . . : File not created. Cause . . . . . : Errors occurred while your job was trying to create a file. Recovery . . . : See the previously listed messages. Correct any errors and then try the request again. CPF3162 Escape 30 QDBDUPFI QSYS 03FB QDBCNVFI QSYS 04CA Message . . . . : Cannot create duplicate file Q009 ?=u in QRCL. Cause . . . . . : An error occurred while you were trying to create duplicate file Q009 ?=u in library QRCL from file CWNCH in library AAFSDATA. Recovery . . . : See the previously listed messages. Correct any errors and then try the request again. These messages occurred 72 times for different files. In the QHST log I found a corresponding message : "CPF32A0 20 ESCAPE Database file conversion failure." The increase in backup time, could in my opinion be explained by these conversion errors. I suggested to execute a RCLSTG , which the customer did last weekend. The joblog of the RCLSTG-job showed also following messages for these 72 files : CPF3226, CPF3205, CPF3162 Fo some files, the message CPF32A0 appeared followed by a CPF9999 : "Function check. CPF32A0 unmonitored by QDBRCLMA at statement *N." Only 6 objects where inserted in QRCL The system processed 579447 objects and deleted 1888 of them. The joblogs of the saves after the RCLSTG still showed the same messages as before and took the same amount of time. The DSPFD, DSPFFD, DSPDBR and DSPOBJD looked fine to me. WRKOBJ OBJ(*ALL/Q0*) OBJTYPE(*FILE) didn't showed anything abnormal. I even ran some SQL-statements on the files QADBXREF and QADBFDEP. No luck. I searched any available source , but couldn't find anything relevant for V5R2. Anyone came across something similar ? PS : I don't have direct access to the clients AS400. I need to ask everything by mail Many thanks in advance, Chris __________________________________________________________________ )() ()( __ ____ ____________________. ( _\ ////// / / \ Just another nail \ _\\\\\\\____\______________\_/ in the coffin. \ _\/_ /_ _ |_____/_/ /| ( (_)__)J-) Email : Chris.Spirinckx@xxxxxxxxxx ( /`., / ICQ : 14033396 \/ ; / MSN : Spirre _| === |__________________________________________________________
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.