Let’s Learn About Ublu

Have you heard about Ublu? It’s a programming language created specifically for IBM i tasks.

Have you heard about Ublu? It’s a programming language created specifically for IBM i tasks. That notion alone makes for an exciting story! On top of that, the language runtime is now an open-source project, which adds a level of “cool.” It also happens to be a very useful language. You can see why I chose to put a spotlight on this technology today: It’s a useful, cool invention built for IBM i!

Today’s post is featuring a guest writer. I’ve asked the creator of Ublu, Jack Woehr of SoftWoehr LLC, to introduce you to the language. (As such, first-person references are from Jack’s perspective.) If you’re interested in learning more, I urge you to check out the thorough documentation written for the language. Let’s learn about Ublu!

What’s Ublu?

Ublu is a language I have authored over the past four to five years for the purpose of automating and managing IBM i from remote Java platforms. It is interactive, compilable and becoming fairly mature. It is also clunky and idiosyncratic, yet rewarding to use.

Some IBM i open source lovers work on porting useful, popular open source to the i platform to make that platform more flexible. We all are thankful for their heroic efforts, but there is also another path, one which I pursue, that makes it easier to encapsulate legacy IBM i as-is and offload the fancy stuff to Linux, Windows and Mac, OpenBSD, etc.

“Let i be i,” say I, “and treat the IBM i as a secure and mature database application engine which provides data and business processes on request to tools and applications coded and executing on platforms more amenable to interactive application delivery.” For an architect of this approach, Ublu is a useful tool in the kit.

# delSpoolFBefore ( mysys myid mypasswd target targdate )
# Delete all spoolfiles on mysys with credentials myid mypasswd for target
# (e.g., a profile SOMEUID or *ALL) created before a given targdate.
# Date is AS400 style:
#   CYYMMDD
#   C 0 = 20th century, 1 = 21st century
#   YY two-digit year
#   MM month
#   DD
# So delSpoolFBefore ( s u p *ALL 1160000 ) deletes all spoolfiles on the system
# starting from the first one and all thereafter created prior to 2016-01-01
FUNC delSpoolFBefore ( mysys myid mypasswd target targdate ) $[
    as400 -to ~ @@mysys @@myid @@mypasswd
    spoolflist -to ~ -as400 ~ @@target
    list -to ~ -source ~
    FOR @i in ~ $[
        @i -to ~ -get createdate
        eval -to  ~  < ~ @@tar gdate
        IF ~ THEN $[ @i -de lete ]$
    ]$
]$

The example above may look clunky, but it’s really simple. Obviously a function is being defined.

• The first line of the function body creates a JTOpen com.ibm.access.AS400 object based on credentials passed into the function and tosses the object on the object stack (represented in Ublu by the tilde “~” character).
• The next line gets a spooled file list consuming the AS/400 object from the stack and the target userid that owns the spooled files and tosses the resultant list on the stack.
• The next line consumes the spooled file list from the stack and makes it an Ublu iterable list.
• The FOR loop tests the create date of each item in the list and if the target date is greater than the spooled file create date the file is deleted.

I call Ublu object-disoriented, in that it manipulates Java objects by doing “what’s right” with them rather than forcing rigid type identification on the programmer. Type info is always available when you ask for it, but generally you don’t need to know.

Whence Ublu? (Adventures in JTOpen)

I began programming OS/400 in the 1990s tangentially and moved onto a career ranging from processor microcode and embedded systems, through Windows, Unix, VMS, OS/2 and z/VM. After exploring ILE languages, I discovered the Java 400 Toolkit, which IBM soon thereafter released as the open source JTOpen. With JTOpen, Java became instantly the most portable facet of IBM i programming. As a devotee of simplicity and small team programming productivity, I was attracted to JTOpen and quickly wrote some toy applications called QCDemo that are still present in the JTOpen CVS repository.

In the following years I coded a few tools in JTOpen such as a Java class loader that loads a class from a database BLOB. I also kept up with the arcane art of building JTOpen from source.

In 2012 I began to become heavily involved in legacy IBM i support and drew on my JTOpen experience to code a series of command-line tools woven together by bash shell scripts. Quickly the need to pass objects back and forth between individual tools necessitated those tools becoming verbs in a domain-specific language.

Design constraints included the following:

• Ublu had to be implemented quickly and easily and be maintainable by me alone.
• The syntax had to be simple and expressive rather than elegant for quickly teaching co-workers.
• The general theory of language design had little application here other than the First Rule:
  • “Keep It Simple Stupid”

Hence Ublu, with its left-to-right one-pass text parser, its trivial language structure and its homely syntax.

It was agreed with my contract partner, Absolute Performance, Inc., that in return for independent effort on my part, the language would become and remain open source under the BSD-2 license, which occurred in 2016.

How does Ublu work?

Ublu is generally a Java interpreter and specifically an interpretive form of JTOpen. Since Ublu programs can call Java methods, recently more functional extensions have been added in the form of application code rather than directly Java coding them in the Ublu interpreter itself. For example,  file  and record are Ublu verbs but record formats are handled in the extension ux.format.ublu; when given a format object, we can push things like the format id or format type to the stack:
 
# Pushes to stack the record format ID.
FUNC ux.format.getRecordFormatID ( fmt ) $[
    calljava -to ~ —  @@fmt   -method getRecordFormatID
]$
 
# Pushes to tuple the record format type.
FUNC ux.format.getRecordFormatType ( fmt ) $[
    calljava -to ~ — @@fmt -method getRecordFormatType
]$
 

Application

Ublu is currently used for tasks such as:

• Process control, e.g., day-ends
• Intelligent green-screen scraping automation (leveraging TN5250J)
• System monitoring and alerts
• Forensic explorations where the fast path is to exercise Unix tools on information extracted from the running system via Ublu.
• Scripting
• Quick fixes

Ublu can also be a TCP/IP socket server and its interpreter can be served up on a socket server if desired.

Documentation

Ublu comes with a Reference and a Guide, which can be read online if you’re curious.

The Future

Ublu has grown beyond merely supporting JTOpen and now supports Common Information Model (CIM) leveraging SBLIM, z/VM SMAPI, and other neat stuff. I (and others) use Ublu in our practice so it is constantly being extended to suit new needs and requirements. There have been over 1,000 commits to Ublu’s git repository in the past year or so with no end in sight. I, along with a few friends who help with Ublu, intend to keep the language living as long as it has useful application, and you’re welcome to join us!

---