 




<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Problem in AS/400 Journal entries</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/problem-in-as400-journal-entries/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/problem-in-as400-journal-entries/</link>
	<description></description>
	<lastBuildDate>Fri, 24 May 2013 19:50:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: tomliotta</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/problem-in-as400-journal-entries/#comment-94015</link>
		<dc:creator>tomliotta</dc:creator>
		<pubDate>Thu, 07 Jul 2011 23:13:07 +0000</pubDate>
		<guid isPermaLink="false">#comment-94015</guid>
		<description><![CDATA[&lt;i&gt;I had Journal Image for *AFTER and the deletion entry in journal was not having record data.&lt;/i&gt;

That&#039;s a difficult position to be in when tracking deletions. The *AFTER image of a deletion is... nothing.

The *AFTER images are useful when doing forward recovery. Restore a file to some past backup point, then apply the *AFTER images from that date/time up to current time.

The *BEFORE images are useful in backwards recovery. Journaled changes can be applied going &lt;i&gt;back in time&lt;/i&gt;. They can also be useful in forensic review such as what you ran into.

Naturally, tracking *BOTH images increases space requirements. Receiver management becomes more intensive.

Tom]]></description>
		<content:encoded><![CDATA[<p><i>I had Journal Image for *AFTER and the deletion entry in journal was not having record data.</i></p>
<p>That&#8217;s a difficult position to be in when tracking deletions. The *AFTER image of a deletion is&#8230; nothing.</p>
<p>The *AFTER images are useful when doing forward recovery. Restore a file to some past backup point, then apply the *AFTER images from that date/time up to current time.</p>
<p>The *BEFORE images are useful in backwards recovery. Journaled changes can be applied going <i>back in time</i>. They can also be useful in forensic review such as what you ran into.</p>
<p>Naturally, tracking *BOTH images increases space requirements. Receiver management becomes more intensive.</p>
<p>Tom</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sim400</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/problem-in-as400-journal-entries/#comment-93953</link>
		<dc:creator>sim400</dc:creator>
		<pubDate>Wed, 06 Jul 2011 02:05:10 +0000</pubDate>
		<guid isPermaLink="false">#comment-93953</guid>
		<description><![CDATA[Thanks Tom.

The info was helpful. I had Journal Image for *AFTER and the deletion entry in journal was not having record data. So I couldn&#039;t identify the entries for those deletions. Again I saw some entries for deletions and I checked those RRNs from Journal with previous update entries in the journal and I got info that who and how the records are deleted.

Thanks, SIM]]></description>
		<content:encoded><![CDATA[<p>Thanks Tom.</p>
<p>The info was helpful. I had Journal Image for *AFTER and the deletion entry in journal was not having record data. So I couldn&#8217;t identify the entries for those deletions. Again I saw some entries for deletions and I checked those RRNs from Journal with previous update entries in the journal and I got info that who and how the records are deleted.</p>
<p>Thanks, SIM</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tomliotta</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/problem-in-as400-journal-entries/#comment-93910</link>
		<dc:creator>tomliotta</dc:creator>
		<pubDate>Tue, 05 Jul 2011 01:36:44 +0000</pubDate>
		<guid isPermaLink="false">#comment-93910</guid>
		<description><![CDATA[First, if the file is journaled and records are actually deleted without a journal entry to mark the event, it&#039;s reason to call IBM for service immediately. Those events simply don&#039;t happen.

More likely some other event is causing an appearance of deletion.

For example, you might have a record that has a primary key of &#039;ABC&#039;. The next day you find that &#039;ABC&#039; is not in the file and that there are no deletion events in the journal. A potential explanation is that some update process was intended to update a record with key &#039;XYZ&#039; but it retrieved &#039;ABC&#039; and wrote over the top of it. The &#039;ABC&#039; record wasn&#039;t deleted -- new data was simply written over it and the &#039;ABC&#039; data was replaced.

There are many possible explanations like that. Essentially all of them will go back to some hidden logic error in an application or to missing controls in ad hoc database access. (Someone with full SQL access can accidentally or purposely change records in confusing ways.

Journaling is the best tool to track nearly all of those issues down. Ensure that the journal records events with IMAGES(*BOTH). Look for any activity at all against the records that disappear, not just &#039;delete&#039; entries.

When you review entries, also be sure to look for any &#039;start journaling&#039; and &#039;end journaling&#039; events. If anything happens when journaling isn&#039;t active, it won&#039;t be recorded. And be sure that all receivers are available for any days in question.

Tom]]></description>
		<content:encoded><![CDATA[<p>First, if the file is journaled and records are actually deleted without a journal entry to mark the event, it&#8217;s reason to call IBM for service immediately. Those events simply don&#8217;t happen.</p>
<p>More likely some other event is causing an appearance of deletion.</p>
<p>For example, you might have a record that has a primary key of &#8216;ABC&#8217;. The next day you find that &#8216;ABC&#8217; is not in the file and that there are no deletion events in the journal. A potential explanation is that some update process was intended to update a record with key &#8216;XYZ&#8217; but it retrieved &#8216;ABC&#8217; and wrote over the top of it. The &#8216;ABC&#8217; record wasn&#8217;t deleted &#8212; new data was simply written over it and the &#8216;ABC&#8217; data was replaced.</p>
<p>There are many possible explanations like that. Essentially all of them will go back to some hidden logic error in an application or to missing controls in ad hoc database access. (Someone with full SQL access can accidentally or purposely change records in confusing ways.</p>
<p>Journaling is the best tool to track nearly all of those issues down. Ensure that the journal records events with IMAGES(*BOTH). Look for any activity at all against the records that disappear, not just &#8216;delete&#8217; entries.</p>
<p>When you review entries, also be sure to look for any &#8216;start journaling&#8217; and &#8216;end journaling&#8217; events. If anything happens when journaling isn&#8217;t active, it won&#8217;t be recorded. And be sure that all receivers are available for any days in question.</p>
<p>Tom</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 6/8 queries in 0.011 seconds using memcached
Object Caching 297/298 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-24 20:33:33 -->