|
There is no need for opinions in this case. We have a list owner. Its his list so its his rules. David, what's the rule? (I am not singling out your response Chris; what you say makes sense too, but so don't all the proposed guidelines.) _______________________ Booth Martin boothm@earth.goddard.edu http://www.spy.net/~booth _______________________ Chris Bipes <rpg@cross-check.com> Sent by: owner-rpg400-l@midrange.com 04/17/2000 05:06 PM Please respond to RPG400-L To: "'RPG400-L@midrange.com'" <RPG400-L@midrange.com> cc: Subject: RE: List Usage IMHO the RPG list is for RPG applications and what ever they may call. If you are having problems passing parms to a RPG pgm from cl then the request is valid. If you want info on process control in cl the post it on the midrange list. If you are having questions regarding disappearing screens after putting up a window by calling a RPG program, then it is RPG related DDS question and valid here. Same goes for SQL imbedded in RPG or an opnqryf front end to a RPG program. JMHO! Christopher K. Bipes mailto:ChrisB@Cross-Check.com Sr. Programmer/Analyst mailto:Chris_Bipes@Yahoo.com CrossCheck, Inc. http://www.cross-check.com 6119 State Farm Drive Phone: 707 586-0551 x 1102 Rohnert Park CA 94928 Fax: 707 586-1884 If consistency is the hobgoblin of little minds, only geniuses work here. Karen Herbelin - Readers Digest 3/2000 -----Original Message----- From: M. Lazarus [mailto:mlazarus@ttec.com] Sent: Monday, April 17, 2000 9:01 AM To: RPG400-L@midrange.com Subject: List Usage Simon, At 09:54 AM 4/17/00 +1000, you wrote: Perhaps the ideal is a PROGRAMMING list for the CL, DDS, possibly REXX, OPNQRYF, SQL and other general programming issues thus leaving MIDRANGE-L for the topics you suggest. Even when those techniques are being used in an RPG application they are rarely related to specific RPG issues. What say you all? Should we separate the topics or alter the function (and name) of the RPG400 list? I think that we should change it Midrange Programming. Major exceptions could be Cobol, MI and probably Java. RPG, CL, DDS, SQL (and to a small degree REXX) are part of the normal RPG programmer's arsenal. Any other midrange language volume is so low that we may as well include it on the list. Maybe us died-in-the-wool RPG'ers will learn something about the "outside" world! I can see Midrange Dot Com taking over from the trade rags ... pity about the NASDAQ ... the IPO for Midrange Dot Com would have been interesting :) David's probably making more off this list than most of the IPO companies today!! :-) ** A read loop should almost always be a DOW. The issue being currently argued is really whether a priming read should be used or a single read in an IF test inside the DO. I used to be in the IF camp when I first started programming but after a while I started thinking about the construction of the loop and the additional unnecessary IF test and changed to the priming read. I never liked the extra test, so I always preferred the priming read. Also, after confirming w/ the compiler developers that the "additional" READ opcode doesn't add much to the program size, and the performance s/b better anyway w/o the extra test, that clinched it. ITER and LEAVE (and the appalling LEAVESR) fall in to the same category and I've said enough about them in the past. I don't see how LEAVESR is worse than a LEAVE. I think it's better, since the scope is usually smaller and there is a definite exit point. It's clear and even legitimate in structured programming. A "we're outta here" statement to a single pre-defined exit point is fine, IMHO. -mark +--- | 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 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.