Discussion:
Hercules 3.03 - CYGWIN version & a P390
Add Reply
'Dave Wade' dave.g4ugm@gmail.com [hercules-390]
2018-07-25 09:18:30 UTC
Reply
Permalink
Raw Message
Gregg,
Thanks for that, I have had one other person who thinks they know where one is what, but again may involve searching!.
Dave

PS Perhaps I should include the full story. Some time ago I was given a PC Server 500 with a P390 in it. It was giving its previous owner some grief. The 6-Disk RAID-5 array kept failing to bring one disk on-line so was operating in degraded mode, the Floppy was un-reliable, and the Display Adaptor had failed. The machine had sat under the table in my "Shack" (Radio Room) for some time. My original intention was to replace the RAID with an SCSI2SD adaptor. After starting down this path I discovered I knew less than I thought about OS/2, P390's and Microchannel. However, after buying odd Microchannel cards and a 2.88 Mb PS/2 floppy drive on E-bay (some of which I don't need) I have managed to install a second SCSI card, backup the OS/2 to a SCSI2SD and get the machine to boot from the SCSI2SD card. The P390 stuff also runs from this card, but performance suffers as I have gone from Wide SCSI-2 to Narrow SCSI-1. So proceeding onwards and upwards I bought a couple of 72Gb Cheetah U320 SCSI drives, put them in the RAID controller and created some mirrored virtual drives, copied OS/2 back from the SD Card, and the machine now runs quite nicely. I have bought a third 72GB drive so I even have a hot spare. The new drives are modern 1/4 height and the machine no longer sounds like a small executive jet starting up when I switch it on, and seems to bring the RAID online without issue. The replacement floppy is still mildly temperamental after a good clean, but PC Server floppy drives are wonder to behold and so not easily replaced with one of the modern emulators.

Now being at the stage where I have a working machine, with backups, some one asked would Hercules run on the Intel Pentium 90 and if so how did it compare with the P390 board. Never one to buck a challenge after a bit of fiddling with SCSI DVD and CD drives I installed NT4 on a bit of disk space that I had saved for such an experiment. The original hardware is supported "Out of the box" and NT4 runs surprisingly well. Of course, with only 32MB of RAM nothing else runs very well. In particular any Web Browser that is usable on the current inter-web is unusable on the PC. I tried an early Hercules 3.02 native build, but that fails as it needs some calls that are, I think, only in XP and later. I tried installing Windows/2000 but it can't find appropriate RAID drivers and hangs on install. On my backups I found a Hercules 2.12 with CYGWIN DLLs and whilst it runs it has issues building CCKD DASD which I needed as only a small area of disk is accessible by NT4 as that dropped HPFS support. I tried the usual cludge to re-enable it but it just slows the machine to a crawl trying to read the directories on the large HPFS partitions. Any way I did manage to run the Whetstone benchmarks which says the P90 runs at about 100 K Whetstones, which is about the same as a 4331 model 1.

I know plan to take a short break while the search for CYGWUN DLLs continues and I lower the level of blood in my alcohol system back to normal levels..
-----Original Message-----
Sent: 25 July 2018 05:17
Subject: Re: [hercules-390] Hercules 3.03 - CYGWIN version
Hello!
Dave W, give me a few days and I'll see if I can track down the libraries plus
possibly even the programs built using that release of Cygwin.
It happens at one point in time I made a habit of collecting practically
everything to do with Hercules, including early releases of Hercules itself,
especially one minor release that was last used to build the diskpacks I use
for running VM/370rel6.
I believe that will satisfy the one who breathes through gills. It would
probably surprise the one who's reading this surrounded by an audience. Oh
and Dave W, your statue problems have ended as it left.
-----
"This signature fought the Time Wars, time and again."
Folks,
Does any one have a copy of the CYGWIN 1.5 DLL’s necessary to run the
3.03 CYGWIN version of Hercules?
Dave Wade
G4UGM & EA7KAE
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
Giuseppe Vitillaro giuseppe@vitillaro.org [hercules-390]
2018-07-25 10:37:54 UTC
Reply
Permalink
Raw Message
Speaking about the Linux implementation of the (spinhawk) 3.13 hercules
emulator ctc_lcs.c code, I'm willing to understand WHY the function
LCS_StartLan() add this host route:

