IBM i Multiple Language Support Generates Value Decisions

June 15, 2015 Dan Burger

IBM i support for multiple programming languages leads to freedom of choice, but that doesn’t necessarily make the choice easy. Many of the application development experts say picking a programming language depends on the goal in mind and, of course, which language skills the user possesses. But to say you can’t argue with that is an oversimplification. RPG is always going to be an IBM midrange programmer favorite no matter what. And then there’s the native versus non-native debate.

IT Jungle turned to several application development experts with deep experience and various opinions on programming language decisions.

For database access and business rules, Scott Klement believes RPG to be the most efficient. “RPG is a very elegant environment for that. It’s easier to maintain. It uses the job log to track errors and it runs natively on the system so it takes advantage of the integrated nature of the operating system. The majority of people on this platform are writing database-heavy business applications, and for that reason RPG is a great choice,” he says.

Richard Milone agrees, calling database access “normally the first hurdle you need to overcome” when using non-native languages.

“RPG developers are amazingly spoiled by having access to rocket-fast record-level access and easy and fast SQL integration. Doing this from other languages is doable, but care must be taken that performance is maintained,” Milone says.

For other types of applications, Klement points out, other languages may be more efficient. When the goal is to generate Web pages, PHP is a language designed for outputting Web pages, so it can be done with less code. The same can be said for languages such as Ruby, Net.Data, and Java (if Java is running in an application server such as WebSphere or Tomcat.)

Ruby is considered to be a very user-friendly language by Aaron Bartell, who believes Ruby lowers the barriers of entry to programming. Many of the scripting languages are able to do more with less. As an example, he says that he recently rewrote a CL program and reduced the lines of code by 50 percent.

Bartell also is impressed with Node.js, which is a server variant of JavaScript, because of its efficiency advantage of essentially being the same language in the Web client as on the backend server.

“This is special because we have a finite capacity to learn new things. Having a single syntax, (where before there was two), is a significant advantage to the developer.”

Klement is fond of Node.js, a language he describes as “extremely efficient” and “very elegant.” Another of the Node.js benefits is a huge repository of prewritten routines that are easy to download and install, and that can save a great deal of development time.

“When looking purely at efficiency of the language, and not needing to do database, I think Node.js is the best thing we have right now,” Klement says.

Klement recommends developers take time to consider whether mixing multiple languages is a benefit and he doesn’t believe programmers should be concentrating on HTML. A better choice from his perspective is using AJAX techniques with a JavaScript framework so programs produce JSON–or maybe XML for older applications–instead of HTML.

Use the right tool for the job, Klement says, but be willing to compromise a bit on that as well, because the extra cost in maintenance and complexity that comes with mixing languages can be higher than what you saved by using a different language in the first place.

“Many of the experts in the industry today recommend writing the Web portion of the application in a language like PHP, and then calling RPG routines–as Web services, stored procedures, etc–for the business logic. Theoretically that would give you the best of both worlds.”

Based on his considerable experience, this requires extra coding to call the RPG routines and therefore, more complexity is required than to simply write the Web side in RPG. He also notes that most of the newer, more efficient languages run in the PASE AIX runtime environment embedded inside of IBM i, which makes them more Unix-like and less IBM i-like. To his way of thinking, this makes the multiple languages approach more clumsy.

“My opinion, at this point, is that RPG is the most efficient way to do things today, assuming that you are writing business logic. The extra overhead of incorporating Web technology into RPG is less cumbersome than splitting it into multiple languages,” Klement contends.

With regard to memory and execution time, he gives high marks to all of the native ILE languages as very good. The PASE-based languages (Python, Node.js, PHP, and Ruby) are less so, and, in his opinion, Java is the worst.

“This does not imply that you couldn’t build a system where these languages work satisfactorily. You definitely can, one of the great things about this platform is its scalability. But you will get more ‘bang for your buck’ with native ILE languages,” he says.

Pay attention to performance, Bartell says, but place a higher priority on the language that fits best with your human resources.

“It doesn’t matter how fast your language is if it doesn’t allow you to produce business applications timely enough to be competitive with the rest of the world. CPU cycles cost less than human resources,” he says. “That’s not to say a healthy balance of performance vs. usability isn’t relevant. But, it isn’t the same balance we had years ago. All language development teams have a continuous eye on performance enhancements.”

“My focus on languages has always been based on usability, learning curve, programmer productivity (my productivity) and IBM i platform support,” says Pete Helgren. “The hardware is so rippin’ fast that performance efficiency really doesn’t enter in to my frame of reference these days. Initially a language like Java made me second guess its use on IBM i (AS/400 at the time) because it was so dog slow, but these days moving from PHP to Java to RPG to JavaScript to Ruby is driven more by the efficiency in building the app than the resultant operational efficiency.”

“Languages themselves probably aren’t the deciding factor,” Helgren continues. “Whether the code is more or less compact really doesn’t matter as much as the framework built on top the language. Rails or the myriad of JS frameworks could all be written in C for all I care, when I develop an app the framework productivity is primary, the language productivity is secondary and how well it all performs only becomes an issue if the performance is bad.”

As a side note on the topic of performance, Bartell says he picked up an interesting tidbit at the Northeast User Group Conference this past spring. During a Linux session, the presenter mentioned the IBM Power8 machines gain performance advantages based on a form of predictive processing. This bodes well for compiled languages, but not so well for scripted languages (PHP, Ruby, Python, Node.js, etc.). However, the future Power9 chip has a focus to address this shortcoming.

From Richard Milone’s perspective, the choice of the language has more to do with the comfort zone and the skills of the programmer than a comparison of advantages and disadvantages of supported languages.

“Over the years IBM has pushed various other languages to the IBM i community such as Java and PHP,” says Milone. “This has been a good thing as is broadens the options for those trying to do something with IBM i. But no matter what languages currently work on IBM i, or future ones that IBM ports over, RPG will probably always be the default. I think it would be helpful to explore differences in programming methodologies in RPG. For example, there are ways to program very verbosely in RPG, but there are also ways to be modern and efficient. The use of reusable service programs, procedures, local variables, etc. can result in very efficient code. However, many developers will duplicate code out of laziness or ignorance and therefore produce inefficient and problematic code.”

Demand Building for Node.js on IBM i

App Dev, Database Top IBM i TR9 and TR1 Enhancements

IBM Delivers Node.js Runtime to IBM i 7.1 and 7.2

As The World Turns: Investments In IBM i

Oh, Ruby! What You Do To Me (On Rails)

RPG, Database Top Enhancements In IBM i 7.1 Technology Release 7

Python On IBM i: Why?

Tags:

Do the Math When Looking at IBM i Hosting for Cost Savings

COVID-19 has accelerated certain business trends that were already gaining strength prior to the start of the pandemic. E-commerce, telehealth, and video conferencing are some of the most obvious examples. One example that may not be as obvious to the general public but has a profound impact on business is the shift in strategy of IBM i infrastructure from traditional, on-premises environments to some form of remote configuration. These remote configurations and all of their variations are broadly referred to in the community as IBM i hosting.

“Hosting” in this context can mean different things to different people, and in general, hosting refers to one of two scenarios. In the first scenario, hosting can refer to a client owned machine that is housed in a co-location facility (commonly called a co-lo for short) where the data center provides traditional system administrator services, relieving the client of administrative and operational responsibilities. In the second scenario, hosting can refer to an MSP owned machine in which partition resources are provided to the client in an on-demand capacity. This scenario allows the client to completely outsource all aspects of Power Systems hardware and the IBM i operating system and database.

The scenario that is best for each business depends on a number of factors and is largely up for debate. In most cases, pursuing hosting purely as a cost saving strategy is a dead end. Furthermore, when you consider all of the costs associated with maintaining and IBM i environment, it is typically not a cost-effective option for the small to midsize market. The most cost-effective approach for these organizations is often a combination of a client owned and maintained system (either on-prem or in a co-lo) with cloud backup and disaster-recovery-as-a-service. Only in some cases of larger enterprise companies can a hosting strategy start to become a potentially cost-effective option.

However, cost savings is just one part of the story. As IBM i expertise becomes scarce and IT resources run tight, the only option for some firms may be to pursue hosting in some capacity. Whatever the driving force for pursing hosting may be, the key point is that it is not just simply an option for running your workload in a different location. There are many details to consider and it is to the best interest of the client to work with an experienced MSP in weighing the benefits and drawbacks of each option. As COVID-19 rolls on, time will tell if IBM i hosting strategies will follow the other strong business trends of the pandemic.

When we say do the math in the title above, it literally means that you need to do the math for your particular scenario. It is not about us doing the math for you, making a case for either staying on premises or for moving to the cloud. There is not one answer, but just different levels of cost to be reckoned which yield different answers. Most IBM i shops have fairly static workloads, at least measured against the larger mix of stuff on the public clouds of the world. How do you measure the value of controlling your own IT fate? That will only be fully recognized at the moment when it is sorely missed the most.

CONTINUE READING ARTICLE

Please visit ucgtechnologies.com/IBM-POWER9-systems for more information.

800.211.8798 | info@ucgtechnologies.com

Article featured in IT Jungle on April 5, 2021