Black Hill Software

  • Home
  • Products
    • EasySMF
      • Online Manual
      • Release Notes and Latest Version
      • License Agreement
    • EasySMF:JE
      • EasySMF:JE Java Quickstart
      • Release Notes and Latest Version
      • Javadoc
      • License Agreement
    • EasySMF:RTI
      • EasySMF:RTI – SMF Real Time Interface
      • Javadoc
    • 30 Day Trial
  • Purchase
    • How to Buy
    • Purchase a License
  • Support
    • Documentation
      • EasySMF Desktop Online Manual
      • EasySMF:JE Javadoc
      • EasySMF RTI Javadoc
      • EasySMF JSON Javadoc
      • z/OS Utilities Javadoc
    • EasySMF Support
    • Get the latest version of EasySMF
    • EasySMF:JE Support
    • Get the latest version of EasySMF:JE
  • News
  • Contact
    • Support
    • Sales

Java vs C++ : Drag Racing on z/OS

August 10, 2021 by Andrew

Which language is faster on z/OS, Java or C++? People will tell you C++ is fast and Java is slow, but does that stand up to a drag race?

Dave Plummer is a retired operating systems engineer from Microsoft. He has created an interesting series of videos “drag racing” different languages and different hardware with a small program searching for prime numbers. The initial video raced C++, Python, and C#. Then he raced an Apple M1 vs an AMD ThreadRipper 3970X vs a Raspberry Pi.

I thought it would be interesting to run the drag race on z/OS, putting C++ up against Java. z/OS people like to tell you that Java is slow – but is that really true?

The program uses the sieve of Eratosthenes to search for prime numbers. The program works through odd numbers starting at 3 and marks each multiple as “not prime”. Then it moves to the next number that has not already been marked as a multiple of another number and repeats the process. At the end, numbers that have not been marked are prime.

This is repeated for numbers up to 1,000,000 as many times as possible in 5 seconds, and the number of passes is the result.

The “drag race” description acknowledges that this isn’t a comprehensive benchmark, just a test of speed at a particular task like drag racing a car.

Setup

The C++ and Java programs had been developed and refined on other platforms. The Java code ran without modification, but the C++ code required a few changes:

  • I couldn’t find <chrono> on z/OS so I used gettimeofday for the timing
  • Some changes to initialization etc. were required due to unsupported syntax

The C++ code was compiled from the unix command line:

xlc -o PrimeCPP31 -O3 -Wl,xplink -Wc,xplink,-qlanglvl=extended0x PrimeCPP.cpp

I configured the zIIP offline for the tests so that the C++ and Java code were running on the same processor.

All source code is available here, if you want to try it out on your own system:

https://github.com/andrew890/Primes-zOS

Note: z/OS CPU speeds vary widely based on the capacity purchased. The z15 LSPR ratios list z15 systems with single CPU MSU ratings from 12 MSU to 253 MSU – a 20x difference! The numbers here should be a reasonable comparison between the languages tested, but be careful comparing them with a different system.

Round 1

Source code:

  • C++ : https://github.com/andrew890/Primes-zOS/blob/main/PrimeCPP/solution_1/PrimeCPP.cpp
  • Java : https://github.com/andrew890/Primes-zOS/blob/main/PrimeJava/solution_1/PrimeSieveJava.java

Results (higher number is better):

C++Java
12954807

I was surprised – I expected Java to do well, but I didn’t expect C++ to do so badly.

There wasn’t anything I could see in the C++ code to make it slower than the Java code. However, marking and checking numbers is the majority of the work, and this processing is hidden inside a vector<bool> in the C++ code. Using vector<bool> was apparently a big gain on other platforms, but maybe not on z/OS?

I changed the C++ code to use bits in an unsigned char array, explicitly testing and setting bits. This was the method Dave used in his initial code. The Java code used a boolean array. To give the closest possible comparison between C++ and Java I also changed the Java code to use a byte array with the same bit testing/setting.

Round 2

Source Code:

  • C++ : https://github.com/andrew890/Primes-zOS/blob/main/PrimeCPP/solution_2/PrimeCPP.cpp
  • Java : https://github.com/andrew890/Primes-zOS/blob/main/PrimeJava/solution_2/PrimeSieveJava.java

