Re: triggers & s36 update pgms

["Jim Franz" <franz400@xxxxxxxxxxxx>]

my files are actually native, and am gradually replacing s36
pgms. Suspect I have a ptf prob. finally got a job log w/detl
 40    05/11/01   08:32:47   QRNXIO         QSYS        *STMT    QRNXIO
   From module . . . . . . . . :   QRNXDBIO
   From procedure  . . . . . . :   _QRNX_DB_SETLL
   Statement . . . . . . . . . :   9
   To module . . . . . . . . . :   QRNXDBIO
   To procedure  . . . . . . . :   _QRNX_DB_SETLL
   Statement . . . . . . . . . :   9
   Message . . . . :   Tried to refer to all or part of an object that no
     exists.
   Cause . . . . . :   The most common cause is that a stored address to
     object is no longer correct because that object was deleted or part
     object was deleted.

calling supportline next
jim

----- Original Message -----
From: "Douglas Handy" <dhandy1@bellsouth.net>
To: <MIDRANGE-L@midrange.com>
Sent: Friday, May 11, 2001 9:45 AM
Subject: Re: triggers & s36 update pgms


> Ken/Jim,
>
> >The S/36 environment works slightly different than most of the 400
> >machines, for example, I'm not sure it recognizes a data base..db2 etc,
> >as most of it's file structures were 'flat' or 'indexed'.
>
> To RPG II programs they are "flat", but to OS/400 they are a bona fide
> externally described file.  It is just the definitions which are somewhat
> lacking.   A sequential file has one "field" consisting of the entire
record.
> An indexed file with the key at either the begining or the end of the
record has
> two fields named something like K00001 and F00001.  If the key is in the
middle
> you get three fields: F00001, K00001, and F00002.
>
> Alternate indexes get extra points for more key fields. <g>
>
> Other than the fact S36EE filenames allow an embedded period, they are
handled
> very much like regular DB2 files.  (And then there are the IDDU
definitions...)
>
> >I doubt also, that you'll find anything that resembles a trigger in the
> >36 arena.
>
> I use triggers on S36EE files all the time.  In fact it is how I did a
major Y2K
> restructing and conversion from S36EE to native.  For the transition
period, I
> set up triggers on the S36EE files which reformatted the data and kept the
> equivalent native file in sync.  Likewise, a trigger on the native side
went the
> other direction so I could have a gradual implementation and phase-out of
the
> old code.
>
> As programs were converted, more and more operations acted on the native
files
> with the triggers keeping the S36EE copy in sync rather than the other way
> around.  When no S36EE programs were left using a given file, the triggers
could
> be removed and no traces of the S36EE heritage were left.   In the
meantime, the
> S36EE applications never knew they were updating two sets of files.
>
> Triggers work just fine against S36EE files.
>
> Doug
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---