Re: z/Linux and VM RDR files

[Ingo Adlung]

I don't recall how an unsolicited DE is processed today, but I don't feel a
udev event would be the adequate action. Perhaps it could become an
informational log entry that could be filtered ...

Best regards
Ingo

Linux on 390 Port  wrote on 21/05/2021 14:12:30:

> From: Dave Jones 
> To: LINUX-390@VM.MARIST.EDU
> Date: 21/05/2021 14:12
> Subject: [EXTERNAL] Re: [LINUX-390] z/Linux and VM RDR files
> Sent by: Linux on 390 Port 
>
> > But I don't know if the Linux device drivers will generate UDEV events
> > based on it.  It would be nice if they did.
> They don't, unfortunately.
> DJ
>
> ---
> DAVID JONES | MANAGING DIRECTOR FOR ZSYSTEMS SERVICES | z/VM, Linux, and
> Cloud
> 703.237.7370 (Office) | 281.578.7544 (CELL)
>
> INFORMATION TECHNOLOGY COMPANY
>
> On 05.20.2021 2:32 PM, Alan Altmark wrote:
> > On Thursday, 05/20/2021 at 07:37 GMT, Dave Jones 
> > wrote:
> >> How can I get automatically notified in a z/Linux guest (in this case
> >> Ubuntu 20.04) when a rdr file arrives for it?
> >
> > (Didn't we have a conversation about this here a few weeks/months ago?)
> >
> > Aside from an IMSG, the reader will get an unsolicited DEVICE-END
> > interrupt indicating a transition from NOT READY to READY.  This is the
> > same kind of interrupt that indicates
> > - a tape has been loaded in a drive and has reached load point,
> > - a disk pack has spun up to speed after being mounted (think 2314)
> > - you have powered on your 3270.
> >
> > Bottom line, the device is ready to send or receive data.
> >
> > But I don't know if the Linux device drivers will generate UDEV events
> > based on it.  It would be nice if they did.
> >
> > 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
> > INVALID URI REMOVED
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwICAg=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=5ywmMJVFZyEf8W6Vzgu1WsH4_ZU6YQzUzMv8mg-
> vkMI=mluEhnHnjo7oGpUwXU9AUnwgN0gFa6nv3SLlcDDOICU=
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> INVALID URI REMOVED
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwICAg=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=5ywmMJVFZyEf8W6Vzgu1WsH4_ZU6YQzUzMv8mg-
> vkMI=mluEhnHnjo7oGpUwXU9AUnwgN0gFa6nv3SLlcDDOICU=
>

--
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: vmrelocate and quiescence time

[Ingo Adlung]

I may be wrong but I think the Guarded Page facility is about load
references. This could e.g. help Java to determine hot versus cold objects
without generating too much overhead. As such it could therewith also
assist determining the active working set ... but in the end the question
remains how stable such working set is, and whether it exists as subset to
the virtual machine allocation in the first place ...

Best regards
Ingo

Linux on 390 Port  wrote on 18/08/2020 16:03:30:

> From: Neale Ferguson 
> To: LINUX-390@VM.MARIST.EDU
> Date: 18/08/2020 16:03
> Subject: [EXTERNAL] Re: [LINUX-390] vmrelocate and quiescence time
> Sent by: Linux on 390 Port 
>
> Could you take advantage of the guard page hardware facility of the
> z15 that the pause-less Java garbage collector uses?
>
>  Original message 
>
> z/VM doesn't have a short cut to determine that no pages have changed. So
> for a guest over 100GB, it has to examine over 26 million things multiple
> times. Validating the I/O is drained is another aspect, but my guess is
the
> traversing of the DAT structures is the biggest factor.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> INVALID URI REMOVED
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIGaQ=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-y49pWL0=MK-
> gQWB799b9yN6buzqOhh1pAPxzHhfZFTMynpjO-
> H8=P75LMSRd_VThN0H8mYgUsmax8xHEBmq_CeYJ5NvxiuA=
>

--
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: VM system name

[Ingo Adlung]

levant for production
> systems at all, but I like interfaces to
> > be consistent... do you have anything people can play with?)
>
> tcg hasn't been a focus of qclib at all so far.
> Try
https://public.dhe.ibm.com/software/dw/linux390/ht_src/qclib-2.1.0.tgzand
> run 'make test', that should do.
>
> >
> > (...)
> >
> >>> If the machine is reporting back something beyond the known model
> >>> generations, then you could print ">z15" or "z15+" or "z16?" until
> >>> zhypinfo is updated. When zhypinfo is updated you then insert the
model
> >>> generation without the question mark and update the question mark to
be
> >>> "z17?" (for example). Loop, repeat.
> >>
> >> Some of these suggestions could be easily mistaken as actual
> model names (e.g.
> >> "z15+" or "z16") while they are not - a very delicate matter.
> Plus, for various
> >> reasons, the unidentified ID might turn out not to be a later
> generation model,
> >> in which case we would give false info. So we should probably resort
to
> >> "unknown", or maybe "UFC" (Unidentified Flying CEC) - just kidding.
> >
> > I'd like to see a flying CEC, even if it is unidentified :)
> >
> > Another thing maybe to consider is QEMU cpu models. If a guest is
> > running on a z host, but the cpu model used for the VM is z,
> > displaying a model of z while the guest actually sees a z could
> > be confusing.
>
> So far, we're only considering the CPU model visible to the guest,
> so we should
> be OK in this scenario.
>
>
> --
>
> Mit freundlichen Grüßen / Kind regards
>
> Stefan Raspl
>
>
> Linux on Z & Virtualization Development
>
-----------

> 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
> https://urldefense.proofpoint.com/v2/url?
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIFaQ=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=1Vxel2ONYBkgqKqQQvGYAZDIthPDfj9u3am-
> j2FNoh0=ZV3OBBVUQ7aSoAbdY7qjxVJiIQwkIcWDdhfC6rrGadk=
>

Mit freundlichem Gruß / Best regards
Ingo Adlung


   
   Ingo AdlungIBM Deutschland Research &   
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, and CTO   Vorsitzender des Aufsichtsrats:  
   IBM Z and LinuxONE Virtualization  Gregor Pillen
   & LinuxGeschäftsführung: Dirk Wittkopp  
   mail: adl...@de.ibm.comSitz der Gesellschaft: Böblingen 
   phone: +49-7031-16-4263Registergericht: Amtsgericht 
  Stuttgart, HRB 243294
  IBM Privacy Statement
  https://www.ibm.com/privacy/us/en/   
  IBM Datenschutzerklärung 
  https://www.ibm.com/privacy/de/de/   
   





--
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: Who is still using z/VM and z/Linux?

[Ingo Adlung]

By which metrics do you think it suffered in its attractiveness?

Best regards
Ingo


   
   Ingo AdlungIBM Deutschland Research &   
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, and CTO   Vorsitzender des Aufsichtsrats:  
   IBM Z and LinuxONE Virtualization  Gregor Pillen
   & LinuxGeschäftsführung: Dirk Wittkopp  
   mail: adl...@de.ibm.comSitz der Gesellschaft: Böblingen 
   phone: +49-7031-16-4263Registergericht: Amtsgericht 
  Stuttgart, HRB 243294
  IBM Privacy Statement
  https://www.ibm.com/privacy/us/en/   
  IBM Datenschutzerklärung 
  https://www.ibm.com/privacy/de/de/   
   






Linux on 390 Port  wrote on 14/04/2020 13:31:56:

> From: Frank Wolfe 
> To: LINUX-390@VM.MARIST.EDU
> Date: 14/04/2020 13:32
> Subject: [EXTERNAL] [LINUX-390] Who is still using z/VM and z/Linux?
> Sent by: Linux on 390 Port 
>
> Hello,
>
> I am wondering since z/VM and z/Linux is obviously the best platform, how
> many people / customers are running it still? It doesn't seem like many
and
> that saddens me.
>
> Frank
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> https://urldefense.proofpoint.com/v2/url?
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIBaQ=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
>
y49pWL0=OqD5bn58zQ1pzCbYSR0NkxhhEWa_aRsM-31E1laoVjc=1YpwzTjNVT4ckZ95aqZ1JMjNldjxzr08xtP_Oi1fOjg=

>

--
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: Cloud using zlinux

[Ingo Adlung]

As mentioned previously by various folks responding to your inquiry "Cloud"
can mean many things these days. So let me add to the zoo of options with
the new IBM Cloud Infrastructure Center offering.

As you have learned if your translation of "Cloud" is the provisioning of
virtual machines there are many options to choose from.

If your goal is a prescriptive Cloud automation tool that allows for the
seamless integration with vRealize Automation, IBM Cloud Automation
Manager, terraform, CloudForms, Ansible etc. without much invention by
yourself your option space shrinks significantly and you may want to
consider giving the new IBM Cloud Infrastructure Center offering a closer
look.

Best regards
Ingo

Linux on 390 Port  wrote on 01/03/2020 08:02:36:

> From: Peter 
> To: LINUX-390@VM.MARIST.EDU
> Date: 01/03/2020 08:08
> Subject: [EXTERNAL] [LINUX-390] Cloud using zlinux
> Sent by: Linux on 390 Port 
>
> Hello
>
> I am trying to understand how cloud is configured using zlinux.
>
> Any manuals or white papers which can help me to read and understand in
> detail ?
>
> Peter
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> https://urldefense.proofpoint.com/v2/url?
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIBaQ=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=bbrzflMCZXsS7kt3_X3J_9yKrx2txiLNTiu5SNAwCKU=270I_rnjm-
> sbfNQzkWjRZSu_v1pXgJ59yrlnsUiUPAM=
>




   
   Ingo AdlungIBM Deutschland Research &   
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, and CTO   Vorsitzender des Aufsichtsrats:  
   IBM Z and LinuxONE Virtualization  Gregor Pillen
   & LinuxGeschäftsführung: Dirk Wittkopp  
   mail: adl...@de.ibm.comSitz der Gesellschaft: Böblingen 
   phone: +49-7031-16-4263Registergericht: Amtsgericht 
  Stuttgart, HRB 243294
  IBM Privacy Statement
  https://www.ibm.com/privacy/us/en/   
  IBM Datenschutzerklärung 
  https://www.ibm.com/privacy/de/de/   
   





--
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: Pervasive disk encryption questions

[Ingo Adlung]

message: INFO LINUX-390 or
visit
> https://urldefense.proofpoint.com/v2/url?
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIGaQ=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=DhEPjijzZHzxFUR5Ocah1MuFFKk-0-wj639ZIZ9EjFo=vIEO-
> HPz83_EsRxjBWYxTWa_wZKC7Qa5SEl0hBZZbJE=
>

   
   Ingo AdlungIBM Deutschland Research &   
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, and CTO   Vorsitzender des Aufsichtsrats:  
   IBM Z and LinuxONE Virtualization  Matthias Hartmann
   & LinuxGeschäftsführung: Dirk Wittkopp  
   mail: adl...@de.ibm.comSitz der Gesellschaft: Böblingen 
   phone: +49-7031-16-4263Registergericht: 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: Happy birthday

[Ingo Adlung]

Linux on 390 Port  wrote on 19/12/2019 14:06:24:

> From: Neale Ferguson 
> To: LINUX-390@VM.MARIST.EDU
> Date: 19/12/2019 14:07
> Subject: [EXTERNAL] Re: [LINUX-390] Happy birthday
> Sent by: Linux on 390 Port 
>
> And thus was born cio_ignore?
>

Yes, that was the quick remedy :-) But in the end wanted to allow for as
many as the clients actually needed and/or desired ...