Results (higher number is better):

C++Java
48282715

This was a much better result for C++. It looks like the vector<bool> implementation on z/OS is not as good as other platforms. However in Java the original solution was much better. The improved C++ version didn’t significantly beat the original Java solution.

On other platforms C++ was faster than Java by 40-70%. The versions using the byte array showed a similar margin. I don’t doubt that you could write a C++ version to beat the fastest Java version on z/OS, but I don’t think it would be easy.

Bonus: COBOL

Someone contributed a COBOL version. I tried that out of interest, compiled with OPT(2):

Source Code:

  • https://github.com/andrew890/Primes-zOS/blob/main/PrimeCOBOL/solution_2/PRIMES

Result:

COBOL
2373

Better than the worst C++, but not as good as Java. To be fair, this program is a long way from the type of work COBOL was designed for. I don’t know COBOL well enough to judge if it could be improved.

Scaling it up

The other interesting test is to scale up from 1,000,000 to larger numbers. I repeated the tests using the different solutions for primes up to 10,000,000, 100,000,000 and 1,000,000,000.

The most interesting result here is the Java boolean[] version. This version is as fast as the fastest C++ version for 1,000,000, but the speed declines much faster as the maximum increases. I guess Java is doing some optimizations that don’t work as well for 1 billion element arrays!

The trend was strong enough that it seemed interesting to try a smaller number as well, so I added a 100,000 run. Very interesting – for 100,000, the Java version using the boolean array was more than 20% faster than C++!

100,0001,000,00010,000,000100,000,0001,000,000,000
C++ using vector<bool>14,3771,295122101 in 7.19 seconds
Java using boolean[]64,4234,807271131 in 9.06 seconds
C++ using unsigned char*52,2514,828417282 in 5.14 seconds
Java using byte[]30,4252,715237142 in 6.99 seconds
COBOL19,2702,3738651 in 21.0 seconds

Java Overhead

Java has some overhead starting the Java Virtual Machine. This can be seen in the SMF data.

The SMF data shows the C++ programs had about 4.95 seconds CPU time and 5.02 seconds elapsed time for the 5 second duration measured by the program.

The Java programs had about 5.24 seconds CPU time and 6.16 seconds elapsed. This presumably reflects the overhead of starting the JVM. There was only one CPU online, so any runtime overhead after the program records the start time will be reflected in the score. Java GC etc. threads could not run in parallel on another CPU and accumulate CPU time without slowing the main program. This startup overhead should be less significant for longer running programs.

Conclusion

Java on z/OS is not slow. It can match C++ for speed, to the point where the selection of algorithms and data structures is more important than the language itself. Java deserves to be considered a high performance language on z/OS, as much as C++ or COBOL. There is one caveat: there is significant overhead starting the JVM, so it might not be a good choice for small programs that run very frequently.

Java’s reputation for being slow probably comes from the ease of combining existing components into very large applications, where the programmer may not even be aware of the size of what they have built.

Many z/OS systems have general purpose CPs running less than full speed to reduce software bills. If you have zIIPs running full speed, Java might actually be the fastest language on your system by a fair margin, with the bonus that the Java work probably doesn’t contribute to software costs.

Dave’s Videos

Here are direct links to the first 2 of Dave Plummer’s Software Drag Racing videos:

Filed Under: Java

Loading data 10 times faster using z/OSMF

March 23, 2021 by Andrew

EasySMF can now load SMF data using the z/OSMF Dataset and File REST API.

The z/OSMF REST API uses HTTPS instead of FTP so it is a good option for sites that don’t want to use FTP. HTTPS works better with firewalls because it uses a single port instead of separate control and data connections used by FTP.

z/OSMF will compress the data for transfer. If the connection is bandwidth-limited, that can make loading SMF data up to 10 times faster.

Limitations

z/OSMF cancels the REST API task if it hasn’t completed after approximately 15 minutes. This limits the amount of data that can be transferred. However, with 10 times faster data transfer, that could be the equivalent of over 2 hours transfer time using FTP.

