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.



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