Re: Batch Formatting of CL Code

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.
>