Hopefully IBM will relax this limitation in the future.

Filed Under: EasySMF News

The Easy Way to View zERT SMF Data

March 23, 2021 by Andrew

  • Are all my z/OS TCP/IP connections encrypted?
  • How do I know what level of TLS is being used?
  • Which TCP/IP clients or servers are using insecure ciphers?

zERT – the z/OS Encryption Readiness Technology is designed to answer these questions.

zERT is a function of TCP/IP on z/OS. It collects information about cryptographic security attributes of TCP/IP connections and writes it to SMF. IBM provides some free zERT reports in z/OSMF, but the data needs to be loaded into DB2 before you can view the reports.

EasySMF allows you to view zERT SMF reports without DB2.

zERT can produce 2 types of records – Connection Detail and Aggregation. Like z/OSMF, EasySMF reports on zERT Aggregation records: SMF type 119 subtype 12.

zERT Aggregation records contain similar information to the zERT Connection Detail records, but information for multiple connections with the same security characteristics are combined. This reduces the number of records generated.

The aggregation records still break the information down to the IP address and port level, but they combine information from multiple connections with the same security settings from the same client.

Finding the Important Information

Even using aggregation records, zERT reports have a lot of information. Records are produced for each client connecting to TCP/IP. Most of these records are not interesting. The entries you probably want to see are connections with specific security attributes, e.g. insecure ciphers or old TLS versions.

EasySMF makes it easy to find the important entries. EasySMF groups connections by security attributes and server port.

Here we can see there are multiple clients connecting to FTP and z/OSMF using TLS V1.0.

zERT Grouping in EasySMF

We can filter the report to show only the TLS 1.0 entries, and expand the groups to show the individual client addresses. To save the report data, you can export it to Excel or in CSV format.

Filtering and expanding groups to view individual clients

zERT is a very useful facility to help you secure your z/OS system. Download a 30 day trial of EasySMF and see how EasySMF can help you interpret your zERT data.

Filed Under: EasySMF News

Comparing bash and /bin/sh on z/OS

August 27, 2019 by Andrew

A few weeks ago, @wizardofzos tweeted about a unix shell script that showed a bug on z/OS.

Here is the script:

#!/bin/bash
mkdir -p broken
c=1
while [ $c -le 4000 ]
do
  f=$RANDOM
  touch broken/$f
  setfacl -m "u:IBMUSER:rwx" broken/$f
  clear
  echo "Testing cut" | cut -c1 
  echo "Done for $c"
  let c=c+1
done

I was curious, so I tried to reproduce it on my system. The original script runs under bash. I tried it under both bash and /bin/sh but was unable to reproduce the bug, so I couldn’t do any further investigation.

What I did notice, however, was that the script was much, much faster under /bin/sh. That was interesting, so I had a closer look at the SMF data using EasySMF. I ran the 2 jobs for 1000 iterations of the loop. 1000 iterations created approximately 5000 unix tasks. Due to the various type 30 subtypes, the /bin/sh job produced about 20,000 type 30 records and the bash job about 28,000.

Here is part of the Job Completions report for the 2 jobs:

ANDREWRA is the job running bash, ANDREWRB runs /bin/sh.

The bash job took 2 minutes elapsed versus 1 minute for /bin/sh, but more interesting is the CPU time: more than 1 minute for bash, less than 5 seconds for /bin/sh. Those CPU times are the totals for all the descendants grouped under the collapsed top level jobs in the report.

The Unix Work report shows this in more detail. It works from the Step End SMF records and shows substep information as well. This is part of the report for ANDREWRA running bash:

We can see some interesting stuff here:

  • Very little of the CPU time is charged back to the owning job JOB06732. Most of it is in OMVS sub tasks.
  • The top level bash step uses the most CPU time.
  • We can see what looks like the fork/exec pattern described in the SMF manual, where the parent forks and then execs another program creating a sub-step in SMF.
  • Forking the bash task also seems to use a relatively large amount of CPU time.
  • Although the Job Number STC06734 is the same for all these tasks, they are actually separate tasks reusing the same OMVS initiator.

