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



>I never said that one should move everything to RPG...
>remember my statement about ILE concepts !  This allows
>a perfect synergy between the best of each language.

Hi Paul!
  Yes, I know you didn't advocate an 'RPG-only' approach - I was only trying
to make a point (and since this is the RPG list, trying to somehow link CL
and RPG!)

>Based on that, I see myself writing an RPG program
>that reads my change management database, and calls
>a CL program to do whatever you described
>regarding compiling, security, ... (and for none of these
>lasts steps I need database operations or complex datatypes).

As you say, there is certainly synergy there.  The point that the CL
expansion advocates are making is that with a little bit more structure
(real loops, subroutines) we could do all this in CL.

As for extra data types, I was thinking along the lines of a true MAKE
command.  I see myself writing several small CL commands (say RTVCRTINFO)
that would call an API to get the creation time stamp.  Another would get me
the source member change time stamp.  A simple comparison and I can
CRTRPGMOD/CRTPGM/CRTSRVPGM, etc.  Could this all be done in an RPG program?
Sure, especially if I wrapper the same functions in a service program.

>If I would be writing everything in CL, I would not
>be using best of both worlds, and even create huge
>monolithic programs.  Modular design is in any
>way the recommended approach and allows you to
>write the parts in the languages that suites best.

Well and truly said!  That's the point though - if CL had a few more
capabilities, we wouldn't be forced into the monolithic programs.  For me,
CL is so close to what I need, I really truly wish we could get these
extensions.

For instance, I routinely write my own commands to do stuff (RTVSPLFA,
RTVCRTINFO, etc.)  The commands return parameters that the CL then acts upon
to direct logic.  Being able to 'self-extend' CL this way since the 80's has
been great!  Only recently has RPG been able to do this through service
programs.  Now I have a dilemma - I have many modular CL commands, used in
many CL programs.  Maintenance is getting tough because of an inability to
propagate external file descriptions for parameter lists, no subroutines,
etc.  I can re-write the commands in RPG and make service programs and then
re-write the control logic in RPG, but all that CL is tested and debugged
already!  It's a tough spot to be in.

My hypothetical change management system was written in CL with many CMD
objects long before RPG IV was around.  It's not entirely CL because of the
database file limitations, and I wrote some commands with RPG CPPs to update
move times and so on, but the bulk of the 'logic' is driven by CL programs,
because it's almost entirely OS-level operations taking place.  I started
with an RPG III driver, but it got out of hand with the number of parameters
I had to pass to the CL.  It was so much easier to directly use CMD objects
in the CL, both for initial coding and ongoing maintenance.

I've already babbled on too long, but I do agree that writing everything in
one language is not the best approach.  My main point is that I have quite a
lot of logic already deployed in CL and that it would be easier to maintain
all that if CL were spruced up a bit.

Good thread!
  --buck


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.