× 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.


  • Subject: RE: RPG400
  • From: "Hockemeyer, Gene" <HockemG@xxxxxxxxxxx>
  • Date: Thu, 25 Jan 2001 15:24:56 -0600

If you are working in RPG400  or RPGILE .... you can verify the date or find
the day of the week with out using API's. 
 
Gene Hockemeyer 
Sunbeam Corporation 
Manager EDI and EC Business Development 
561 912-4877 
hockemg@sunbeam.com <mailto:hockemg@sunbeam.com>  

 
 

-----Original Message-----
From: jerickson@800.com [mailto:jerickson@800.com]
Sent: Thursday, January 25, 2001 3:30 PM
To: RPG400-L@midrange.com
Subject: RE: RPG400


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 <http://800.com/>  

-----Original Message-----
From: areavill [mailto:areavill@bluecarrots.com]
Sent: Thursday, January 25, 2001 12:07 PM
To: RPG400-L@midrange.com
Subject: Re: RPG400


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.

1.      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 

2.      the 1st of January 1990 was a Monday 

3.      The range of years tested will be within 1900 to 2099. 

4.      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 ----- 
From: Alistair  <mailto:alistairr@tbsa.co.za> Rooney 
To: RPG400-L@midrange.com <mailto:RPG400-L@midrange.com>  
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                                     
                                                                        

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of DAsmussen@aol.com
Sent: Wednesday, January 24, 2001 11:47 AM
To: RPG400-L@midrange.com
Subject: Re: RPG IV Performance


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 is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.