>
>  Original message 
> From: Ingo Adlung 
> Date: 12/19/19 23:55 (GMT+10:00)
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: [LINUX-390] Happy birthday
>
> And I remember the legendary Install Fest parties we had with clients in
> groups of 10-15 and eventually doing 1:1 calls. I wrote the I/O layer at
> that time and was overwhelmed when people booted (IPLed) Linux into
OS/390
> partitions with 10s of thousands of I/O devices defined/attached. In
order
> for not having to allocate so much static memory I first limited the
number
> of addressable devices to 1024, following the VSE/ESA model, and only
when
> clients wanted more (many did start with Linux in LPAR and only
partitions
> configured for OS/390 at hand) I back-ported dynamic boot memory
allocation
> back from the 2.3 kernel to 2.2, still avoiding large memory allocations
> when all a client wanted to operate where just a handful of devices ...
>
> Mit freundlichem Gruß / Best regards
> Ingo Adlung
>
>
>
>Ingo AdlungIBM Deutschland Research &
>IBM Distinguished Engineer Development GmbH
>Chief Architect, and CTO   Vorsitzender des Aufsichtsrats:
>IBM Z and LinuxONE Virtualization  Matthias Hartmann
>& LinuxGeschäftsführung: Dirk Wittkopp
>mail: adl...@de.ibm.comSitz der Gesellschaft: Böblingen
>phone: +49-7031-16-4263Registergericht: Amtsgericht
>   Stuttgart, HRB 243294
>
>
>
>
>
>
>
>
>
> From:   Mike Riggs 
> To: LINUX-390@VM.MARIST.EDU
> Date:   19/12/2019 13:34
> Subject:[EXTERNAL] Re: [LINUX-390] Happy birthday
> Sent by:Linux on 390 Port 
>
>
>
> And thus started the new future of judicial technology here. Not too long
> after, a distro was running (well, sorta walking) on a 9672. Been a blast
> ever since.
>
> Mike Riggs
> OES/SCV
>
> -Original Message-
> From: Linux on 390 Port  On Behalf Of Rich
Smrcina
> Sent: Wednesday, December 18, 2019 9:34 PM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: Happy birthday
>
> I’m sure there were more than a few of us installing the ‘Marist’
> distribution on our mainframes over Christmas.
>
> I know I was working on the install at Grede Foundries.
>
> Rich Smrcina
> Sr. Systems Engineer
>
> Velocity Software Inc.
> Main: (650) 964-8867
> Main: (877) 964-8867
> r...@velocitysoftware.com <mailto:r...@velocitysoftware.com>
>
>
> > On Dec 18, 2019, at 8:25 PM, Neale Ferguson 
wrote:
> >
> >
> https://urldefense.proofpoint.com/v2/url?
>
u=https-3A__tech-2Dinsider.org_linux_research_1999_1218.html=DwIGaQ=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=6Vdtn9czQLmEFCLh41YmBe-
> CZzwY375fuXlEuAgDrNo=QoPSQ9tkxyy7_dafKnVSmtqWoHB6nZaezrAdL2ji_MY=
>
> >
> > "Dec 18, 1999
> >
> > According to Alan Cox's 2.2.14pre14 patch, Linux now has at least
> preliminary support for running on the IBM S/390 Mainframe. Rumors that
IBM
> has been engaged in a port have been circulating for some time, but this
is
> the first concrete code that has surfaced to date..."
> >
> > --
> > For LINUX-390 subscribe / signoff / archive access instructions, send
> > email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> > visit
> >
> https://urldefense.proofpoint.com/v2/url?
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIGaQ=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=6Vdtn9czQLmEFCLh41YmBe-
> CZzwY375fuXlEuAgDrNo=SB0o_Utp2GmkAmFiGILQpRbYiW1Vmnz9Jh2eAtxvc80=
>
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send
email
> to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
> https://urldefense.proofpoint.com/v2/url?
>
u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIGaQ=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=6Vdtn9czQLmEFCLh41YmBe-
> CZzwY375fuXlEuAgDrNo=SB0o_Utp2GmkAmFiGILQpRbYiW1Vmnz9Jh2eAtxvc80=
>
>
> ---

Re: Happy birthday

[Ingo Adlung]

And I remember the legendary Install Fest parties we had with clients in
groups of 10-15 and eventually doing 1:1 calls. I wrote the I/O layer at
that time and was overwhelmed when people booted (IPLed) Linux into OS/390
partitions with 10s of thousands of I/O devices defined/attached. In order
for not having to allocate so much static memory I first limited the number
of addressable devices to 1024, following the VSE/ESA model, and only when
clients wanted more (many did start with Linux in LPAR and only partitions
configured for OS/390 at hand) I back-ported dynamic boot memory allocation
back from the 2.3 kernel to 2.2, still avoiding large memory allocations
when all a client wanted to operate where just a handful of devices ...

Mit freundlichem Gruß / Best regards
Ingo Adlung


   
   Ingo AdlungIBM Deutschland Research &   
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, and CTO   Vorsitzender des Aufsichtsrats:  
   IBM Z and LinuxONE Virtualization  Matthias Hartmann
   & LinuxGeschäftsführung: Dirk Wittkopp  
   mail: adl...@de.ibm.comSitz der Gesellschaft: Böblingen 
   phone: +49-7031-16-4263Registergericht: Amtsgericht 
  Stuttgart, HRB 243294
   








From:   Mike Riggs 
To: LINUX-390@VM.MARIST.EDU
Date:   19/12/2019 13:34
Subject:[EXTERNAL] Re: [LINUX-390] Happy birthday
Sent by:Linux on 390 Port 



And thus started the new future of judicial technology here. Not too long
after, a distro was running (well, sorta walking) on a 9672. Been a blast
ever since.

Mike Riggs
OES/SCV

-Original Message-
From: Linux on 390 Port  On Behalf Of Rich Smrcina
Sent: Wednesday, December 18, 2019 9:34 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Happy birthday

I’m sure there were more than a few of us installing the ‘Marist’
distribution on our mainframes over Christmas.

I know I was working on the install at Grede Foundries.

Rich Smrcina
Sr. Systems Engineer

Velocity Software Inc.
Main: (650) 964-8867
Main: (877) 964-8867
r...@velocitysoftware.com <mailto:r...@velocitysoftware.com>


> On Dec 18, 2019, at 8:25 PM, Neale Ferguson  wrote:
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__tech-2Dinsider.org_linux_research_1999_1218.html=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-y49pWL0=6Vdtn9czQLmEFCLh41YmBe-CZzwY375fuXlEuAgDrNo=QoPSQ9tkxyy7_dafKnVSmtqWoHB6nZaezrAdL2ji_MY=

>
> "Dec 18, 1999
>
> According to Alan Cox's 2.2.14pre14 patch, Linux now has at least
preliminary support for running on the IBM S/390 Mainframe. Rumors that IBM
has been engaged in a port have been circulating for some time, but this is
the first concrete code that has surfaced to date..."
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions, send
> email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-y49pWL0=6Vdtn9czQLmEFCLh41YmBe-CZzwY375fuXlEuAgDrNo=SB0o_Utp2GmkAmFiGILQpRbYiW1Vmnz9Jh2eAtxvc80=



--
For LINUX-390 subscribe / signoff / archive access instructions, send email
to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-y49pWL0=6Vdtn9czQLmEFCLh41YmBe-CZzwY375fuXlEuAgDrNo=SB0o_Utp2GmkAmFiGILQpRbYiW1Vmnz9Jh2eAtxvc80=


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-y49pWL0=6Vdtn9czQLmEFCLh41YmBe-CZzwY375fuXlEuAgDrNo=SB0o_Utp2GmkAmFiGILQpRbYiW1Vmnz9Jh2eAtxvc80=





--
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: S3 compatible private cloud server for Linux on Z

[Ingo Adlung]

Linux on 390 Port  wrote on 11/12/2018 10:40:20:

> From: Timothy Sipples 
> To: LINUX-390@VM.MARIST.EDU
> Date: 11/12/2018 10:40
> Subject: Re: [LINUX-390] S3 compatible private cloud server for Linux on
Z
> Sent by: Linux on 390 Port 
>
> What do you mean by "S3 compatible," Jim? Are you looking for Amazon
Simple
> Storage Service (S3) API compatibility in a cloud storage server?
>
> Assuming that's what you're looking for, and among commercial offerings,
> IBM Spectrum Scale should work for you:
>
> https://www.ibm.com/support/knowledgecenter/en/STXKQY_5.0.2/
> com.ibm.spectrum.scale.v5r02.doc/bl1ins_S3APIemulation.htm
>
> IBM Spectrum Scale uses an IBM supplied and supported distribution of
> OpenStack Swift's S3 API to provide these features. You can of course
> obtain the OpenStack Swift codebase separately if you wish.

Good point, there is a Swift3 project layering on top of Swift to provide
an S3 compatible API

>
>


> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
>


>
> E-Mail: sipp...@sg.ibm.com
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> INVALID URI REMOVED
>
u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIFAg=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=3v5chFeMYu7Ub0NTS60Umr6-
> wvkKPAaFM733Oocr1dw=pWu1YjrvF8TdBqMHBh3CXaSa30i-PEOWg0l3_hT9lWk=
> --
> For more information on Linux on System z, visit
> INVALID URI REMOVED
> u=http-3A__wiki.linuxvm.org_=DwIFAg=jf_iaSHvJObTbx-
> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
> y49pWL0=3v5chFeMYu7Ub0NTS60Umr6-wvkKPAaFM733Oocr1dw=cC1hSoq-
> qQNMuNRKx8GiNC-n3MST5jrWvqbze7D5Fjc=
>


Mit freundlichem Gruß / Best regards
Ingo Adlung


   
   Ingo AdlungIBM Deutschland Research &   
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, and CTO   Vorsitzender des Aufsichtsrats:  
   IBM Z and LinuxONE Virtualization  Martina Koederitz
   & LinuxGeschäftsführung: Dirk Wittkopp  
   mail: adl...@de.ibm.comSitz der Gesellschaft: Böblingen 
   phone: +49-7031-16-4263Registergericht: 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://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: z/Linux 32-bit modules

[Ingo Adlung]

Different to the spirit of this mail thread I would like encouraging
you to invest in 64-bit versions of your software. Not only may the
distributors at some point choose to deprecate 31 (32) bit compat mode,
but all performance optimizations for the gcc compiler back-end for
new Z hardware are done for 64-bit only. 31-bit may or may not benefit
occasionally, too, but it is not a focus at all. I.e. while some workload
may possibly benefit from 31-bit because of its cache footprint,
generally speaking you should expect 64-bit to generate code that is
better optimized for recent Z hardware - or will be as we move on.

Linux on 390 Port <LINUX-390@VM.MARIST.EDU> wrote on 28.05.2018 08:15:57:

> From: Paul Edwards <mutazi...@gmail.com>
> To: LINUX-390@VM.MARIST.EDU
> Date: 28.05.2018 13:53
> Subject: Re: [LINUX-390] z/Linux 32-bit modules
> Sent by: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>
>
> > And that, Paul, is why it’s not going to fly.
> > All of the 31 bit code would have to be reimplemented.
>
> > A bunch of other people do all that work and
> > take on all the risk to what end?
>
> Hi Alan.
>
> What code needs to be reimplemented? I think
> it is very unlikely any C code needs to be changed.
> A C programmer would need to go to a lot of
> effort to make their code 31-bit specific. It is
> more likely that it is already AM-anything.
>
> The existing 31-bit code merely needs to be run
> as AM64 and it will likely work fine.
>
> > What is the commercial value?  What do they
> > get for their efforts?
>
> A decent platform that runs 32 bit binaries with
> a 4 GiB address space, and 64 bit binaries with
> a 16 EiB address space, just like all competing
> platforms provide.
>
> BFN. Paul.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> INVALID URI REMOVED
>
u=http-3A__www.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwIFaQ=jf_iaSHvJObTbx-

> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
>
y49pWL0=JOdhBeHl39zHyMABaQdYX11GAkR60MQJSEE8fd4nBOU=2IOevbNHjaXFHds5Vg5kA-

> niS8RwOqf6ykDiCI__ZAo=
> --
> For more information on Linux on System z, visit
> INVALID URI REMOVED
> u=http-3A__wiki.linuxvm.org_=DwIFaQ=jf_iaSHvJObTbx-
> siA1ZOg=jQ4IiHbzZ0l-wFKuUHMHvPIsi5vD8MZZCyI-
>
y49pWL0=JOdhBeHl39zHyMABaQdYX11GAkR60MQJSEE8fd4nBOU=Rl2aVlL8NmGJszDPQbRy-

> knNYOuU5w0FlKkYFr6_JC8=
>

Mit freundlichem Gruß / Best regards
Ingo Adlung


   
   Ingo AdlungIBM Deutschland Research &   
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, and CTO   Vorsitzender des Aufsichtsrats:  
   IBM Z and LinuxONE Virtualization  Martina Koederitz
   & LinuxGeschäftsführung: Dirk Wittkopp  
   mail: adl...@de.ibm.comSitz der Gesellschaft: Böblingen 
   phone: +49-7031-16-4263Registergericht: 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://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: RHEL 6 CPU Scalability

[Ingo Adlung]

It really depends on the workload whether scale-up or scale-out is better
suited. With z/VM 6.3 you should be well prepared for both options (as you
are with running Linux in LPAR) but it is really a workload question. E.g.
many applications would allow for scale-out clustering at linear scale,
while e.g. databases would require for data sharding in a scale-out model
if scale-up is not an option. In any case don't define more vCPUs to a
single virtual machine than you have logical CPUs defined to your LPAR as
also Scott pointed out.

Now this said, if your capacity needs keep growing and the concurrent,
aggregated CPU capacity needs exceed 64 cores (or 32 cores running SMT2
giving you 64 HW threads) you may need spilling over into an additional
z/VM instance anyhow ...

Mit freundlichem Gruß / Best regards
Ingo Adlung


   
   Ingo AdlungIBM Deutschland Research &   
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, and CTO   Vorsitzender des Aufsichtsrats:  
   z Systems and LinuxONE Martina Koederitz
   Virtualization & Linux Geschäftsführung: Dirk Wittkopp  
   mail: adl...@de.ibm.comSitz der Gesellschaft: Böblingen 
   phone: +49-7031-16-4263Registergericht: Amtsgericht 
  Stuttgart, HRB 243294
   






Linux on 390 Port <LINUX-390@VM.MARIST.EDU> wrote on 03.04.2017 15:46:38:

