13
Fri, Dec
4 New Articles

Practical RPG: Service Programs–Why?

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Service programs let you use your business logic with more flexibility.

If you've never heard of a service program or actually worked with one, there are many fantastic introductory resources out there. We here at MC Press Online have a wide selection of them, including great articles written over the years and excellent books as well. They provide a thorough explanation of the fundamental concepts, and I recommend that you use those resources prior to beginning your journey into service program design. But if you already know the basics of service programs and have maybe even dipped your toe into the architecture of modules, binder source, and UPDSRVPGM, then you might now be asking a simple question: Why would I use a service program?

Not Just a PLIST on Steroids

At the simplest level, service programs contain procedures that you can call using prototypes. Service programs essentially allow you to encapsulate common business logic used by multiple programs into a single entity, which in turn provides future-proofing; change the business rules in one place (the service program) and it takes effect throughout the entire application. To be sure, this can be done in other ways: called programs or even /COPY books (eww!). And when people first begin implementing service programs, one of the things they do is write a procedure for each called program.

To me, the primary benefit of service programs is that they provide multiple interfaces to the same business logic. To appreciate how this behavior allows us to write better code, we have to understand some concepts from the world of object-oriented programming (OOP). In OOP, the ability to call the same business logic different ways is called “polymorphism,” and it's one of the most powerful techniques you can use to future-proof your code, because it allows you to start with a basic implementation and add features as time goes on.

I'm going to avoid delving too deeply into OOP for the time being. If you'd like to familiarize yourself with some of the conceptual framework around polymorphism, you might want to investigate some of the related terms, such as Adapter and Facade. A wealth of information is available online; as one example, I suggest reading Thorben Janssen's article on Stackify as a fantastic overview of the Adapter. Just understand that ILE doesn't directly support OOP, but it does allow us to borrow the concepts.

Let's start with the fundamental difference between calling a program and calling a service program procedure. The first thing to note is that you don't call a service program, you call a procedure in the service program. And since you can have many procedures in the service program, that means a service program has multiple entry points. That's the magic! Let me take a real-world example of this. An old ERP system I work on employs a very old-school way of converting between numeric and alphanumeric values. It uses a /COPY book that defines a subroutine. The calling program loads a bunch of predefined variables with data and then performs an EXSR (execute subroutine) to the appropriate subroutine. When the subroutine returns, the program checks other predefined variables for the results. Since the subroutine is complex (it can handle various precisions, different language settings, and so on), the application has to set quite a few variables. Programs end up with hundreds of lines of code to set up, invoke, and retrieve the results from this one subroutine. But with the service program, I write a single procedure that accepts all the possible variables, and then the call requires only a single line of code, like this:

   Convert( wNUM: wALPH: 'M': 7: 2: '.');

I pass both the numeric field and the alpha field. This particular routine works that way natively. You clear one field and put a value in the other, and the routine determines which way to convert based on those values. This would also be the case when calling a program. All the parameters would be in the PLIST, and the calling program would pull the return value out of the list. Note, though, that at least in this case you can pass some constants. The prototype looks like this:

     dcl-pr Convert extproc(*dclcase);

      uNUM packed(29:9);

      uALPH char(29);

      iEDTC char(1) const;

      iDCCD packed(1) const;

      iFLDD packed(2) const;

      iDCFM char(1) const;

     end-pr;

So the two value fields, uNUM and uALPH, are specified at the beginning with large field sizes (these are the maximums for the routine). The rest of the fields are specified with the keyword CONST, which allows us to pass them in as variables, literals, or even calculated expressions. It's very powerful stuff. Oh, you may also have noticed that I used the keyword *DCLCASE on the EXTPROC statement. That will force the procedure name Convert to be declared to the rest of the system in mixed case. The default in RPG is to uppercase everything. I originally had to do this because of a bug in Rational Developer, but I think I may use mixed case for everything moving forward.

Now the Power—Order and Default

So you might be looking at this and saying to yourself that I didn't do much more than create a prototype for the subroutine, and that you could have done that without a service program by simply moving the conversion code to a standalone program and defining a prototype. Yes, that's correct. But now that we have the base procedure in place, the power of polymorphism come into play.

For example, I probably shouldn't have to specify the decimal separator over and over again. In fact, with a little forethought, I shouldn't have to specify it at all; it should at least be optional. And ILE RPG supports optional parameters just fine as long as they're at the end. All I would have to do is change the parameter definition slightly.

iDCFM char(1) const options(*nopass);

In my program, I skip the decimal separator:

   Convert( wNUM: wALPH: 'M': 2: 7);

The Convert routine checks for the parameter and if not passed, defaults it to something appropriate. That works well at the end of the parameter list, but a problem arises when an optional parameter is somewhere in the middle. For instance, if I find that I'm using edit code M most of the time, I might want that as the default. Unfortunately, the edit code is near the beginning of the parameter list, and I can't use the *NOPASS technique, because I will always specify the digits and decimals. You can't just skip a parameter in the middle of the list. Now, ILE does support a technique called *OMIT, which would look something like this:

   Convert( wNUM: wALPH: *OMIT: 2: 7);

In the called program, you can check for an omitted parameter using a little RPG magic, but the syntax is very RPG-specific and I've never been entirely comfortable with it. I would prefer not to specify unnecessary parameters at all, and with service programs that's easy to accomplish. In this particular case, I just create convenience procedures with only the parameters I need, in the correct sequence. These would be called Adapters in OOP terms. Here is one:

     dcl-pr ToAlpha char(15) extproc(*dclcase);

      iNUM packed(15:6) const;

      iFLDD packed(2) const;    

      iDCCD packed(1) const;

      iEDTC char(1) const options(*nopass);

      iDCFM char(1) const options(*nopass);

     end-pr;

This simple routine shows all of the power of service programs and prototypes. Remember that the original required that I use work variables that are passed to the procedure. So, in addition to the call, I'd also have to do some data movement. Here's the entire sequence to convert a numeric value in ORQTY to a display value in XQTY:

   wNum = ORQTY;

   clear wALPH;

   Convert( wNUM: wALPH: 'M': 2: 7);

   XQTY = wALPH;

This is in addition to a couple of DCL-S statements to define the work variables wNUM and wALPH, and it closely mirrors what you would do with an external program using a PLIST. But with the convenience procedure, the code is much simpler:

   XQTY = ToAlpha( ORQTY: 7: 2);

I moved the less-used parameters to the end of the procedure, so it's easier to leave them out. I swapped the number of digits and number of decimals to the order we're more used to seeing in RPG BIFs. But there's also one very important additional feature. The application software has two default sizes: high-precision internal 29-character values and the more commonly used 15-character variants used in database files and displays. I changed the width of the parameters on the convenience methods to use the more common sizes. The convenience procedure ToAlpha widens the data before calling the base procedure Convert and narrows the result before returning it to the caller. Also, I have one procedure dedicated to taking a number and converting it to alpha; another procedure (ToNumber, not shown here) converts an alpha value to a number. Because ToAlpha returns a value instead of updating a work variable, I can directly assign the result of the call to my target variable. I can't emphasize enough how important that becomes as you build more-powerful libraries of procedures. Finally, my default edit code is M and my default decimal separator is a period, which means conversions become very simple. I don't need work variables and can omit the defaults, so all the work is done with a single, easy-to-read line of code.

And perhaps the most important thing to remember is that all the convenience procedures still call the base procedure Convert. Because of that, any fixes or enhancements to Convert are automatically available to all the calling programs. And because they use a service program, they don't even have to be recompiled. To me, this is the best way to architect your applications to build immediately functionality but provide future-proofing at the same time.

Other Characteristics of Service Programs

While polymorphic behavior is probably the most immediate tangible benefit of service programs, service programs provide many more advantages. Another critical area is inter-communication among parts of your application. Service programs allow you to define data that can be shared between procedures in a module, between modules in a service program, and even among all the programs that call the service program procedures. The service program can initialize variables and keep track of state, if you design it to do so. We'll look at these and other capabilities in another article.

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: