× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Rob

I'm wiht you here, AFAIK. Use the best tool for the job at hand. Losts of system things are just hard in something other than CL. OTOH, if you don't need it, don't use it - go straight to the action.

Using a front-end CL is a vestige of System/36, I believe, where you had to have an OCL wrapper to do anything.

The details of what is bets done in which language becomes a matter of taste after a while. I find using a call to QCMDEXC to do an OVRDBF to be a bit cumbersome. But it is necessary in some circumstances, esp. when doing OPNQRYF based on user-entered values from a DSPF in RPG, which involves USROPN on the file. (Oy! Sorry!) Of course, that's probably better done now with embedded SQL.

But maybe that's how we can talk of the "art" of programming.

BTW, it was a few years before I saw much use of DSPFs in CL - the single-file limitation always bugged me. It'll be easier in V5R3 and on. Of course, the SNDF still does not do anything for data files, AFAIK.

Enough of this, I think. I' have to find Ernie Malaga's utility again - saw it once upon a time.

Vern

At 04:00 PM 5/28/2004, you wrote:
Here I am trying to convert people to fixed format in CL (at least parts
of it) and free format in RPGLE.  Seems odd eh?  But I bet there's those
that will go down fighting for the other way.

I still use CL for stuff that can remain all CL without being shoehorned
in.  Like maybe a nightly backup routine.  But I don't use CL for the sake
of "that's the way we've always done it".  Like always wrapping a HLL
program in CL.  Especially if it's only to do something like OVRDBF (which
is better done, documented, etc, if done in the RPG).  And I sure won't
use it for multifile processing, etc.

But in general you're right.  The enhancements are too late for me.  But I
can't say too little - too late.  Those enhancements are nice.  Especially
the structured programming capabilities.

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+rob=dekko.com@xxxxxxxxxxxx
05/28/2004 03:27 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] 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.

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.