> From: "Wheeler, Mark L" <mark_whee...@optum.com>
> To: LINUX-390@VM.MARIST.EDU
> Date: 03.04.2017 15:47
> Subject: [LINUX-390] RHEL 6 CPU Scalability
> Sent by: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>
>
> Greetings!
>
> We have eight RHEL 6 servers with 8 vCPUs each handling a large
> workload, which continues to grow. We could expand the server farm
> horizontally by adding more servers, or vertically by adding more
> vCPUs. I'm concerned about SMP effects of adding more vCPUs but
> don't have any data to validate that concern one way or another.
>
> Can anyone provide a recommendation? More servers or more vCPUs?
>
> Very best regards,
>
> Mark Wheeler
> z/VM and zLinux
> Optum Technology
> 952-912-9524
> Mark_Wheeler at optum.com
>
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the
intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: hyptop question

[Ingo Adlung]

Hi Alan,

> This isn't how DIAGNOSE instructions work.  Instead of worrying about
> converting user privclass to IBMCLASS and associating with the running
> DIAGNOSE, it's done in the more primitive hindbrain of CP.
> Architecturally, a DIAGNOSE is associated a SINGLE privilege class (or
> privclass ANY).  They aren't supposed to change behavior based on
> privilege class (directory OPTION, maybe, but not privclass).
>
> DIAGNOSE 2FC is violating that architecture.  I would suggest a PMR so
> that you can discuss with Development whether that violation is Right and

> Proper.

I guess the challenge with DIAG 2FC is that not every issuer is necessarily
supposed to see guest information beyond themselves. So while I agree with
your assessment I see reasoning in the approach taken ...

Best regards
Ingo

Linux on 390 Port  wrote on 20.05.2016 17:19:01:

> From: Alan Altmark 
> To: LINUX-390@VM.MARIST.EDU
> Date: 20.05.2016 17:19
> Subject: Re: [LINUX-390] hyptop question
> Sent by: Linux on 390 Port 
>
> On Friday, 05/20/2016 at 06:41 GMT, Karl Kingston

> wrote:
> > > For z/VM, the guest virtual machine must have privilege class B
> > > or, preferably, a locally-defined privilege class that contains
> > > diagnose 2fc.
> >
> > How does one do this?Don't like giving my linux guests access to
> CLASS
> > B so I would like to make my own class and give that to the user.
>
> Well, isn't this embarrassing... (blush) (look down) (kick rock)   You
> can't.  I keep forgetting that DIAGNOSE instructions are architecturally
> different than commands.
>
> (For a fascinating description of how CP commands and DIAGNOSE
> instructions are processed, keep reading!)
>
> The system supports privclass-qualified versions of a command.  When you
> enter a command, the highest level (A->9) for which you have the assigned

> privilege class will run.  That is, if a command has a class B version
and
> a class G version, then if you have class ABG, the command will be
> qualified as class B.  If you had class AG, then the command will be
> qualified as class G.  That's the last time CP looks at the issuer's
> privclass.  The system instead looks at the command qualifier.  We refer
> to the command qualifier as the "IBMCLASS".  That is, the IBM-defined
> privilege class associated with the version of the command that's
running.
>  The MODIFY COMMAND command lets you change the association between the
> user privclass and the IBMCLASS.
>
> This all gets resolved before the command actually runs, eliminating any
> need for CP to worry about user privclass.  He just cares about the
> IBMCLASS of the command that's running.  This allows a single entry point

> to handle the command.
>
> This isn't how DIAGNOSE instructions work.  Instead of worrying about
> converting user privclass to IBMCLASS and associating with the running
> DIAGNOSE, it's done in the more primitive hindbrain of CP.
> Architecturally, a DIAGNOSE is associated a SINGLE privilege class (or
> privclass ANY).  They aren't supposed to change behavior based on
> privilege class (directory OPTION, maybe, but not privclass).
>
> DIAGNOSE 2FC is violating that architecture.  I would suggest a PMR so
> that you can discuss with Development whether that violation is Right and

> Proper.
>
> Alan Altmark
>
> Senior Managing z/VM and Linux Consultant
> Lab Services System z Delivery Practice
> IBM Systems & Technology Group
> 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://www.marist.edu/htbin/wlvindex?LINUX-390
> --
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: cio_ignore vs Linux in System z

[Ingo Adlung]

Indeed, as pointed out by other folks this feature was introduced in our
very early days, when clients started to install Linux into LPARs with
possibly tens of thousands of devices they would need if IPLing z/OS into
it. Not only did it take long to boot, but we initially only operated on
the first 1024 devices found, and didn't have plugging rules yet. And other
z/OS holding permanent RESERVEs on shared ECKD devices it owned didn't help
much either. We'd discussed whether to introduce black lists or white lists
addressing the challenges at hand and eventually implemented both.

Much has changed since then and whether it should be a default or not is a
valid discussion to have. You may consider it paranoia but its introduction
served a purpose - and still does. If running under z/VM and/or if using
Linux in LPAR with your IODF written in a way that only devices the LPAR is
supposed to operate on are configured to it you can presumably safely turn
it off.

Best regards
Ingo


   
   Ingo AdlungIBM Deutschland Research
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, System z  Vorsitzender des Aufsichtsrats:  
   Virtualization  Linux Martina Koederitz
   mail: adl...@de.ibm.comGeschäftsführung: Dirk Wittkopp
   phone: +49-7031-16-4263Sitz der Gesellschaft: Böblingen
  Registergericht: Amtsgericht 
  Stuttgart, HRB 243294
   






Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 12.01.2015 20:43:00:

 From: Mike Walter mike.wal...@aon.com
 To: LINUX-390@VM.MARIST.EDU
 Date: 12.01.2015 20:43
 Subject: Re: [LINUX-390] cio_ignore vs Linux in System z
 Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU

 Thanks, Sam, Jay, Jim, Harley, and Mark (and anyone else who may
 have replied since I looked at the log),

 There are no LPAR-only Linux servers running here, only those
 running (RHEL) under z/VM.  I suspected that cio_ignore was
 something related to security (perhaps an auditor fearing that an
 errant z/VM sysprog might attach a wrong device address to a guest,
 or poor security rules coupled with use of VMCP would let the wrong
 Linux user access the wrong devices), or performance.  It appears
 that the performance issue was the culprit, but not one of concern
 for me with only z/VM guests.

 I've shared the suggestions with our zLinux admins, who will
 probably make dynamic updates for the few PoC guests currently
 running, and the next Golden Image(s).

 Have to love this list, thanks again!

 Mike Walter
 Aon Corporation
 The opinions expressed herein are mine alone, not necessarily those
 of my employer.






 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: dasdfmt - why are you so darn slow?

[Ingo Adlung]

  PS No, dasdfmt does not do a verify. There is a bit of reading
 afterwards, but that's it. ICKDSF however does do a verify.

Interesting, isn't end-to-end data checking provided by FICON I/O about
there not being a need for data verification? At the time you wrote the
data and got a successful completion status you know it ended up fine on
the device? i.e. verification only satisfying paranoia?

Mit freundlichem Gruß / Best regards
Ingo Adlung


   
   Ingo AdlungIBM Deutschland Research
   IBM Distinguished Engineer Development GmbH 
   Chief Architect, System z  Vorsitzender des Aufsichtsrats:  
   Virtualization  Linux Martina Koederitz
   mail: adl...@de.ibm.comGeschäftsführung: Dirk Wittkopp
   phone: +49-7031-16-4263; fax:  Sitz der Gesellschaft: Böblingen
   +49-7031-16-3456   Registergericht: Amtsgericht 
  Stuttgart, HRB 243294
   






Linux on 390 Port LINUX-390@vm.marist.edu wrote on 08.11.2012 12:43:10:

 From: Rob van der Heij rvdh...@gmail.com
 To: LINUX-390@vm.marist.edu,
 Date: 08.11.2012 12:47
 Subject: Re: [LINUX-390] dasdfmt - why are you so darn slow?
 Sent by: Linux on 390 Port LINUX-390@vm.marist.edu

 On 8 November 2012 00:58, Marcy Cortes marcy.d.cor...@wellsfargo.com
wrote:
  The list is a little quiet so I thought I would ask this.
 
  It takes about 42 minutes here to dasdfmt a volume with 65519
 cylinders on it.
  It takes about 18 minutes to dd an already formatted volume over
 to a new one.
  It also takes about 19 minutes to fill it up with zeros by cat /
 dev/zero  to it.
 
  Why does dasdfmt take so long?
 

 The full answer involves data and experiments and could at least
 excite the presenter for an hour ;-)  (you can blame Marcy if you get
 trapped in there)

 On a real round brown disk, doing a format write is a delicate
 process that requires dedication and a steady hand. It's done one
 track at a time. This takes a full round trip per track, so roughly 1
 million of those in your case. Given that, 20 would be explained.

 If there's more FICON things in between, there may be more hops to
 take and your I/O response might be worse. The amount of data does not
 look like it would saturate your NVS, but who knows what else is going
 on. If you upload an hour of data while this was running, I'd be most
 happy to investigate what is going on and whether there is room for
 improvement.

 Depending on where the bottleneck is, you could imagine to do PAV and
 a multi-threaded dasdfmt. We used to be able to tell dasdfmt to do
 just a range of cylinders (so you could run more in parallel) but that
 option was taken out because people forgot to format the entire disk

 When simply writing data (rather than format write) you can chain many
 tracks in a single I/O and need far less round trips and are down to
 the transfer rates. With high channel bandwidth that may indeed be
 faster. Most fun is to flashcopy a previously formatted pack.

 PS No, dasdfmt does not do a verify. There is a bit of reading
 afterwards, but that's it. ICKDSF however does do a verify.

 Rob

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: z/Linux and z/OS

[Ingo Adlung]

I wouldn't go that far to state that IBM recommends a production
environment to be z/VM based.

Whether z/VM or PR/SM is more appropriate depends whether the runtime
characteristics of the application workload benefits more from the reduced
overhead PR/SM LPARs imply or from z/VM's capabilities to virtualize and
overcommit all possible resources a virtual server depends on (CPU, memory,
storage, network, crypto, console). I.e. it depends whether steady state
resource demand fits well with the PR/SM model of resource sharing for I/O
with I/O passthru support, dedicating memory, and CPU virtualization, or
varies heavily such that it benefits from z/VM's capabilities to much more
dynamically balance how and when virtual resource demand is backed by
physical resources for all possible resources.

This said if you look for the right hosting environment for your
production, mother database for enterprise wide operations that shows
high, steady state resource requirements most probably a PR/SM LPAR is the
most efficient way hosting it. If your use case is the consolidation of a
larger set of virtual servers that show varying resource demand from high
to idling z/VM is the more appropriate choice. And of course it is possible
leveraging both for distinct Linux workloads on the same system - or go for
one model only. And yes, creating and decomissioning virtual servers at
high frequency is much more handy with z/VM than with PR/SM LPARs. Anyhow,
luckily customers can choose the hosting environment more appropriate for
their very workload use patterns :-)

Mit freundlichem Gruß / Best regards
Ingo Adlung

Linux on 390 Port LINUX-390@vm.marist.edu wrote on 26.07.2012 17:17:19:

 From: גדי בן אבי gad...@malam.com
 To: LINUX-390@vm.marist.edu,
 Date: 26.07.2012 17:38
 Subject: Re: [LINUX-390] z/Linux and z/OS
 Sent by: Linux on 390 Port LINUX-390@vm.marist.edu

 The short answer is yes,
 zLinux can run Natively on a standard processor.

 IBM recommends that in a production environment z/VM is used. The
 main reason is that is is much easier to create a new guest under VM
 than creating a new LPAR.

 Gadi

 -Original Message-
 From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf
 Of Spring, David
 Sent: Thursday, July 26, 2012 3:28 PM
 To: LINUX-390@VM.MARIST.EDU
 Subject: z/Linux and z/OS

 Good morning all,

 Hope this is the right place to ask this question. Please pardon the
 intrusion if I should be posting this someplace else.

 Our management is considering the acquisition of a new z114
 sandbox system primarily for testing new hardware (DASD and tape).
 They would also like to conduct a z/Linux POC using the same
 machine. I know that z/Linux can run in native mode on a System z
 processor but I wasn't sure about it running side by side with z/OS.
 Can this be done using PR/SM and building separate LPARs on the z114
 for running z/Linux and z/OS together on the same machine? I know
 that the most sensible solution would probably be to get a z/VM
 hypervisor and run z/OS and z/Linux as guest operating systems under
 it. However, there's a lot of resistance here to running yet another
 operating system such as z/VM.

 Any comments, advice, etc.?

 David Spring
 Social Security Administration
 DCS/OTSO/DMSS/MOSB
 MVS Operating System Team
 Desk:  (410) 965-9309
 BB: (443) 379-7839
 Email: david.spr...@ssa.gov

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit http://wiki.linuxvm.org/

 לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או
 מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של
 החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר
 מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין
 לראות באמור בהודעה אלא משום טיוטה לדיון,
 ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


 Please note that in accordance with Malam's signatory rights, no
 offer, agreement, concession or representation is binding on the company,
 unless accompanied by a duly signed separate document (or a scanned
 version thereof), affixed with the company's seal.

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/

