Re: Scoop on v5r3 CL enhancements

SOP is that if you compile them to run at an earlier release they will run 
at that earlier release.  However, any new feature that used in a program 
that is V5R3 specific will cause the compile to fail if compiled for a 
previous release.  SOP is also that you can only compile down to release - 
(1 or 2).  Don't know if V5R3 is any different, but that's the way the SOP 
has been.

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: midrange-l-bounces+rob=dekko.com@xxxxxxxxxxxx
03/17/2004 08:27 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Scoop on v5r3 CL enhancements






And a big TeeHee right back atcha!

But a question arises - can programs created at V5R3 run at earlier 
releases (I suppose back to V5R1)? Probably not, but it'd be cool if they 
could.

Vern

At 08:05 PM 3/17/2004 -0500, you wrote:
>Hee, hee, hee.  Now there's one person slathering at the bit for V5R3.
>
>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: midrange-l-bounces@xxxxxxxxxxxx
>03/17/2004 05:35 PM
>Please respond to
>Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
>
>
>To
>Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
>cc
>
>Subject
>Re: Scoop on v5r3 CL enhancements
>
>
>
>
>
>
>dcl &cantusecmd *char 7 'CPFxxxx'
>dcl &cantuselib *char 7 'CPFxxxx'
>dcl &cantusefil *char 7 'CPFxxxx'
>
>mycommand
>     monmsg cpf0000
>     rcvmsg msgid(&msgid) rmv(*yes)
>     SELECT
>        WHEN COND(&msgid *eq '       ') /* everything is cool */
>        WHEN COND(&msgid *eq &cantusecmd) THEN(DO)
>                /* oops security issue, alert the proper people */
>             ENDDO
>        WHEN COND(&msgid *eq &cantuselib ) THEN(DO)
>                /* library issue */
>             ENDDO
>        WHEN COND(&msgid *eq &cantusefil ) THEN(DO)
>                /* File issue */
>             ENDDO
>        OTHERWISE CMD(DO)
>                /* now we have an opportunity for improvement */
>             ENDDO
>     ENDSELECT
>
>At 03:17 PM 3/17/2004 -0500, you wrote:
> >Through the use of API's or the use of either QCAPCMD, QCMDEXC or
> >system().  Whichever one I favor at the time.  I like the flexibility 
of
> >QCAPCMD, but it takes a little longer to set up.  Since Barbara showed 
us
> >how to use RPG's PSDS to handle QCMDEXC better I've gotten rather fond 
of
> >that one again over system().
> >
> >How would you code the following in CL?
> >callp(e) QCMDEXC(mycommand:cmdlen);
> >Select;
> >When exceptionid=*blanks;
> >   // everything is cool
> >When exceptionid=YouCannotUseThatCommand;
> >   // oops security issue, alert the proper people
> >When exceptionid=YouCannotAccessThatLibrary;
> >   // library issue
> >When exceptionid=YouCannotAccessThatFile;
> >   // File issue
> >Other;
> >   // now we have an opportunity for improvement
> >EndSl;
> >
> >The following?
> >MYCOMMAND ...
> >MONMSG CPF###1 EXEC(DO)
> >...
> >ENDDO
> >MONMSG CPF###2 EXEC(DO)
> >...
> >And what happens if an intermediate command in the first MONMSG 
triggers
>a
> >different MONMSG condition?  Once you get a few lines of code in there 
it
> >get's tough to associate what triggered off what MONMSG.  I just find
> >using the API's encourage a more structured model.  And thus may
>encourage
> >you to trap for more error conditions.  Sort of like assuming an error 
on
> >a read was due to the fact that the record was not found.  When it 
could
> >be any number of conditions:  you forgot to open the file, a trigger
> >program aborted the read, etc.
> >And especially since most people using CL probably also use SEU it's 
not
> >that the code will be spaced nice, (read as "imbedded do loops").
> >
> >
> >
> >Rob Berendt
> >--
> >Group Dekko Services, LLC
> >Dept 01.073
> >PO Box 2000
> >Dock 108
> >6928N 400E
> >Kendallville, IN 46755
> >http://www.dekko.com
> >
> >
> >
> >
> >
> >Pat Barber <mboceanside@xxxxxxxxxxxxxxxx>
> >Sent by: midrange-l-bounces+rob=dekko.com@xxxxxxxxxxxx
> >03/17/2004 05:51 PM
> >Please respond to
> >Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> >
> >
> >To
> >Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> >cc
> >
> >Subject
> >Re: Scoop on v5r3 CL enhancements
> >
> >
> >
> >
> >
> >
> >Just a small question..
> >
> >How do you constuct complicated job streams with many programs ?
> >I assume you have job streams of some sort.
> >
> >
> >rob@xxxxxxxxx wrote:
> >
> > > I think these new CL enhancements are nice.  However it may be too
>late.
> >
> > > I've already gotten as much away from CL as possible.  I find the
> > > flexibility in RPG, more functionality with the API's, etc the way 
to
> >go.
> >
> >
> >_______________________________________________
> >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/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/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/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/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/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.