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

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