Re: File transaction date

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

I have to disagree that the information is so hard to get at - there are 
utilities from several places to get journal entries into usable form. 
http://systeminetwork.com/node/61261 has an example that might work for 
this. A google on "journal utility iseries" brought up several hits, 
including products like JMT/400 (I know nothing about this one). I 
imagine TAA Tools has something, too.

So there are lots of things out there, in addition to the DSPJRN command 
to an *OUTFILE that could be the beginning of things. You can filter on 
the kind of journal entry in that command, as I recall.

Vern

On 11/26/2010 3:42 AM, dieter.bender@xxxxxxxxxxxx wrote:
> Hi,
>
> the Journal Receiver will contain this information, but its not to easy to
> get it. starting journaling does not touch your applications and would be a
> good idea anyway.
>
> what about adding the timestamp (or something like this), filling it by
> trigger and letting your application work with LFs ommiting this field with
> identical name s to now?
>
> Dieter
>
> --------------------------------------------------
> From: "David FOXWELL"<David.FOXWELL@xxxxxxxxx>
> Sent: Friday, November 26, 2010 9:44 AM
> To: "Midrange Systems Technical Discussion"<midrange-l@xxxxxxxxxxxx>
> Subject: File transaction date
>
> > Hi,
> >
> > I'm currently adding a date field to an old PF which will hold the date
> > that a transaction gets modified. The file has 3 or 4 mentions in
> > different RPG modules that get bound by copy to almost everything. This
> > results in having to recompile pratically the whole system. The job that
> > migrates the file takes about 2.5 hours to run and I need to plan it in
> > advance so noone is using the file when ir runs. In other words, it's a
> > headache.
> >
> > I don't know much about journals/receivers as they aren't used here. But
> > aren't they designed for this kind of information? I'm also thinking of
> > the rollback feature that they permit. I've never used that either. What
> > kind of preparations do we need to think about to be able to switch to
> > this kind of file management?