Ignore an output parameter of RUN statement?

Your last solution is the obvious simple one.  The other approach is not to return indvidual values, but to return a value object containng the values, i.e., a single return parameter which is an object.  One can fake this with non-OO by using delimited name-value pairs and the like, but if you have OO then a value or parameter object is ideal.  Such objects have no behavior, merely properties with values.  Then, if you want to ignore the return value, simply don't read it.

Thanks for the input.  Ideally I would do something object-oriented similar to what you have provided, but as I said I cannot (my coworkers are unable to understand, and more unfortunately staunchly unwilling to learn OOABL).

However, it is comforting to know that there is nothing that can be done procedurally, as I thought.

Maybe you can sneak in a little OO!

Defining a value class is just putting a couple of property definitions in a class wrapper.  Assigning properties and reading them doesn't look much different than buffer operations, so really there is only the one NEW line to clue one in to the fact that OO is being used.

Who knows, once they see how flexible this is, they might like it.

In the extreme, you could even define a generic parameter class with a temp-table in it that has name and value fields (one per type if you like.  Add a few getter and setter methods and you are ready to go for any combination of parameters anywhere.

Hint, this is basically what is done for passing error messages since every error handler can have a signature that consists of a handle to where the error occurred and an error object which is one of the value objects thus supporting an open ended number of return values.

my coworkers are unable to understand, and more unfortunately staunchly unwilling to learn OOABL

...

Who knows, once they see how flexible this is, they might like it.

I would provide them with a sample of a parameter or value object and explain them how easy to use it is and how much simpler it will be to add additional (optional) parameters in the future.

Over the past years we have helped many Progress developers to introduce the GUI for .NET - and so basics of object oriented programming in the ABL. You need to convince your colleagues, that using a class here and there with OO code does not require full adoption of OOABL. Very often developers are afraid of a disruption in productivity when they need to introduce a new programming paradigm like OO. And that's absolutely true. There is a learning curve - yes of course. But that's for the full adoption of OO, not using a small class here and there (full OO adoption will pay in the end with greater productivity, but that's not subject of this discussion).

If you would provide them a sample parameter object and they could use it and copy it to other use cases that's a first step towards learning and using OOABL. No need to confuse them with inheritance and interfaces etc. ...

I've never made the experience the developers really dislike OOABL once they've seen it in action and in combination with procedural - legacy (?) - Progress code.

I've covered that as one use case in a EMEA PUG Challenge presentation: http://blog.consultingwerk.de/consultingwerkblog/2010/11/using-object-oriented-language-features-with-procedural-progress-code/

There's also a ZIP with a tiny sample.

Some good stuff in a similar vein at PUG Challenge Americas too! http://pugchallenge.org/index.html

if you are running foo.p with these parameters more than once, create a foo.p wrapper

foo2.p

def input parameter bar as whatever.

def input paramter baz as something else.

def var junk as int.

run foo.p (bar,baz,output junk).

then all your programs can now

run foo2.p (bar,baz).

The best way is, as mentioned, covert the parameters into an object.

*WARNING FOR WANNABE OO NEWBIES*

Beware though, an object parameter is INPUT-OUTPUT by nature.

Yes. Got bit by that a couple of times

I appreciate the advice, but I have tried many times before in many different ways and I'm simply burned out of trying.  My coworkers simply don't want to take the time to learn about these things; they just want to keep doing things the way that they've been done for the past 15-20 years.  They would much rather argue and stick their heads in the sand.

I'm glad that others have had better luck with different audiences.  Personally, I consider this attitude of resisting education in advances in techniques an affront to the principles of our profession and a slap in the face to developers who will have to maintain their code, but I digress.  I'm in the process of looking for another job already so hopefully it won't be my problem much longer.  All I can hope is that after looking at some code I've written years from now a light bulb will turn on in their heads

When I read your first paragraph, my first question was going to be "are you looking for a new employer?".  So, in addition to getting yourself to PUG Challenge, maybe you need to get your employer to come to so that they get the message that the old ways just don't cut it any more.

Which said, Julian's suggestion of using a facade is one way to get the job done without having to introduce any OO.  If it just very messy if there is more than one or two patterns of use.

Also, depends on what you are calling, but if it is an IP in a PP, you could always put the facade within the PP like it was an overloaded method and call the interface which fits.

Objects are pass by REFERENCE, not INPUT-OUTPUT.  There is a big difference. 

With input-ouput, if the parameter variable is reassigned during the course of the method/procedure, then the new value (in this case an object) is returned to the caller at the point of the invocation.  The original value stored in the caller's variable is lost.

With pass by reference, as with a standard input parameter that uses a type, you can reassign the input parameter, without affecting the caller, because the value of the object isn't copied, only a reference to the object is copied.

Yes, you are right - I was just trying to couch it in terms that

someone using parameters would easily understand. My bad.

I've only been out of school for a couple years (B.S. in Computer Science), so I am still well versed in design patterns (although that knowledge is starting to fade thanks to Progress).  It doesn't work well at all trying to explain them - even the simple ones - to people that don't understand object orientation.  Especially if they flat out refuse to try.

I appreciate your efforts to coax me into goading my employer about this, but it really isn't worth my energy.  I don't get paid enough at this job for all the effort required, and in fact I am degrading my resume by sticking around as long as I have.  Frankly, the employers I want to apply at will laugh at the notion of a "4GL" or "business language".  I know this because I do.  This isn't an issue for you contractors, as I'm sure you are well compensated for your expertise in this niche language, and frankly it appears a lot of you aren't far away from retirement anyway so you don't have to worry about a 10 or 20 year future outlook.

I find OOABL still incomplete, although you can do a lot of the basics with it.  But there are opportunities out there for me where I don't have to sit around on my hands (or worse, coding a bunch of workarounds) waiting for the technology to catch up to a competent level.

PUG Challenge Americas sounds like a great opportunity to update the old programmers on new Progress techniques, but what's new to Progress is like 10+ years behind the rest of the software industry.  No young programmer with any talent is going to make a career coding in Progress, because it is just a bunch of marketing BS and the actual implementation is not technically impressive at all (I'm sure in the 80's it was a different story).

IMO the smarter companies should move their data to better databases and leverage more competent programming languages, although I realize that it isn't simple for companies that have a large Progress codebase.  This would be the advice I give my employer, but an even bigger issue is what to do with the deprecated programmers who refuse to advance with the times.

Sorry if this sounds a little raw / brutally honest, but this is how I feel after my short time in Progress-land (I'm not trying to offend anyone).

What it sounds like is that you are allowing your experience in a regressive shop to sour you on the whole product.  I assure you the same could happen in many Java or C# shops as well.  You are completely wrong about where PSC is relative to the industry.  Yes, there are a few things which are not as far forward as I would like, but the pace of change is good and there are other areas where their products are leading the industry, not following it.  PUG Challenge Americas is most likely to help the young programmer who hasn't been exposed to the broader world of what is possible.  Us old fossils either have fgured that out long ago or will never learn.

It's true that this shop is probably somewhat 'regressive', but I have pushed ABL (/OOABL) to its limits in my own short time and am left unimpressed.  Even if this shop was on the cutting edge of what ABL/OpenEdge has to offer, I still would be exhausted with it, although I probably could have put up with it for a little longer.  I don't think there is anything at PUG Challenge Americas that would change my mind about it - I think ABL/OpenEdge is just not a good fit for me.  I think it might be better for people with MIS or tech. school degrees.

As far as PSC's other products - the only products they have that will affect me are ABL and the OpenEdge database, both of which I find archaic and uninteresting.  The pace of change in these systems is glacial compared to the innovation going on with other languages and databases.

That attitude is why you would get something out of PUG Challenge .. or even Revolution.  Who else in the industry provides intimate integration with BPM?  That is relevant to every shop interested in a modern application.  Do these other languages you fancy provide the simple, seamless integration with Sonic or any other ESB which is found in ABL?  And isn't SOA relevant to every application with an interest in supporting the requirements of modern business?  Maybe not every company needs CEP, but an increasing number are finding it an important way of timely response to rapidly changing business events and where else are you going to find a product as good as Apama or the seamless integration with ABL.  Yes, there are other monitoring and management tools than Actional ... but are they actually as good and do they support all the tools you want to use?

When 10.1A came out, I had a fair list of OO deficiencies.  Most of that list is now in the product.  More will be in the next release.  That is hardly glacial progress.  Yes, there are OO languages which have been evolving longer than ABL, but how much of what they have today did they have a few years ago ... and yet, a few years ago people were busy getting real work done despite those additions which had not yet been made.

It should probably be a new thread, but it would be interesting to hear what these overwhelming deficiencies are that you think exist.  I wouldn't be surprised if it included things I am glad are not in the language.

That attitude is why you would get something out of PUG Challenge .. or even Revolution.  Who else in the industry provides intimate integration with BPM?  That is relevant to every shop interested in a modern application.  Do these other languages you fancy provide the simple, seamless integration with Sonic or any other ESB which is found in ABL?  And isn't SOA relevant to every application with an interest in supporting the requirements of modern business?  Maybe not every company needs CEP, but an increasing number are finding it an important way of timely response to rapidly changing business events and where else are you going to find a product as good as Apama or the seamless integration with ABL.  Yes, there are other monitoring and management tools than Actional ... but are they actually as good and do they support all the tools you want to use?

I don't have the money or time to fly out to some conference just to hear about Progress.  Your first paragraph sounds like something out of a sales flyer.  If Progress is so great and all-powerful how come noone outside of the Progress bubble has heard of it?  Go to any software development oriented site not owned by PSC or an affiliated contractor and see how many hits you get for any of the above technologies.

When 10.1A came out, I had a fair list of OO deficiencies.  Most of that list is now in the product.  More will be in the next release.  That is hardly glacial progress.  Yes, there are OO languages which have been evolving longer than ABL, but how much of what they have today did they have a few years ago ... and yet, a few years ago people were busy getting real work done despite those additions which had not yet been made.
It should probably be a new thread, but it would be interesting to hear what these overwhelming deficiencies are that you think exist.  I wouldn't be surprised if it included things I am glad are not in the language.

A lot of my gripes are core design deficiencies that won't be able to be fixed due to backwards compatibility needing to be maintained.  I agree OOABL has gotten a lot better, but still needs improvement.  If you pay me for my time I'm sure I can come up with a decent list.  Otherwise, my time is better spent job hunting!

Over $500M a year in sales and over 160,000 customers is not an unknown company.

Sure, there are a lot of companies that still run COBOL too and make a lot of money (e.g. insurance companies and banks).  COBOL has also added object-oriented features in recent times, too.  But, as a developer, do I want to code in it?  Hell no; it's painful.

That said, ABL is better than COBOL, but not leaps and bounds like other more modern languages.  Specializing in a niche language like ABL is a risky proposition to a young developer (unless the shop uses the .NET CLR bridge to full advantage) because they are making themselves an endangered species.  For example, some of my coworkers who have been around for awhile are having trouble finding work because their true programming skills have rusted so much by coding ABL for so long that noone wants them because they aren't competent in modern techniques.  I don't want to end up like that.

Again, all my subjective opinion (a drop in the bucket).  Take it for what it's worth.  But you won't be convincing me of Progress' superiority because I have real-world experience with it and have earned great disdain for it.

The $500M is not a Progress customer; it is PSC, the people selling the technology.   AFAIR the figure for annual sales of PSC ISVs is significant number of billions and the total revenues of the companies they sell to may easily be in the trillions.  So, if you want to make a comparison, don't make it to the bank using COBOL, make it to the compnay that is selling new COBOL licenses and technology.

To be sure ... although job prospects are quite a branch from the topic of this thread ... there are fewer jobs in ABL than in Java ... duh.  But, take a closer look.  On average, an ABL programmer worth his or her salt gets a significant premium, exactly because they are hard to find.  Java programmers are a commodity.  At any giveen level, it is hard to set yourself apart from the crowd, even if you are good.  And, if you are mediocre, just average, aren't there hundreds of other people willing to do the same job?  An individual can stand out in either realm, but it is really hard to do so in Java, whereas the merely competant can get a premium in ABL.