|
Hey, that's a great idea, RTVCLSRC to QTEMP! I like that a lot and it preserves the original code. Screwing up (i.e., losing) code comments and such was the main reason why I didn't want to use RTVCLSRC...but pushing it out to QTEMP for the duration of the scan is perfect! That didn't even occur to me. Thanks Dan! Shannon O'Donnell ----- Original Message ----- From: "Dan" <dbcemid@xxxxxxxxx> To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx> Sent: Wednesday, May 07, 2003 2:13 PM Subject: Re: Batch Formatting of CL Code > Shannon, I recently had a need to read through CL source to extract certain items used to generate > other data and, to keep my programming simple, I required that the parameters be in IBM's default > order. This was a perfect exercise for using RTVCLSRC as I outlined earlier since I am > *guaranteed* that the formatting will be consistent. I just compile the CL source to QTEMP, > RTVCLSRC to a QTEMP/QCLSRC member, run my extraction, job ends and stuff in QTEMP disappears. > Don't know if that's too simple a scenario for your situation, but it works very well for me. > > Even if I didn't do the fancy formatting as I described in the prior post, I'd still do it this > way cuz I hate surprises, and I'd be a fool to assume that everyone that has ever written CL in > this shop always used the prompter to create the CL statements. > > I realize my solution keeps my "weird" formatting intact, whereas you appear to want the source to > be consistent for future use. Because of the manual formatting I do, I find my CL code to be far > more readable than what the prompter creates. > > - Dan > > --- Shannon O'Donnell <sodonnell@xxxxxxxxxxxxxxx> wrote: > > Yeah, well....I disagree with you Rob, but each to their own. By the way, > > who cares about "valuable real estate" in an OS/400 source member? It's not > > like you're likely to run out of memory any time soon because you happened > > to code a full-syntax DCL statement, is it? > > > > However, I need to have some consistency in our CL code so that I can write > > a program to analyze it and extract the variables used in the PGM PARM list, > > and then get those variable types and lengths, which I'm then storing in a > > database for another application to use. > > > > If I don't have consistency, then it's hard to figure out where a variable > > definition begins and ends. Especially considering that you can have the > > variable definition run across multiple source lines, if a programmer had > > coded it that way (it happens). If I know that each DCL statement has the > > same format (i.e., DCL VAR() TYPE() LEN() ) then it's a lot easier to find > > the information I need, regardless of how many actual source lines it may > > span. > > > > Of course...if I had the option of coding this source analyzer in another > > language besides RPGIV, say VB, then this wouldn't be near the chore it is > > at the moment. > > > > But since this has to be code that the "old fogeys" ha! in our shop can read > > and understand also....I'm forced into trying to fit a square peg into a > > round hole on this by using RPG. > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo.cgi/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-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.