|
Paul, if you want to call procedures from service programs you can also try a more obscure technique that uses MI/rslvsp, QleActBndPgm and QleGetExp. Beppe. ----- Original Message ----- From: "PAPWORTH Paul" <Paul.Papworth@xxxxxxx> To: <rpg400-l@xxxxxxxxxxxx> Sent: Wednesday, May 25, 2005 11:15 AM Subject: RE Variable Procedure Names > Thanks to everyone who replied. > A couple of comments. > The problem I was addressing was to able to 'dynamically' assign procedure names which are in effect RPG *MODULES. The prototype would be the same in all cases but the idea was to retrieve the name of the procedure from a application parameter as we do with dynamically called programs. I follow the PROCPTR approach outlined by Brigitta and Jon but there is still the problem that the procedure name is hard coded. Perhaps we need to move these to a service program and then use the API described by Alan and Beppe. Yes Alan I would be interested to have the code. > > -----Message d'origine----- > De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de rpg400-l-request@xxxxxxxxxxxx > Envoyé : mardi 24 mai 2005 18:47 > À : rpg400-l@xxxxxxxxxxxx > Objet : RPG400-L Digest, Vol 4, Issue 561 > > Send RPG400-L mailing list submissions to > rpg400-l@xxxxxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.midrange.com/mailman/listinfo/rpg400-l > or, via email, send a message with subject or body 'help' to > rpg400-l-request@xxxxxxxxxxxx > > You can reach the person managing the list at > rpg400-l-owner@xxxxxxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPG400-L digest..." > > > Today's Topics: > > 1. RE: Variable Modules (Hauser, Birgitta) > 2. Re: Variable Modules (Beppe Costagliola) > 3. RE: Best options for polling a file (Rick DuVall) > 4. Re: Unable to view management central monitors on win xp with > sp2 ? (David Gibbs) > 5. RE: Variable Modules (Jon Paris) > 6. *** ADMIN: Experimental Wiki (David Gibbs) > 7. RE: Variable Modules (Alan Campin) > > > ---------------------------------------------------------------------- > > message: 1 > date: Tue, 24 May 2005 13:25:50 +0200 > from: "Hauser, Birgitta" <Birgitta.Hauser@xxxxxxxxxxx> > subject: RE: Variable Modules > > Hi Paul, > > to call modules oder better procedures dynamically, you have to use > prototyping and procedure pointers. > In contrary to programs that are called dynamically, that means they aren't > activated before the CALL statement is executed, the procedures must exist > at compile time. The module object that contains the procedures or the > signature of the service program where the module is bound to are physically > embedded into the program object. > > Here an example: > I have three procedures that convert a date into a character representation. > > The first procedure converts to *EUR format, the second to *USA-Format and > the third to *JIS-Format. > You will see the prototypes for these functions > D CvtDateToEur PR 10A extproc('CVTDATEUR') > > D ParmDate D const options(*NoPass) > > D CvtDateToUSA PR 10A extproc('CVTDATUSA') > > D ParmDate D const options(*NoPass) > > D CvtDateToJIS PR 10A extproc('CVTDATJIS) > > D ParmDate D const options(*NoPass) > > Here are the functions: > ************************************************************ > * Converte Date into European Format > ************************************************************ > P CvtDateToEur B Export > D CvtDateToEur PI 10A > D ParmDate D const options(*NoPass) > *----------------------------------------------------------- > /Free > If %Parms >= 1; > Return %Char(ParmDate: *Eur); > else; > Return %Char(%Date(): *Eur); > EndIf; > /End-Free > P CvtDateToEur E > ************************************************************ > * Convert Date into USA Format > ************************************************************ > P CvtDateToUSA B Export > D CvtDateToUSA PI 10A > D ParmDate D const options(*NoPass) > *---------------------------------------------------------------- > /Free > If %Parms >= 1; > Return %Char(ParmDate: *USA); > else; > Return %Char(%Date(): *USA); > EndIf; > /End-Free > P CvtDateToUSA E > ***************************************************************** > * Convert Date into Japanese Format > ***************************************************************** > P CvtDateToJIS B Export > D CvtDateToJIS PI 10A > D ParmDate D const options(*NoPass) > *---------------------------------------------------------------- > /Free > If %Parms >= 1; > Return %Char(ParmDate: *JIS); > else; > Return %Char(%Date(): *JIS); > EndIf; > /End-Free > P CvtDateToJIS E > > Depending on the language or country you want to call one of these > functions. > To do this you need an additional prototype. Add the Keyword EXTPROC and > specify a procedure pointer variable instead of a procedure name. > A procedure pointer has the data type * and the key word PROCPTR. > The following example shows you the additional prototype and the definition > of the procedure pointer variable: > > D CvtDate PR 10A ExtProc(MyProcPtr) > D ParmDate D const options(*NoPass) > > D MyProcPtr S * ProcPtr > > This prototype and procedure pointer must be embedded in the source where > you want to calle the functions "dynamically". > The next example shows you how to call these functions. > D ConstProcUSA C const(%PAddr('CVTDATUSA')) > > D ConstProcJIS S * ProcPtr inz(%PAddr('CVTDATJIS')) > > /Free > Select; > When Country = 'DE '; > MyProcPtr = %PAddr('CVTDATEUR'); > When Country = 'USA'; > MyProcPtr = ConstProcUSA; > When Country = 'JPN'; > MyProcPtr = ConstProcJIS; > EndSL; > > MyCharDate = CvtDate(MyDate); > /End-Free > > I hope this helps! > > Birgitta > > Mit freundlichen Gren > > i.A. Birgitta Hauser > > LUNZER + PARTNER GMBH > Unternehmensberatung > Carl-Zeiss-Strae 1 > 63755 Alzenau > > Tel: + 49 6023 951-255 > Fax: + 49 6023 951-111 > Internet. www.lp-gmbh.com > www.rpg-schulung.de > > > > > ------------------------------ > > message: 2 > date: Tue, 24 May 2005 14:12:36 +0200 > from: "Beppe Costagliola" <beppecosta@xxxxxxxx> > subject: Re: Variable Modules > > Paul, > > if your procedures are in a service program you can dynamically call with > QZRUCLSP Api that also allows you to use variable parameters and get return > values. > > Example: > > QZRUCLSP(SrvPgm+SrvPgmLib:%trimr(Procedure)+x'00': > RETTYPE_NONE:PARMTYPE_PTR:1:ApiError: > RtnVal:Parameter1); > > > > ----- Original Message ----- > From: "Hauser, Birgitta" <Birgitta.Hauser@xxxxxxxxxxx> > To: <rpg400-l@xxxxxxxxxxxx> > Sent: Tuesday, May 24, 2005 1:25 PM > Subject: RE: Variable Modules > > > > Hi Paul, > > > > to call modules oder better procedures dynamically, you have to use > > prototyping and procedure pointers. > > In contrary to programs that are called dynamically, that means they > aren't > > activated before the CALL statement is executed, the procedures must exist > > at compile time. The module object that contains the procedures or the > > signature of the service program where the module is bound to are > physically > > embedded into the program object. > > > > Here an example: > > I have three procedures that convert a date into a character > representation. > > > > The first procedure converts to *EUR format, the second to *USA-Format and > > the third to *JIS-Format. > > You will see the prototypes for these functions > > D CvtDateToEur PR 10A extproc('CVTDATEUR') > > > > D ParmDate D const options(*NoPass) > > > > D CvtDateToUSA PR 10A extproc('CVTDATUSA') > > > > D ParmDate D const options(*NoPass) > > > > D CvtDateToJIS PR 10A extproc('CVTDATJIS) > > > > D ParmDate D const options(*NoPass) > > > > Here are the functions: > > ************************************************************ > > * Converte Date into European Format > > ************************************************************ > > P CvtDateToEur B Export > > D CvtDateToEur PI 10A > > D ParmDate D const options(*NoPass) > > *----------------------------------------------------------- > > /Free > > If %Parms >= 1; > > Return %Char(ParmDate: *Eur); > > else; > > Return %Char(%Date(): *Eur); > > EndIf; > > /End-Free > > P CvtDateToEur E > > ************************************************************ > > * Convert Date into USA Format > > ************************************************************ > > P CvtDateToUSA B Export > > D CvtDateToUSA PI 10A > > D ParmDate D const options(*NoPass) > > *---------------------------------------------------------------- > > /Free > > If %Parms >= 1; > > Return %Char(ParmDate: *USA); > > else; > > Return %Char(%Date(): *USA); > > EndIf; > > /End-Free > > P CvtDateToUSA E > > ***************************************************************** > > * Convert Date into Japanese Format > > ***************************************************************** > > P CvtDateToJIS B Export > > D CvtDateToJIS PI 10A > > D ParmDate D const options(*NoPass) > > *---------------------------------------------------------------- > > /Free > > If %Parms >= 1; > > Return %Char(ParmDate: *JIS); > > else; > > Return %Char(%Date(): *JIS); > > EndIf; > > /End-Free > > P CvtDateToJIS E > > > > Depending on the language or country you want to call one of these > > functions. > > To do this you need an additional prototype. Add the Keyword EXTPROC and > > specify a procedure pointer variable instead of a procedure name. > > A procedure pointer has the data type * and the key word PROCPTR. > > The following example shows you the additional prototype and the > definition > > of the procedure pointer variable: > > > > D CvtDate PR 10A ExtProc(MyProcPtr) > > D ParmDate D const options(*NoPass) > > > > D MyProcPtr S * ProcPtr > > > > This prototype and procedure pointer must be embedded in the source where > > you want to calle the functions "dynamically". > > The next example shows you how to call these functions. > > D ConstProcUSA C const(%PAddr('CVTDATUSA')) > > > > D ConstProcJIS S * ProcPtr inz(%PAddr('CVTDATJIS')) > > > > /Free > > Select; > > When Country = 'DE '; > > MyProcPtr = %PAddr('CVTDATEUR'); > > When Country = 'USA'; > > MyProcPtr = ConstProcUSA; > > When Country = 'JPN'; > > MyProcPtr = ConstProcJIS; > > EndSL; > > > > MyCharDate = CvtDate(MyDate); > > /End-Free > > > > I hope this helps! > > > > Birgitta > > > > Mit freundlichen Gren > > > > i.A. Birgitta Hauser > > > > LUNZER + PARTNER GMBH > > Unternehmensberatung > > Carl-Zeiss-Strae 1 > > 63755 Alzenau > > > > Tel: + 49 6023 951-255 > > Fax: + 49 6023 951-111 > > Internet. www.lp-gmbh.com > > www.rpg-schulung.de > > > > > > -- > > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > > To post a message email: RPG400-L@xxxxxxxxxxxx > > To subscribe, unsubscribe, or change list options, > > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l > > or email: RPG400-L-request@xxxxxxxxxxxx > > Before posting, please take a moment to review the archives > > at http://archive.midrange.com/rpg400-l. > > > > > > ------------------------------ > > message: 3 > date: Tue, 24 May 2005 07:50:45 -0600 > from: "Rick DuVall" <R_C_DuVall@xxxxxxxxxx> > subject: RE: Best options for polling a file > > Hi Rich, > > with all due respect, I don't think Data Queues are cleared at ipl. I use > them regularly and have never noted that. The manual says in regard to the > crtdtaq cmd parameter 'Force' > > FORCE > Specifies whether the data queue entries sent to or received by this > data queue are forced to auxiliary storage. > > Note: This parameter is valid only when TYPE(*STD) is specified. > > *NO: Send and receive operations are not immediately forced to auxiliary > storage. > > *YES: Send and receive operations are immediately forced to auxiliary > storage. ***This ensures that the changes are not lost if a system failure > occurs.*** This requires additional system overhead. > > > which would lead me to believe that they are not cleared at ipl. (as i am > sure they are not from experience) > > Regards > > Rick DuVall > Systems Manager > Dealer's Auto Auction of Okc > 405 947-2886 Ext:143 > rick@xxxxxxxxxx > > > [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Rich Duzenbury > Sent: Monday, May 23, 2005 9:41 PM > To: RPG programming on the AS400 / iSeries > Subject: RE: Best options for polling a file > > > On Mon, 2005-05-23 at 14:08 -0700, Alan Campin wrote: > > > or using EOFDLY which again takes all kinds of resources. > EOFDLY doesn't consume large amounts of resources. The job goes to > sleep until a record appears in the file. EOFDLY has been around since > system/38 (perhaps before that), and it *couldn't* use much in the way > of resources because there weren't that many to consume. > > The drawback to EOFDLY is that a database write must be made in order to > signal the listening job to do something. > > > Data queues are just about as perfect as anything can be on the AS/400. > The problem with data queues is that they are transient. If the system > goes down while there are (perhaps *important*) messages in the data > queue, you kiss them goodbye. > > When the system is IPL'd, one of the things it does is to initialize > (read 'empty') the queues. > > Regards, > Rich > > > > > ------------------------------ > > message: 4 > date: Tue, 24 May 2005 09:05:08 -0500 > from: David Gibbs <david@xxxxxxxxxxxx> > subject: Re: Unable to view management central monitors on win xp with > sp2 ? > > Luqman wrote: > > I want to view system monitors of Management Central, using Iseries > > Navigator on my laptop, having windows xp pro, service pack 2, any idea how > > can I do so ? > > This question has nothing to do with RPG programming ... please post any > follow ups to MIDRANGE-L (http://lists.midrange.com/listinfo/midrange-l) > where it is more appropriate. > > david > > > -- > David Gibbs > david@xxxxxxxxxxxx > > Receipt of this message does not grant you permission to send me > Unsolicited Commercial Email > > > > ------------------------------ > > message: 5 > date: Tue, 24 May 2005 10:26:32 -0400 > from: "Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx> > subject: RE: Variable Modules > > >> Is it possible to have a variable that contains the *module to be called > > You don't call modules - you call procedures .... > > But the answer is yes you can. > > Use the ExtProc keyword on the prototype and put a variable name in the > parm. e.g. Extrproc(WhichToCall) > > WhichToCall is an procedure pointer and you can load it by doing WhichToCall > = %PAddr('ProcedureA') etc. > > There is an example in the RPG Redbook that will give you the basics. I > have to go back to teaching class or I'd be a bit more explicit. > > Jon Paris > Partner400 > > www.Partner400.com > www.RPGWorld.com > > > > ------------------------------ > > message: 6 > date: Tue, 24 May 2005 09:59:05 -0500 > from: David Gibbs <david@xxxxxxxxxxxx> > subject: *** ADMIN: Experimental Wiki > > Folks: > > As a bit of an experiment, I've setup a wiki for iSeries users. > > While it doesn't have a lot of content yet, I'm opening it up to public > beta test. > > The URL is http://wiki.midrange.com. > > If you are unfamiliar with the Wiki concept, check out > http://en.wikipedia.org/wiki/Wiki. > > david > > > > ------------------------------ > > message: 7 > date: Tue, 24 May 2005 09:46:52 -0700 > from: Alan Campin <Alan.Campin@xxxxxxx> > subject: RE: Variable Modules > > When you say a *MODULE, I hope you are not using *ENTRY points to create service programs instead of writing service programs with procedures. The whole concept just makes me reek. > > In any case, any service program can be dynamically loaded. When you bind a service program to a program, you are hard coding the name of the service program and giving IBM control of when the service program loads. At program startup, IBM calls system API's and loads the service program. They get a pointer to each procedure that is going to be used. All of the occurs under the covers and you cannot see it. > > But what happens if you do not know which service program to call until you are running the program? The solution is to load the service program dynamically. You call system API's to load the service program and get pointers to the procedures. From that point on, everything is the same just as if IBM had loaded the service programs. > > I have service programs that do just that and example programs showing how to make the calls. With the logic encapsulated in a service program, very easy to do. (Again, thanks to David Morris for publishing the original code). > > I have sent this code to others in the past. If you are interested, let me know. > > Here is example. Note the declaration for GetInputAmt. The declaration of the external procedure is based on a procedure pointer instead of a name. This is one of the tricks to dynamically loading a service program. Let me know if there are any questions. > > /copy *libl/qsrcf,cb_Std_Con > > /copy *libl/qsrcf,cb_StdType > > /copy *libl/qsrcf,XVDYNL_PR > > * Prototype for function GetInputAmt based on a procedure pointer. > * Must have a procedure pointer and prototype for each procedure you > * want to call dynamically. > > * This procedure receives an account number and returns a 7/2 amount. > > d pptrGetInputAmt... > d s Like(StdPrcPtr) > d GetInputAmt... > d pr 7p 2 ExtProc(pptrGetInputAmt) > d > d PR_InAccountNumber... > d 5p 0 Value > > d ActivationMark01... > d s Like(StdActMark) > d ActivationMark02... > d s Like(StdActMark) > d InputAmt... > d s 7p 2 > d pptr01... > d s Like(StdPrcPtr) > d pptr02... > d s Like(StdPrcPtr) > /Free > > // Activate the first service program. > > ActivationMark01 = DYNL_ActivateServiceProgram('TEST_EF01': > '*LIBL' ); > > // Now get a procedure pointer to procedure we are going to use. > > pptr01 = DYNL_GetPointerToExportedProcedure(ActivationMark01: > 'GetInputAmt' ); > > // Now activate the second program. > > ActivationMark02 = DYNL_ActivateServiceProgram('TEST_EF02': > '*LIBL' ); > > // Now get a procedure pointer to procedure we are going to use. > > pptr02 = DYNL_GetPointerToExportedProcedure(ActivationMark02: > 'GetInputAmt' ); > > // Call the procedure in the first service program. > > pptrGetInputAmt = pptr01; > InputAmt = GetInputAmt(1005); > > // Now call same procedure in second service program. > > pptrGetInputAmt = pptr02; > InputAmt = GetInputAmt(1005); > > // Note that the amount returned is different from each service program. You could call any number > // of different service programs with same prototypes as long as each procedure > // has the same prototype. You can, also, have different named procedure in each service program as > // long as they have the same interface. > > *InLR = *On; > Return; > > /End-Free > > -----Original Message----- > From: PAPWORTH Paul [mailto:Paul.Papworth@xxxxxxx] > Sent: Tuesday, May 24, 2005 12:29 AM > To: rpg400-l@xxxxxxxxxxxx > Subject: Variable Modules > > > We are getting more and more into ILE RPG programming , and I recently came across the following problem. Is it possible to have a variable that contains the *module to be called ? , like we did for years with dynamic program calls. I have seen some suggestions which use the PROCPTR feature but this has been less than clear. > > Thanks in anticipation > -----Message d'origine----- > De: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de rpg400-l-request@xxxxxxxxxxxx > Envoy: vendredi 20 mai 2005 19:01 > : rpg400-l@xxxxxxxxxxxx > Objet: RPG400-L Digest, Vol 4, Issue 555 > > Send RPG400-L mailing list submissions to > rpg400-l@xxxxxxxxxxxx > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.midrange.com/mailman/listinfo/rpg400-l > or, via email, send a message with subject or body 'help' to > rpg400-l-request@xxxxxxxxxxxx > > You can reach the person managing the list at > rpg400-l-owner@xxxxxxxxxxxx > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPG400-L digest..." > > > Today's Topics: > > 1. RE: work files in qtemp (Larry Ducie) > 2. RE: File object got deleted! > (Chaudhary, Sachin (GE Equipment Services, Consultant)) > > > ---------------------------------------------------------------------- > > message: 1 > date: Fri, 20 May 2005 17:33:32 +0100 > from: "Larry Ducie" <larry_ducie@xxxxxxxxxxx> > subject: RE: work files in qtemp > > Hi Ken, > > <snip> > If Larry and I worked at the same company, and he used his utility to take > over one of my jobs and had it delete an object, then *I* deleted the > object. If object auditing is turned on and you looked the audit record for > the deletion, it would show deleted by me. There would be no clue that Larry > was the one who instigated it, except the program name might show the name > of his exit program, but even then there would be no way to know from that > audit record who it was that actually used the utility. > </snip> > > ...and the deletion of the object caused the application to crash, and the > company lost $millions? Would you still insist that "you" deleted the > object? :-) > > I agree with you about the way it works, I wont argue that point - on a > system level it's the user running the job that performs the action. Or > rather, the action is performed under the user profile that runs the job. > I've never argued otherwise. The problem here, as you pointed out, is that > the audit trail is broken - that's the big security concern for me. You'd > have to prove it "wasn't" you that deleted the object when all evidence > indicates that you did. > > Having said all that, it's been a really useful tool for me over the years > (whichever way it works). It can still bel useful, even if it's only used as > a development tool - to help debugging batch jobs. > > This is quite a good topic. Makes you think. > > Have a good weekend. > > Cheers > > Larry Ducie > > > > > ------------------------------ > > message: 2 > date: Fri, 20 May 2005 12:45:40 -0400 > from: "Chaudhary, Sachin \(GE Equipment Services, Consultant\)" > <sachin.chaudhary@xxxxxx> > subject: RE: File object got deleted! > > I got it. Thanks a lot. > > -----Original Message----- > From: rpg400-l-bounces+sachin.chaudhary=ge.com@xxxxxxxxxxxx > [mailto:rpg400-l-bounces+sachin.chaudhary=ge.com@xxxxxxxxxxxx]On Behalf > Of Scott Klement > Sent: Friday, May 20, 2005 3:18 AM > To: RPG programming on the AS400 / iSeries > Subject: Re: File object got deleted! > > > > > 1. Thinking that creating a new file from DDS will lead to recompiling > > all programs to avoid level check error > [SNIP] > > Creating a duplicate object, to production didn't change the > > Identifier?? > [SNIP] > > Can you explain me? > > What does a record format level check do, and why do we need it? > > First, understand the problem that it's designed to solve: > > When you compile an RPG program that uses an external definition, what it > does is look at the fields in the file and generate I-specs (yes, the old > fashioned input specs) in your program for you. > > Since these are now compiled into your program, if you change anything in > the record format, it would read from the wrong positions. > > For example, consider the following file: > > A R TESTFMT > A FIELD1 10A > A FIELD2 10A > > When you compile an RPG program that uses this file, and use an external > definition, the system will AUTOMATICALLY create the following input > specs... > > ITESTFMT NS > I 1 10 field1 > I 11 20 field2 > > If you go back and change the file so tha FIELD1 is 15A instead of 10, > you now have the following: > > A R TESTFMT > A FIELD1 15A > A FIELD2 10A > > Now FIELD1 is taking up positions 1-15 and field2 is 16-25. However, > unless you re-compile your RPG program, it won't know that! Instead, > it'll continue to try to read field1 from positions 1-10, and FIELD2 from > 11-20. That means that FIELD2 in the RPG program will actually read data > out of FIELD1! > > So, IBM insituted record format level identifiers. The system computes a > "checksum" or "hash" of the things that are important to the format of a > record. These things are the field's name, length, data type, and > position in the record. > > So, in the above example, the record format level identifier would have > changed, since the size of FIELD1 has changed, and also because the > position of FIELD2 has changed. > > When you compile your RPG program, it reads the external definition and > generates the input specs as I explained above. It saves the record > format level from the file into the RPG program's compiled object. Every > time it tries to open that file, it compares the one it saved with the one > in the file. If they don't match, it knows it's input specs are wrong, and > aborts the program. This way, a programmer won't forget to recompile his > program to generate the correct input specs. > > Now that you understand that, why didn't CRTDUPOBJ or re-building the PF > from source cause the record format level id to be different? Quite > simply because the record format was the same. Since it was the same, the > system generates the same checksum. The input specs that it would > generate are identical, so there's no reason for the level id to be > different. > > Make sense? > > > 2. How can we know from which AS400 id was this object deleted?. History > > log (DSPLOG QHST) is no good. > > The history log isn't intended for that sort of thing. If you want the > system to log who deleted files, you need to turn on object auditing. > Unfortunately, if the file is already gone, it's too late. You need to > turn it on ahead of time so that these sort of events are logged. > > Do a search for CHGOBJAUD and CHGUSRAUD and you should find more info on > object auditing. > > good luck > -- > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l > or email: RPG400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > > > > ------------------------------ > > -- > This is the RPG programming on the AS400 / iSeries (RPG400-L) digest list > To post a message email: RPG400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l > or email: RPG400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > > > End of RPG400-L Digest, Vol 4, Issue 555 > **************************************** > > > > > > > > ------------------------------ > > -- > This is the RPG programming on the AS400 / iSeries (RPG400-L) digest list > To post a message email: RPG400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l > or email: RPG400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > > > End of RPG400-L Digest, Vol 4, Issue 561 > **************************************** > > -- > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l > or email: RPG400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. >
As an Amazon Associate we earn from qualifying purchases.
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
