Re: console modes - what Linux sees

[Alan Ackerman]

Great work! 

That's a great write-up! I know nothing about "system console". I'm in 
California and the mainframes are on the East Coast (meaning anything East of 
the Rockies.) Nor am I trusted with access to the HMC via TCP/IP.


A few more comments.

As a friend of mine said "green screen is an acquired taste". (Green screen is 
a name for the IBM 3270 family of terminals.) Unless you want to learn to 
control z/VM or z/OS or z/TPF, it's not worth learning.

And it still won't give you 'vi' or 'top' or anything else full-screen, on a 
3270-emulator.


Some history:

A 3270 had only a few "attention" keys. PF1-12, PA1-3, Clear, Enter, and some 
Reset keys.

PF1-12 and Enter sent in the whole screen. (Approximately). When the screen was 
set up (by z/VM in 3215-emuation mode) with 2 input lines (132 characters) at 
the bottom, those are what got sent in.

PA1-3 sent only the key pressed. I'm not sure what Clear sent in, but in any 
case it was a request to clear the screen and redraw it.

There were also numerous keys that modified the screen or cursor position, but 
did not send anything.(Cursor movement arrows, tabs, Erase Input, etc.)

Esc did not exist. 


Now for Linux running on z/VM:

^C (hat-C or not-C) doesn't send anything, so you have to type ^C + Enter. (The 
Linux driver interprets this as a control-C).

PA1 takes you from VM Read to CP Read, so you can type CP commands directly, 
without #CP space in front of them. To get back to the normal mode you have to 
type BEGIN (or B) which is the CP command to start the virtual machine running 
again. (Someone else can talk about SET RUN ON if they like.)

I don't know what PA2 and PA3 do in Linux.

You can program PF1-24 to send short character strings, via CP SET commands. So 
if you want PF3 to send control-C you can do that:

#CP SET PF3 ^C

The above was all about real 3270s (3278s). You are probably sitting at a PC 
running a 3270-terminal emulator, and it can be programmed in many different 
ways. (See its manual.) But it still cannot send anything but the above, or 
combinations of them. What Esc does is up to the terminal emulator vendor, but 
I cannot think of any way to make 'vi' usable.

You could program the Esc key to send in a PF key which was set up via

#CP SET PFn ^[ 

but that would be interpreted as Esc + Enter, not just Esc.


> ]On Feb 23, 2015, at 11:45 AM, Rick Troth  wrote:
> 
> Started this a couple weeks ago, but then had to put it aside. (Other
> things urgent, and had some checking to do.) But a friend asked a
> related question last week, so when answering that I think I managed to
> finish this.
> 
> The thread with subject "Interrupting Linux under z/VM session" again
> points out the crucial need for understanding some basics in mainframe
> Linux. Console interaction with Linux on z is not difficult, but is
> grossly misunderstood by newcomers. (No slam on newbies; the interface
> tools paint a deceptive picture.) It's the kind of thing that should be
> covered early ... during orientation, before classes start your very
> first semester, prior to Linux/390 101.
> 
> It's all about what Linux sees. With all hypervisors, there is a big
> difference between physical interaction and virtual interaction. The
> other hypervisors (than z/VM) have things somewhat easier because most
> of the virtual devices they present as "console" at least allow
> byte-at-a-type interaction. Confusion there is a little less.
> 
> There are five modes of console operation for Linux on z:
> 
>  * what Linux sees as a 3215 (typewriter)
>  * what Linux sees as a 3270
>  * what Linux sees as the "system console" (SYSC in z/VM speak)
>  * what Linux sees as the ASCII system console
>  * what Linux sees by way of IUCV (can do byte at a time)
> 
> 
> The 3215 is most common when Linux is hosted by z/VM. You connect with a
> 3270 emulator, so the conversation is about "3270", but that's *not*
> what the guest sees.
> 
> 
> On 01/21/2015 07:55 AM, John McKown wrote:
>>   ...   I can't duplicate the OP's environment,
>> but I wonder why he can't just do the normal:  followed by ":q!" to
>> exit vi.
> 
> There's no way for Linux on z/VM to see an  character by way of
> the 3215.
> Linux using (what it sees as) a 3215 will never get byte-at-a-time and
> will never see an actual  nor an actual Ctrl-C.
> 
> ^c or ^z are special short-hand for faking it, but as John mentioned (in
> the note cited above), 'vi' (VIM) can intercept interruptions.
> 
> - what follows is long -
> 
> Back up ... always an exception to the rule ... it's possible but really
> really really difficult for Linux to see an  by way of what it
> thinks is a 3215. If the 3215 is presented by way of a 3270 (emulated or
> otherwise) it is likely not possible.
> 
> The 3215 console driver in the Linux kernel takes the EBCDIC "not"
> (sometimes rendered as "hat") and then marks the following character as
> a control character. So "^c" becomes Ctrl-C. For Escape, that would
> typic