Re: Informix on zLinux ?

[Ingo Adlung]

You might also want to consider having a look at

http://www.ibm.com/developerworks/linux/linux390/perf/tuning_pap_database.html

http://www.ibm.com/developerworks/linux/linux390/perf/tuning_rec_database_Informix.html

http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/perf/linux_z_database_performance_2008_02_26.pdf

for more information about running Informix on Linux on z.

Best regards
Ingo Adlung




Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 19.09.2008 16:38:54:

 anyone doing this yet ?
 We appear to be about to jump into this world and any advise is welcome.

 We have 2 IFLs, VM 5.3 and SLES 10.1 ( or maybe 10.2 by now ) but are
truly
 raw rookies in this environment.
 We are going to look at the Velocity toolset and take whatever tools IBM
 has provided us - what else need to go into the toolkit ?

 Bruce Lightsey
 Mississippi Dept. of Information Technology Services
 301 N. Lamar St., Suite 508
 Jackson, Ms 39201-1495
 (601) 359-2644  voice   (601) 359-1394   fax
 www.its.ms.gov   www.ms.gov
 mailto:[EMAIL PROTECTED]

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390



   
 Ingo Adlung IBM Deutschland Research 
 Senior Technical Staff Member   Development GmbH  
 SCEM, Virtualization  Linux on IBM Vorsitzender des Aufsichtsrats:   
 System zMartin Jetter 
 mail: [EMAIL PROTECTED] Geschäftsführung: Erich Baier 
 phone: +49-7031-16-4263; fax:   Sitz der Gesellschaft: Böblingen
 +49-7031-16-3456Registergericht: Amtsgericht  
 Stuttgart, HRB 243294 
   





--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: z/Linux or zLinux - which is preferred?

[Ingo Adlung]

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 21.07.2007 17:24:49:

 Neither. The official instructions I've gotten from IBM marketing and
 legal review when writing white papers is Linux for System z (note
 lower case).


Actually we use Linux for System z to qualify the *distributions* that
specifically support z achitecture - remember there was Linux for S/390
initially :-) and use Linux on System z when talking about Linux on IBM
mainframes just generally ... nit-picking.

  I prefer Linux/390 or just mainframe Linux.  Linux
  for System z (IBM's real preference) doesn't do much for me either.

 I tend to use mainframe Linux when not working ex cathedra. Then I
 don't have to care what generation of system it's running on, and don't
 accidentally foul anyone's trademarks.

 -- db

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390


Mit freundlichem Gruß / Best regards
Ingo Adlung
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: GDPS/XRC for z/VM and Linux volumes

[Ingo Adlung]

Bob  David,

I understand and share your frustration in regard to this particular
issue. However, let me please assure this is not about stepchild'ing
the z/VM environment and/or not understanding the necessity for z/VM
being a critical part of an end-to-end managed structure. Instead it
is about doing immediately what can be done immediately and complete
the solution as complexity and resources allow eventually - and of
course we try basing priority decisions based on customer demand and
our insight into it. Sometimes z/VM leads in that respect and sometimes
Linux. Unfortunately with respect to z/VM supporting XRC for its own
I/O operations this gap is now lasting for quite some time already,
and therewith only partially allowing customers to take advantage of
GDPS/XRC as their Linux/VM environment is concerned.

We appreciate the kind reminder :-)

Best regards
Ingo

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 29.06.2007 19:47:19:

 David,

 After reading your reply, feel free to pass yourself off as me anytime!
 :-)

 Extremely well stated! And it is exactly where I was going with this
 thread.

 Bob Richards


 -Original Message-
 From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
 David Boyes
 Sent: Friday, June 29, 2007 10:55 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: GDPS/XRC for z/VM and Linux volumes

  could you please explain your pain points with GDPS/XRC in your
 Linux/VM
  setup? While z/VM itself doesn't seem to timestamp its I/O Linux does
 and
  z/VM would carry all Linux timestamps out to the storage control unit
 as
  it re-issues the Linux I/O requests. Do you have problems with these
  limitations? Other?

 While I'm not Bob, an observation:

 The problem here is a common one when having conversations with IBM
 about virtualization on Z at any real scale. The solution that is
 offered supports only part of the problem. You've addressed the Linux
 and z/OS layers, but the z/VM layer -- which is just as important, as it
 controls the resource allocation to the Linux layer and is directly
 critical to the cost and ROI cases for having Linux on Z in the first
 place, is completely left out of the management picture of the solution.


 If you're trying for a completely managed solution (which is what GDPS
 is supposed to provide), then omitting a major portion of the solution
 from the management integration pretty much torpedoes the argument for
 creating the solution in the first place. If I have to create exceptions
 to the IBM management infrastructure to *deal with a strategic product
 made by IBM*, then there is a fundamental design problem here. Having VM
 be unmanaged in that environment blows the whole premise of completely
 controllable failover.

 The same argument applies to EWLM, IRD, and many other things -- GDPS
 and the tools required to implement really highly-available managed
 solutions need to be actively cognizant of the presence of VM in
 scenarios like GDPS, and not treat it as a poor stepchild who can be
 ignored as a helpless invalid. Treat it as a client, but treat it you
 must, because it's a critical piece of the plumbing. LPAR isn't an
 acceptable alternative.



 LEGAL DISCLAIMER
 The information transmitted is intended solely for the individual or
 entity to which it is addressed and may contain confidential and/or
 privileged material. Any review, retransmission, dissemination or
 other use of or taking action in reliance upon this information by
 persons or entities other than the intended recipient is prohibited.
 If you have received this email in error please contact the sender
 and delete the material from any computer.

 SunTrust and Seeing beyond money are federally registered service
 marks of SunTrust Banks, Inc.
 [ST:XCL]





 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: GDPS/XRC for z/VM and Linux volumes

[Ingo Adlung]

Of course this is Alan's very own perspective that I don't share.
We should support GDPS/XRC also with z/VM. No doubt about that to me.

But to be fair, it is not only about z/VM time-stamping its I/O but
also participating in an ETR/STP-based time synchronization with
z/OS such that it facilitates the definition of data consistency
groups also beyond a single z/VM image. This is likely the much more
complex part to achieve and hence it didn't make the doability for
quite some time. Also Linux has only recently started to deliver on
this - for LPAR - and has not yet made it into the distros - sigh.
So also for Linux volumes that are GDPS/XRC managed through z/OS you
must currently not define data consistency groups passing LPAR
boundaries - z/VM or not. If you have an immediate need for it (or
already use it unaware of said limitations) please let me know!

Best regards
Ingo
-
Ingo Adlung
Senior Technical Staff Member
SCEM, Chief Technical Strategist for Linux on IBM System z
mail: [EMAIL PROTECTED]
phone: +49-7031-16-4263; fax: +49-7031-16-3456

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 29.06.2007 22:35:30:

 On Friday, 06/29/2007 at 09:36 AST, Richards.Bob
 [EMAIL PROTECTED] wrote:

  Out of curiosity, Alan, why aren't z/VM writes timestamped?

 Host-generated timestamps are part of the older XRC architecture (z/OS
 Global Mirror) that z/VM can't really use.  When multiple LPARs or CECs
 are involved, you need a single time source (Sysplex Timer or STP) to
 ensure that I/Os will be reordered properly at the other end.  z/VM
 doesn't do time synchronization.

 Also, XRC is not available to Open systems, and CP has to be able to
 operate in a SCSI environment (z/OS does not).  We didn't want to invest
 in two technologies.

 XRC rebranding to z/OS Global Mirror helps us drive home the point that
 it is intended for use only by z/OS.

 Alan Altmark
 z/VM Development
 IBM Endicott

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: GDPS/XRC for z/VM and Linux volumes

[Ingo Adlung]

Bob,
could you please explain your pain points with GDPS/XRC in your Linux/VM
setup? While z/VM itself doesn't seem to timestamp its I/O Linux does and
z/VM would carry all Linux timestamps out to the storage control unit as it
re-issues the Linux I/O requests. Do you have problems with these
limitations? Other?

