What can cause a journal entry where JOENTT = ‘CR’ (besides CLRPFM)?
Home > IT Answers > AS/400 > What can cause a journal entry where JOENTT =...
NoHandle
0 pts.
0
Q:
What can cause a journal entry where JOENTT = 'CR' (besides CLRPFM)?
RPG
I have a problem with an interactive option that unintentionally clears an entire physical file - only very occasionally but catastrophically when it does happen.

On the last occasion, the file was journalled and indicates the program responsible. The journal entry has type, JOENTT = 'CR'. Nowhere does the program do a CLRPFM. It does do an SQL delete of all records in a renamed & overridden copy of the file in QTEMP. This seems to result normally in a series of journal entries of 'DL', so seems unlikely to be the cause. There are several other SQL operations, e.g. a selective insert from the QTEMP file into the live one. Would there be a problem if something else had locks on the file?

Does anyone have any idea what's going on?
ASKED: May 20 2005  5:12 AM GMT
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
RELATED QUESTIONS
0
TomLiotta
8025 pts.
0
A:
 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0
  • AddThis Social Bookmark Button
I am not familiar with journals so I not sure what CR means, but one thing that comes to mind is to make sure your library list and overides are correct, and if possible qualify your table name in your SQL statement.

Also, it's not clear but is the SQL statement clearing the Qtemp File as well? If not maybe your SQL is referencing the wrong library and clearing the wrong file. I ahve some issues using SQL with library lists and overides, so I now I always remove overides and Qualify my SQL whenever possible.

====================================================

From the V5R4 Info Center: DELETE Performance: An SQL DELETE statement that does not contain a WHERE clause will delete all rows of a table. In this case, the rows may be deleted using either a clear operation (if not running under commitment control) or a change file operation (if running under commitment control).

IIRC, the behavior to use a clear operation was introduced in V5R3.

A CLRPFM may be substituted in place of a series of DELETEs.

As for what's happening in your case, more info is needed.

Tom
Last Answered: Oct 25 2009  11:58 AM GMT by TomLiotta   8025 pts.
Latest Contributors: Lpgast   0 pts.
  •   
0
0
RSS - Discussions Help
Discuss This Answer:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

NoHandle   0 pts.  |   May 20 2005  11:26AM GMT

The SQL delete statement deletes all records in an overridden & renamed version of the file, specifying “QTEMP/”, so it does seem really unlikely that this is what’s clearing the live & un-renamed file. Certainly whenever I’ve looked, the overrides are as intended, but the problem occurs infrequently.

The program also does a couple of SQL deletes of the live data, but these have select statements. Also SQL deletes seem always to show up on the journal as type DL.

There’s also an SQL insert from the QTEMP renamed file to the live one - surely that couldn’t clear the live data?

I just can’t see anything in the program that would clear all of the live data, let alone register on the journal as CR.

 

WaltZ400   535 pts.  |   May 20 2005  12:25PM GMT

A CR journal entry does mean a CLRPFM occurred. But you will get this entry followed by a bunch of PT entries if you do a CPYF with MBROPT(*REPLACE) to the journalled file.

Is there some SQL-type utility you are running that is doing an insert with a replace option to this file?

 

NoHandle   0 pts.  |   May 20 2005  12:53PM GMT

I’m only using ordinary embedded SQL.

The file is created in QTEMP using CRTDUPOBJ, rather than CPYF. And, in any case, that is done by a different program, a CL one, to the one on the journal.

The CR is immediately preceded by 4 CL entries (the file is referred to more than once in the program but I’m not sure why there’s as many as that) and immediately followed by 4 OP entries.

 

TheQuigs   0 pts.  |   May 20 2005  2:53PM GMT

Is the file opened for ‘Output’ by a HLL program? Sometimes opening a file for output will clear it.

Just a thought.

 

Bradskk   0 pts.  |   May 23 2005  8:53AM GMT

I believe that a look at the actual programming would help to find an answer to this. The program identified by the journal as the culprit would be the logical place to start.

 

NoHandle   0 pts.  |   May 23 2005  10:02AM GMT

Don’t think that we haven’t looked at the program!

There’s no obvious culprit - no CLRPFM, no CPYF, etc.

It does the following:
- updates & writes to a renamed & overridden logical over the renamed & overridden physical in QTEMP (RPG),
- does an SQL insert from the live, overridden physical into its renamed & overridden QTEMP copy (target library specified) of selected records,
- does an SQL update of all records in the QTEMP file,
- does an SQL delete of all records in the renamed & overridden QTEMP copy (target library specified),
- does an SQL delete of selected records in the renamed & overridden QTEMP copy (target library specified),
- does an SQL delete of selected records only in the live file,
- inserts (SQL) selected records into the live file from the QTEMP one,
- updates (SQL) selected records in the live file.

The most obvious culprit would be the SQL delete of all records in QTEMP, but this would mean that the override has failed AND the SQL statement is ignoring the hard-coding of the library AND the journal entry is not the usual string of DLs.

Which of the following actions could result in a CR journal entry? Does the journal ever record the wrong program?????

 

fanbot   0 pts.  |   May 24 2005  8:56AM GMT

SQL delete will also issue a CR in the journal entry

 

NoHandle   0 pts.  |   May 25 2005  10:21AM GMT

Do you know under what circumstances an SQL delete results in a CR journal entry? My SQL deletes always seem to give a string of DLs, one for each record.

 
0