ctc_lcs.c:
--------------------------------------------------
1324 #ifdef OPTION_TUNTAP_DELADD_ROUTES
1325
1326 // Add a Point-To-Point routing entry to the
1327 // host's routing table for our interface...
1328
1329 if( pLCSDEV->pszIPAddress )
1330 {
1331 VERIFY( TUNTAP_AddRoute( pLCSPORT->szNetDevName,
1332 pLCSDEV->pszIPAddress,
1333 "255.255.255.255",
1334 NULL,
1335 RTF_UP | RTF_HOST ) == 0 );
1336 }
1337 #endif // OPTION_TUNTAP_DELADD_ROUTES

for the LCS "guestip" address defined in the configuration
file as, for example with:

0E20.2 3088 LCS -n /dev/net/tun guestip

What I'm doing is adding, with the bridge command

"brctl addif tapN bridge_name"

the hercules tap interface to one of my existing bridges
(a virt-manager bridge I use also for my KVM virtual
machines).

It perfectly works if I delete this host route, using,
after the tap device is started by LCS_StartLan(), a
"route delete" command:

route delete -host guestip tapN

but it doesn't, while this host route is defined.

If I simply "ifdef out" this fragment of code, everything
simply work out of the box.

What am I missing here? Why hercules add this host route?

Would I damage any other functionality commenting this
"route add -host guestip tapN" from the ctc_lcs.c code?

Another question.

From what I'm reading in the tuntap.c code, the tap device
is ALWAYS created, so it is not possible to use a persistent
preconfigured tap interface name, from the hercules-3.13 spinhawk
emulator.

I can't see any way to define the "tap name" in "ifr_name", as
the code ask always for a new tap device with the code:

1519 strcpy( ifr.ifr_name, pLCSPORT->szNetDevName );
1872 memset( pLCSPORT->szNetDevName, 0, IFNAMSIZ );

Do I understand correctly?

Is this feature supported by the hercules 4.x hyperion version?

What I would like to have is a configuration flag like

0E20.2 3088 LCS -n /dev/net/tun -t tapname guestip

which allows hercules to use an already defined interface "tapname",
already added to the correct bridge, before hercules start.

Is there any way to achieve this goal with the existing code?

Peppe.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2018-07-25 12:25:15 UTC
Reply
Permalink
Raw Message
Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
0E20.2 3088 LCS -n /dev/net/tun -t tapname guestip
which allows hercules to use an already defined interface "tapname",
already added to the correct bridge, before hercules start.
Simple comment :

If this is going to be a layer 2 interface, you don't have to specify a
"guest ip address" (the bridge/vswitch will simply forward Eth/802.3
frames as-is accross whatever port(s) is/are necessary depending on the
policies, destination address, 802.1q VLAN tags and possible STP blocking).

This work fine in hyperion with :

E00.2   LCS     -if tap0

while /dev/net/tun is implied and with "tap0" being a
predifined/persistent tap interface defined with "ip tuntap add mode tap
name tap0" (the name being an arbitrary string) connected to a bridge
(in my case an openvswitch virtual switch, but works the same with a
simple linux bridge).

PS : The link must also be brought up with 'ip link tap0 set up' but you
don't need (and probably shouldn't) give it any IP address (the tap
interface is just a cable connecting the hercules LCS nic to a virtual
switch/bridge).

In this case hyperion tries to fire hercifc anyway, but you don't have
to have it setuid root since whatever it does is irrelevant for a layer2
interface (there is a bug there, but it's pretty much cosmetic at that
point).

Spinhawk might not support "-if" though, haven't tried lately...

--Ivan



[Non-text portions of this message have been removed]
Giuseppe Vitillaro giuseppe@vitillaro.org [hercules-390]
2018-07-25 16:12:25 UTC
Reply
Permalink
Raw Message
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
0E20.2 3088 LCS -n /dev/net/tun -t tapname guestip
which allows hercules to use an already defined interface "tapname",
already added to the correct bridge, before hercules start.
If this is going to be a layer 2 interface, you don't have to specify a
"guest ip address" (the bridge/vswitch will simply forward Eth/802.3
frames as-is accross whatever port(s) is/are necessary depending on the
policies, destination address, 802.1q VLAN tags and possible STP blocking).
That the theory, hercules-3.13 doesn't work if I do not add
the "guestip". No way. Or guestip is there, and MATCH the real
"guest ip" address, or it doesn't simply work, with the vary same
hercules and guest configuration.

With guestip works for me, without it DOESN'T.

I can't understand exactly why, but I see code in
the hercules-3.13 ctc_lcs.c source which test for the "guestip"
address:

1703 // If this is an exact match use it
1704 // otherwise look for primary and secondary
1705 // default devices
1706 if( pLCSDev->lIPAddress == lIPAddress )
1707 {
1708 pMatchingLCSDEV = pLCSDev;
1709 break;
1710 }
1711 else if( pLCSDev->bType == LCSDEV_TYPE_PRIMARY )
1712 pPrimaryLCSDEV = pLCSDev;
1713 else if( pLCSDev->bType == LCSDEV_TYPE_SECONDARY )
1714 pSecondaryLCSDEV = pLCSDev;