Best regards
Ingo

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 28.06.2007 21:03:45:

 Dave,

 So what is the reasonable recommended methodology for handling those
 volumes? Stop everything and do point-in-time? Say it ain't so! :-(

 Bob Richards


 -Original Message-
 From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
 Dave Jones
 Sent: Thursday, June 28, 2007 2:51 PM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: GDPS/XRC for z/VM and Linux volumes

 Hi, Bob...

 Sorry, no you wont:-( GDPS/XRC don't play nice in the z/VM and Linux
 world, at least in my experience at a couple of client sites

 Richards.Bob wrote:
  Is anyone here running GDPS/XRC and how are you handling z/VM and
 Linux
  volumes? I didn't exactly like what I was reading in the Advanced Copy
  Services manual. Hopefully, I'll feel better here. grin



 LEGAL DISCLAIMER
 The information transmitted is intended solely for the individual or
 entity to which it is addressed and may contain confidential and/or
 privileged material. Any review, retransmission, dissemination or
 other use of or taking action in reliance upon this information by
 persons or entities other than the intended recipient is prohibited.
 If you have received this email in error please contact the sender
 and delete the material from any computer.

 SunTrust and Seeing beyond money are federally registered service
 marks of SunTrust Banks, Inc.
 [ST:XCL]





 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: GDPS/XRC for z/VM and Linux volumes

[Ingo Adlung]

Bob,
AFAIK GDPS/XRC is a supported configuration except that only the Linux I/O
is timestamped and hence XRC eligible while I/O on VM's own behalf is not
(unless it changed recently). I.e. if this is acceptable for your setup you
should be able adding Linux volumes to your XRC configuration. Not sure
about the GDPS side of the configuration, hence adding Dave Petersen on
copy. He should be able telling us whether he can manage Linux operated
minidisks or whether he requires dedicated disks when running Linux under
z/VM in a GDPS/XRC setup.

Best regards
Ingo

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 28.06.2007 22:04:41:

 Alan,

 Unfortunately, my backup site is about 500 miles away. PPRC is not an
 option here. Does TSA for Linux also require PPRC? Are there any plans
 to support GDPS/XRC customers?

 Bob Richards


 -Original Message-
 From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
 Alan Altmark
 Sent: Thursday, June 28, 2007 3:59 PM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: GDPS/XRC for z/VM and Linux volumes

 On Thursday, 06/28/2007 at 03:03 AST, Richards.Bob
 [EMAIL PROTECTED] wrote:

  So what is the reasonable recommended methodology for handling those
  volumes? Stop everything and do point-in-time? Say it ain't so! :-(

 Tivoli System Automation for Linux (TSA) will work with GDPS on z/OS to
 handle LPAR failover and volume failover  TSA will monitor VM volumes
 (user and CP-owned) and work with GDPS and CP HYPERSWAP to recover the
 failing volume.

 GDPS uses PPRC (Metro or Global Mirror) rather than XRC (aka z/OS
 Global
 Mirror).

 Alan Altmark
 z/VM Development
 IBM Endicott

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390



 LEGAL DISCLAIMER
 The information transmitted is intended solely for the individual or
 entity to which it is addressed and may contain confidential and/or
 privileged material. Any review, retransmission, dissemination or
 other use of or taking action in reliance upon this information by
 persons or entities other than the intended recipient is prohibited.
 If you have received this email in error please contact the sender
 and delete the material from any computer.

 SunTrust and Seeing beyond money are federally registered service
 marks of SunTrust Banks, Inc.
 [ST:XCL]





 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Linux on z and VTS == compatible at all?

[Ingo Adlung]

The tape support should be in place to my knowledge. What's missing is
the tape management piece.

Of course we could consider writing a driver that applies tape library
functions for VTS but without any tape management software on top it
would only be a piece of technology. I.e. if there is any outlook for
an exploiter we can consider putting in onto the requirements list.
But then the tape library API may not be published causing implementation
delays and possibly you could instead attach to the VTS through FCP, too
and use TSM support off the box. That way you wouldn't have to hold your
breath while we figure out how to deliver on your requirement validating
with more customers such that we understand its general market importance
and push it into plans eventually - still awaiting tape management
exploitation ... Thoughts?

Best regards
Ingo

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 01.05.2007 20:41:03:

 True.  Except that there also needs to be drivers for the tape and the
 VTS.  And tape management.  I'm guessing that even if all of the
 different IBMs got their act together, it would be awhile before we
 would see something usable.

  -Original Message-
  From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On
  Behalf Of Dave Jones
  Sent: Tuesday, May 01, 2007 1:37 PM
  To: LINUX-390@VM.MARIST.EDU
  Subject: Re: Linux on z and VTS == compatible at all?
 
  Chris, I think the real roadblock to getting this done lies
  with Tivoli, and not with IBM itself.
 
  DJ
 
  Little, Chris wrote:
   U.
  
   IBM?  Are you there?  Can you hear me?  Would like to drive
  a TS7700
   from Linux.  Pretty please?
  
   -Original Message-
   From: Linux on 390 Port [mailto:[EMAIL PROTECTED]
  On Behalf Of
   Dave Jones
   Sent: Tuesday, May 01, 2007 9:25 AM
   To: LINUX-390@VM.MARIST.EDU
   Subject: Re: Linux on z and VTS == compatible at all?
  
   Then, as DB has noted, you're basically SOL.sorry.
  
   DJ
  
 
  --
  For LINUX-390 subscribe / signoff / archive access
  instructions, send email to [EMAIL PROTECTED] with the
  message: INFO LINUX-390 or visit
  http://www.marist.edu/htbin/wlvindex?LINUX-390
 

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Pros/Cons of FCP connection DASD

[Ingo Adlung]

That's somewhat outdated information at least for SLES 9  10.
We have Linux I/O statistics for FCP/SCSI and shortly we'll have
FCP adapter I/O statistics, too.

It is true that ECKD attached disks provide QoS features like
end-to-end data protection and is the dominant I/O attachment
for Linux. It is also true that customers would usually observe
higher throughput with FCP attached storage.

More performance related data to disk I/O is available at

http://www-128.ibm.com/developerworks/linux/linux390/perf/index.html

and more specific information for related to the DS8000 at

http://www-128.ibm.com/developerworks/linux/linux390/perf/tuning_res_dasd_ds8000.html


Best regards
Ingo


Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 26.03.2007 22:38:21:

 When performance is bad, do you want to know why? Until we know how
 to show when the SAN
 is impacting your application and how - do you want to trust your
 production to something
 where performance is not manageable?
 For example, an ibm controller was benchmarked first as eckd, then
 as scsi. on eckd, we
 get cache stats - could show the dasd fast write filled up, and
 could show response time.
   for scsi, all we could show was thruput was degraded.  we can't
 even measure silly
 response time numbers on scsi.


 Lionel B. Dyck wrote:

  I've heard several good reasons to have my zlinux images use dasd that
is
  on the fibre connected san and a few for using the old tried and true
  dasd. What I'd like to find out is what is true and what isn't -
basically
  what is considered the best practice for zlinux dasd.
 
  Thus - what do y'all think?
 
  Thanks in advance.
 
  Lionel B. Dyck, Consultant/Specialist zLinux Platform
  Client and Platform Engineering Services (CAPES)
  KP-IT Enterprise Engineering, Manager Toni Nicotera
  925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED]
  AIM: lbdyck | Yahoo IM: lbdyck
  Kaiser Service Credo: Our cause is health. Our passion is service.
We’re
  here to make lives better.”
 
  “Never attribute to malice what can be caused by miscommunication.”
 
  NOTICE TO RECIPIENT: If you are not the intended recipient of this
e-mail,
  you are prohibited from sharing, copying, or otherwise using or
disclosing
  its contents. If you have received this e-mail in error, please notify
the
  sender immediately by reply e-mail and permanently delete this e-mail
and
  any attachments without reading, forwarding or saving them. Thank you.


 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 [attachment barton.vcf deleted by Ingo Adlung/Germany/IBM]

Re: DB2 UDB consolidation on zSeries Linux

[Ingo Adlung]

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 09.01.2007 08:10:52:


 Hi.
 I'm just curius, what's the purpose of having 2 virtuell cpu's defined
when
 only 1 physical is around.
 br
 Thomas Broman


I would be surprised if it would not run, however, from a performance
pespective you would not want to overcommit the physically available CPUs
for a single guest. I would not recommend to configure guests with a larger
SMP than the underpinnng physical infrastructure provides backing for, i.e.
if there is only one CPU available to VM the guests should also be uni-
processor guests only. If you want/need to exploit SMP in guests based on
workload requirements VM should also have at least as many processors
available to itself and hence be able to dispatch to its guests as
required.


 We run DB2 on 8 Linux virtual servers w/ z/VM. We have
 2 cpus configured, even though there is only 1
 physical cpu, and it works well. DB2 does gripe about
 the second cpu but runs never the less.
 To answer your question, We pay for only 1 cpu and all
 is well.


Hmm, perhaps we were misled by your statement ... does DB2 provide some CPU
configuration option? May be useful if you have a larger SMP than you want
DB2
to use, but why would you configure a larger SMP to it than available? Just
curious ...

 Mace
 --- Ceruti, Gerard G
 [EMAIL PROTECTED] wrote:

  Hi All
 
  I have been following the discussion on
  consolidating Oracle on zSeries
  Linux to exploit z/VM to achieve some license
  saving, we are in the
  process of doing a paper exercise to see what our
  numbers would be, this
  morning a question was asked  What about DB2 UDB ?
  as the license
  model is also price per cpu, has anyone been down
  this path and could
  share some insight ?.
 
  Regards
  Gerard Ceruti
 


Mit freundlichem Gruß / Best regards,
Ingo Adlung

* * * Frohes Neues Jahr * * * Happy New Year * * * Feliz Año Nuevo * * *
Bonne Année * * *


--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: SNA via OSA - Best option?

[Ingo Adlung]

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 07.12.2006 06:25:33:

 On Wednesday, 12/06/2006 at 07:26 MST, Lee Stewart
 [EMAIL PROTECTED] wrote:
  Getting close to trying this, but...
 
  For Linux to use it, I have to give a MAC address to Linux, right?  (In
  Yast/Network Devices/Network Card/Advanced Options.)

 I don't know how to set the MAC manually on Linux.

Please check your Linux on System z Device Drivers, Features, and Commands
manual.


  What do I use for a MAC address?   And if I just pick one, how do I
know
  it's valid and not a dup on the net?

 This is the beauty of a layer 2 (TYPE ETHERNET) VSWITCH.  You can pick
the
 NIC MAC in the directory (NICDEF) and not worry about Linux.  Locally
 Assigned Addresses (LAAs) have to be unique only within their local LAN
 segments; MACs do not travel through the entire network.


Well, whether you define the locally assisgned MAC in Linux or whether you
choose to do so in the guest directory (and have Linux observe it as a
pseudo burn-in (universal) address) doesn't solve the problem of MAC
uniqueness in your network segment. Whether you choose the one or other
way is a matter of administration policies - and in case of using the
OSA layer-2 feature in an LPAR setup you don't have a choice in the first
place ...

http://standards.ieee.org/regauth/groupmac/tutorial.html

provides a little MAC address tutorial that gives you some context

 But the bottom line of LAAs is that if they are to be used, then they
must
 be managed.  That means there has to be a process in your networking
group
 who assigns them.

 Alan Altmark
 z/VM Development
 IBM Endicott


Best regards,
Ingo

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Server Time Protocol support for zSeries

[Ingo Adlung]

Rob,
I'm sorry if I wasn't clear enough in my example :-)

The user space doesn't typically care about the TOD - agreed. The TOD
is the TOD and the wall-clock time observed by user space may correlate
back to the TOD or may observe some +/- offset, e.g. caused by NTP.

However, the disk device driver uses the TOD to time stamp its I/O.
Of cause, the roll back isn't done on TOD values, but the *data* that is
asynchronously replicated by XRC is indeed sorted by TOD value. If there
are 2 OS instances, that have a requirement for data consistency
managing their work units we also need TOD consistency because of the
way XRC works.

Applications may have nicely flushed their buffers or written data with
O_DIRECT in the first place, but while the data from one tier (system)
is replicated already, the data from the other tier (system) may still
be queued for replication if the TODs are out of sync - specifically if
we don't talk about msecs, but seconds or even worse minutes ... this
may have many interesting effects on transactional rollback when 2-phase
commits are broken after the fact due to an outage during replication.
The transaction log from tier 1 assumes a 2-phase commit being finished
for a unit of work and the log on tier 2 doesn't even show the transaction
at all or some intermediary state only, and you may have further tiers
that have already consumed the data regardless ...

Time consistency in asynchronous data replication scenarios avoids much
head aches you may face without!

Best regards,
Ingo

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 11.10.2006 20:41:46:

 On 10/11/06, Ingo Adlung [EMAIL PROTECTED] wrote:

  We are working to provide ETR support asap, but currently this
  anticipated support is limited to LPAR only, as z/VM doesn't provide
  the required guest support, yet. STP will follow.

 No doubt the lack of my imagination, but I think it would be
 interesting to know which applications would take advantage of such
 new function. I was not aware that people would make roll-back based
 on TOD clock. All I have seen is where units of work are separated by
 in-band markers and roll-back or commit being locked on those.

 The consistency groups is when two different parallel sysplex
 configurations would both have the need to run on slightly different
 time, and both need a Linux virtual machine on the same z/VM image to
 run in synch with them? If it were only one, you could have z/VM run
 along with the same clock and you would be fine. If so, that might not
 be the first problem many of us run into, I would think.

 Rob

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Server Time Protocol support for zSeries

[Ingo Adlung]

Bob,
including Linux in a GDPS/XRC environment is generally fine, also
without ETR or STP support for time synchronization.

As far as I can see you only have the need for a data consistency
group throughout multiple Linux images or between Linux and z/OS if
you have transactional data in your multi-tier setup that requires
time consistency in case of an outage for proper rollback processing.
Remember your respective logs get (implicitly) synchronized through
the z/OS data mover based on the time stamps. With the logs in case
of an outage getting out of sync due to time inconsistency (one side
thinks the 2-phase commit completed successfully and the other side
perhaps not even finding the transaction it in its logs at all) the
recovery process is getting more complicated ...

However, please be aware that this becomes an issue *only* if the
LPAR hypervisor can't adjust the time transparently (which it usually
does) and therefore depends on OS collaboration. You may call this
paranoia, but it is real. Without OS support for respective machine
checks the hypervisor is required to virtualize the TOD for the OS
not participating and thus the respective OS images start working
on different TOD values. Therewith what used to be a consistency group
will show a time shift between images. Hence all OS images that have
the requirement for a consistency group (as outlined above) better
collaborate on ETR/STP time synchronization.

We are working to provide ETR support asap, but currently this
anticipated support is limited to LPAR only, as z/VM doesn't provide
the required guest support, yet. STP will follow.

Best regards,
Ingo

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 11.10.2006 18:11:51:

 Ingo,

 I am a GDPS/XRC environment and I *will* want Linux to participate
 there. What is the answer or issues I face?

 Bob Richards



 -Original Message-
 From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
 Ingo Adlung
 Sent: Wednesday, October 11, 2006 12:05 PM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: Server Time Protocol support for zSeries

 The only use case I'm aware of where standard NTP usage is not
 accurate enough, but asking for ETR or STP usage is when you want
 Linux to participate in an XRC asynchronous replication scheme *and*
 you have a requirement for building XRC time consistency groups
 across multiple OS images. Those might either be homogeneous Linux
 or heterogenous Linux and z/OS environments where the z/OS data
 mover replicates data based on TOD timestamps and you can't tolerate
 time inconsistency in case of an outage.

 Best regards,
 Ingo

 --
 Ingo Adlung,
 STSM, System z Linux and Virtualization Architecture
 mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

 Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 11.10.2006
 17:40:42:

   -Original Message-
   From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On
   Behalf Of Dave Jones
   Sent: Wednesday, October 11, 2006 10:31 AM
   To: LINUX-390@VM.MARIST.EDU
   Subject: Re: Server Time Protocol support for zSeries
  
  
   That's a good question, John. As far as I know, Linux on
   zSeries (either
   VM guest or native) can use an external time source to set its
 clock.
  
   The real problem is that z/VM and it's guests can not use the
   same time
   source as z/OS to sync their clocks together. Consider the case
 where
   there are two LPARS in a z9-BC, one running z/OS and using STP to
 set
   its clock and the other LPAR running z/VM and Linux guests
   with its time
   set by the operator's Timex.  :-)
  
   DJ
 
  I'm still a bit confused. I know that z/VM cannot set its clock to the
  STP time source. But why couldn't the Linux systems under z/VM use
 XNTP
  to set their clock to the z/OS value? z/OS 1.7 can run an NTP daemon
  which the Linux instances should be able to use. I hope that would be
  close enough.
 
  --
  John McKown
  Senior Systems Programmer
  HealthMarkets
  Keeping the Promise of Affordable Coverage
  Administrative Services Group
  Information Technology
 
  This message (including any attachments) contains confidential
  information intended for a specific individual and purpose, and its
  content is protected by law.  If you are not the intended recipient,
 you
  should delete this message and are hereby notified that any
 disclosure,
  copying, or distribution of this transmission, or taking any action
  based on it, is strictly prohibited.
 
 
  --
  For LINUX-390 subscribe / signoff / archive access instructions,
  send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
 or
 visit
  http://www.marist.edu/htbin/wlvindex?LINUX-390

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email

Re: ECKD vs FBA problem on MF Linux Lpar

[Ingo Adlung]

I'm confused. I think to recall that with EMC storage subsystems you
could surface SCSI disks as FBA disks, hence the fba discipline of the
dasd device driver would detect it and take care of it ... is this the
use case described initially?

