Highlight

"Bring me to the test"
Shakespeare, Hamlet, III, 4

Home | Intro | Tutorial | Reference | Download | AboutMe

A comparison.

In a mainframe environment, that is, in a business environment of a bank or of a big firm, the most used programming language is COBOL, and in this language are written the most important applications, applications that are the reason why so high budget is devoted to EDP.

Why a so old and obsolete language is nowadays so widely used in a business environment ? The answers are: continuity and portability.
Continuity, because a program written twenty years ago, runs today as in those days and is easy to find programmers to maintain it.
Portability, because programs can be written for every mainframe environment (Batch, CICS, TSO, MVS, VSE, DB2, etc.) and also in Unix or Pc environment. Nevertheless, portability don't mean easy migration from an environment to another: COBOL (as other languages) is only a procedural base-language (a "cradle") in which to interact with a not-portable environment (see EXEC CICS, EXEC SQL or EXEC DLI).
The first strength of COBOL (continuity) it's a fact and cannot be reduced: is the same strength (and nowadays perhaps the only) of a mainframe host.

But Cobol is used for only a part of the applications that run in a mainframe: is used to write
User Applications, that is programs used by not-EDP clerks to manage business; this is a big part, but in a mainframe there are some other tasks done by:
System Applications, usually products that are bought to simplify, improve or speed-up daily EDP work (TLMS or DataBase utility, for example), and
System Maintenance, that is applications written inside the firm by a System Programmer to integrate Operating System utilities and System applications with daily application development, ordinary maintenance and organization rules.
System Applications are written in Assembler (perhaps in "C" ?) whereas System Maintenance Applications are usually written in REXX, using ISPF dialog management to yield a user-friendly interface.

With this outline, let's summarize characteristics of Hilmas and other mainframe languages with this table:

LANGUAGE	User Application	System Application	System Maintenance	Portability	Productivity
COBOL	YES	NO	NO	YES	NO
MANTIS	YES	NO	NO	NO	YES
REXX	YES/NO	NO	YES	YES	YES
C	YES/NO	YES/NO	YES/NO	YES	NO
Assembler/370	NO	YES	YES/NO	NO	NO
HiLMAs	YES	YES	YES/NO	YES/NO	YES/NO

Let's comment on this table.

• With YES we mean that is possible and advisable (for reasons that can not be the same for every language) develop the specified type of applications.
• With YES/NO we mean that is possible but not always advisable use this language (often the reason is Productivity = NO).
• With NO we mean that is not possible or, if possible, strongly not advisable develop the specified type of applications.
• MANTIS is a language developed by CINCOM: it run in CICS (and only in CICS), is interpreted, well structured, user friendly, integrated with a Map designer; this language speed up development of interactive applications, especially in respect to traditional COBOL-CICS.
• With REXX is possible to develop User Applications batch (using TSO batch), interactive (in TSO) and now also CICS (using CICS/REXX); but is often not advisable because TSO user is heavy (in respect to CICS user) and an interpreted language is less efficient that a compiled language.
• With C language is possible to develop everything, but is often not advisable because has a poor productivity.
• With Assembler/370 is nowadays crazy to develop a business application; is perhaps the unique possibility to develop a System Application and so interface all Operating System Macros; is crazy use assembler instead of REXX but there are situations in which only an assembler routine can solve the problem in daily work of system maintenance.

And now let's see how Hilmas I think can be compared with these languages:

• I think that Hilmas is more productive than Cobol, to develop an User Application
• I think that with Hilmas you can do every thing that you do with Assembler, with many, many more productivity
• I think that REXX is the best for System Maintenance, but you can use Hilmas if REXX cannot solve the problem, if necessary using Hilmas/REXX interface (see EXECIOVS in Download page)
• I think that Hilmas has the best portability, inside the IBM mainframe world (but only in this world).
• I've assigned a YES/NO to Hilmas in Productivity column because developing speed I think is less than REXX or MANTIS.

This can seems self-conceited, and perhaps it is !

 

But there are some faults in Hilmas ?

