Re: CRTSRVPGM

Bryce,

at the moment I don't see too much Serviceprogramms, sold by vendor a and used by other vendors, or in shops with homegrown software. There are some OpenSource Components out (Mihael is one of them, who delivers such things) , but I have the impression, that most of this stuff is copied to other (monolithic) programm sources (another great problem). And one of the points working against modular technics ist the complexity of static binding and the lack of the possibility for an easier to use mechanism of late binding and better checking at compile time. Its time that the developers of ILE and RPG take a look to java or C#.

D*B


--------------------------------------------------
From: "Bryce Martin" <BMartin@xxxxxxxxxxxx>
Sent: Thursday, January 13, 2011 2:43 PM
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: Re: CRTSRVPGM

Dieter.... Binding multiple modules to one SRVPGM makes a TON of sense as
a good developement practice for any ISV looking to create some sort of
"MODULE" to sell. Thus, this feeds your second point on delivering
SRVPGMs. If I'm an ISV trying to hauck my wares I would think that the
best way would be to have everything I can wrapped up in SRVPGMs.
Unfortunately this is not always the case from vendors, in fact it is
rare, but I believe that if this platform continues to carry on then
you'll see more and more new code delivered this way. Which is what it
was intended for.... so it seems to make a lot of sense to me.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



<dieter.bender@xxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
01/13/2011 07:32 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


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

Subject
Re: CRTSRVPGM






Mihael,

there are very few cases binder language might be usefull:
- binding multiple modules to one SRVPGM
- delivering SRVPGM Libraries
less compile work or using 3rd party SRVPGMS is no reason to use binder
language!

but the above conditions don't match to so many people and most usage of
binder language is nonsens and is not the medicine, but the illness!

Dieter


--------------------------------------------------
From: "Schmidt, Mihael" <Mihael.Schmidt@xxxxxxxxxxx>
Sent: Thursday, January 13, 2011 1:14 PM
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: RE: CRTSRVPGM

I don't agree with binder source beeing unnessecary. It is quite the
contrary.

We got a change management system which manages our code but the 3rd

party

libraries are not managed by the cms. So how do you make an easy

recompile

of all dependent programs when a new version of a 3rd party service
program comes in?

Simple and stable: that is binder source for me. What is more simple

than

just NOT having to recompile everything.

Without 3rd party service programs and a change management system it is
probably easy/easiest to just recompile everything but that situation is

not always the case.

(as always we disagree on this topic =)

Best regards

Mihael


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
dieter.bender@xxxxxxxxxxxx
Sent: Thursday, January 13, 2011 12:20 PM
To: Midrange Systems Technical Discussion
Subject: Re: CRTSRVPGM

from the programmer perspective, it's highly efiicient to keep it simple

and
stable !!!
Binder language seems to me to be one of the unnecessary annoying joke
features like /free /end-free (what the hell should it be else with a
blank
in column 6), eval (there comes an assignment afterwards!), callp (there
comes a function call afterwards), semicolons within statements
(preventing
from nesting an assignment in a condition)...

Dieter

That may not be the most efficient way but it seems to me to be the
simplest (Yes, I realise that with multiple modules, private procedures
will be rendered public). I'm sure we'll have some opposing views in a
couple of hours from now ;-)
--

--
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 message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us and destroy this message immediately. --- --
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.