|
you'll
save yourself lots of lines of code and hours testing if you use RPG IV instead
of RPG III (400)! you wont need to use any API's as there is built in date
support.
check
out this link for examples on writing date routines to determine leap years,
figure day of week, number of days in a month, etc....
a few
well coded loops and the program should practically write itself!
;-)
Look
into the date API's. You should be able to take Jan 1 of any year and
find the day, (Sun-Sat), as well as test for valid dates, e.g.
02/30/##.
Regards,
Jon A. Erickson
Sr. Programmer Analyst
800.COM Inc.
1516 NW Thurman
St
Portland, OR
97209-2517
Direct: 503.944.3613
Fax: 503.944.3690
Web: http://800.com
Dear Alistair,
Could you help me with the
following:-
How do i design and write a print program in RPG400 to produce a
single page calendar, as in the example below. It should be able to accept
any year between 1900 and 2099, passed as a four-character parameter via a
data area.
NB.
- Leap years may be calculated by dividing the year by four. With the
exception of years ending in 00, unless it is divisible by 400. Eg 2000 is
a leap year is not
- the 1st of January 1990 was a Monday
- The range of years tested will be within 1900 to 2099.
- Jan, Mar, May, July, Aug, Oct ,Dec have 31 days
Calendar 97
January
February
March April
M T W T F S
S M T W T F S
S M T W T F S
S M T W T F S S
01 02 03 04 05
etc.
I would be grateful for any help
Thanks
----- Original Message -----
Sent: Wednesday, January 24, 2001
1:21 PM
Subject: RE: RPG IV Performance
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
|
midrange.com