Yes, and we divide these flaws in "marketing" and "technical" flaws:

Some marketing flaws of Hilmas:

• Hilmas is created, developed, maintained only by one person (me !)
• Not adhere to any standard and is inseparable by old mainframe world
• Is very light, simple to install (and simple to copy !): Hilmas macro deck (the heart of the language) is 360K long and all can be contained in a floppy of 1.44M; in minutes I can install and use Hilmas in every mainframe environment, with only a 3270 PC emulation and without any system intervention.
• Hilmas is a collection of assembler Macros, so it is in source form and can be easily copied and changed with an editor (by a programmer that knows Assembler/370 !). Indeed, this can also be a worth.
• For now I has been the only beta tester of Hilmas (and the results are in Download page) and I cannot exclude other bugs, although I think that Hilmas is now enough stable.

Some technical flaws of Hilmas:

• Expressions cannot be nested in any instruction, that is an instruction operand can be only a variable or a constant, but cannot be a result of a computation, a conversion, etc. written inside; first you must use an instruction to do this computation, conversion, etc. putting its result in a variable, then use this variable in the instruction you want.
  This fault is not serious for a Cobol programmer (this nesting is not possible even in Cobol) but can be a trouble for a programmer accustomed with Pascal, REXX or C.
• The LET instruction support only one level of nesting, that is only one level of parenthesis is permitted. At the same time, in comparison expressions only one level of parenthesis is permitted and there isn't any operator precedence.
• A source line can contain only one instruction, unlike REXX, Pascal, C etc. I think that is a little trouble, because this limitation can increase readability.
• Programs generated must be 12K bytes long for executable code and 12K bytes long for data. Remember that code generated is very compact so you can write 300/600 Hilmas statement before to reach this limit.
  Every internal subroutine can be 12K, so, if you divide the source in some small subroutines, a program can reach a big size, without limitations.
  For data this limitation is effective, but there are some tricks to circumvent this limitation:
  - define long arrays at the bottom of thhe data area
  - use pointers to a huge data area insteead of symbolic variables
  - use data area "local" to intternal subroutines, that is define some variables after the "ENDSUB" instruction of the subroutine that uses it and before the following "SUBDEF" (or "ENDPROG") instruction.
  These variables aren't true local variables, that is its values CAN be visible from some other preceding subroutines and, in every case, is not possible to use the same name of other variables.
  But this is useful to circumvent the 12K limitation.
  For assembler programmers: these limitations are due to addressing techniques used in Assembler/370: in Hilmas 3 registers are used for code addressing and 3 for data (every register addresses 4K).
  
• Error checking of Hilmas is weak, especially for a Hilmas beginner that don't have never seen a listing and messages of an assembler program.
  Some errors are trapped by Hilmas itself, and these are MNOTE with error code 16, but others cannot be trapped and an assembler message is printed. In general terms, instruction misspelling and generic syntax errors are trapped by assembler, whereas data type errors and some logic errors (like "ENDIF"missing) are trapped by Hilmas.
  

In short, the main values of Hilmas are three:

• Is a true structured "assembler" language
• Is portable even in file management and full-screen management
• Has a plenty of functions for string and data management

A word about IBM Toolkit Feature available in High Level Assembler.

An add on for HLASM is Toolkit Feature, that contain a Disassembler, an Interactive Debugger, a Cross-Reference Facility and (the thing that is of interest to us) "Structured Programming Macros", that is a set of macro instructions that implement the most widely used structured-programming constructs (IF, DO, CASE, SEARCH, SELECT). IBM says that "these macros simplify coding and help eliminate errors in writing branch instructions".

This tool is not a competitor for Hilmas for these reasons:

• Only flow control instructions are covered by these macros
• The arguments of these macros are registers, constants, assembler instructions or condition flags previously set, and its syntax is not so simple.
• In this way, only an expert assembler programmer can use these macros that can replace only a little part of the native assembler instructions.

This toolkit isn't even been the starting idea for Hilmas because I have started the writing of it about five years before the come in of HLASM.

Home | Intro | Tutorial | Reference | Download | AboutMe