What can cause a journal entry where JOENTT = ‘CR’ (besides CLRPFM)?

0 pts.
Tags:
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
UPDATED: October 24, 2010  10:58 AM

Answer Wiki

Thanks. We'll let you know when a new response is added.

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

Discuss This Question: 9  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • NoHandle
    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.
    0 pointsBadges:
    report
  • WaltZ400
    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?
    655 pointsBadges:
    report
  • NoHandle
    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.
    0 pointsBadges:
    report
  • TheQuigs
    Is the file opened for 'Output' by a HLL program? Sometimes opening a file for output will clear it. Just a thought.
    0 pointsBadges:
    report
  • Bradskk
    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.
    0 pointsBadges:
    report
  • NoHandle
    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?????
    0 pointsBadges:
    report
  • Fanbot
    SQL delete will also issue a CR in the journal entry
    0 pointsBadges:
    report
  • NoHandle
    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 pointsBadges:
    report
  • TomLiotta
    A CR entry type will be generated with entry code F when a 'clear member' (CLRPFM) is performed. There are no other causes. (A CLRPFM may be substituted by the system under conditions where it is clearly more efficient, such as SQL DELETE with a null WHERE clause.) Without seeing the journal entry and the relevant program code, no one can say anything beyond that. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following