Re: Dummy query Install type identifier SUSE 12

[Mark Post]

>>> On 2/23/2015 at 01:18 PM, Jake anderson  wrote: 
> I am trying to build a SUSE gold image on VM. Based on the previous install
> how can we identify if the previous version of SUSE was installed using
> KIWI or AUTOYAST?
> Is KIWI or AUTOYAST considered to be a kick start file in SUSE?

I've not personally used Kiwi to create a system.  I have used autoYaST, and it 
is equivalent to kickstart in Red Hat.

If autoYaST was used to install a system, you should see this file:
/var/adm/autoinstall/cache/installedSystem.xml


Mark Post

--
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/

console modes - what Linux sees

[Rick Troth]

Started this a couple weeks ago, but then had to put it aside. (Other
things urgent, and had some checking to do.) But a friend asked a
related question last week, so when answering that I think I managed to
finish this.

The thread with subject "Interrupting Linux under z/VM session" again
points out the crucial need for understanding some basics in mainframe
Linux. Console interaction with Linux on z is not difficult, but is
grossly misunderstood by newcomers. (No slam on newbies; the interface
tools paint a deceptive picture.) It's the kind of thing that should be
covered early ... during orientation, before classes start your very
first semester, prior to Linux/390 101.

It's all about what Linux sees. With all hypervisors, there is a big
difference between physical interaction and virtual interaction. The
other hypervisors (than z/VM) have things somewhat easier because most
of the virtual devices they present as "console" at least allow
byte-at-a-type interaction. Confusion there is a little less.

There are five modes of console operation for Linux on z:

  * what Linux sees as a 3215 (typewriter)
  * what Linux sees as a 3270
  * what Linux sees as the "system console" (SYSC in z/VM speak)
  * what Linux sees as the ASCII system console
  * what Linux sees by way of IUCV (can do byte at a time)


The 3215 is most common when Linux is hosted by z/VM. You connect with a
3270 emulator, so the conversation is about "3270", but that's *not*
what the guest sees.


On 01/21/2015 07:55 AM, John McKown wrote:
>...   I can't duplicate the OP's environment,
> but I wonder why he can't just do the normal:  followed by ":q!" to
> exit vi.

There's no way for Linux on z/VM to see an  character by way of
the 3215.
Linux using (what it sees as) a 3215 will never get byte-at-a-time and
will never see an actual  nor an actual Ctrl-C.

^c or ^z are special short-hand for faking it, but as John mentioned (in
the note cited above), 'vi' (VIM) can intercept interruptions.

- what follows is long -

Back up ... always an exception to the rule ... it's possible but really
really really difficult for Linux to see an  by way of what it
thinks is a 3215. If the 3215 is presented by way of a 3270 (emulated or
otherwise) it is likely not possible.

The 3215 console driver in the Linux kernel takes the EBCDIC "not"
(sometimes rendered as "hat") and then marks the following character as
a control character. So "^c" becomes Ctrl-C. For Escape, that would
typically be "^[". But don't get me started about square brackets and
Codepage 500.

Forgive my tone. Explaining this is actually fun. And the
implementations are neat! But the gap in what you have been told is
frustrating.

DO NOT run 'vi' on Linux on z on a typical 3270 session.


*Linux sees a 3215*, ye olde Selectric

z/VM uses the bottom two lines of your 3270 session for input. The far
right of the second line is reserved for status (eg: VM READ or RUNNING
or others) and shows the VM hostname. The rest of your 3270 screen (what
you see) is guest output (or is VM/CP output).

Input is line at a time. The content delivered to the guest by VM (CP)
is the line you entered without any control characters. The 3270 console
driver (in Linux) tacks on a 0x0A newline at the end for the shell and
other apps (like 'vi'). When the console device is in cooked mode, I
expect it's actually 0x0D and 0x0A (CR/LF), but haven't bothered to look
into that for a long time. Doesn't matter: the control characters are
simulated. The  you pressed is not really the same  the
shell gets.

The 3215 driver will convert a "^c" to a Ctrl-C 0x03. Ctrl-C is the
default "intr" character. See the 'stty' command for more info about all
that.

