Re: Batch Formatting of CL Code

Another alternative is to extract each command as you'd do
anyway, and let the API format it in a consistent fashion
before you run your parser code over it.

- Alan



----- Original Message -----
From: "Shannon O'Donnell" <sodonnell@xxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, May 07, 2003 3:19 PM
Subject: 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 (MIDRA
NGE-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.
| >
|
|
| _______________________________________________
| 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.
|