Re: triggers & s36 update pgms

[ken shields <kjs@xxxxxxxxxxx>]

Jim
    You are absolutely right.
    There are two worlds of existence on the 400 for S/36, one as a client ,
which basically runs identical machine code to the old 36 system, then there is
the co-existance model, which works in tandem with the 400..
    I was referring to the client type setup, the objects of which will not run
on the 400. The only real interraction is thru some utilities like 'RUN400' etc 
,
which allows
for things like file transfers...and on.
    I'm sure that the native machine, which runs 400 machine code, can do all 
the
hoops.
    Here's a common problem , especially with work files, that often assumes the
existence or non existence of files.
    In one example, a procedure writes a work file, assuming that , on the last
pass the procedure ended normally, and deleted all it's work files.
    In fact, some other operation interferred with it, or whatever ; and the
procedure aborted, the operator logged the abend, and went home at 5.
    Your job then runs, and tries unsucessfully, to write an identically named
file.
     Result: job aborts....
    Examine the flow of the problem CL, and see if you can't find something 
which
might (other side of the coin), delete the named file when you don't want it to.
Just a suggestion
If there are 'triggers' on the S/36 guest machine, I guess I have never used 
them
or
 found a need for them.
Ken

Jim Franz wrote:

> 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
> +---

--
Best Regards
Ken Shields
Home phone: 905 404-2062
Bus  phone  905 725-1144 (326)


+---
| 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
+---