In this case zfcp would be completely out of the picture ...

Best regards,
Ingo

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 08.08.2006 18:57:51:

 That looks like you don't have the zfcp kernel module on your system.
 What does:
 find /lib/modules/`uname -r` -iname *zfcp*
 show you?


 Mark Post

 -Original Message-
 From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
 Michael Harvey
 Sent: Tuesday, August 08, 2006 12:30 PM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: ECKD vs FBA problem on MF Linux Lpar


 Another question on same issue, let me know if you can help.

   When I try to 'MAP' the FBA disk using the 'ZFCP' module this is what
 I get
 :

 LNOUC4D:~ # insmod zfcp map=0x0406 0x01:0x50060482ccb539c8
 0x0:0x0107
 insmod: can't read 'zfcp': No such file or directory
 LNOUC4D:~ #

 Can see what I am missing !
 Thank You.

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: ECKD vs FBA problem on MF Linux Lpar

[Ingo Adlung]

 Wow ... such an interesting suggestion.  You mean,  Ingo,  that EMC might
 speak FBA on the IBM channel?

Hi Rick, when you sneak through Mike's initial mail (snippet)

 lsdasd
 0.0.0100(ECKD) at ( 94: 0) is dasda : active at blocksize 4096,
 546840 blocks, 2136 MB
 0.0.0101(FBA ) at ( 94: 4) is dasdb : active at blocksize 512, 524288
 blocks, 256 MB
 0.0.0102(ECKD) at ( 94: 8) is dasdc : active at blocksize 4096, 54000
 blocks, 210 MB
 0.0.0406(FBA ) at ( 94: 12) is dasdd : active at blocksize 512,
 71454720 blocks, 34890 MB
 I am able to go into yast and creat an LVM and Filesystem,
 but when I do a mkinitrd it thinks the DASD is an ECKD device instead of
 FBA, this is wrong ?

it suggests for exactly this being the case - i.e. my brain can't be that
off :-)

While I remember that we had heart about this feature some years ago I
don't
think we ever had an EMC box to test with ourselves. If we could nail down
the problem Mike describes it could certainly become a nice add-on feature
:-)

Best regards,
Ingo

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 08.08.2006 19:29:00:

 Wow ... such an interesting suggestion.  You mean,  Ingo,  that EMC might
 speak FBA on the IBM channel?

 I have tried, and tried, and tried to get the storage vendors and/or
 in-house storage management teams to present FBA (eg: 9336) on the
 channel.  I get the  deer in the headlights  response every time.  They
 just don't seem to know what disk is if it isn't CKD.  Oh ... SAN,
maybe,
  but that's on a different wire.  Plug the same system into an IBM
 processor and it must be CKD  (3390, maybe 3380).

 It would be a great boon to all of us  (VM, VSE, Linux)  if EMC and STK
 and IBM would give us an FBA handle on SAN volumes.  Think about it!  SAN
 on one side,  which can talk to z/VM and to zLinux,  but also to Solaris,
 AIX, Windows,  but then also FBA to z/VM and to zLinux  as FBA  without
 EDEV overhead.  (Don't get me wrong:  EDEV is great,  but it's a hack,
and
 it's heavy.)

 The CKD wrapper around the data which all DASD vendors now appear to
 mandate  (if using an IBM strand of fibre)  is overhead.  The disk system
 must wrap-up the data;  Linux and CMS  (even CP to some extent)  must
then
 un-wrap it.  Overhead on both ends.  [sigh]  Why is it that  turning off
 this overhead is such a difficult concept to grasp?

 -- R,





 Ingo Adlung [EMAIL PROTECTED]

 Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU




 08/08/2006 01:05 PM
 Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU

 From
 Ingo Adlung [EMAIL PROTECTED]
 To
 LINUX-390@VM.MARIST.EDU
 cc

 Subject
 Re: ECKD  vs FBA problem on MF Linux Lpar






 I'm confused. I think to recall that with EMC storage subsystems you
 could surface SCSI disks as FBA disks, hence the fba discipline of the
 dasd device driver would detect it and take care of it ... is this the
 use case described initially?

 In this case zfcp would be completely out of the picture ...

 Best regards,
 Ingo

 --
 Ingo Adlung,
 STSM, System z Linux and Virtualization Architecture
 mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

 Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 08.08.2006 18:57:51:

  That looks like you don't have the zfcp kernel module on your system.
  What does:
  find /lib/modules/`uname -r` -iname *zfcp*
  show you?
 
 
  Mark Post
 
  -Original Message-
  From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
  Michael Harvey
  Sent: Tuesday, August 08, 2006 12:30 PM
  To: LINUX-390@VM.MARIST.EDU
  Subject: Re: ECKD vs FBA problem on MF Linux Lpar
 
 
  Another question on same issue, let me know if you can help.
 
When I try to 'MAP' the FBA disk using the 'ZFCP' module this is what
  I get
  :
 
  LNOUC4D:~ # insmod zfcp map=0x0406 0x01:0x50060482ccb539c8
  0x0:0x0107
  insmod: can't read 'zfcp': No such file or directory
  LNOUC4D:~ #
 
  Can see what I am missing !
  Thank You.
 
  --
  For LINUX-390 subscribe / signoff / archive access instructions,
  send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
or
 visit
  http://www.marist.edu/htbin/wlvindex?LINUX-390

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390


 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send

Re: ECKD vs FBA problem on MF Linux Lpar

[Ingo Adlung]

EDEV: Oh, I missed that minor detail ... . I think to recall that EMC
at some point in time really allowed to configure their systems to present
SCSI disks as channel attached FBA as you asked for. Therefore I was
misled.
Don't know whether this feature still exists, though. Perhaps Mike can
shed some light on that ...

Best regards,
Ingo

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 08.08.2006 23:31:47:

 Ah!  I see what you meant.
 Yes,  he was using EDEV.  Neat stuff,  EDEV.  VM talks to the SAN and
 presents FBA to the guest.
 Wouldn't it be ... elegant ... if the storage vendors presented FBA to
 the System z host?

 -- R,





 Ingo Adlung [EMAIL PROTECTED]

 Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU




 08/08/2006 04:33 PM
 Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU

 From
 Ingo Adlung [EMAIL PROTECTED]
 To
 LINUX-390@VM.MARIST.EDU
 cc

 Subject
 Re: ECKD  vs FBA problem on MF Linux Lpar






  Wow ... such an interesting suggestion.  You mean,  Ingo,  that EMC
 might
  speak FBA on the IBM channel?

 Hi Rick, when you sneak through Mike's initial mail (snippet)

  lsdasd
  0.0.0100(ECKD) at ( 94: 0) is dasda : active at blocksize 4096,
  546840 blocks, 2136 MB
  0.0.0101(FBA ) at ( 94: 4) is dasdb : active at blocksize 512, 524288
  blocks, 256 MB
  0.0.0102(ECKD) at ( 94: 8) is dasdc : active at blocksize 4096, 54000
  blocks, 210 MB
  0.0.0406(FBA ) at ( 94: 12) is dasdd : active at blocksize 512,
  71454720 blocks, 34890 MB
  I am able to go into yast and creat an LVM and Filesystem,
  but when I do a mkinitrd it thinks the DASD is an ECKD device instead
of
  FBA, this is wrong ?

 it suggests for exactly this being the case - i.e. my brain can't be that
 off :-)

 While I remember that we had heart about this feature some years ago I
 don't
 think we ever had an EMC box to test with ourselves. If we could nail
down
 the problem Mike describes it could certainly become a nice add-on
feature
 :-)

 Best regards,
 Ingo

 --
 Ingo Adlung,
 STSM, System z Linux and Virtualization Architecture
 mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

 Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 08.08.2006 19:29:00:

  Wow ... such an interesting suggestion.  You mean,  Ingo,  that EMC
 might
  speak FBA on the IBM channel?
 
  I have tried, and tried, and tried to get the storage vendors and/or
  in-house storage management teams to present FBA (eg: 9336) on the
  channel.  I get the  deer in the headlights  response every time.
They
  just don't seem to know what disk is if it isn't CKD.  Oh ... SAN,
 maybe,
   but that's on a different wire.  Plug the same system into an IBM
  processor and it must be CKD  (3390, maybe 3380).
 
  It would be a great boon to all of us  (VM, VSE, Linux)  if EMC and STK
  and IBM would give us an FBA handle on SAN volumes.  Think about it!
SAN
  on one side,  which can talk to z/VM and to zLinux,  but also to
 Solaris,
  AIX, Windows,  but then also FBA to z/VM and to zLinux  as FBA  without
  EDEV overhead.  (Don't get me wrong:  EDEV is great,  but it's a hack,
 and
  it's heavy.)
 
  The CKD wrapper around the data which all DASD vendors now appear to
  mandate  (if using an IBM strand of fibre)  is overhead.  The disk
 system
  must wrap-up the data;  Linux and CMS  (even CP to some extent)  must
 then
  un-wrap it.  Overhead on both ends.  [sigh]  Why is it that  turning
off
  this overhead is such a difficult concept to grasp?
 
  -- R,
 
 
 
 
 
  Ingo Adlung [EMAIL PROTECTED]
 
  Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU
 
 
 
 
  08/08/2006 01:05 PM
  Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU
 
  From
  Ingo Adlung [EMAIL PROTECTED]
  To
  LINUX-390@VM.MARIST.EDU
  cc
 
  Subject
  Re: ECKD  vs FBA problem on MF Linux Lpar
 
 
 
 
 
 
  I'm confused. I think to recall that with EMC storage subsystems you
  could surface SCSI disks as FBA disks, hence the fba discipline of the
  dasd device driver would detect it and take care of it ... is this the
  use case described initially?
 
  In this case zfcp would be completely out of the picture ...
 
  Best regards,
  Ingo
 
  --
  Ingo Adlung,
  STSM, System z Linux and Virtualization Architecture
  mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263
 
  Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 08.08.2006
 18:57:51:
 
   That looks like you don't have the zfcp kernel module on your system.
   What does:
   find /lib/modules/`uname -r` -iname *zfcp*
   show you?
  
  
   Mark Post
  
   -Original Message-
   From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
   Michael Harvey
   Sent: Tuesday, August 08, 2006 12:30 PM
   To: LINUX-390@VM.MARIST.EDU
   Subject: Re: ECKD vs FBA problem on MF Linux Lpar
  
  
   Another question on same issue, let me know if you can help.
  
 When I try to 'MAP' the FBA

Re: Bad Linux backups

[Ingo Adlung]

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 25.07.2006 11:23:02:

 Alan Altmark wrote:
  But, Carsten, the application may start up just fine, however it may be
  using old data.  I have an application running on my workstation right
now
  that saves its configuration data only when you shut it down (working
as
  designed according to the vendor).  Since the application is only
  terminated when the system is shut down, a live backup of the disk
would
  have no effect.  I mean, it would restore and run just fine, but be
  running with old data.
 Well, backups are always about using old data in case of recovery as
 far as I can see. Using an application that saves important data only
 on shutdown in a mission critical environment is very dangerous
 regardless of the backup soloution.


Well, I guess the question is whether you relaunch from a deterministic
starting point, or whether your starting point is arbitrary. You are
arguing
along the line that one shouldn't be afraid about discretionary starting
points, as anecdotal knowledge suggests that it will usually work anyhow.
Alan is arguing that customers would typically not want to bet on
arbitraryness and we shouldn't paper the risks doing so but clearly
articulate
it. Either you have application support/awareness for live backups, or the
result by definition *is* arbitrary - unless you can guarantee a well
defined
transactional state (as viewed by an aplication) which we currently lack
file
system or more generally operating system support for.

  I can jump up and down and stamp my feet, claiming that the application
is
  broken, but that doesn't make it so.

I fully support Alan's view.

 What application (Server Application on Linux) acts like you claim?

 regards,
 Carsten

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

Ingo

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Compiler tuning options

[Ingo Adlung]

Rich
-march will take advantage of the instruction set available on the
respective models while -mtune takes into consideration the instruction
scheduling and select accordingly. In combination you will achieve
the maximum result. However, if you know that while your execution
sweet spot is a z9, you nonetheless occationally need to have the
application run on a z990 you might consider choosing -march=z990 and
-mtune=z9. Likewise -march=z900 would allow the program to run on any
z architecture machine, while mtune assures you take best advantage of
the compiler knowing about processor pipeline design and instruction
implementation for the target machine you choose. The mtune value
defaults to the cpu-type specified by march if not specified differently.
(which raises the question which distribution/compiler version it
requires to get z9 march/mtune support in the first place ... the compiler
on SLES 9 and RHEL 4 may not come with the required support for taking
specific advantage of z9 - just guessing).

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 20.07.2006 00:40:29:

 Is there any benefit to using both -march and -mtune compiler options
 when compiling code for z990 or z9?  Since -mtune seems to allow the
 code to run on other processor models, does it degrade the performance?

 Thanks.
 --
 Rich Smrcina
 VM Assist, Inc.
 Phone: 414-491-6001
 Ans Service:  360-715-2467
 rich.smrcina at vmassist.com

 Catch the WAVV!  http://www.wavv.org
 WAVV 2007 - Green Bay, WI - May 18-22, 2007

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

Mit freundlichem Gruß / Best regards,
Ingo Adlung

--
Ingo Adlung,
STSM, System z Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Temporary disruption to channel paths - impact on z/Linux?

[Ingo Adlung]

Generally I would strongly recommend to vary the CHPIDs offline prior to
swap the cards minimizing related error recovery efforts when accidentally
catching an I/O operation in the middle ... regardless whether running
z/OS, z/VM, or Linux.
Without any specifics about the nature of your problems and the service
level you were running back then it is hard to judge whether you unveiled
a possible bug, though. Did you involve IBM or distributor service at that
time?

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 19.02.2006 02:53:39:



 Ingo Adlung wrote:
  VM doesn't shield from Linux that there is 6 paths available, but Linux
  sees them, too. I.e. if you vary CHPIDs offline the guest Linux will
also
  see them disappear. But you are also on the safe side with Linux as we
can
  handle channel outages, no matter if running under VM or LPAR. Assuring
  such is part of a rigid device qualification program :-)
 

 That is nice to know. However when we swapped cards some time ago when
 Linux was running on bare metal, we had problems. Perhaps we did not
 vary off the channel on the linux lpar before we swapped the cards?
  Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 18.02.2006
