Re: Batch Formatting of CL Code

[Dan <dbcemid@xxxxxxxxx>]

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