×
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.
By this logic there is no reason to use service programs as any sub-procedure could be converted to a program in a similar manner. I have a service program that handles display file issues, and simple dialogs like this are part of that service program.
Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx
-----Nathan Andelin <nandelin@xxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Nathan Andelin <nandelin@xxxxxxxxx>
Date: 05/16/2017 06:29PM
Subject: Re: Service programs
So... I wish to get out of the 1990s and create a service program named
DropdownBox_PaymentTerms****. What would be a recommended organization for
this? **
After reviewing the code, I don't see a compelling reason to create a
*SRVPGM procedure from it. You could get some marginal benefit from a
procedure that returned the "term".
term = getTerm();
But that would not be much different than:
getTerm(term);
Where getTerm() is a *PGM call based on a prototype defined in the caller.
This mailing list archive is Copyright 1997-2025 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.
midrange.com