When Linux boots, you see a lot of garbage looking output. The startup
scripts in most Linux distros contain ANSI X3.64 escape sequences for
highlighting and color. What looks nice on a PC looks like junk on a
3215. (And then Codepage 500 makes matters worse. When you see
"Ýsomething¨", that's CP 500 mucking things up.)

This is where most of us running Linux on z/VM live when we do console
work.

Mother never told you, but Ctrl-C in X3270 on your desktop will not be
heard by Linux at the other end.


*Linux sees a 3270*, '#cp term conmode 3270'

There is a 3270 driver for Linux. It's really slick! (DO NOT try "#cp
term conmode 3270" on a running guest.)

The 3270 driver in zLinux came from Amdahl. Long story.
Remember Amdahl? Okay, not everyone knows the name ... so there once was
a company called Amdahl that made IBM compatible hardware. It was
founded by a man named Amdahl who used to work for IBM. (He's a legend
right up there with Fred Brooks.)

In the 70s, the company picked up a Unix implementation for S/370. It
was a *great* implementation of Unix, having no allergy to true Unix
things nor confusion over true mainframe things. A fully ASCII system,
it could do full-screen 3270 just fine. This system was called UTS.

Amdahl (the company) spun off UTS (t

Re: Multiple migration products visible to zypper prior to SP2 upgrade to SP3

[Rick Troth]

On 02/20/2015 10:59 AM, Ron Foster wrote:
> We are still in midst of upgrading our last SLES11SP2 system.
>  ...

Hi, Ron, --

I expect you'll want to stay the course w/r/t how you're handing this
(especially since this is the last guest in this round of upgrades).
However ...

Cannot help but think this is a good case for "upgrade by
virtualization". What I mean is, where possible, deploy a new guest
ALREADY AT the target release level, then transfer the user and app
content from the old guest to the new guest. When everything looks good
on the new release, pack-up the old guest and put it on ice, return its
resources (disk space) to the pool.

I've seen a lot of upgrade in place, which makes sense historically, but
not so much in a virtual world. People treat a virtual machine as having
intrinsic value. (I make the same mistake ... too often.) But really,
one of the great things about virtualization is that we can discard a
virtual machine, and should!, when we're done with it.

There are base line requirements (which may not have been done or
perhaps *could* not have been done) to make deploy-a-new-guest kind up
update possible: isolate apps from the op sys, keep the users distinct
from system IDs (and normalize them across all systems), isolate the
data, get a firm handle on configuration.

Ideally, a virtual machine should be something you can drop-in with
whatever op sys and related sofware you need. On top of that run the
apps. Within the apps, use the data.

I hope this helps.



--

Rick Troth
Senior Software Developer

Velocity Software Inc.
Mountain View, CA 94041
Main: (877) 964-8867
Direct: (614) 594-9768
ri...@velocitysoftware.com 

--
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/

Dummy query Install type identifier SUSE 12

[Jake anderson]

Hi

I am trying to build a SUSE gold image on VM. Based on the previous install
how can we identify if the previous version of SUSE was installed using
KIWI or AUTOYAST?
Is KIWI or AUTOYAST considered to be a kick start file in SUSE?

Jake

--
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: Anyone has experience on selling zLinux at fixed price?

[James Vincent]

Hello!

There are going to be a lot of ideas on how to do charging all the way from
"we don't charge back" to "we charge by the micro-process".

Fixed-price charging is good for very well contained zLinux servers.  Using
SHARE ABSOLUTE and even CPU POOLING can help with this.  CPU POOLING is
really good if you are thinking of mixing those fixed-resource servers with
high-performance or "premium services" servers.  There are pros and cons to
fixed price charging.  A pro is it is MUCH easier than any other kind of
charging (other than no-cost!).  A con is that some folks may think they
are being charged too much if they really don't use it that much or that
heavy, and some may not be thrilled being capped when they want to run
something heavy for a short while.

We use a variable rate based on consumption for most of our servers. We
also have "lab" servers that are contained within SHARE ABS. We have
processes to "cap" non-premium production servers when they get out of hand
and the entire processor has been running in the high 90's for CPU. We use
zVPS to collect all the data for the processor/LPARs and the zLinux servers
to evaluate what they are up to every minute. Using that data, we are able
to charge-back to the business units based on what they consume by
process/application. There is a small base charge for just having a server,
then the use of resources adds to it. This was all built over the last 10
years and we are still tuning it!

Figuring out what your business will accept for charging is the hard part.
Between the knobs in z/VM and performance monitoring/collecting tools
available, you can make it work the way you need it.



-- *James Vincent*
-- President, SHARE Inc.
-- Calendar: http://tinyurl.com/JSVCalWeek
-- SHARE is an independent volunteer-run information technology association
that provides *education*, professional *networking *and industry
*influence*

On Mon, Feb 23, 2015 at 2:10 AM, Agblad Tore  wrote:

> This seems to be the biggest hinder for most people to start using Linux
> on z.
> Anyone having done this ?
> There is a number of options to limit cpu and resources, SHARE and setting
> max memory for example. Is this helping out here ?
>
> BR /Tore
>
> 
> Tore Agblad
> zOpen Teamleader
> IT Services
>
> Volvo Group Headquarters
> Corporate Process & IT
> Assar Gabrielssons väg 9
> SE-405 08, Gothenburg  Sweden
> E-mail: tore.agb...@volvo.com
> http://www.volvo.com/volvoit/global/en-gb/
>

--
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/