Wed, Apr
0 New Articles

RPG IV (aka "The Integrator") vs. C--The Final Conflict

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

In this, the last article of my series, you will examine some of the current deficiencies in RPG IV, critically evaluate the differences between RPG IV and C, and understand what RPG IV requires to position it as the premier integration language for the iSeries. While C, with its descendent C++, can afford to stay locked at its current level of support, RPG IV does not have that luxury and must continue to improve and evolve to secure the "Integrator" title for the iSeries. This article discloses the most critical areas where RPG IV severely lags behind C and explains why your favorite tool is in need of an evolutional design change and why you should be more concerned with this deficiency than with adding yet another %BIF in the next release. For the complete code for this article, click here.

A Brief Re-visitation...

In "What? RPG IV a Better C Than C?", the first article in this series, you learned the basics of prototyping C functions, using printf() as an example for flexible output results and as a debugging supplement, and you learned about some of the gotchas you may experience when mixing RPG IV with C. In the second, "How Could Life Be Better?", you saw the flexibility gained by using C database I/O functions rather than using the more static behavior of RPG I/O opcodes. Then, in "Interfaces in ILE RPG IV--Finding the Middle Ground", you advanced your technical prowess by discovering the importance of interfaces in object-oriented (OO) languages and by learning how to create similar binding commitments in RPG IV, with a corresponding source example demonstrated in Java. Now, it's time for you to explore what RPG IV requires in order to achieve its full potential and become the premier integration language for the iSeries platform and possibly more.

What Can Your Language Do?

To be competitive as a language that integrates applications written in other languages, a language must provide semantics and advanced programming constructs for such things as abstract data types (ADTs--for example, user-defined data types), free-form algorithmic expression, separate variables storage area and scope resolution for procedures (local variables), full data type support for the range of commonly supported primitive data types, embedded ANSI SQL support (including support for stored procedures and triggers), both automatic and on-demand memory allocation, statically ("strongly") typed pointers and references for both primitive data types and ADTs, interoperability with other languages (both procedural languages and Object-Oriented Programming Languages [OOPLs]), support for all types of binding (static, referential, and dynamic), built-in functionality to convert strings between diverse encoding schemes (supporting cultural language independence), and the ability to bind with APIs that support diverse communications and data exchange protocols and formats (for example, the XML format using the SOAP protocol over TCP/IP).

As noted in "What? RPG IV a Better C Than C?", with the exception of full free-form expressions and statically typed pointers and references, RPG IV fulfills all of these requirements and adds %BIFs for such things as file status indications; rounding and editing of diverse numeric types; string manipulation and conversion functions; manipulation functions for time, date, and timestamp data types; etc.

What Is Lacking in the RPG IV Language?

For the RPG IV language to properly evolve and fulfill its niche as an integration language, statically typed pointers and references, for ADTs as well as for primitives, absolutely must be at the top of the list of things the developers at Rochester need to pay particularly close attention to. While static type checking by the compiler is accomplished on function prototypes for primitives (except with length on character fields), such checking is lacking on pointers and references to variables of a data structure type. Statically typed pointers and references are important both for elimination of runtime errors in arguments passing (shifting responsibility to the compiler to catch invalid arguments) and for proper function signature resolution (better granularity) should function overloading be added. For example, you have probably experienced the problem of either passing a parameter on a program call that was longer than that expected by the called program or passing parameters in the wrong order. Unpredictable runtime results usually occur. A similar situation arises when you pass a basing pointer to a called function that uses it for a structure (ADT variable) that does not match the structure it is based on.

Why Is Static Type Checking So Important?

The code in Figure 1 demonstrates the current deficiencies in static type checking in RPG IV, as compared to C. In the example, an ADT called Address (A in Figure 1) has been defined with the typical subfields of name, address lines 1 and 2, city, state, and ZIP. Additionally, another ADT named Bogus (C in Figure 1) has been defined with distinctly different content that's more representative of an item in inventory, with subfields such as item, on-hand quantity, and price.

     h dftactgrp(*no) actgrp(*new) bnddir('QC2LE')

     d printf          pr                  extproc('printf')
     d                                 *   value options(*string)
     d                                 *   value options(*string)
     d                                 *   value options(*string:*nopass)
     d                                 *   value options(*string:*nopass)
     d                                 *   value options(*string:*nopass)
     d                                 *   value options(*string:*nopass)
     d                               10u 0 value options(*nopass)

     d newline         c                   x'25'

     d printAddress    pr
      * Data pointer not strongly typed for Address *
     d                                 *   value

