Re: RHEL 8.3 install stuck

2020-12-09 Thread Paul Gilmartin
On 2020-12-09, at 13:54:34, David Boyes wrote:
> 
> Update your phone to the current IOS. This is a known bug in IOS 14 GA.
>  
'Tain't no phone; 'twas MacOS Mojave.

> You'd think after a while, they'd quit fooling with their MIME 
> implementation. Ain't broke, don't fix it.
>  
Rich's message contains:
X-Mailer: Apple Mail (2.3445.104.17) (mystery to me)
iOS 14.2 (the latest) has:
X-Mailer: iPhone Mail (18B92)
MacOS Mojave (however obsolescent) has:
X-Mailer: Apple Mail (2.3445.104.17)

Regardless, using:
Content-Type: multipart/alternative; ...

and making one alternative the text payload and the other the
vendor logo is just plain wrong; MIME violation.

And iOS 14.2 shows the same problem.

MacOS Snow Leopard provided a "View; Next Alternative".
I miss it for seeing bad MIME content.

> On 12/8/20, 1:20 PM, Paul Gilmartin wrote:
> 
>Your mailer or your configurartion is broken.  All I see in my
>viewr is the Velocity logo .gif because that's the favored
>alternative:

-- gil

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


Re: RHEL 8.3 install stuck

2020-12-09 Thread David Boyes
Update your phone to the current IOS. This is a known bug in IOS 14 GA.

You'd think after a while, they'd quit fooling with their MIME implementation. 
Ain't broke, don't fix it.

On 12/8/20, 1:20 PM, "Linux on 390 Port on behalf of Paul Gilmartin" 
 wrote:

Your mailer or your configurartion is broken.  All I see in my
viewr is the Velocity logo .gif because that's the favored
alternative:

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


Re: Running SLES9 on z14 under zVM 6.4

2020-12-09 Thread David Boyes
On 12/8/20, 5:42 PM, "Linux on 390 Port on behalf of Paul Gilmartin" 
 wrote:

> On 2020-12-08, at 14:12:21, Bruce Hayden wrote:
>
> z/VM doesn't hide the hardware.  In just about all cases, if it won't run
> in an LPAR, it also won't run under z/VM.

>I recall a counterexample was OpenSolaris.  It wouldn't run in
>an LPAR, but only under VM.  I suspect the matter was not "hid[ing]
>the hardware" but required CP services not available from the hardware.

Bruce is correct. Without ESA/390 mode support in the processor, something as 
old as SLES9 won't run reliably as a VM guest. VM doesn’t simulate support 
that's not in the hardware and I think you'll spend a lot of time chasing 
snarks when things break unexpectedly. Probably time to just bite the bullet 
and build new systems.

Reflecting on OpenSolaris, we deliberately and intentionally wrote the code to 
exploit VM services because at the time we felt that LPARs were insufficiently 
flexible and too difficult to manage to be cost effective, and anyone running 
it probably also had VM to support Linux. Nothing to do with the hardware (we 
avoided anything that depended on hardware level where we could so it would run 
on the maximum number of systems); it was easier to do that way. DIAG 250 made 
disk support a lot simpler, and the DIAG 2A8 networking did the job after IBM 
declined to give us enough information on the OSA to write a proper driver. We 
were able to exploit a lot of the prior wisdom on running operating systems 
efficiently as VM guests; no point in wasting effort re-inventing the wheel 
when there was an easier way right in front of us.

In retrospect, I wish OpenSolaris had taken off. It would have saved a lot of 
the recent annoyance we seem to be experiencing with the changes in device 
naming and bloat of the Linux environment (and dealing with the whole systemd 
aberration). Solaris is a production grade Unix system that works well - ZFS 
would have been a game changer at the time.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


Re: Running SLES9 on z14 under zVM 6.4

2020-12-09 Thread Alan Altmark
On Wednesday, 12/09/2020 at 08:07 GMT, Dennis Andrews 
 wrote:
> 64 bit SLES9 will boot on a z15 running under zVM 7.1

