×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
And
another thing. I can show you a pointer based trigger program in ILE which only
takes a few lines. Try doing that with RPG III.
F* FILE
SPECIFICATIONS
F*****************************************************************
F* Inventory Transaction Image
file
FINVL9101 IF
E K
DISK
F* Inventory Transaction header
ile
FETSP960J O A
E K
DISK
F*
F/EJECT
D*****************************************************************
D* Data
structures
D*****************************************************************
D
ptr
s
*
D
arr
s
1 dim(32767)
based(ptr)
D Parm1
ds
32767
D
FileName
1
10
D
FileLibr
11 20
D
FileMbr
21
30
D
TrEvent
31
31
D
TrTime
32
32
D
CommLck
33
33
D
Reserve
34 36
D
CCSID
37 40B 0
D
Reserve2
41 48
D
OffsOld
49 52B 0
D
LenOld
53 56B 0
D
OnOff
57 60B 0
D
OnLen
61 64B 0
D
newoff
65 68B 0
D
LenNew
69 72B 0
D
NNoff
73 76B 0
D
NNLen
77 80B 0
D
parm2
ds
D
plen
9b 0
* - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - -
D
newptr
s
*
D newrec e
ds
extname(invp960j) based(newptr)
* - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
C *entry
plist
C
parm
parm1
C
parm
parm2
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
C
eval ptr =
%addr(parm1)
C
eval newptr = %addr(arr(newoff +
1))
C VendrJ
IfEq 'SKB
'
C WRNUMJ
Chain
INV910I
55
C
move
INNO@I
REFNOJ
C
Write
ETS960J
C
Endif
C
return
****************** End of data
****************************************
Sounds like they know not what they
do.
Alistair
Lisa,
et al,
In a message dated 1/19/01 8:15:37 AM Eastern Standard Time,
Lisa.Abney@universalflavors.com writes:
Hi all! I've just heard some rather negative performance
things on RPG IV,
and
wonder if anyone can give me some feedback on
how true this might be.
We're working with a consulting company who
is doing some performance
analysis
on some of our programs.
They seem very knowledgeable, and I have a lot of
confidence in
what they've done up until now. However, today they were
showing
us a mock-up of a trigger program they want to use. As they
explained it,
this
trigger program will be constantly running in the
background for every user
on
the system to monitor changes to two
files, and will feed data to a dataque.
The program they showed me was
written in RPGIII, and I made my usual
request to an outside contractor
that this be done in RPGIV. His response
was "Sure, if
you
want the program size to be 5 - 10 times the size of an RPGIII program."
When I asked him to explain that, he only said that, in his experience,
this is
always true, and that it would have a very negative
performance. I even
mentioned removing observability (not that I
really understand what that
means,
but I just read something the
other day about that being a way to reduce
program
size!), and he
said that might move it down to 3 - 5 times the size of an
equivalent
RPGIII program. The program will only be about 50 - 100 lines of
code.
Can someone explain if this is true, and, if so, why?
And, if true, what
does
this really mean from a performance
standpoint?
To reiterate some points already made,
and to highlight some that weren't.
Program size has absolutely no
impact on it's performance. I could write an
absolutely enormous
program in RPG III that, given a single unexecutable IF
statement skipping
98% of the logic, would still perform quite well.
However,
comparing apples to apples, RPG IV will almost always be larger
given the
same functionality. This is a case where size doesn't matter.
Now to the unmentioned! Unless you're running SETOBJACC against
it, a
trigger program is _NOT_ constantly running in the background.
It is invoked
as part of whatever job "triggers" it by performing
the proscribed change
action against the relative file. Unless the
only thing that every single
one of your users is doing is constantly
updating one or both of these two
files at the same time, the trigger is
not running at all times. The trigger
also does _NOT_ write to a
data queue unless that's how you wrote it.
It sounds to _ME_, with the
information given, that one of two things is
happening here:
1.
Simon and Mr. Peabody have stepped into the "Wayback" machine and we're
rehashing ILE performance on CISC in the days when there weren't many RISC
machines on the market (see the archives from three or so years ago).
There
was no performance advantage indeed, a degradation, of ILE on
CISC.
2. These "consultants" do not understand true UDB/400
triggers, and have
written some sort of "NEP" solution involving read
waits and data queues
instead of utilizing the native "TRG" commands.
The more I think about it, the more the latter seems to be the case.
I
suppose that the "acid test" would be to ask your consultants
which AS/400
command adds a trigger to a file, and which removes it.
During add, what is
the significance of the ALWRPTCHG parameter?
Finally, I don't know what we're talking about in terms of "lines of
code",
but I have yet to write a trigger that required more than 20 "C"
specs. If
you need more than that, you either need to normalize your
database or
reconsider why you're using triggers...
JMHO,
Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC USA
E-mail: DAsmussen@aol.com
"Without a struggle, there can be no progress." -- Frederick
Douglass
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