02:45:22:
 
...

Mit freundlichem Gruß / Best regards,
Ingo Adlung
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Temporary disruption to channel paths - impact on z/Linux?

[Ingo Adlung]

VM doesn't shield from Linux that there is 6 paths available, but Linux
sees them, too. I.e. if you vary CHPIDs offline the guest Linux will also
see them disappear. But you are also on the safe side with Linux as we can
handle channel outages, no matter if running under VM or LPAR. Assuring
such is part of a rigid device qualification program :-)

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 18.02.2006 02:45:22:

 I would vary the paths offline, swap the card, and vary the paths online.
May
 not be necessary but it might. No need to do anything to the linux
guests,
 that's what VM is for.

 [EMAIL PROTECTED] wrote:

  We have a problem in our disk array. One of the ficon channel
controller
  cards is down. Our ops wants to swap it today. This will require
downing
  3 channel paths out of 6 that are shared to z/VM.
 
  In the past, I have always shutdown all Linux instances and z/VM and
  brought it back after the card swap.
 
  If three out of the six are suddenly unavailable, would z/VM ignore
them
  and use the only three that are available? When all the six are
  available when both cards are functioning, will z/VM auto-detect and
use
  the channels?
 
  Would this all be transparent to the Linux guests?
 
  Apparently this is not an issue on the z/OS side.
 
  --
  __
  Ranga Nathan
  Work: 714-442-7591

 --
 Stephen Frazier
 Information Technology Unit
 Oklahoma Department of Corrections
 3400 Martin Luther King
 Oklahoma City, Ok, 73111-4298
 Tel.: (405) 425-2549
 Fax: (405) 425-2554
 Pager: (405) 690-1828
 email:  stevef%doc.state.ok.us

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

Mit freundlichem Gruß / Best regards,
Ingo Adlung
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks

[Ingo Adlung]

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 07.10.2005 17:35:05:

  vmcp has a return value, which you can check in scripts.
  e.g:
 
  # vmcp some large query
  # echo $?
 
  0 stands for everything is fine, any other value for problems.
  vmcp returns ENOBUFS (105) if the buffer was not large enough
  That means the output was larger than 64kb.

 Usability suggestion: since this is a VM-specific widget, could you
return
 codes that are consistent with the implementation of DIAG 8 on CMS? I
think
 it would help in understanding how to use the gadget, and folks coming
over
 from CMS would be more familiar with those return codes.

David,
I beg you pardon, but i don't like the CP return code approach. While a VM
widget it is nonetheless a Linux module and should adhere to Linux return
code principles. But your point is well taken, it would certainly be
valuable
to describe how those get mapped to Linux values.



  If there is a consensus that vmcp should always print
  something to stderr if the buffer was not large enough, tell
  us and we can add that.

 A combination of the familiar return codes noted above, and an
explanatory
 message to stderr would be my preferred approach.

 -- db

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390


Ingo

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: I want to conifrm VSWITCH's MTU size.

[Ingo Adlung]

It is the (virtual) network infrastructure that imposes the
payload restrictions, hence the MTU size. I case of QDIO the
VSWITCH supports any MTU the attached (coupled) vNICs support, too.
If you use a VSWITCH to interconnect guest virtual NICs with a
distributed switched fabric over OSA Express, however, it is this
connection that imposes your MTU limits - is OSA connected to a
network supporting jumbo frames and have you configured the VM OSA
TCP/IP definition accordingly? If yes you should be fine.

Best regards,
Ingo Adlung

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 09.06.2005 07:33:13:

 Hi,all

 Please teach me.
 I want to comfirm VSWITCH's MTU size.
 SLES9's eth0 connected to the VSWITCH is MTU 9000.
 But VSWITCH's MTU size isn't diplayed on screen by using
 Q VSWITCH DETAILS command.

 VSWITCH don't have MTU??

 I want to use eth0 for MTU size 9000.

 Please teach me.

 Thank you.
 -
 K.M.


 __
 Save the earth
 http://pr.mail.yahoo.co.jp/ondanka/

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: SuSE and GDPS/XRC

[Ingo Adlung]

David,
I guess I disagree. While you are certainly right that there is
data cached in memory we ought to look at the scenario that could
take place.

If there is transactional data the transaction monitor and/or the
database would typically worry about data being written to persistent
data store so that in case of an outage you have roll-back or
roll-forward capabilities.

If there is on the fly generated data that nobody worries about
if being synced to disk at a particular point in time, a Linux
crash would certainly cause data loss for data not flushed to disk yet.
If anyone worries about such possible data loss, you better talk to
your application provider articulating your concern about its data
hardening policy for critical data.

If the customer uses GDPS/XRC for data replication of the Linux
environment (VM doesn't time stamp its data, though it honours Linux
writing timestamps) or alternatively GDPS/PPRC with or without
HyperSwap for both, Linux and z/VM they probably get as close as ever
possible, minimizing any critical data loss you probably can. And
in case of transactional data you typically also have full data
consistency assurance.

Therewith depending on your data loss objective in case of a
disaster scenario a backup like the one TSM usually delivers might
be good enough, or more sophisticated concurrent data replication
DR setup like the one delivered by like GDPS/XRC or GDPS/PPRC
is mandatory - if you have the opportunity integrating Linux into
your z/OS BR setup that GDPS provides support for.

Best regards,
Ingo

--
Ingo Adlung,
zSeries Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 04.05.2005 16:36:30:

  I
  was thinking
  to do a Sync and Drop process on the Linux volumes , the
  LPAR would remain
  up during this process. Has anyone else already looked at
  this ?

 You will not get a usable backup. This process does not take into
 account the data cached in memory.

  Any ideas what the
  change would
  be if z/VM was in place .

 You still can't use Sync and Drop reliably. You need a backup solution
 that is aware of what's going on inside the Linux system, eg something
 with a Linux client like Bacula or TSM.

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: SuSE and GDPS/XRC

[Ingo Adlung]

David,

 I think we're starting from different assumptions.

You may be right. I understand your rationale, let me elaborate on
mine once more :-)

I don't expect that any of the filesystems would or should change their
behavior, or Linux changing its caching policies. My point was that if
you can't afford loosing the data you better assure to write the data
synchronously or programmatically flush the buffers from time to time
assuring to have consistent data to recover from.

I guess by saying so I'm inspired by similar thoughts that causes you
to suggest using a file backup program from within Linux.

It is not necessarily about backups exclusively. XRC and PPRC aren't
just snapshot technologies, but are meant to permanently replicate all
data stored locally to a remote storage subsystem. In case of PPRC with
GDPS/HyperSwap this allows e.g. to non-disruptively to your workload
swap storage subsystems either locally or remotely. While more expensive
certainly more convenient than falling back to a backup you don't have
any well defined data recovery scheme identifying what you've lost since
then ...

Regards,
Ingo

Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on 04.05.2005 18:39:27:

  If there is transactional data the transaction monitor and/or the
  database would typically worry about data being written to persistent
  data store so that in case of an outage you have roll-back or
  roll-forward capabilities.

 I think we're starting from different assumptions. I start from the
 assumption that the majority of Linux users are storing data on normal
 filesystems rather than in database applications.

 Technically one could argue that a journaling filesystem may play this
 role, but I've seen too many cases where a Linux system does not recover
 from a snapshot-based backup.

  If there is on the fly generated data that nobody worries about
  if being synced to disk at a particular point in time, a Linux
  crash would certainly cause data loss for data not flushed to
  disk yet.
  If anyone worries about such possible data loss, you better talk to
  your application provider articulating your concern about its data
  hardening policy for critical data.

 I doubt we'll get changes in ext2/ext3/reiserfs/xfs/etc. All use the
 buffering in memory technique extensively for performance reasons on the
 Intel side, and we're not going to change that on 390.

  If the customer uses GDPS/XRC for data replication of the Linux
  environment (VM doesn't time stamp its data, though it honours Linux
  writing timestamps) or alternatively GDPS/PPRC with or without
  HyperSwap for both, Linux and z/VM they probably get as close as ever
  possible, minimizing any critical data loss you probably can. And
  in case of transactional data you typically also have full data
  consistency assurance.

 For transactional applications, I might agree. However, looking at the
 dozen or so running Linux instances I have easy access to here, I have
 approximately 100-200M of unwritten data in storage that I have no
 guarantee that it has been flushed to disk. The only way to be *certain*
 that that data is committed to a recoverable backup is to run a client
 inside those Linux machines, so that the backup application is aware of
 the *actual* state of the data and represents it correctly in the
 backup.

 Another good reason for IBM SSD to publish the control interfaces...8-)

  Therewith depending on your data loss objective in case of a
  disaster scenario a backup like the one TSM usually delivers might
  be good enough, or more sophisticated concurrent data replication
  DR setup like the one delivered by like GDPS/XRC or GDPS/PPRC
  is mandatory - if you have the opportunity integrating Linux into
  your z/OS BR setup that GDPS provides support for.

 I'm not saying that GDPS is a bad idea -- if your applications can take
 advantage of it, great. I simply maintain that it does not produce
 reliable backups for a large class of users.





 
  Best regards,
  Ingo
 
  --
  Ingo Adlung,
  zSeries Linux and Virtualization Architecture
  mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263
 
  Linux on 390 Port LINUX-390@VM.MARIST.EDU wrote on
  04.05.2005 16:36:30:
 
I
was thinking
to do a Sync and Drop process on the Linux volumes , the
LPAR would remain
up during this process. Has anyone else already looked at
this ?
  
   You will not get a usable backup. This process does not take into
   account the data cached in memory.
  
Any ideas what the
change would
be if z/VM was in place .
  
   You still can't use Sync and Drop reliably. You need a
  backup solution
   that is aware of what's going on inside the Linux system,
  eg something
   with a Linux client like Bacula or TSM.
  
  
  --
   For LINUX-390 subscribe / signoff / archive access instructions,
   send email to [EMAIL PROTECTED] with the message: INFO
  LINUX-390

Interest in a shared (cluster) file system for Linux on zSeries environments

[Ingo Adlung]

I'm looking for customers having interest in a shared (cluster) file system
implementation for Linux on zSeries distributions.

Could you please explain whether your interest is general nature or whether
it solves a particular business issue ? E.g. replacing a NFS
infrastructure.
Further, is Linux binary compatibility sufficient (either in a homogeneous
zSeries environment or cross different platforms, like Intel and zSeries)
or would you require heterogeneous cross-platform compatibility, like
Windows, Linux - please explain ?

Could you please also describe your business urgency ?

Please contact me directly at [EMAIL PROTECTED]

Thanks in advance and best regards,
Ingo Adlung

--
Ingo Adlung,
zSeries Linux and Virtualization Architecture
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Parallel Access Volumes with SLES7

[Ingo Adlung]

Jim,

 We would consider it VERY important.

thanks for your feedback.

Since PAV is not going to be turned off (great z/OS performance
improvements), Linux needs to be PAV tolerant, even if it does not take
advantage of it.