It looks like a packet filter code, isn't it?
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
E00.2   LCS     -if tap0
while /dev/net/tun is implied and with "tap0" being a
predifined/persistent tap interface defined with "ip tuntap add mode tap
name tap0" (the name being an arbitrary string) connected to a bridge
(in my case an openvswitch virtual switch, but works the same with a
simple linux bridge).
Nice, thanks for the reference, I missed it.

But I would like to have this feature available
also under spinhawk. I can't see neither the flag,
neither the code to support an existing tap interface.
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
PS : The link must also be brought up with 'ip link tap0 set up' but you
don't need (and probably shouldn't) give it any IP address (the tap
interface is just a cable connecting the hercules LCS nic to a virtual
switch/bridge).
In this case hyperion tries to fire hercifc anyway, but you don't have
to have it setuid root since whatever it does is irrelevant for a layer2
interface (there is a bug there, but it's pretty much cosmetic at that
point).
Spinhawk might not support "-if" though, haven't tried lately...
Yep I understand this, I've a simple test code which does exactly
the same and anyway I do not use "setuid", too dangerous, for
hercifc. I'm using capabilities (managed with setcap), under Linux,
which works nicely.

My test code goes a little bit further. With a very simple
subroutine (under Linux) it would be possible to add to an existing
bridge the tap interface, just after has been created, using again
hercifc and without any needs to use the "-if" flag.

It would be possible to have a configuration line like this:

E00.2ᅵᅵ LCSᅵ -b br100

where "br100" it is the "name" of the bridge and
the tap interface is created directly from
emulator and it disappears from the system
when the emulator terminates.

I just tested, with my few lines of test code

setcap cap_net_admin+ep hercifc

would allow hercules to automatically creates the
tap interface and add it to the "br100" bridge,
without any other privilege escalation.

Those are the very same capabilities already required
from hercifc to be able to add and configure interfaces.

Beside that, it would be nice if hercules may
use, under Linux, a different name template
for the "tap" interfaces created by the emulator.

It is enough to use, for the interface name, a string
like this:

"hrc%d"

to ask to "ioctl(fd, TUNSETIFF, (void *) &ifr))" to
create interface names like "hrc0,hrc1,..." and so
on. Tested, it works.

I've bridges with many ports active and being able
to see, from the names, which one belongs to hercules,
just from the names, like in this example

vbr100 8000.0a36410d683e yes hrc0

would be really nice, especially when grepping
the "brctl show" output.

Peppe.

[Non-text portions of this message have been removed]
Giuseppe Vitillaro giuseppe@vitillaro.org [hercules-390]
2018-07-25 18:03:40 UTC
Reply
Permalink
Raw Message
Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
With guestip works for me, without it DOESN'T.
I can't understand exactly why, but I see code in
the hercules-3.13 ctc_lcs.c source which test for the "guestip"
1703 // If this is an exact match use it
1704 // otherwise look for primary and secondary
1705 // default devices
1706 if( pLCSDev->lIPAddress == lIPAddress )
1707 {
1708 pMatchingLCSDEV = pLCSDev;
1709 break;
1710 }
1711 else if( pLCSDev->bType == LCSDEV_TYPE_PRIMARY )
1712 pPrimaryLCSDEV = pLCSDev;
1713 else if( pLCSDev->bType == LCSDEV_TYPE_SECONDARY )
1714 pSecondaryLCSDEV = pLCSDev;
It looks like a packet filter code, isn't it?
Yep. It definitely IS a packet filter.

With this really rude HACK (I'm sure it brokes other
configuration options):

1831 #if PEPPE
1832 // No match found, discard frame
1833 if( !pMatchingLCSDEV )
1834 {
1835 if( pLCSPORT->pLCSBLK->fDebug )
1836 logmsg( _("HHCLC015I Port %2.2X: "
1837 "No match found - Discarding frame\n"),
1838 pLCSPORT->bPort );
1839 continue;
1840 }
1841 #endif
1842 if( !pMatchingLCSDEV )
1843 pMatchingLCSDEV = pLCSPORT->pLCSBLK->pDevices;

ctc_lcs.c works as you suggested, Ivan, without specifying
a "guestip" address (by the way it is supposed to be "optional"
in the spinhawk 3.12 documentation, it is NOT, if my analysis
is correct).