The same report for ANDREWRB running /bin/sh:

Interesting differences:

  • The top level shell uses a lot less CPU.
  • It does not show the same sub-step pattern. The commands themselves exist as top level steps in the OMVS initiator. Overall it uses a lot less CPU.

Conclusions

This isn’t meant to be a criticism of the bash port. I imagine IBM has a lot more ability to get into the operating system internals and optimize /bin/sh. But it is interesting to see the difference in resource usage.

The obvious conclusion would be to avoid bash for shell scripts with significant loops, or (probably) scripts that spawn many subcommands e.g. find. Use bash if you really need it’s functionality, e.g. for login shells.

Much of my description of what is going on is speculative based on what I can see in SMF, if you know more please feel free to comment.

Filed Under: EasySMF News

User Key Common Flags in EasySMF

August 15, 2019 by Andrew

As you have probably heard, user key common storage will not be allowed in z/OS 2.4.

For more information on z/OS 2.4 User Key Common removal see Marna Walle’s article: Reminder to take a look: z/OS V2.4 user key common removal

IBM added some flags in the type 30 SMF record to audit usage of user key common storage. The flags allow you to see which jobs used user key common storage. The flags are:

  • SMF30_UserKeyCsaUsage
  • SMF30_UserKeyCadsUsage
  • SMF30_UserKeyChangKeyUsage

There is another flag for Restricted Use Common Service Area:

  • SMF30_UserKeyRuCsaUsage

Restricted use CSA is a relatively new function not going away in 2.4, but IBM discourage its use and it is becoming a priced feature.

EasySMF provides reports to show these flags and help you find any jobs or address spaces using user key common storage. The common storage flags are shown in the following reports:

  • Job Memory Information – Shows information from jobs and address spaces after they have ended.
  • Step Completions – Shows information from ended steps. This report shows the program name.
  • Running Jobs – Shows information including jobs that are still running (from SMF type 30 interval records).

You will need to scroll right to find the User Key Common columns.

EasySMF User Key Common Report
  • User Key Audit indicates whether the SMF30_UserKeyCommonAuditEnabled flag is set. This must be on, otherwise the information in the other fields is not valid.
  • User Key CSA shows the value of SMF30_UserKeyCsaUsage.
  • User Key CADS shows the value of SMF30_UserKeyCadsUsage
  • User Key CHANGKEY shows the value of SMF30_UserKeyChangKeyUsage
  • Restricted Use CSA shows the value of SMF30_UserKeyRuCsaUsage

Click the column headers to sort the values and find any jobs where the flags are set (click twice to sort descending).

User Key Common reports on z/OS using Java

If you don’t want to download SMF data to a PC, you can run a report on z/OS using Java. EasySMF:JE (a set of Java classes to map SMF records) provides a sample report to show User Key Common information.

Quickstart installation information for EasySMF:JE can be found here: EasySMF:JE Java Quickstart

Change the class name in IVP4 from com/blackhillsoftware/samples/RecordCount to com/blackhillsoftware/samples/UserKeyCommon to run the User Key Common sample report.

30 Day Trial

Both EasySMF and EasySMF:JE can be downloaded for 30 day trials.

Information about the trial is available here.

Filed Under: EasySMF News

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • …
  • 7
  • Next Page »

30 Day Trial

EasySMF and EasySMF:JE are available for a free 30 day trial. Download now and start using them immediately.
30 Day Trial

Information

EasySMF:JE Java API for SMF: Quickstart

Java vs C++ : Drag Racing on z/OS

News

  • Using zEDC compression for SMF data
  • Text message alerts using the z/OS SMF Real Time Interface
  • DCOLLECT Reports and DCOLLECT to JSON using Java

Black Hill Software

Suite 10b, 28 University Drive, Mt Helen, VIC 3350, Australia
PO Box 2214, Bakery Hill, VIC 3354, Australia
+61 3 5331 8201
+1 (310) 634 9882
info@blackhillsoftware.com

News

  • Using zEDC compression for SMF data
  • Text message alerts using the z/OS SMF Real Time Interface
  • DCOLLECT Reports and DCOLLECT to JSON using Java

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in