Linux is PAV tolerant. It just won't be able operating any alias devices
in LPAR - if this is all you want/need no further support is required
(you may get some annoying messages during IPL/boot about devices becoming
not operational, though :-(

So is Linux exploitation beyond toleration very important to you ? If
yes, do you have more details about your workload profile ? What I'm
interested in is to learn what limitations people observe exploiting
Linux striping support that could potentially be overcome by additional
(or alternative) PAV exploitation.

I'm not looking for constructed scenarios (this is not meant as a
response to your mail, but I perfectly understand those) but real
workload you folks run in your shops.

Thanks and best regards,
Ingo

--
Ingo Adlung,
Linux for zSeries - Architecture  Design
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263


|-+
| |   James Peddycord  |
| |   [EMAIL PROTECTED]|
| |   s.ntrs.com  |
| |   Sent by: Linux on 390|
| |   Port |
| |   [EMAIL PROTECTED]|
| |   EDU |
| ||
| ||
| |   24.06.2003 15:15 |
| |   Please respond to|
| |   Linux on 390 Port|
| ||
|-+
  
-|
  |
 |
  |   To:   [EMAIL PROTECTED]  
   |
  |   cc:  
 |
  |   Subject:  Re: [LINUX-390] Parallel Access Volumes with SLES7 
 |
  |
 |
  |
 |
  
-|



Ingo,

We would consider it VERY important.
All of our DASD is PAV enabled. It was enabled last December. All of the
Linux instances that were already running have been OK, but I have to jump
thru hoops to get a new instance created. I'm also concerned about lack of
support should one of our production instances somehow decide not to boot
because of PAV.

Since PAV is not going to be turned off (great z/OS performance
improvements), Linux needs to be PAV tolerant, even if it does not take
advantage of it.

I'll be pointing our IBM SE to this discussion as well.

Thanks,
Jim


Ingo Adlung wrote:

Some time ago, there is a discussion about PAV and Linux/390 in the list.
The last thing that i can remember it is Linux/390 can't be loaded from
PAV volume. Try search to find details.

We are considering doing a write up how to use PAV under z/VM using LVM
(requires SLES 8). Under LPAR we currently don't have the necessary Linux
support in place.

Would be good to hear from you how important you consider it.

Ingo

Re: Wine on Linux for S/390

[Ingo Adlung]

 I presume there are binaries around

John,
In his life prior to IBM Ulrich used to work on Wine.
He thus has the much better expertise than I do.

Is there anybody out there considering it valuable on
zSeries as a migration path ? Remember you need to have
the Windows sources of the applications you worry about...

Ingo

--
Ingo Adlung,
Linux for zSeries - Architecture  Design
mail: [EMAIL PROTECTED] - phone: +49-7031-16-4263

Re: Betr.: Re: SuSE or RED HAT

[Ingo Adlung]

We are aware of it and are already working with George Kraft
defining a LSB base for zSeries ... :-) Getting applications,
including IBM's embracing it is a different challenge, though,
and not unique to a particular platform.

Best regards,
Ingo



Alan Cox [EMAIL PROTECTED]@VM.MARIST.EDU on 02.10.2002 02:41:03

Please respond to Linux on 390 Port [EMAIL PROTECTED]

Sent by:Linux on 390 Port [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:
Subject:Re: [LINUX-390] Betr.: Re: SuSE or RED HAT



On Tue, 2002-10-01 at 23:10, Rich Smrcina wrote:
 Websphere runs today on SuSE Linux.  I have also heard that Lotus Domino
will
 be ported to Linux for S/390, there was no mention that it would be
 specifically Redhat.  If it was, it would be a grave mistake.

I would agree with that sentiment. Maybe customers need to gently poke
their IBM reps about a defined LSB base and compatibility test set for
S/390 Linux, in the same way as the LSB is finally making sensible
guarantees about a base compatibility for x86

Re: LVM Shark

[Ingo Adlung]

Sergey,

you can use LVM with Shark - indeed, if you want to overcome the
ESCON throughput limitations striping over multiple volumes is an
appropriate way doing so. Similar if 3390 Mod 9 capacity is not
sufficient for you - defining a volume group is a way to get to
larger file systems.

Ingo

--
Ingo Adlung,
Linux for zSeries - Strategy  Design

The box said, 'Requires Windows95 or better', ...so I installed LINUX.


Sergey Korzhevsky [EMAIL PROTECTED]@VM.MARIST.EDU on 25.05.2002
11:36:19

Please respond to Linux on 390 Port [EMAIL PROTECTED]

Sent by:Linux on 390 Port [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:
Subject:[LINUX-390] LVM  Shark



Hello, All.

I heard some rumor about Don't use LVM with Shark/ESS because  it use
RAID5.
Is this true?


WBR, Sergey

Re: Lotus Domino Server for L/390

[Ingo Adlung]

It is not - I'll contact you offline, understanding your requirements.

Ingo

--
Ingo Adlung,
Linux for zSeries - Strategy  Design

The box said, 'Requires Windows95 or better', ...so I installed LINUX.


Sergey Korzhevsky [EMAIL PROTECTED]@VM.MARIST.EDU on 25.05.2002
13:17:31

Please respond to Linux on 390 Port [EMAIL PROTECTED]

Sent by:Linux on 390 Port [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:
Subject:[LINUX-390] Lotus Domino Server for L/390



Maybe it is existing too?



WBR, Sergey

Re: LinuxWorld Article series

[Ingo Adlung]

This is something we're looking at. There's some risk getting into
such a situation if ...

a) you significantly overcommited your memory, and
b) you have oversized Linux images (more than the application
   working set requires), and
c) the images are rather busy

Then from a VM perspective it is hard to determine a page that can
be selected for paging in case of memory pressure, if everything
appears to be ongoingly in use ...

If the sum of the images requires that much storage for its working
set (other than I/O buffering), and are busily active, then there is
little we can do, though. Then you must not excessively overcommit
your memory.

There is some thought, oversizing Linux memory to be prepared for
arbitrary peak workloads, thinking VM could page more efficiently.
You may choose to have Linux use its memory more restrictive, and
let Linux page in case of memory pressure instead. Depends on the
workload ...

Best regards,
Ingo

--
Ingo Adlung,
Linux for zSeries - Strategy  Design

The box said, 'Requires Windows95 or better', ...so I installed LINUX.


Barton Robinson [EMAIL PROTECTED]@VM.MARIST.EDU on
25.04.2002 16:48:30

Please respond to Linux on 390 Port [EMAIL PROTECTED]

Sent by:Linux on 390 Port [EMAIL PROTECTED]


To:[EMAIL PROTECTED]
cc:
Subject:Re: [LINUX-390] LinuxWorld Article series



The author is correct. This has NOT been addressed for Linux
on zSeries.

From: Werner Puschitz [EMAIL PROTECTED]

Is the author right on this:

http://www.linuxworld.com/site-stories/2002/0416.mainframelinux-p7.html
Linux memory management assumes control of a machine and so grabs up
free memory for use in I/O buffering. Having multiple Linux instances do
this to independently buffer I/O to the same files resident on a shared
mini-disk not only wastes memory, but dramatically increases the paging
effort.

Or has this already been addressed for Linux on zSeries?

Thanks
Werner







If you can't measure it, I'm Just NOT interested!(tm)

//
Barton Robinson - CBW Internet: [EMAIL PROTECTED]
Velocity Software, IncMailing Address:
 196-D Castro Street   P.O. Box 390640
 Mountain View, CA 94041   Mountain View, CA 94039-0640

VM Performance Hotline:   650-964-8867
Fax: 650-964-9012 Web Page:  WWW.VELOCITY-SOFTWARE.COM
//

Re: PAV Support - any requirement for it ?

[Ingo Adlung]

David,

the way we envision we could operate PAV devices would work for
different storage attachment technologies than ESCON/FICON too ... :-)

Best regards,
Ingo

**
Ingo Adlung,
Linux for zSeries - Strategy  Design

The box said, 'Requires Windows95 or better', ...so I installed LINUX.


David Boyes [EMAIL PROTECTED]@VM.MARIST.EDU on 13.03.2002 12:14:39

Please respond to Linux on 390 Port [EMAIL PROTECTED]

Sent by:  Linux on 390 Port [EMAIL PROTECTED]


To:   [EMAIL PROTECTED]
cc:
Subject:  Re: [LINUX-390] PAV Support - any requirement for it ?



 PAVs have been used to a great degree by DB2 on the OS/390 side of the
 zbox.  I would expect that UDB on our Linux side will appreciate the
 multiple exposures as well.

As would anyone working with large aggregated arrays (think large LVMs or
md
RAID setups). Having PAV would help immensely with some I/O related
bottlenecking on such setups).  Introducing something like this for
OpenFCP-attached storage would be a very useful concept.

-- db

Re: DHCP Client problem with SUSE distribution.

[Ingo Adlung]

 I've never tried to use DHCPCD on Linux/390.  Sounds a little bizarre to
me.
 Still, you might try using a Linux DHCPD server and see if it handles
things
 better.

If you're using an OSA in QDIO mode, virtual hipersockets in z/VM 4.2 or
CTC/IUCV links, DHCP (server or client) will not work.  It (DHCP) needs
broadcast support, and none of these devices support it.  Dedicated OSAs
in
LCS mode will work OK, as will CIP cards.

 -- db


I guess the magic it requires besides broadcast (client) is MAC
addressing support at the network layer which is not available in
QDIO mode, nor with CTC/IUCV, but LCS only (not sure about CLAW).

Now folks, please let me know about the importance of having DHCP
support with Linux on zSeries - and is client or server more important
to you, or both ?

Best regards,
Ingo

PAV Support - any requirement for it ?

[Ingo Adlung]

I'd like to gather your feedback on the requirement for Linux
exploiting Parallel Access Volume (PAV) support available on ESS
(Shark) storage subsystems and its competitors in the market.

In the past some customers expressed their concern about the data
throughput ESCON attachments provide, which made us think about PAV
support. However, I would appreciate any thoughts about FICON based
storage attachments already satisfying your throughput requirements
or whether you consider PAV exploitation a major requirement
nonetheless ? Any opinions ? e.g. do you see requirements for it
as you can't move to FICON in the forseeable future ?

I would appreciate your feedback, either offline or to this list.
In any case I would appreciate if you could also depict the business
scenario / solution you expect PAV exploitation being a requirement
for.

Thanks and best regards,

Ingo

**
Ingo Adlung,
Linux for zSeries - Strategy  Design

The box said, 'Requires Windows95 or better', ...so I installed LINUX.

Re: DASD layout error

[Ingo Adlung]

My understanding is that the old, old, old, _real_ 3380 devices don't
support ECKD, which is necessary for support in Linux/390.  If those are
indeed that type of device, then I believe you are out of luck.

If the 3380's are behind a 3990 Control Unit I suppose one could go
and remove all coded dependencies on 3390 geometry, but if this is
indeed a non-ECKD control unit then it would be painful.

Another possibility, if it was a 3380 attached to a 3990 controller -
the original mail from Maciek implies that he used ICKDSF to format the
disk, which doesn't build a Linux compatible layout either. He should
use dasdfmt instead.

Ingo

Re: dedicate DASD not operational under z/VM 4.1

[Ingo Adlung]

Holger,

you confuse me - we can deal with VM rejecting our SPID requests.
Worked fine with minidisk and dedicated disks in the past. Did
smth change ?

Best regards,

Ingo

**
Ingo Adlung,
Linux for zSeries - Strategy  Design

The box said,  'Requires Windows95 or better'  , ...so I installed LINUX.


Holger Smolinski/Germany/IBM@[EMAIL PROTECTED] on 29.01.2002 16:33:07

Please respond to Linux on 390 Port [EMAIL PROTECTED]

Sent by:  Linux on 390 Port [EMAIL PROTECTED]


To:   [EMAIL PROTECTED]
cc:
Subject:  Re: [LINUX-390] dedicate DASD not operational under z/VM 4.1



Did you define the DASDs as 'unsupported' in z/VM?
z/VM imagining the device to be supported by itself
prevents it from allowing a SetPathGroupID.

Best Regards
Holger Smolinski
--
Dr. Holger Smolinski, Tech. Planning (Storage I/O) for Linux on zSeries
IBM Deutschland Entwicklung GmbH,Schönaicher Str. 220, 71032 Böblingen
FAX: +49-7031-16-3456, Tel. +49-7031-16-4652


|+---
||  Ferguson, Neale|
||  Neale.Ferguson@SoftwareA|
||  G-USA.com   |
||  Sent by: Linux on 390|
||  Port |
||  [EMAIL PROTECTED]|
||   |
||   |
||  29.01.02 15:44   |
||  Please respond to Linux  |
||  on 390 Port  |
||   |
|+---
  
---|

  |
|
  |  To: [EMAIL PROTECTED]
|
  |  cc:
|
  |  Subject: Re: dedicate DASD not operational under z/VM 4.1
|
  |
|
  |
|
  
---|




What does a query of the real devices show? What does the
CP directory entry of the Linux guest look like?

 -Original Message-
 Hi,
   We installed Linux under z/VM 4.1 which is upgraded
 from VM 2.4. Yesterday we restart the VM include all
 related hardware power off/power on because of
 maintainence reason (just restart, not change in
 system), but after that we cannot start the linux
 servers properly. Now Linux can only detect the
 minidisk but not dedicate volumes any more.
   The System log is:

 Ready; T=0.01/0.01 09:06:08
 i 100
 Linux version 2.2.19 ([EMAIL PROTECTED]) (gcc
 version 2.95.2.1 19991024 (release)) #1 SMP Thu May 24
 12:43:49 PDT 2001
 Command line is: root=/dev/dasda1 ro noinitrd
 dasd=100,200,1729-172b,119