It shortcut the filter created by this "continue statement", forcing to
send the ethernet frames to the very first device in the list,
pLCSPORT->pLCSBLK->pDevices. For the case of a configuration file without
oatfile, should be always the correct one. If I'm not wrong, it shouldn't
even broke the "oat" case, if ONE and ONLY interface hasn't an IP address
associated, it should works as expected if ALL the interfaces specify
a valid IP address, not sure what would happens for other cases.

Now it works WITHOUT specifying "guestip", as expected from the
official documentation:

guestip

is an optional IP address of the Hercules (guest OS) side. Note: This
is only used to establish a point-to-point routing table entry on driving
system. If you use the --oat option, do not specify an address here.

By the way, if "guestip" is NOT specified, with this hack,
the "host route", of course, it is not added. And everything
seems to work as expected from the documentation.

May this be a spinhawk hercules 3.13 bug?

Peppe.
Giuseppe Vitillaro giuseppe@vitillaro.org [hercules-390]
2018-07-26 12:06:28 UTC
Reply
Permalink
Raw Message
Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
With guestip works for me, without it DOESN'T.
I can't understand exactly why, but I see code in
the hercules-3.13 ctc_lcs.c source which test for the "guestip"
1703 // If this is an exact match use it
1704 // otherwise look for primary and secondary
1705 // default devices
1706 if( pLCSDev->lIPAddress == lIPAddress )
1707 {
1708 pMatchingLCSDEV = pLCSDev;
1709 break;
1710 }
1711 else if( pLCSDev->bType == LCSDEV_TYPE_PRIMARY )
1712 pPrimaryLCSDEV = pLCSDev;
1713 else if( pLCSDev->bType == LCSDEV_TYPE_SECONDARY )
1714 pSecondaryLCSDEV = pLCSDev;
It looks like a packet filter code, isn't it?
Yep. It definitely IS a packet filter.
With this really rude HACK (I'm sure it brokes other
1831 #if PEPPE
1832 // No match found, discard frame
1833 if( !pMatchingLCSDEV )
1834 {
1835 if( pLCSPORT->pLCSBLK->fDebug )
1836 logmsg( _("HHCLC015I Port %2.2X: "
1837 "No match found - Discarding frame\n"),
1838 pLCSPORT->bPort );
1839 continue;
1840 }
1841 #endif
1842 if( !pMatchingLCSDEV )
1843 pMatchingLCSDEV = pLCSPORT->pLCSBLK->pDevices;
ctc_lcs.c works as you suggested, Ivan, without specifying
a "guestip" address (by the way it is supposed to be "optional"
in the spinhawk 3.12 documentation, it is NOT, if my analysis
is correct).
It shortcut the filter created by this "continue statement", forcing to
send the ethernet frames to the very first device in the list,
pLCSPORT->pLCSBLK->pDevices. For the case of a configuration file without
oatfile, should be always the correct one. If I'm not wrong, it shouldn't
even broke the "oat" case, if ONE and ONLY interface hasn't an IP address
associated, it should works as expected if ALL the interfaces specify
a valid IP address, not sure what would happens for other cases.
Now it works WITHOUT specifying "guestip", as expected from the
guestip
is an optional IP address of the Hercules (guest OS) side. Note: This
is only used to establish a point-to-point routing table entry on driving
system. If you use the --oat option, do not specify an address here.
By the way, if "guestip" is NOT specified, with this hack,
the "host route", of course, it is not added. And everything
seems to work as expected from the documentation.
May this be a spinhawk hercules 3.13 bug?
Peppe.
Just my last 2 cents note, if anyone may be interested.

I patched spinhawk hercules-3.13 to support this configuration
options:

0E20.2 3088 LCS -b vbr100 -x hrc%d

where "-b" is for an "existing" bridge name and
"hrc%d" is the template name hercifc should creates
(requires setuid or capabilities) and add to the
the bridge specified with the "-b" option.

The "-x" (long option "-if") option, should be
compatible with the current hyperion options.

It works without a glitch, under Linux and ONLY under Linux,
and it connects an LCS emulated device to an existing
linux bridge, through a TAP Linux interface, which
may be a persisting existing tap interface, if
specified without a "%d" specification, like for example
"tap0" or "hrc0".

This way the spinhawk hercules emulator may be
connected to a real physical network or, for
example, to "virtual network", likes the standard
bridges used by qemu/kvm.

It is really nice to have my virtual machines able
to communicate directly, over an emulated network,
with an hercules emulated mainframe.

No external commands are needed, hercules just use
the standard hercifc module to perform the configuration
of the tap interface, attaching it to the specified bridge.

Peppe.

Loading...