RE: CL Formatting, was WDSc workstation requirements -- WDSCI-L

Vern said:  "I go back and forth on this. I try to do nice indents and other
"pretty-print" stuff, and, of course, that's wiped out if you prompt in SEU.
So I give up on "pretty-print". But then the structure is harder to follow."

I do a fair amount of CL coding, but I still rely heavily on F4 in SEU.
(Why overload my brain with details when command prompting is one of the
great facilities of OS/400?)  I hate the default formatting that results.  

Fortunately, many years ago Ernie Malaga (?sp) wrote a CL formatter for
Midrange Computing.  I like and have grown used to the indented source it
creates.  If I destroy the formatting by prompting it takes just a couple of
seconds to reformat the whole program.

It's a REXX program that is quite nippy on RISC machines.  It relies on
fully prompted CL code, but for me that isn't an issue, though I know some
people consider some command keywords as "noise".  

I run Ernie's command as a PDM user option.  Works great for me, since I do
most CL programming in SEU because I find the LPEX prompting too slow.  I do
tidy up and comment the code in LPEX.  (In theory I suppose I could run the
indenter from RSE as long as the member isn't open in LPEX.)

The formatter will stop working at V5R3 when new opcodes are introduced to
CL, but I suspect it could be upgraded, though I'm not a REXX expert.

Seems to me that something similar could/should be put into the LPEX editor
for CL, but auto indenting of RPG Free is probably more important.

Sam

FWIW, here's a sample of the resulting indented codel:

   /* If not *ALL, process member immediately */
   IF COND(&SRCMBR *NE '*ALL') THEN(DO)
      RTVMBRD FILE(&SRCFLIB/&SRCF) MBR(&SRCMBR) SRCTYPE(&SRCTYPE)
      IF COND(&SRCTYPE *NE 'CL' *AND &SRCTYPE *NE 'CLP' *AND +
         &SRCTYPE *NE 'CLP38') THEN(DO)
         SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Member' +
            *BCAT &SRCMBR *BCAT 'is not a CL source member') +
            MSGTYPE(*ESCAPE)
         RETURN
      ENDDO
      ELSE CMD(DO)
         CALL PGM(INDCLC2) PARM(&SRCMBR &SRCF &SRCFLIB &CVTCASE +
            &INDRMKS &OUTPUT &SAVOLDSRC &BGNCOL &INDCOL &INDCONT)
         MONMSG MSGID(CPF0000) EXEC(DO)
            RCVMSG MSGTYPE(*EXCP) MSGDTA(&MSGDTA) MSGID(&MSGID) +
               MSGF(&MSGF) MSGFLIB(&MSGFLIB)
            SNDPGMMSG MSGID(&MSGID) MSGF(&MSGFLIB/&MSGF) +
               MSGDTA(&MSGDTA) MSGTYPE(*ESCAPE)
            RETURN
         ENDDO
      ENDDO
   ENDDO



>>-----Original Message-----
>>From: wdsci-l-bounces+lennon_s_j=hotmail.com@xxxxxxxxxxxx
>>[mailto:wdsci-l-bounces+lennon_s_j=hotmail.com@xxxxxxxxxxxx] On
>>Behalf Of Vern Hamberg
>>Sent: Friday, May 28, 2004 4:28 PM
>>To: Websphere Development Studio Client for iSeries
>>Subject: Re: [WDSCI-L] CL Formatting, was WDSc workstation
>>requirements
>>
>>Rob
>>
>>I go back and forth on this. I try to do nice indents and other
>>"pretty-print" stuff, and, of course, that's wiped out if you prompt
>>in
>>SEU. So I give up on "pretty-print". But then the structure is
>>harder to
>>follow.
>>
>>jLPEX in RSE has done some (IMO) really bad things. I've reported
>>some and
>>I think they're on the list for being fixed. I believe the latest
>>version
>>will/does have better options/customization for formatting CL - hope
>>so.
>>Because I'd really like to keep indents, etc. Esp. with the new
>>structured
>>opcodes in V5R3.
>>
>>Of course, you'll never use those, since you don't use CL,
>>right?   Ducking!!  ;-)
>>
>>Happy Memorial Day
>>Vern
>>
>>At 01:02 PM 5/28/2004, you wrote:
>>>Vern,
>>>
>>>I detest the CL formatting in SEU.  There is too much wasted space
>>on the
>>>left.  And often times I don't want the real estate eaten up by the
>>>parameters.  For instance I find this much easier to process
>>>     DCL  &USER        *CHAR   10 /* User profile
>>*/
>>>     DCL  &EMAILADR    *CHAR   50 /* Email address
>>*/
>>>
>>>Than how SEU would format that, when prompted.
>>>
>>>Or when I type in the following, and some messes it up by prompting
>>it in
>>>SEU:
>>>SAV     DEV(&SAVDEV) +
>>>         OBJ(('/*') +
>>>             ('/QSYS.LIB' *OMIT) /* Saved with SAVLIB */ +
>>>             ('/QDLS' *OMIT)     /* Saved with SAVDLO */ +
>>>             ('/QCA400' *OMIT)   /* iSeries access updates */ +
>>>             ('/QFileSvr.400' *OMIT) /* 400-to-400 mapping */ +
>>>             ('/QOPT' *OMIT)     /* Optical drives */ +
>>>             ('/QPWX*' *OMIT) +
>>>             ('/QTCPTMM' *OMIT) +
>>>             ('/tmp'     *OMIT)  /* Temp data, avoid conflicts */ +
>>>             ('/PSF400'  *OMIT) +
>>>             ('/PSFSMTP' *OMIT) +
>>>             ('/QIBM/ProdData/InfoCenter' *OMIT)) +
>>>         SAVACT(*YES) SAVACTOPT(*ALWCKPWRT) +
>>>         OUTPUT(*PRINT) EXPDATE(&EXPDT) +
>>>         ENDOPT(*LEAVE) UPDHST(*YES)
>>>
>>>Rob Berendt
>>>--
>>>Group Dekko Services, LLC
>>>Dept 01.073
>>>PO Box 2000
>>>Dock 108
>>>6928N 400E
>>>Kendallville, IN 46755
>>>http://www.dekko.com
>>>
>>>
>>>
>>>
>>>
>>>Vern Hamberg <vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx>
>>>Sent by: wdsci-l-bounces@xxxxxxxxxxxx
>>>05/28/2004 12:14 PM
>>>Please respond to
>>>Websphere Development Studio Client for iSeries <wdsci-
>>l@xxxxxxxxxxxx>
>>>
>>>
>>>To
>>>Websphere Development Studio Client for iSeries <wdsci-
>>l@xxxxxxxxxxxx>
>>>cc
>>>
>>>Subject
>>>RE: [WDSCI-L] WDSc workstation requirements
>>>
>>>
>>>
>>>
>>>
>>>
>>>Charles, you got me looking again.
>>>
>>>I don't know about whether to view CODE as a separate product or as
>>a
>>>feture - IBM does the latter, I'll live with that.
>>>
>>>Nonetheless, I agree that it should be more explicit. And there is
>>even
>>>more confusion here -are you guys in Toronto listening? I know you
>>are.
>>>;-)
>>>
>>>On the "Features" page for the client is a link to CODE and one to
>>VARPG.
>>>There is also a link to "Server development tools". The latter
>>points to
>>>things like the WAS test environment, and there is NO WAY that runs
>>in
>>>256MB. (The requirements page even says this.) So, the exact same
>>phrase
>>>is
>>>used for completely different aspects of the same product, with
>>>contradictory recommendation. It'd be better to say something like
>>>"Classic
>>>Tools" - 256MB, 233MHz PII on the requirements page, IMO.
>>>
>>>Now the main reason I believe these minima are for the classic
>>tools is,
>>>they are the same as the requirements for the separately packaged
>>version
>>>of those tools in the old WDT, IIRC.
>>>
>>>So, bottom line, maybe--if all you do is RPG, CL, and DDS, install
>>the
>>>whole blame package (you have to anyway, until the latest version)
>>with
>>>classic tools (I forget the name on the install dialog) and do not
>>start
>>>WDSC itself, rather start the classic tools stand-alone. You will
>>not need
>>>
>>>a monster machine to do this. But the minute you want to try the
>>new
>>>client
>>>(which is getting better and better), get the horsepower - you'll
>>need it.
>>>
>>>And, BTW, I will not use either client for CL- formatting gets
>>really
>>>strange, compared to SEU. I like what I'm used to, behaviorally and
>>the
>>>results I get. I understand there are changes in the RSE client
>>>forthcoming
>>>but not in CODE - deprecation lives.
>>>
>>>Cheers
>>>Vern
>>
>>
>>_______________________________________________
>>This is the Websphere Development Studio Client for iSeries  (WDSCI-
>>L) mailing list
>>To post a message email: WDSCI-L@xxxxxxxxxxxx
>>To subscribe, unsubscribe, or change list options,
>>visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
>>or email: WDSCI-L-request@xxxxxxxxxxxx
>>Before posting, please take a moment to review the archives
>>at http://archive.midrange.com/wdsci-l.