But it will not boot in an LPAR.  As a z/VM guest, a virtual machine 
enjoys the luxury of ESA/390-compatibility architectural mode, which 
allows the guest to operate in something approximating ESA/390 mode as 
long as DAT remains off.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM Systems Lab Services
IBM Z Delivery Practice
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


Re: Running SLES9 on z14 under zVM 6.4

2020-12-09 Thread Dennis Andrews

64 bit SLES9 will boot on a z15 running under zVM 7.1
( 32 bit won't boot ).

Welcome to SUSE LINUX Enterprise Server 9 (s390x) - Kernel
2.6.5-7.321-s390x (ttyS0).
sles9x login:

Totally unsupported, not sure I'd trust it for production.

On 12/8/2020 12:31 PM, Darren Bygrave wrote:

Does anyone know if SLES9 will run on a z14, running under zVM 6.4? Or, has 
anyone tried to run SLES9 on a z14 under VM? We have 3 extremely old SLES9 
servers that are still hanging around after all these years, and are planning 
on a z14 refresh in the coming months. I'm pretty sure they won't run native in 
an LPAR, but will they run under VM?

Darren Bygrave
Technology Consultant
Technical Services for zSeries
Configuration Management & zVM
Data Centre & IT Services
TELUS Communications Inc.
Tel:  (604) 220-1439
Cell: (604) 220-1439
Fax: (604) 581-3105
Email: darren.bygr...@telus.com
A Proud Member of the TELUS Team
CONFIDENTIALITY CAUTION: This message is intended only for the use of the 
individual or entity to which it has been addressed and may contain information 
that is privileged and confidential. If you are not the intended recipient, or 
the employee or agent responsible for delivering the message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If this communication has 
been received in error, respond immediately via telephone or return e-mail, and 
delete all copies of this material.
TELUS  the future is friendly(r)P Think about the environment before 
printing out this message


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


--

Dennis Andrews
Senior Architect
Velocity Software Inc.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


Re: Looking for advice setting up SMC-D between RHEL and z/OS

2020-12-09 Thread Stefan Raspl

For the benefit of others that might be interested in this topic:
Turns out the issue was rooted in use of a LINK instead of an INTERFACE 
statement when defining the OSA in z/OS. Once converted to INTERFACE, things 
worked as expected.

Otherwise, in case of any issues:
You can find materials at 
https://linux-on-z.blogspot.com/p/smc-for-linux-on-ibm-z.html. In particular, 
check the FAQ at https://linux-on-z.blogspot.com/p/smc-faq.html, and the 
troubleshooting section at 
https://linux-on-z.blogspot.com/p/smc-troubleshooting.html.

Here's an outline of what has to be done to get SMC-D up and running on Linux:

# Hotplug ISM device if not yet visible via lspci command (see next step)
# Alternative: Use echo 1 > /sys/bus/pci/slots/0080/power if smc_rnics is
# not available
$ smc_rnics -e 80

# Verify presence of ISM device
# NOTE: No extra setup for VLAN usage required
$ lspci
0001:00:00.0 Non-VGA unclassified device: IBM Internal Shared Memory (ISM) 
virtual PCI device


# Run application using smc_run
$ smc_run foo_socks

# Verify that SMC is really used (see 'SMCD' in final column)
$ smcss -a
StateUID   Inode  Local AddressForeign Address  Intf Mode
ACTIVE   2 115762 10.101.4.8:60594 10.101.4.49:3220  SMCD
ACTIVE   2 112844 10.101.4.8:60592 10.101.4.49:3220  SMCD
ACTIVE   2 112605 10.101.4.8:60590 10.101.4.49:3220  SMCD


Best regards,
Stefan Raspl



On 12/8/20 5:58 PM, Eric Chevalier wrote:

My apologies for the poor formatting of my original message. Let's try again:

[root@zlinux4 Temp]# hostname
zlinux4.phx
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# date
Tue Dec  8 06:37:35 PST 2020
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# lspci
00:00.0 Non-VGA unclassified device: IBM Internal Shared Memory (ISM) virtual 
PCI device

[root@zlinux4 Temp]#
[root@zlinux4 Temp]# ls -ld /sys/bus/pci/slots/*
drwxr-xr-x 2 root root 0 Dec  7 11:23 /sys/bus/pci/slots/1018
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# smc_rnics
  FID  Power  PCI_ID    PCHID  Type   PPrt PNET_ID   
Net-Dev
- 


     1018  1  :00:00.0  07e1   ISM    n/a PNET1 n/a
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# smc_rnics -e 1018
Error: FID 1018 is already enabled
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# ip link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
group default qlen 1000

     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: encf804:  mtu 1500 qdisc mq state UP mode 
DEFAULT group default qlen 1000

     link/ether 02:00:00:00:00:09 brd ff:ff:ff:ff:ff:ff
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# smc_pnet
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# smc_pnet -a PNET1 -I encf804
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# smc_pnet
PNET1 encf804 n/a 255
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# smc_pnet -a PNET1 -D :00:00.0
smc_pnet: Object exists
[root@zlinux4 Temp]#
[root@zlinux4 Temp]# smc_run sftp eric...@mvs60.phx
eric...@mvs60.phx's password:
Connected to eric...@mvs60.phx.
sftp> quit
[root@zlinux4 Temp]# smc_run -d sftp eric...@mvs60.phx
libsmc-preload: map sock to AF_SMC
eric...@mvs60.phx's password:
Connected to eric...@mvs60.phx.
sftp> cd Temp
sftp> ls -l E*
-rwxr-x---    ? 1050 0    429391872 Dec  1 13:14 EJES.V600.pax.Z
sftp> get EJES.V600.pax.Z
Fetching /u/ericadm/Temp/EJES.V600.pax.Z to EJES.V600.pax.Z
/u/ericadm/Temp/EJES.V600.pax.Z 100%  410MB  29.9MB/s   00:13
sftp>
sftp> quit
[root@zlinux4 Temp]#

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390



--

Mit freundlichen Grüßen / Kind regards

Stefan Raspl


Linux on Z
---
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-2177
E-Mail: stefan.ra...@de.ibm.com
---
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: 
Gregor Pillen

Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 
243294


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


Re: Running SLES9 on z14 under zVM 6.4

2020-12-09 Thread van Sleeuwen, Berry
I can't comment on SLES9 but we did have a few SLES10 guests in z14 and z/VM 
7.1. This year we have decommissioned the SLES10 guests.

SLES10 is not supported on z13 already and during the z13 migration we have had 
one guest that didn't survive that. So we had to migrate that guest into 
SLES11. We simply swapped out the OS disks with SLES11 disks, the application 
was able to run in the new environment (though the application itself isn’t 
supported on SLES11). I don't know for sure why this guest wasn't able to run 
in z13 while others had no problems. But there is no point in investigating 
that as both SLES10 and running SLES10 in z13 isn't supported.

Since the z13 and z14 have changed much compared to the machines that are 
supported for SLES9 I would suggest to take a look at migrating them to a newer 
level. I doubt if a SLES9 guest would be able to run correctly in a z14, if it 
will IPL at all.

As Bruce mentioned, when a system will IPL in ESA390 mode it will not IPL in 
either LPAR or z/VM. We have seen that for a z/OS guest during our z14 
migration. z/OS 1.11 cannot start in a z14 environment, we had to migrate that 
to z/OS 1.13 to be able to IPL the guest.

Met vriendelijke groet/With kind regards/Mit freundlichen Grüßen,
Berry van Sleeuwen
Flight Forum 3000 5657 EW Eindhoven

-Original Message-
From: Linux on 390 Port  On Behalf Of Darren Bygrave
Sent: Tuesday, 8 December 2020 21:32
To: LINUX-390@VM.MARIST.EDU
Subject: Running SLES9 on z14 under zVM 6.4

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

Does anyone know if SLES9 will run on a z14, running under zVM 6.4? Or, has 
anyone tried to run SLES9 on a z14 under VM? We have 3 extremely old SLES9 
servers that are still hanging around after all these years, and are planning 
on a z14 refresh in the coming months. I'm pretty sure they won't run native in 
an LPAR, but will they run under VM?

Darren Bygrave
Technology Consultant
Technical Services for zSeries
Configuration Management & zVM
Data Centre & IT Services
TELUS Communications Inc.
Tel:  (604) 220-1439
Cell: (604) 220-1439
Fax: (604) 581-3105
Email: darren.bygr...@telus.com
A Proud Member of the TELUS Team
CONFIDENTIALITY CAUTION: This message is intended only for the use of the 
individual or entity to which it has been addressed and may contain information 
that is privileged and confidential. If you are not the intended recipient, or 
the employee or agent responsible for delivering the message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If this communication has 
been received in error, respond immediately via telephone or return e-mail, and 
delete all copies of this material.
TELUS  the future is friendly(r)P Think about the environment before 
printing out this message


--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390data=04%7C01%7CBerry.vanSleeuwen%40atos.net%7C813bb5c01e3c4dc954b308d89bb86506%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637430563558720808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=IVnTtvoYJ1FAWqU7turjh%2BH4s54cmVCnncikJrIC0QA%3Dreserved=0

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, Atos’ liability cannot be triggered for the message 
content. Although the sender endeavours to maintain a computer virus-free 
network, the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. On all 
offers and agreements under which Atos Nederland B.V. supplies goods and/or 
services of whatever nature, the Terms of Delivery from Atos Nederland B.V. 
exclusively apply. The Terms of Delivery shall be promptly submitted to you on 
your request.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390


Re: Looking for advice setting up SMC-D between RHEL and z/OS

2020-12-09 Thread Christian Borntraeger
On 08.12.20 17:58, Eric Chevalier wrote:
> My apologies for the poor formatting of my original message. Let's try again:
> 
> [root@zlinux4 Temp]# hostname
> zlinux4.phx
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# date
> Tue Dec  8 06:37:35 PST 2020
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# lspci
> 00:00.0 Non-VGA unclassified device: IBM Internal Shared Memory (ISM) virtual 
> PCI device
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# ls -ld /sys/bus/pci/slots/*
> drwxr-xr-x 2 root root 0 Dec  7 11:23 /sys/bus/pci/slots/1018
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# smc_rnics
>  FID  Power  PCI_ID    PCHID  Type   PPrt PNET_ID   
> Net-Dev
> -
>     1018  1  :00:00.0  07e1   ISM    n/a PNET1 n/a
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# smc_rnics -e 1018
> Error: FID 1018 is already enabled
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# ip link
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
> DEFAULT group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: encf804:  mtu 1500 qdisc mq state UP mode 
> DEFAULT group default qlen 1000
>     link/ether 02:00:00:00:00:09 brd ff:ff:ff:ff:ff:ff
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# smc_pnet
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# smc_pnet -a PNET1 -I encf804
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# smc_pnet
> PNET1 encf804 n/a 255
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# smc_pnet -a PNET1 -D :00:00.0
> smc_pnet: Object exists
> [root@zlinux4 Temp]#
> [root@zlinux4 Temp]# smc_run sftp eric...@mvs60.phx
> eric...@mvs60.phx's password:
> Connected to eric...@mvs60.phx.
> sftp> quit
> [root@zlinux4 Temp]# smc_run -d sftp eric...@mvs60.phx
> libsmc-preload: map sock to AF_SMC
> eric...@mvs60.phx's password:
> Connected to eric...@mvs60.phx.
> sftp> cd Temp
> sftp> ls -l E*
> -rwxr-x---    ? 1050 0    429391872 Dec  1 13:14 EJES.V600.pax.Z
> sftp> get EJES.V600.pax.Z
> Fetching /u/ericadm/Temp/EJES.V600.pax.Z to EJES.V600.pax.Z
> /u/ericadm/Temp/EJES.V600.pax.Z 100%  410MB  29.9MB/s   00:13

With 30MB/sec you are far below what the network card could give you so this
is not the bottleneck. SMC cannot help you when your bottleneck is somewhere
else (e.g. disk I/O overloaded, subcapacity CPUs and unconfigured crypto 
resulting
in slow encryption). So I would suggest to watch the CPU load as well as the 
disk load to find out why things are slow.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390