(A)  d Address         ds
     d  name                         30a
     d  add1                         30a
     d  add2                         30a
     d  city                         20a
     d  state                         2a
     d  zip                          10u 0

(B)  d myAddress       ds                  likeds(Address)
     d yourAddress     ds                  likeds(Address)

(C)  d Bogus           ds
     d  item                         15a
     d  onhand                       10i 0
     d  price                         8f

(D)  d myBogusItem     ds                  likeds(Bogus)


         // Initialization of myAddress
         myAddress.name  = 'My Name';
         myAddress.add1  = 'My First Address Line';
         myAddress.add2  = 'My Second Address Line';
         myAddress.city  = 'My City';
         myAddress.state = 'MS';
         myAddress.zip   = 55555;
   /     printAddress(%addr(myAddress));
        // Initialization of yourAddress
         yourAddress.name  = 'Your Name';
         yourAddress.add1  = 'Your First Address Line';
         yourAddress.add2  = 'Your Second Address Line';
         yourAddress.city  = 'Your City';
         yourAddress.state = 'YS';
         yourAddress.zip   = 66666;
         // Initialization of myBogusItem
(F)      myBogusItem.item   = '145L_X203';
         myBogusItem.onhand = 152;
         myBogusItem.price  = 38.9500;

         // Remove the comment indication from the line below and compile
         // the printAddress statement passing the Bogus structure.
(G)      printAddress(%addr(myBogusItem));

         *inlr = *on;
     p printAddress    b
     d                 pi
     d ptr_to_Address                  *   value

     d inAddress       ds                  likeds(Address)
     d                                     based(ptr_to_Address)

(H)             printf(newline+'%s'+newline+'%s'+newline+'%s'+newline+'%s, '
                      +'%s. %d'+newline
     p printAddress    e

Figure 1: Type checking in RPG IV

At B in Figure 1, two variables, myAddress and yourAddress, are declared to adopt the ADT structure of Address. Then, at E, they're initialized with appropriate values. Meanwhile, a variable called myBogusItem is declared to adopt the Bogus ADT at D and initialized with appropriate values for that data type at F. In each of these situations, after the variable has been initialized, a function called the printAddress() function (which takes a pointer, presumably to an Address ADT) is invoked. Yet, in G, you can clearly see that a pointer to myBogusItem is passed to the printAddress() function. This mistake is unfortunate but typical. The printAddress() function (H) uses the printf() C function to print the results to the display. This example compiles perfectly, but it fails to produce desirable results. So why didn't the compiler catch the mismatch of type?

Figure 2 shows the identical function coded in C.


(A) struct Address{
      char name[30];
      char add1[30];
      char add2[30];
      char city[20];
      char state[2];
      unsigned int zip;

(B) struct Bogus{
      char   item[15];
      int    onhand;
      double price;

    /* Data Pointer Strongly typed for Address struct */
    void printAddress(struct Address *);

    int main(int argc, char* argv[])
(C)   struct Address myAddress, yourAddress;
      struct Bogus myBogusItem;

     /* Initialization of myAddress */
      strcpy(myAddress.name,"My Name");
      strcpy(myAddress.add1,"My First Address Line");
      strcpy(myAddress.add2,"My Second Address Line");
      strcpy(myAddress.city,"My City");
      myAddress.zip  = 55555;
  /   printAddress(&myAddress);
    /* Initialization of yourAddress */
      strcpy(yourAddress.name,"Your Name");
      strcpy(yourAddress.add1,"Your First Address Line");
      strcpy(yourAddress.add2,"Your Second Address Line");
      strcpy(yourAddress.city,"Your City");
      yourAddress.zip  = 66666;

     /* Initialization of myBogusItem */
(E)   strcpy(myBogusItem.item,"145L_X203");
      myBogusItem.onhand  = 152;
      myBogusItem.price   = 38.9500;

     /* Remove the comment indication from the statement below */
     /* and attempt to compile and run the program             */
(F)     printAddress(&myBogusItem);                            

    void printAddress(struct Address * inAddress)
(G)    printf(" %s %s %s %s, %s. %d ",
              inAddress->name, inAddress->add1,
              inAddress->add2, inAddress->city,
              inAddress->state, inAddress->zip);

Figure 2: Type checking in C

Once again, an ADT called Address has been defined to contain the typical subfields in the structure with name, address lines 1 and 2, city, state, and ZIP in A of Figure 2. Then, in B, Bogus has been defined just as it was in the Figure 1 RPG IV example--as an item in inventory. The two address variables, myAddress and yourAddress, are declared in C to adopt the structure of Address. The Bogus variable myBogusItem is also declared in C, as it was in the RPG IV example. In D, both myAddress and yourAddress are initialized identically as they were in the RPG IV example. In E, myBogusItem is initialized the same as it was in its RPG IV counterpart. As in the RPG IV example, a function named printAddress() has been declared and defined to take a pointer to an Address ADT and print the expected results (G of Figure 2). And once again, you can see in F that a pointer to myBogusItem has been inappropriately passed to that function. However, this time you get completely different results when you attempt to compile it.


*=SEVERE==========> a -  CZM0280  Function argument assignment between types "struct Address*" 

and "struct Bogus*" is not allowed. 

Figure 3: C knows the difference in types pointed to

In Figure 3, you see that the C compiler rejects the statement in F of Figure 2 that attempts to pass a pointer to a Bogus ADT instead of a pointer to an Address ADT. This is a good example of static type checking, something RPG IV currently lacks and seriously needs in order to properly evolve.

In a somewhat perfect world, you would be able to define a print() function in different forms like the example shown in Figure 4: one for an Address ADT and another for a Bogus ADT.

  /* To print an Address ADT */
       d  print  pr
d    pointer_to_address_adt *    static_cast(Address) 


/* To print an Bogus ADT */
       d  print  pr
d    pointer_to_bogus_adt *    static_cast(Bogus) 


Figure 4: Static casting in a perfect RPG world

You'd then define different procedure code to properly print the type being pointed to. This is the essence of function overloading, and it's what RPG IV needs. Given the new static_cast keyword (or something like it) and a type specified in parentheses, the compiler would be able to resolve the function name ambiguity by casting the pointer in a prototype to a particular data type (ADTs included). The compiler would then invoke the proper version of the print() function reflected by the type passed. Currently, the basing pointer simply points to a void* data type, meaning that it can point to anything. This is a fairly significant deficiency in the RPG IV type-checking system that must be corrected for RPG IV to move forward, and it was recognized as such by Bjarne Stroustrup in The Design and Evolution of C++ when he stated, "Allowing implicit conversions of void* to other pointer types would open a serious hole in the type system." Static type checking is a significant feature requirement for any language that contemplates OOPL attributes like function overloading. Stroustrup went on to say, "Static type checking was to me, after my experience with Simula and Algol68, a simple must...."

IBM can add all the %BIFs it wants, but until this flaw has been corrected, RPG IV will cease to be competitive and will eventually become a minor language even on the iSeries platform.

Function Overloading--What Is It and Why Does RPG IV Need It?

Ranked recently in an MC Press Online poll as seventh (in a three-way tie) out of 10 choices for new RPG features (receiving only 4% of the vote when this article went to press), parameters (or function) overloading can't get any respect from RPG programmers. Perhaps that's because, unless you're a Java or C++ programmer, you have heard the term but weren't quite sure what to make of it. Function overloading is usually discussed in the context of OOPLs but is equally applicable to procedural languages like RPG IV. It is also prerequisite to enhancing a procedural language to enable it for OO development, as it is capable of acting as an integrator between diverse, and often differently constructed, types (objects). As you have seen in this discussion so far, only OO languages typically implement function overloading, but as an integration language, it is critical for RPG IV to have this capability. While C has a static type checking system (but did not always), it does not implement function overloading, as shown both in the failed attempt to overload the print() function in Figure 5 and in the prototypes from the CNOOVRLD program written in C in the downloadable source with this article. C left that to its descendent, C++.

/* Print function for Address struct */
   void print(struct Address *);

/* Print function for Bogus struct */
   void print(struct Bogus *);
*=SEVERE==========> a - CZM0343  Redeclaration of print differs from 

previous declaration on line 29 of "JBARNESS/QCSRC(CNOOVRLD)".
*=INFORMATIONAL===> a - CZM0377  The type "struct Bogus*" of parameter 1 

differs from the previous type "struct Address*". 

Figure 5: Failed attempt to overload print() in a C program (CNOOVRLD)

To give you an idea of the importance of function overloading in an OOPL, Figure 6 presents the same application you saw earlier in Figures 1 and 2, but Figure 6 presents it in Java to demonstrate function overloading.

import java.text.*;

class OverLoad{

(A) static class Address{
       String name, add1, add2, city, state;
       int zip;

       // Constructor 
       Address(String name,
              String add1,
              String add2,
              String city,
              String state,
              int zip)
         this.name = name;
         this.add1 = add1;
         this.add2 = add2;
         this.city = city;
         this.state = state;
         this.zip = zip; 
(B)    public void print()
          System.out.print(" "+name
                         +" "+add1
                         +" "+add2
                         +" "+city.trim()
                         +", "+state.trim()
                         +". "+zip);
(C)    public void print(String special_message)
          System.out.print(" "+ special_message);

(D) static class Bogus{
       String item;
       int    onhand;
       double price;

       // Constructor
       Bogus(String item,
             int onhand,
             double price)
         this.item = item;
         this.onhand = onhand;
         this.price = price;

(E)    public void print()
          System.out.print(" Item: "+item
                         +" On-hand: "+onhand
                         +" Regularly priced: "+price+" ");
(F)    public void print(double markup)
          System.out.print(" For you the special price of:"
    +" "+NumberFormat.getInstance().format(price*markup));


(G) static public void main(String[] args)
(H)   Address myAddress = new Address("My Name","My First Address Line",
                                      "My Second Address Line",
                                      "My City", "MS", 55555);

(I)   Address yourAddress = new Address("Your Name","Your First Address Line",
                                      "Your Second Address Line",
                                      "Your City", "YS", 66666);
      yourAddress.print("A special address for a special person...");

(J)   Bogus myBogusItem = new Bogus("145L_X203",152,38.9500);

Figure 6: Function overloading in Java

In the OverLoad class written in Java in Figure 6, you can see the Address ADT has been represented as a static inner class in A. (For the moment, don't worry about what static inner classes are--for purposes of this exercise, you are using them simply to reduce the number of source modules required to compile a functioning, self-contained application.) Additionally, you can see that it contains the data elements expected--a name, address lines 1 and 2, city, state and ZIP. Also note that two print() functions--one that takes no arguments (B) and one that takes a String argument containing a special_message (C)--have been defined for this class. The two print() functions can exist in the same class because of the signature differences and can be properly accessed by the compiler because of the function overloading feature built into Java.

Notice that the Bogus ADT has also been represented as a static inner class in D. Once again, this type (class) has been represented to be consistent with previous examples in this article, as an item in inventory with an item code, on-hand quantity, and price. The Bogus type has also been defined to include two print() functions--one that takes no arguments (E) and one that takes a double argument as a percentage markup on the price (F). This is another good example of function overloading in action--two functions with the same name but different signatures, co-existing in the same module or class.

The actual objects for these two classes are created in the main() body of the OverLoad class starting at G. At H and I, you can see the creation of the two Address ADT variables (objects), myAddress and yourAddress. Then, at J, you can see the creation of the Bogus ADT variable, myBogusItem. The objects are created using the new operator. (Note: If you refer to the C++ code, this is accomplished as a part of the variable declaration with an implicit call by the compiler to the constructor of each type, but it could also have been an explicit call to the new operator in C++.) You can see in H of Figure 6, myAddress.print() selects the address print() function that only prints the address, while in I, yourAddress.print("A special address for a special person...") opts to use the version of print() that prints a message as well as the address. In fact, it uses the base print() function that has no arguments to print the basic address information as shown in C. In J, you can also see that myBogusItem.print(1.5) selects its version of the print() function that calculates and prints an item with a marked-up price, once again calling the base print() function that has no arguments to print the basic inventory information as shown in F.

The function overload feature can also be seen as a valuable feature in C++. While I have included C++ source along with the other downloadable code with this article, it is not valuable to present it as another item for discussion here. However, you should examine the source, if only to acquaint yourself with how function overloading is defined and represented in C++.

Function overloading would not be possible (or certainly not safe) without the language having previously implemented a good static type-checking system to resolve function name ambiguity (to bind the proper function call at the appropriate places, usually using a name-mangling technique) and enable compile-time rather than runtime errors to be detected when the wrong type is passed to the a function (you saw this deficiency in the RPG IV example).

Who's in the Lead, C or RPG IV?

While it can be argued that C supports many %BIF functions currently in RPG IV, there are some that have no comparable equivalent in C. These %BIFs add an ease and elegance not supported in the C procedural language. Add to that the JNI wrapper support for Java in the form of the (O)bject data type in RPG IV, and RPG IV barely pulls out in front ahead of C in unique built-in features and interoperability, and some would argue, with better print file support (I would be remiss to not at least mention that). And while C has a stronger type checking system implemented than RPG, it does nothing significant with it until C++. In most of the other areas listed, RPG IV and C run neck and neck.

However, C++ (as a direct descendant of C) clearly eclipses RPG IV (as it should, being an OOPL) with function and operator overloading and true objects (data wrappered with function). Yet, most C++ compilers still support source written using standard C procedural syntax. This same strategy could be taken with RPG IV (ILE RPG). IBM could provide a version of the ILE RPG compiler that could be used to assemble code written in RPG++ (for example) for object-oriented applications, yet still support the procedural syntax of RPG IV. This would help bridge the semantic and conceptual gap that currently exists between procedural RPG developers and Java (or C++) developers.

From my perspective, the point is to learn OO design and analysis concepts (constructs and patterns), not any one particular OOPL. It is this knowledge that is transferable from one OOPL to another; makes OO programmers productive and efficient; and ensures OOPL projects meet time, features, and performance objectives. Otherwise, Java (or C++) is "just another language to learn." The skills you acquire can help you simply use the language or help you use the language well.

This knowledge would go far in helping to avoid costly mistakes that occur during the application design and early-implementation stages because of the lack of understanding of the design initiatives on one side or the other. And this is why IBM should roll forward (without delay) to an OO version of RPG. Just like the dinosaurs, RPG must evolve or fade into extinction. What's the alternative if RPG goes extinct?

I'd Like a Mocha, Light on the Espresso, Please

A new form of Java has been slowly entering the market that I like to call "JAVARG." It uses Java syntax with an RPG flavor, but without the (P)rocedural aspect (thus dropping the "P" from RPG). JAVARG is a strange animal in that it does not usually conform to the Sun-recommended naming conventions (so you are likely to see all uppercase-named objects, such as MYJOBQ, instead of myJobq) and uses opcode methods like MYFILE.CHAIN() to retrieve data from an iSeries server, while under the hood actually using SQL SELECT to get the data. In so doing, JAVARG has, and rightly so, earned frowns and scorn from real Java programmers. The tools used in conjunction with JAVARG (RPG/400-to-Java translators and cut-and-paste IDEs) attempt to keep the programmer insulated from the true OO nature of Java by turning them into business rules writers rather than earnestly helping them make the switch to Java.

There will quite likely be a need for JAVARG programmers in iSeries organizations that are happy with the business analytical skills of their RPG staff and do not have the resources to train a new staff of Java developers in industry-specific knowledge. Their business worth is more valuable to these organizations, which are not in the software business, than pure technical talent. You just need to decide if JAVARG is for you and become familiar with the limitations it imposes.

Power and Sleek Design

You probably never thought you'd hear the words "power" and "sleek design" used to describe the RPG language. However, if IBM moves the language to the next evolutionary step and makes RPG IV the premier integration language of choice on the iSeries platform, software artisans would be challenged to take another look at the new and improved RPG language.

Why evolve? Why not? This next logical step for RPG IV plugs a long-standing type safety hole. And languages other than RPG IV (C, for example) have taken on the OOPL challenge and succeeded. There is ample documentation on the problems you must overcome to reach your destination, and there's a roadmap on how to get there (OOPL) from here (procedural language). Let's give the developers at Rochester an interesting challenge rather than just another %BIF to implement. Move parameters (function) overloading to the top of your wish list and tell IBM to hurry! You can't wait until next Christmas!

Jim D. Barnes is a freelance writer and Systems Engineer in Plano, Texas. Jim can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

Jim D. Barnes is a freelance writer and Systems Engineer in Plano, Texas.



Support MC Press Online

$0.00 Raised:

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: