After installing Python 3.9 side-by-side with Python 3.6, one of our friends observed, “I noticed that the newer version, Python 3.9, became the default on my IBM i system. How does the default version get set?” I thought this was a good time to explain how IBM uses the update-alternatives program to set the default version of Python and other open source software packages.
Visual Studio Code is a widely used IDE in the non-IBM i world. Recently we released Code for IBM i, a freely available extension for VS Code that supports RPGLE and COBOL development for IBM i. You can read about the basics of Code for IBM i and about code coverage functionality in my previous posts.
Today I’m going to cover three additional tips for using Code for IBM i. Of course, for any of this to work, you need to install Code for IBM i.
If you download files onto your system using PHP, Yum, RPM, or other tools, there’s a good chance curl is involved, be it part of a library (such as PHP’s curl extension and the Guzzle HTTP client) or called as its own program.
While curl is very reliable, there’s a specific scenario that can trip it up: lack of threading in a job. IBM i PASE provides a version of curl that speeds up common tasks like DNS lookups by using additional threads. When threading support is not available, however, curl fails.
Visual Studio Code is an IDE and platform for developers to write backend, progressive web apps, frontend, and everything on the spectrum of development. I have created an extension for VS Code, called Code for IBM i, that allows users to work on and maintain their IBM i code. VS Code is the best IDE for extensibility, which is why I wanted to take on such a task.
While Visual Studio Code was built to work with all languages, in my opinion it didn’t have much support for RPGLE or COBOL on IBM i until this point. We’re streamlining RPGLE development in terms of tools and speed for our users. We want to make developing RPGLE and COBOL easy for everyone in the most efficient way possible.
Python on IBM i has proven itself as a tool for building utilities to create/read Excel files, transfer data, automate processes, call REST APIs such as Salesforce and ServiceNow, monitor applications, and more. What was missing was an easy way to use the power of Python from CL and RPG.
In 2019 we introduced you to the PYRUN command for running Python scripts from CL and RPG programs.
In this post we introduce you to QSHPYRUN, the next generation of PYRUN and part of Richard Schoen’s open source QShell on i Library – QshOni. QSHONI makes it easy for traditional CL and RPG programs to call Python utilities and use their output. This is supported via the QSHPYRUN command. QSHONI also supports general calls to other QShell, PASE and bash calls via the QSHEXEC and QSHBASH commands. This means QSHONI commands support calling Python, Node, PHP, Java and all things open source, making QSHONI much more versatile than the standalone PYRUN command was. The QSHONI commands can safely live side-by-side with the PYRUN command because they live in different IBM i libraries. This allows for migration to QSHPYRUN to happen as needed. Read more
When we use open source languages such as PHP, Python, and Node.js on IBM i to help companies build and access APIs and other resources, we expect these resources to be protected with encryption (for example, the https:// protocol). Further protection is provided by an SSL / TLS certificate that can be authorized, or signed, by a popular certificate authority such as Verisign, Comodo, or Let’s Encrypt, or signed internally by the company itself.
Self-signed certificates are most useful in situations where public trust of a certificate is unnecessary, such as:
IBM i developers now have an alternative to proprietary data visualization tools to pinpoint potential bottlenecks in PHP, Python, and Node.js code. QCachegrind, an open source tool developed by KDE, turns raw application profiling data into meaningful graphs and visualizations that highlight a program’s most time-consuming functions.
Getting Started with MariaDB on IBM i
MySQL and MariaDB have long been databases used in the Linux world for popular web apps in PHP and other languages. The collective development components—Linux, Apache, MySQL and PHP—are often called the LAMP stack. When PHP was released on IBM i in 2006, the combination of IBM i, Apache, MySQL and PHP became known as the iAMP stack.
PHP 8 has been the biggest change to PHP in years. While PHP 8’s JIT compiler gets most of the publicity, more significant to most developers would be PHP 8’s changes that encourage better coding practices. PHP 8 pushes developers to use clearer syntax and is stricter with problematic code.
While the PHP runtime itself has improved, what about extensions such as ibm_db2? What changes do extension developers need to make to adapt to PHP 8? As maintainers of the ibm_db2 and PDO_IBM database extensions, we’ve learned what it takes to make PHP extensions compatible with PHP 8.