A Mainframe is the handler of a very large DB2-system. Historically, mainframe has been a lot of other things, but today this is the important – and only – niche of the mainframe. The mainframe supplies the processing power and the storage needed to run the DB2-system, and COBOL or Java supplies the logic web connecting the different SQL-calls. The idea of a ‘server park’ or ‘cloud’ is not able to handle a very large SQL-system. Buying a book at Amazon illustrates this point: Amazon says: ‘We have about 5 copies of this book on store’. Ok, you buy, and maybe you get an email hours later, stating that ‘The book was out of stock, but Amazon can deliver in 3 weeks’. The reason for this (acceptable) mess is that Amazon runs on a distributed database with no central commit. Running a bank instead of a bookstore is not possible this way (‘We have made a withdrawal of §123.14 on Alice's account and you can be pretty sure that the money normally will be added to Bob's account - otherwise the money is lost ’). Banks runs on mainframes, securing that all transactions inside the organization are handled with centralized commit. Ok, a distributed solution may be supplemented with a commit mechanism, Oracle does this, but it is a complicated solution, creating a lot of messaging between the servers.
All established scripting languages on the z/OS mainframe – most notably REXX, Easytrieve, FileAid, FileManager - are from a time before DB2 was the king of the mainframe, and accordingly all the languages have a focus on handling sequential files. Around 1990 the languages have been supplemented with DB2-interfaces, but these interfaces are additions, they are not integrated in the fundamental syntax of the languages.
You can make the same complaint about COBOL and Java: SQL-interfaces are additions, and not part of the fundamental syntax of the languages. And you could further invalidate my argument by saying that this is just the way it should be: The procedural logic of COBOL and Java should not be mixed with the imperative logic of SQL; COBOL or Java describing step by step how to reach a conclusion, SQL just asking the question to pull the conclusion: ‘Does the database contain any red-haired persons with a weight of exactly 101 kg?’ (as example). But a scripting language should focus on short formulation, and without that capability in the language, you might as well solve the problem in COBOL or Java. The common mainframe scripting languages use the COBOL-way of interacting with DB2: Define a cursor, open it, fetch until no more data, and close it. That is not very ‘scripting’ like.
Now let's focus on RXS: Historically, the development of the RXS scripting language is a side effect of a very large (> 40 developers) project which started in 1991. The project was, and is, serving the Danish tax administration. Two problems got focus in the development process: The need to automatically generate a lot of COBOL coding, and the project’s stated policy of a strict DB2 focus. Both problems pointed to the flaws in the common scripting languages of the mainframe. Code generation on mainframe via REXX plus File-tailoring services plus ISPF-skeletons works fine, but it is complicated, and not intended for quick ad hoc solutions. DB2 access via REXX also works fine, but the abstraction is not thoroughly enough: You must deal with details in the interface instead of just focusing on the SQL-syntax. In both cases: code generation and DB2 access, RXS offer a better abstraction.
Handling of other ‘modern’ data formats: XML, MQSeries and UNIX-files on mainframe are integrated in RXS. Transporting data to and from Windows is also integrated in RXS. Again 'abstraction' is the word: RXS offers a common syntax spanning all these data-sources on the mainframe, including DB2 and code generation. A common syntax also means a thoroughly programming of error handling: Error messages are always in English, and handling or bypassing of errors are done the same way, regardless of which data source or sink.
RXS is built on published IBM interfaces to the mainframe, thereby securing that IBM's guarantee for forward and backward compatibility on the mainframe is also covering RXS. Together with a syntax stable (but extended) since 1995, RXS has full forward compatibility: A script written in RXS today will function the same way 20 years from now – just like a RXS script from 1995 works today. RXS itself is written solely in COBOL and REXX, so any optimizing and lifting of constraints in these two languages by IBM, will benefit RXS without any adjusting of the source-code of RXS. For instance, to enter the 64-bit addressing in the COBOL of tomorrow, only a recompile of the COBOL part of RXS is needed. REXX has been better at handling large data files since MVS release V2R1, and this has lifted some constraints in RXS programs as well.
The syntax of RXS is based on the concept of a pipeline language. This concept places RXS outside the classes of well-known contemporary languages like Java: RXS is not object-oriented. Instead it has a focus on handling data stores outside the language (DB2 for instance), not its own objects. Internal data stores in the language are in the form of ‘pipes’, not objects.
RXS is ‘open source’: The source code of the language is published here on this web-site. The development of RXS is done, and the costs has been paid for. A broader use base for RXS could benefit the project by creating more discussion on RXS, and by creating more knowledge of the pros and cons of the language.
RXS is in the group of scripting languages, like REXX and Easytrieve - you can program any logic in these languages. FileAid and FileManager are not languages, but rather collections of separate scripting mechanisms.
A RXS example: A script checking some relations across 3 different DB2-systems (test, pre-production and production), making a report on its findings: