It brings the following improvements:

• New Image tool bar with actions similar to the Linux console panel
• New improved, bigger status bar with CPU selector
• If a suspend file is found, an option to resume is offered

Here is a screenshot of the new version, running the standard Hercules setup and my Slack/390 installation simultaneously:

The two virtual machines are shown as tabs and you can easily switch between them.

The updated SlackBuild script has been submitted to SlackBuild.org and pre-built versions for Slackware and Slackware64 are available on my site.

Hebe is described on its homepage as:

Hebe is a new KDE 4.4 front-end GUI for the Hercules z/Arch emulator. It was designed to have a modern look, like the VirtualBox interface; there are no dials! Hebe provides two consoles, one for Hercules and one for the SCP (system control program), AKA, the operating system. Input is automatically routed to the correct receiver. You can start as many instances of Hercules as your hardware can support.

I am not a big KDE fan, but I have all the libraries installed, as they come with Slackware, so the program works fine even under Xfce.

Using the standard cmake-template.SlackBuild, I put together a script in just a couple of minutes, which I submitted to SlackBuilds.org.

The resulting program looks really nice:

One really nice feature is the capability to run several copies of Hercules at the same time through one single interface.

For the inpatient, pre-built packages can be downloaded from my site.

I used a (quite old) utility called nbench that was originally written in 1995 but still is a simple way to compare how processors perform, emulated or real. And it has a nice advantage that it can be built on x86, s390 and Arm processors without problems.

Here is the result of Slack/390x-11.0 running in Hercules 3.06 with two emulated processors:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
 : : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 34.476 : 0.88 : 0.29
STRING SORT : 3.012 : 1.35 : 0.21
BITFIELD : 8.3237e+06 : 1.43 : 0.30
FP EMULATION : 2.3056 : 1.11 : 0.26
FOURIER : 70.649 : 0.08 : 0.05
ASSIGNMENT : 0.35083 : 1.33 : 0.35
IDEA : 94.416 : 1.44 : 0.43
HUFFMAN : 34.368 : 0.95 : 0.30
NEURAL NET : 0.10472 : 0.17 : 0.07
LU DECOMPOSITION : 3.5645 : 0.18 : 0.13
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 1.194
FLOATING-POINT INDEX: 0.136
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU : Dual IBM/S390
L2 Cache :
OS : Linux 2.4.33.3
C compiler : gcc version 3.4.6
libc :
MEMORY INDEX : 0.278
INTEGER INDEX : 0.314
FLOATING-POINT INDEX: 0.075
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

And here is the result of ArmedSlack running in Qemu:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
 : : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 199.84 : 5.13 : 1.68
STRING SORT : 22.453 : 10.03 : 1.55
BITFIELD : 9.048e+07 : 15.52 : 3.24
FP EMULATION : 28.281 : 13.57 : 3.13
FOURIER : 139.34 : 0.16 : 0.09
ASSIGNMENT : 4.4836 : 17.06 : 4.43
IDEA : 922.7 : 14.11 : 4.19
HUFFMAN : 322.93 : 8.95 : 2.86
NEURAL NET : 0.26406 : 0.42 : 0.18
LU DECOMPOSITION : 8.8432 : 0.46 : 0.33
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 11.288
FLOATING-POINT INDEX: 0.313
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : Linux 2.6.32.7-versatile
C compiler : gcc version 4.4.3 (GCC)
libc : libc-2.11.1.so
MEMORY INDEX : 2.814
INTEGER INDEX : 2.819
FLOATING-POINT INDEX: 0.174
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

And finally, my host system where Hercules and Qemu run:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
 : : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 1339.8 : 34.36 : 11.28
STRING SORT : 282.56 : 126.26 : 19.54
BITFIELD : 5.6507e+08 : 96.93 : 20.25
FP EMULATION : 186.88 : 89.67 : 20.69
FOURIER : 30009 : 34.13 : 19.17
ASSIGNMENT : 38.938 : 148.16 : 38.43
IDEA : 8292 : 126.82 : 37.65
HUFFMAN : 2983.2 : 82.72 : 26.42
NEURAL NET : 61.4 : 98.63 : 41.49
LU DECOMPOSITION : 1939.9 : 100.50 : 72.57
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 92.652
FLOATING-POINT INDEX: 69.676
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU : Dual GenuineIntel Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz 3010MHz
L2 Cache : 6144 KB
OS : Linux 2.6.32.7-custom64
C compiler : gcc version 4.4.3 (GCC)
libc : libc-2.11.1.so
MEMORY INDEX : 24.774
INTEGER INDEX : 21.953
FLOATING-POINT INDEX: 38.645
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

As you can see, the S/390 emulation is the one that suffers most. The new s390x 64-bits version performs a bit faster, but the processor on the host machine tops at 100% during more complex tasks.

I won’t put all the different (i486 / x86_64 / arm / s390 / s390x) packages on my site, but I’ll submit the SlackBuild script to SlackBuilds.org, so that you can build them yourself on your machines.

So what better to do than finally test the 64-bits version of Slack/390?

I wrote an 11-part post about installing Slack/390 on Hercules more than a year ago, and it is still valid and can be used for installing the newer version of Slack/390 as well – at least for about 90%.
I did encounter some problems though, but the 64-bits version of Slack/390 is still in the testing phase, so we should give it some credit.

What went wrong:

• The “ramdisk_size” from the supplied parmfile.txt is way too small, I made it 64000 to work
• Some packages were missing (sgml-tools / bin86 / clisp / gcc-gnat), but no show-stoppers
• The “etc” package was not installed, causing some problems with standard users and groups
• The symlink “sh” pointing to “bash” was missing, so none of the rc.* scripts would work (created it manually)
• The “/etc/slackware-version” file was missing

I managed to solve all problems one by one and installed SlackPkg from /extra afterwards to update my installation with the latest packages.
I sent my findings to the maintainers of Slack/390 to that future users won’t have the same challenges that I had

I might write a new series of posts on installing Slack/390, with updated information, but I’ll probably wait until the new version is a bit more stable.

For now, I’m having fun with my new 2x 64-bits emulated Mainframe running Slackware!

On his site you can find pre-built packages in RPM and DEB format.
For us Slackware users, I created Slackware packages as well, after getting some extra information from a very friendly Jacob Dekel.

The packages for Slackware, both 32 & 64 bits versions, can be downloaded from my site here.
The stable 3.06 version of Hercules is not prepared for a Linux GUI, so you will need the latest svn snapshot, also available as a Slackware package on the same page.

The result can be seen here:

I have used Hercules for some time now to run Slack/390 and had already created my own package, but it was not really up to the right standards to be published.

But, with the release of Slackware 13.0 I have reorganized some of my packages and built new ones following the guidelines of SlackBuilds.org.

The result can be downloaded from my site:

• hercules-3.06-i486-1_nhh.tgz (32-bits version)
• hercules-3.06-x86_64-1_nhh.tgz (64-bits version)

xpdf has been updated for Slack/390.
This is a security patch, so update your -current system with SlackPkg without further ado!

In the mean time: I’ve been playing around with ARMedslack. I’m just waiting for an opportunity to test it on real hardware, but for the moment I’m running it on the Qemu ARM emulator.

Expect some posts on ARMed slack in the near future…

After almost two years without activiry, the maintainers have released some patches / upgrades for Slack/390 – both the -stable and the -current versions.
Since I use SlackPkg on my other Slackware installations (12.1, 12.2 & -current), I wanted to use this same tool in my Slack/390 installation.

First i tried with the version that is included in /extra in Slack/390, but it is quite old (1.4, from 2005) and it simply didn’t work.

The first problem is that the big majority of packages on the Slack/390 mirrors do not have the associated xxxx.tgz.asc file, which contain the GPG ckecksum of the package.
This was simple to resolve, setting CHECKGPG=off in /etc/slackpkg/slackpkg.conf

But the second problem I encountered was with the naming of some files on the Slack/390 mirrors that differs from the ‘main’ Slackware version:

• The MANIFEST.bz2 files are called MANIFEST.s390.bz2 in Slack/390
• The CHECKSUM.md5 files are called CHECKSUM.s390.md5 in Slack/390
• The PACKAGES.TXT files are called PACKAGES.s390.TXT in Slack/390
• The FILELIST.TXT file is called FILELIST.TXT.s390 (yes, at the end) in Slack/390

I remembered from the newer versions that there was an option for the ‘architecture’, so I decided to try SlackPkg 2.70.5 from slackware-12.2
It can be downloaded here or any valid Slackware mirror.
Since SlackPkg is written as a collection of scripts and marked as “noarch”, I expected no problems.

So I downloaded the package, upgraded the 1.4 version with upgradepkg and edited /etc/slackpkg/slackpkg.conf
I commented out the ’standard’ x86 architecture and uncommented the ARCH=s390 line.
But no luck yet… Still the same problems with the differences in the file names.

At this moment I reached the conclusion that I had to ‘hack’ the SlackPkg scripts to get it working.

I ended up modifying two files, /usr/bin/slackpkg & /usr/libexec/slackpkg/core-functions.sh

The first patch is to the main slackpkg script and defines a variable ’subARCH’ to insert the “.s390″ text in the filenames in case the ARCH is s390:

--- slackpkg.orig 2009-04-10 23:44:49.000000000 -0300
+++ /usr/sbin/slackpkg 2009-04-10 23:57:28.000000000 -0300
@@ -40,6 +40,7 @@
SOURCE=$(grep -e "^\([a-z]\)" $CONF/mirrors)
. $CONF/slackpkg.conf
ARCH=${ARCH:-i[3456]86}
+[ "$ARCH" = "s390" ] && subarch=".s390"
LOCAL=0
KERNELMD5=$(md5sum /boot/vmlinuz 2>/dev/null)
TMPDIR=$(mktemp -p /tmp -d slackpkg.XXXXXX 2>/dev/null || echo "FAILED")


The second patch is to the core-functions script and inserts the $subARCH variable in the filenames:

--- core-functions.sh.orig 2009-04-10 23:53:19.000000000 -0300
+++ /usr/libexec/slackpkg/core-functions.sh 2009-04-11 00:02:49.000000000 -0300
@@ -618,16 +618,16 @@
#
echo -e "\t\tList of all files"
for i in $FIRST $SECOND $THIRD $FOURTH $FIFTH ; do
- getfile ${i}/MANIFEST.bz2 $TMPDIR/${i}-MANIFEST.bz2 && \
+ getfile ${i}/MANIFEST${subARCH}.bz2 $TMPDIR/${i}-MANIFEST.bz2 && \
dirs="$dirs $i"
done

# Format FILELIST.TXT


With these changes, I got SlackPkg working in my Slack/390 installation!

There are still some problems, but they depend on some cleaning up of the Slack/390 mirrors.
In the following image you can see that SlackPkg wants to “upgrade” some packages to older versions:

The fact that SlackPkg want to “downgrade” itself to version 1.4 is understandable, as it is the official version for Slack/390.
The suggestions to downgrade abiword, gftp and gucharmap are caused by the fact that these packages exist two times on the mirrors, once in slackware/gnome (the older versions) and once in slackware/xap (the newer versions).
I wrote about these inconsistencies to s390support@slackware.com but unfortunately have not received any answers yet.

Even with these minor problems, keeping your Slack/390 installation is a lot simpler now with a working SlackPkg!

I recently managed to patch a current version of SlackPkg to work on Slack/390 (the version included in /extra does not work).
I’ll try to organize my notes during the following days and publish the patch so that everyone can keep Slack/390 updated with this wonderful tool

Final configuration and IPLing Slack390

