|
A number of you have mentioned service programs I have started to create prototyped procedures but not service programs What are the differences (Coding, Calling, Compiling) Thank You Mike -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of rpg400-l-request@xxxxxxxxxxxx Sent: Tuesday, February 01, 2005 3:52 PM To: rpg400-l@xxxxxxxxxxxx Subject: RPG400-L Digest, Vol 4, Issue 135 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. RPG read loops (Paul Morgan) 2. RE: (Jeff Crosby) 3. RE: Prototyped Procedures (Alan Campin) 4. RE: Leave / Iter (was: Suggested Technique) (Alan Campin) 5. RE: RPG read loops (Bob Cozzi) 6. RE: Submitting jobs with a higher priority (Alan Campin) 7. RE: Prototyped Procedures (rob@xxxxxxxxx) ---------------------------------------------------------------------- message: 1 date: Tue, 1 Feb 2005 15:27:01 -0500 from: "Paul Morgan" <pmorgan@xxxxxxxxxxxxxx> subject: RPG read loops Almost all of the code in the current Leave / Iter thread showed a loop like: DoU F3 or F12 exfmt If Not (F3 or F12) // do something EndIf EndDo This only has one exfmt statement inside a DoU loop. A similar file read loop would be: DoU %EoF Read If Not %Eof // do something EndIf EndDo which has one read statement inside of a DoU loop. Isn't there a better way of coding loops with more than one read/exfmt like: exfmt DoW Not (F3 or F12) // do something exfmt EndDo or Read DoW Not %Eof // do something Read EndDo or SetLL ReadE DoW Not %Eof // do something ReadE EndDo Most programmers seem to code with the single read/exfmt style which IMHO complicates the code. In a DoU/Read loop the body of the loop is nested two deep inside the DoU and an If statement. In a Read/DoW/Read loop the body of the loop is nested one deep inside a DoW. Doesn't this reduction in the nesting of the body of the loop improve the program? Readability is improved. Performance is also improved (although minor) with the removal of one test against the end of loop. Other programmers I work with are adamant about not coding more than one read statement. Why is coding more than one read statement such a problem? Paul -- Paul Morgan Senior Programmer Analyst - Retail J. Jill Group 100 Birch Pond Drive, PO Box 2009 Tilton, NH 03276-2009 Phone: (603) 266-2117 Fax: (603) 266-2333 ------------------------------ message: 2 date: Tue, 1 Feb 2005 15:27:14 -0500 from: "Jeff Crosby" <jlcrosby@xxxxxxxxxxxxxxxx> subject: RE: Prototyped Procedures > 1 other responder used QPROTOSRC. :-) I use QPROTOSRC. But then I'm just an ordinary everyday guy. -- Jeff Crosby Dilgard Frozen Foods, Inc. P.O. Box 13369 Ft. Wayne, IN 46868-3369 260-422-7531 The opinions expressed are my own and not necessarily the opinion of my company. Unless I say so. ------------------------------ message: 3 date: Tue, 1 Feb 2005 13:31:37 -0700 from: Alan Campin <Alan.Campin@xxxxxxx> subject: RE: Prototyped Procedures I am not sure what your question is concerning prototypes. Prototypes are just copies of the procedure definition to tell the compiler what the procedure looks like so they are just copies but I have a hunch that is not your question. As to subprocedure in a source member, to me, the central rule is still the same, encapsulation, in other words, you group together things that belong together to hide them. For example, I have a common functions service program. In XVCMNF_M01, I have error message handling. In XVCMNF_M02, I have ILE Condition Handling. In XVCMNF_M03, I have String Functions, etc. They all get bound together to become XVCMNF. I just put like functions in the same module. I then have one source member, XVCMNF_PR that contain the prototypes for the service program. I am looking at program now where I want message processing in one module and IFS I/O in another. What I am always trying to do is information hiding. In a module that is doing message processing, I don't need to have functions that do IFS I/O. I can hide them away. I don't need the complexity in that module. Do I really need to know how IFS I/O works? No, I just need to call a function to read or write. How it works is immaterial to me. That, to me, is the whole purpose of having subprocedure and modules. Encapsulate complexity and hide it away. I then can focus on the problem I am trying to solve and when I work on the IFS I/O, I can test it separately and concentrate on it without worrying about anything else. The other issue that comes up is global variables. In my XVCMNF_M01 module, I have certain global(static) variables. The only functions that I want acting on those variables are error message handling functions. If I mix together String functions with error message handling, something from string functions could screw up the variables for error handling by accident. Putting the error handling in a separate module means I protect those variables so I am always looking at a module to see if their are global variables that should be hidden in a separate module so I naturally group together any functions that work on a static variable in a separate module. Also, on source file names. Why do we insist on using multiple source file names? I prefer to use one source file, QSRCF. I than have everything together in one source files and do not have to constantly be shifting between source files. My boss forces me to use multiple source files and I end up using 4 or 5 different source files for a project. What a waste of time. Anyway, my two cents. -----Original Message----- From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx] Sent: Tuesday, February 01, 2005 11:59 AM To: RPG programming on the AS400 / iSeries Subject: Re: Prototyped Procedures Traditionally prototypes are saved in a source file named QPROTOSRC. And they would have the same name as the subprocedure or program they are the prototype for. For example D/COPY MYLIB/QCPYSRC,GETGRP_PR becomes D/COPY MYLIB/QPROTOSRC,GETGROUP The advantages to setting up multiple subprocedures in one source member are the same for setting up multiple subroutines in a source member. However, if you are talking about subprocedures you are planning on using in a service program then that's a different story. I suppose a lot of that is style. Some may be because the subprocedures are written in different languages. But whether you: - Keep each subprocedure in it's own source member and in it's own service program. - Keep subprocedures grouped by function (like date, or bill of material, etc) in multiple source members but one service program - Keep subprocedures grouped by function in one source member and one service program - Keep all subprocedures in separate source members, but one service program - Keep all subprocedures in one source member and one service program is largely a matter of style. I will caution you that one monolithic general copy member will drive the anal retentive people who's goal is to not have one unreferenced variable in their program into a foaming at the mouth fit. They will end up chopping out what they need and physically copying in to each desired member. And I am not talking /copy here. If you still want the monolith it's better to - use /include instead of /copy, (but they work the same on V5R3) (imbedded SQL programmers understand the difference between /include and /copy) - and nest the members For example your monolith becomes merely a string of /include statements. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Ala, Michael A" <michael.ala@xxxxxx> Sent by: rpg400-l-bounces@xxxxxxxxxxxx 02/01/2005 01:28 PM Please respond to RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> To <rpg400-l@xxxxxxxxxxxx> cc Subject Prototyped Procedures What is the best way to perform Procedure prototyping I would like some rules I am not sure if I am performing any steps that are unecessary This is in the caller D/COPY MYLIB/QCPYSRC,GETGRP_PR This is what is copied in D GetGroup PR 1A EXTPROC('GETGROUP') D $Group 10A D $Cust# 8S 0 CONST OPTIONS(*OMIT) D $Item# 25A OPTIONS(*NOPASS) Here is the call for the Procedure (um Function) EVAL $CustGrp=GETGROUP($Group:CUST#) Here is what is in the called Procedure D/COPY MYLIB/QCPYSRC,GETGRP_PR PGETGROUP B EXPORT D GetGroup PI 1A D $Group 10A D $Cust# 8S 0 CONST OPTIONS(*OMIT) D $Item# 25A OPTIONS(*NOPASS) D $Found S 1A INZ('N') Also what are the advantages to setting up multiple sub-procedures in a single source member What limitations does this have I am always doing things I can't do; that's how I get to do them. -Pablo Picasso -- 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: 4 date: Tue, 1 Feb 2005 13:34:08 -0700 from: Alan Campin <Alan.Campin@xxxxxxx> subject: RE: Leave / Iter (was: Suggested Technique) I would agree. The function does one thing, control. Lower level functions implement actions. Beautiful clean code. -----Original Message----- From: Bob Cozzi [mailto:cozzi@xxxxxxxxx] Sent: Tuesday, February 01, 2005 12:01 PM To: 'RPG programming on the AS400 / iSeries' Subject: RE: Leave / Iter (was: Suggested Technique) Beautiful! -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of MWalter@xxxxxxxxxxxxxxx Sent: Tuesday, February 01, 2005 12:45 PM To: RPG programming on the AS400 / iSeries Subject: RE: Leave / Iter (was: Suggested Technique) I agree. If you keep your looping constructs within manageable boundries using subprocedures and/or subroutines, using leave or iter, to me, is just as intuitive as not using them. I often code display loops like this: dow 1 = 1; exfmt prompt; select; when f3Key; leave; when f6Key; add(); when f5Key; doSomethingElse(); endsl; enddo; return; Thanks, Mark Mark D. Walter Senior Programmer/Analyst CCX, Inc. mwalter@xxxxxxxxxx http://www.ccxinc.com "Bob Cozzi" <cozzi@xxxxxxxxx> Sent by: To rpg400-l-bounces@ "'RPG programming on the AS400 / midrange.com iSeries'" <rpg400-l@xxxxxxxxxxxx> cc 02/01/2005 01:26 Subject PM RE: Leave / Iter (was: Suggested Technique) Please respond to RPG programming on the AS400 / iSeries <rpg400-l@midrang e.com> What's the real difference from a maintenance perspective if I use: EXIT_MODE = QUIT or if I use: LEAVE or LEAVESR It just seems strange that someone would advocate (and I'm not say you Joel) avoiding Leave/LeaveSR and then use *IN03 in their code illustrating the point. -Bob -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joel Fritz Sent: Tuesday, February 01, 2005 12:12 PM To: RPG programming on the AS400 / iSeries Subject: RE: Leave / Iter (was: Suggested Technique) Well... You could code it something like: exit_mode = STAY; //STAY is a constant--others defined for different possible states dow exit_mode = STAY; select; when *in03; exit_mode = QUIT; when cond_1; exit_mode = proc_cond_1(....); ................ endsl; enddo; In an event loop it's very likely that there is more than one condition that will end the loop. It may be cleaner to examine the state, especially since you may need to know the state after the loop ends. -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of antoine.contal@xxxxxxx Sent: Tuesday, February 01, 2005 2:23 AM To: RPG programming on the AS400 / iSeries Subject: Leave / Iter (was: Suggested Technique) Using an indicator variable cannot be the best solution. I'm not saying leave/iter is the best, but your solution leads to code duplication. And we all know what code duplication leads to in the long run, from both theoretical and practical perspectives. :-( Regards. -- Antoine CONTAL ***************************** NOTICE: All e-mail sent to or from this e-mail address will be received or otherwise recorded by The Sharper Image corporate e-mail system and is subject to archival, monitoring, and review by and/or disclosure to Sharper Image security and other management. This message is intended only for the use of the addressee and may contain information that is privileged and confidential. The contents of this message may contain personal views which are not the views of The Sharper Image. If you are not the intended recipient, dissemination of this communication is prohibited. ***************************** -- 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) 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) 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: 5 date: Tue, 1 Feb 2005 14:39:06 -0600 from: "Bob Cozzi" <cozzi@xxxxxxxxx> subject: RE: RPG read loops Yes there is a better way... I will only tell you the answer, however, after you send me a diagram illustrating how, in the figure below, to connect the top row of 3 dots with the bottom row of 3 dots using a line drawn with a pen or pencil WITHOUT ever allowing any of the lines to intersect. This has to be accomplished on a two-dimensional surface. You have ten minutes... Go! * * * * * * -Bob Cozzi -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Morgan Sent: Tuesday, February 01, 2005 2:27 PM To: rpg400-l@xxxxxxxxxxxx Subject: RPG read loops Almost all of the code in the current Leave / Iter thread showed a loop like: DoU F3 or F12 exfmt If Not (F3 or F12) // do something EndIf EndDo This only has one exfmt statement inside a DoU loop. A similar file read loop would be: DoU %EoF Read If Not %Eof // do something EndIf EndDo which has one read statement inside of a DoU loop. Isn't there a better way of coding loops with more than one read/exfmt like: exfmt DoW Not (F3 or F12) // do something exfmt EndDo or Read DoW Not %Eof // do something Read EndDo or SetLL ReadE DoW Not %Eof // do something ReadE EndDo Most programmers seem to code with the single read/exfmt style which IMHO complicates the code. In a DoU/Read loop the body of the loop is nested two deep inside the DoU and an If statement. In a Read/DoW/Read loop the body of the loop is nested one deep inside a DoW. Doesn't this reduction in the nesting of the body of the loop improve the program? Readability is improved. Performance is also improved (although minor) with the removal of one test against the end of loop. Other programmers I work with are adamant about not coding more than one read statement. Why is coding more than one read statement such a problem? Paul -- Paul Morgan Senior Programmer Analyst - Retail J. Jill Group 100 Birch Pond Drive, PO Box 2009 Tilton, NH 03276-2009 Phone: (603) 266-2117 Fax: (603) 266-2333 -- 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: 6 date: Tue, 1 Feb 2005 13:41:01 -0700 from: Alan Campin <Alan.Campin@xxxxxxx> subject: RE: Submitting jobs with a higher priority If you are using ILE and modules, just use the language that does it best. Do it in CLLE. Create a module for CL to receive the parms and do a submit job. Then just bind them to the RPG. The CL does it's job and the RPG does it's job and you have one program object. That is why I love ILE. Of course my boss hates it. He wants everything done in one big monolith program. -----Original Message----- From: JMBauman@xxxxxxxxxxxxxxxx [mailto:JMBauman@xxxxxxxxxxxxxxxx] Sent: Tuesday, February 01, 2005 8:00 AM To: rpg400-l@xxxxxxxxxxxx Subject: Submitting jobs with a higher priority I want to submit jobs to a job queue at a run priority of 20. Any clue on how to do this? I am submitting job from an RPG program using QCMDEXEC. Thanks John M. Bauman Project Manager - Lead Programmer/Analyst Ward Trucking Second Avenue & Seventh Street, Greenwood Altoona, PA 16603 Direct Voice (814) 947-1284 Fax (814) 944-5470 www.wardtrucking.com ------------------------------ message: 7 date: Tue, 1 Feb 2005 15:51:38 -0500 from: rob@xxxxxxxxx subject: RE: Prototyped Procedures bad manners and the fact that you have to give it different names. Like the _PR example previously noted. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Bob Cozzi" <cozzi@xxxxxxxxx> Sent by: rpg400-l-bounces@xxxxxxxxxxxx 02/01/2005 03:23 PM Please respond to RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> To "'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx> cc Subject RE: Prototyped Procedures QPROTOS QPROTOSRC QCPYSRC QINCLUDE QINCSRC Doesn't matter to me. I think the redbook folks probably just picked a name for their file/member names that, in this case, were somewhat documenting the thing. And, can you believe IBM still names its book pages as "section 2.1.6.2"? Talk about writing for Attorneys, yuke! The best thing to do is to put the prototypes someplace other than within the procedure implementation source. Keeping it altogether in one source member is just bad manners. :) -Bob -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx Sent: Tuesday, February 01, 2005 2:10 PM To: RPG programming on the AS400 / iSeries Subject: RE: Prototyped Procedures 1 other responder used QPROTOSRC. :-) I see a lot of SUBPROCSRC in everyone's favorite redbook. They had a golden opportunity to clarify this in section 2.1.6.2 but left it alone. The redbook talked about keeping the prototypes and the data structures used within it in the same member. We don't. For example, we may put our prototypes for a particular api in one member and a separate member(s) for the data structure(s) involved. Some sample member names: MBRD0100 MBRD0200 MBRD0300 QUSRMBRD Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Bob Cozzi" <cozzi@xxxxxxxxx> Sent by: rpg400-l-bounces@xxxxxxxxxxxx 02/01/2005 02:16 PM Please respond to RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> To "'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx> cc Subject RE: Prototyped Procedures I agree with all but one of Rob's comments. "Traditionally prototypes are saved in a file name QPROTOSRC". "Traditionally in Rob's shop" is probably accurate. I have only seen prototypes in a source file with one of the following names: QCPYSRC QCPYLESRC QINCSRC QINCLUDE I see QCPYSRC used the most frequently and have made that my standard. I do see other names used in things such as CGIDEV2, but standards and consistency when it comes to naming conventions has never been a strong point of CGIDEV2. -Bob -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx Sent: Tuesday, February 01, 2005 12:59 PM To: RPG programming on the AS400 / iSeries Subject: Re: Prototyped Procedures Traditionally prototypes are saved in a source file named QPROTOSRC. And they would have the same name as the subprocedure or program they are the prototype for. For example D/COPY MYLIB/QCPYSRC,GETGRP_PR becomes D/COPY MYLIB/QPROTOSRC,GETGROUP The advantages to setting up multiple subprocedures in one source member are the same for setting up multiple subroutines in a source member. However, if you are talking about subprocedures you are planning on using in a service program then that's a different story. I suppose a lot of that is style. Some may be because the subprocedures are written in different languages. But whether you: - Keep each subprocedure in it's own source member and in it's own service program. - Keep subprocedures grouped by function (like date, or bill of material, etc) in multiple source members but one service program - Keep subprocedures grouped by function in one source member and one service program - Keep all subprocedures in separate source members, but one service program - Keep all subprocedures in one source member and one service program is largely a matter of style. I will caution you that one monolithic general copy member will drive the anal retentive people who's goal is to not have one unreferenced variable in their program into a foaming at the mouth fit. They will end up chopping out what they need and physically copying in to each desired member. And I am not talking /copy here. If you still want the monolith it's better to - use /include instead of /copy, (but they work the same on V5R3) (imbedded SQL programmers understand the difference between /include and /copy) - and nest the members For example your monolith becomes merely a string of /include statements. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Ala, Michael A" <michael.ala@xxxxxx> Sent by: rpg400-l-bounces@xxxxxxxxxxxx 02/01/2005 01:28 PM Please respond to RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> To <rpg400-l@xxxxxxxxxxxx> cc Subject Prototyped Procedures What is the best way to perform Procedure prototyping I would like some rules I am not sure if I am performing any steps that are unecessary This is in the caller D/COPY MYLIB/QCPYSRC,GETGRP_PR This is what is copied in D GetGroup PR 1A EXTPROC('GETGROUP') D $Group 10A D $Cust# 8S 0 CONST OPTIONS(*OMIT) D $Item# 25A OPTIONS(*NOPASS) Here is the call for the Procedure (um Function) EVAL $CustGrp=GETGROUP($Group:CUST#) Here is what is in the called Procedure D/COPY MYLIB/QCPYSRC,GETGRP_PR PGETGROUP B EXPORT D GetGroup PI 1A D $Group 10A D $Cust# 8S 0 CONST OPTIONS(*OMIT) D $Item# 25A OPTIONS(*NOPASS) D $Found S 1A INZ('N') Also what are the advantages to setting up multiple sub-procedures in a single source member What limitations does this have I am always doing things I can't do; that's how I get to do them. -Pablo Picasso -- 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) 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) 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) 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) 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 135 ****************************************
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