The setup program configured our network, but missed some important details we need to get our network up and running.

1) Loading the network adapter kernel module at boot time

Since we selected to use the LCS we need to load the kernel module that supports it.
This is done by editing the /etc/rc.d/rc.modules file.
I personally prefer VI as an editor, but use whatever you’re more familiar with (and is available in our limited ‘live’-system).
If you use VI, search for ‘lcs’ (hint: open the file with ‘vi /etc/rc.d/rc.modules’ and type ‘/lcs’ + Enter – it’s at line 69) and remove the ‘#’ at the beginning of the line that reads:

#/sbin/modprobe lcs

(hint: press ‘Home’ to go to the beginning of the line, ‘d’ + ’space’ to delete the ‘#’)

Now save the modified file (hint: press ‘:’ + ‘wq’ + Enter)

2) Setting the options for the lcs kernel module

We also need to tell the lcs kernel module the device number of our emulated LCS.
So we create a /etc/modprobe.conf file with the needed information by typing this line:
# echo "options lcs 0xf00,1" > /etc/modprobe.conf

3) Repeating the chandev information from parmfile.txt

To finish, we need to create the /etc/chandev.conf file with the information we put in our original parmfile.txt:
# echo "lcs0,0xf00,0xf01" > /etc/chandev.conf

4) Shutdown our system

Now everything is ready to shutdown our running system, so just enter:
# halt
and press Enter.

Our telnet session will be closed so we’ll change to the Hercules console, where we’ll see the following lines:

Now quit from Hercules to guarantee a clean start by typing ‘quit’ after the Commmand ==> prompt.

5) IPLing our Slack/390 installation for the first time

Start Hercules again and IPL from the first DASD (device number 0120) by typing ‘ipl 120′ after the Commmand ==> prompt.

Since we selected to start the SSH daemon at boot time, Slack/390 will create three public / private key pairs, one each for rsa1, dsa and rsa.
This will take some time (especially the dsa key pair), depending on your processing power (like 10 to 30 minutes).
You’ll see – amongst others – the following lines on the Hercules console:

Starting OpenSSH SSH daemon: /usr/sbin/sshd
Generating public/private rsa1 key pair.
Generating public/private dsa key pair.
Generating public/private rsa key pair.

This only occurs the first time you IPL your Slack/390. All the other times it will be a lot faster.

The last line on the Hercules console will be:

bash-3.00#

This means that Slack/390 was loaded and is ready to receive connections.

6) Connecting to your Slack/390 system

Now go back to your normal console on your host system.
For security reasons, telnet sessions are not allowed, so we’ll have to use ssh from now on.
Connect to your Slack/390 system from your host system (or any other system on your network) with the following command:
$ ssh root@192.168.1.162

The first time you connect to your new Slack/390 system you’ll see the following lines:

The authenticity of host '192.168.1.162 (192.168.1.162)' can't be established.
RSA key fingerprint is df:27:56:56:4b:c3:30:aa:c5:dc:94:2e:21:93:c3:af.
Are you sure you want to continue connecting (yes/no)?

Simply answer ‘yes’ to continue and you’ll see these lines:

Warning: Permanently added '192.168.1.162' (RSA) to the list of known hosts.
root@192.168.1.162's password:

Enter the password for root you defined and you’ll get this prompt:

Linux 2.4.29.
root@herc-slack:~#

Congratulations! You finished installing Slack/390 on your (emulated) mainframe!

7) Where to go from here

First of all, create a normal user with ‘adduser’ so that you don’t have to use root to login to your mainframe.

And then? Well, depending on your processing power, there are many fun things to do, like configuring the http daemon to run a webserver on your mainframe, with mysql. Or configure samba, so that you can access it from Windows desktops.

Or start browsing the web with lynx to check for updates of Slack/390:

Oh, but you complain that there are no graphics?
We have graphics on our mainframe! Just enter ‘info aalib’ and you’ll see what I mean: