Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Alan Altmark wrote: On Thursday, 10/13/2005 at 09:11 ZE8, John Summerfied <[EMAIL PROTECTED]> wrote: But why lock? CP can handle multiple parralel diag8 As I recall someone asserted there's a problem getting the proper cp feedback at present. VM return codes don't map to *x return codes, so another action is needed to get the VM return code and publish it some place a script can use it. Without locking, this will fail from time to time. All output data areas and registers must be stashed in instance-specific memory such as that associated with a file descriptor. But this is normal coding practice in file/network drivers. Implicit locks would be appropriate for those diagnose functions that are stateful. E.g. you can't have two processes using diag 14 at the same time. But there's no reason they can't both issue diag 210 (for example). Much earlier in this thread (which seems to have changed its subject from time to time), folk were talking about using this in scripts, and examples using /bin/sh were given. For this purpose, serialisation and paralellisation by the driver are inadequate. The state must be preserved for use by the script. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
On Thursday, 10/13/2005 at 09:11 ZE8, John Summerfied <[EMAIL PROTECTED]> wrote: > > But why lock? CP can handle multiple parralel diag8 > > As I recall someone asserted there's a problem getting the proper cp > feedback at present. VM return codes don't map to *x return codes, so > another action is needed to get the VM return code and publish it some > place a script can use it. > > Without locking, this will fail from time to time. All output data areas and registers must be stashed in instance-specific memory such as that associated with a file descriptor. But this is normal coding practice in file/network drivers. Implicit locks would be appropriate for those diagnose functions that are stateful. E.g. you can't have two processes using diag 14 at the same time. But there's no reason they can't both issue diag 210 (for example). 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
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Carsten Otte wrote: Rick Troth wrote: Lock the file. Or have the device driver enforce single access. But why lock? CP can handle multiple parralel diag8 As I recall someone asserted there's a problem getting the proper cp feedback at present. VM return codes don't map to *x return codes, so another action is needed to get the VM return code and publish it some place a script can use it. Without locking, this will fail from time to time. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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: procfs [was DIAG ]
Carsten Otte wrote: John Summerfied wrote: --w--- 1 root root 4096 Oct 12 08:02 class/pcmcia_socket/pcmcia_socket0/card_eject PCMCIA socket is an excellent example for what /sys is useful: once you plug your card, you'll see it connected to that socket there just as you do see a qeth card connected to 3 subchannels on the mainframe. I fail to see your proposed connection to diag8, and which attributes one would modify on it (power state, online/offline and such does'nt apply). Here is an example where a MVS users found a need to use diagnose 8 from a guest: http://www2.herethey.com:/p370.w3archive/199804/msg00035.html I don't see that a similar need would not exist in Linux, and I think a location in sysfs is appropriate because here we're talking about modifying (or commanding) the host environment, not talking to a device. However, I'm not talking about diag8 specifically, but asserting that sysfs is the correct place to communicate with the hardware (real or virtual). -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
Carsten Otte wrote: David Boyes wrote: Suggestion, using DIAG 8 as an example: Implemented in all DIAG drivers: /sysfs/zvm/diag/nn/lock - semaphore to use as a reserve/release flag. Processes attempt to flock() this file. Success indicates acquisition of the DIAG nn interface This is troublesome as pointed out before: What if your script that has aquired the lock crashes? I didn't think David was talking about a script, though I was and that's why I specified a timeout, and not flock() either. I guess thatever happens depends on what's being attempted, but the consquences are little worse from those if the kernel support backing it crashes. Fear of bad consequences isn't an argument for not doing it, though it should temper the diligence applied to designing, coding, testing etc. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
David Boyes wrote: If process acquires lock on /sysfs/zvm/diag/8/lock (ie flock succeeds), then write CP command into cmdstring to prepare for call. Once parameters are loaded, open of /dev/diag8 and write a 1 to /dev/diag8 to execute the I don't understand why you would use a device for this which seems to me is just another control function. Doesn't this function belong in sysfs too? -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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: One of those things that make you go "hmmm..."
Post, Mark K wrote: In my daily review of the linuxvm.org web server logs, I discovered that someone at Microsoft mirrored the entire web site. H. One day a while ago I created the website mentioned below; there's a wildcard DNS so I can and did just invent a name and configure Apache to service from that vhost. I then populated it with some pics from my mac (OS X does some things well) and then create the sig below on an account I then used to post to debian-user. As we all know, Debian is dedicated to exchanging free software and of course, Microsoft knows this too. In under one hour I had my first hit. Whois revealed the visitor was someone from Microsoft. I'm surprised it's taken Bill this long to track you down:-) -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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
I am under the impression that Linus does not want any more stuff like this in /proc. I think he has requested that some of the stuff in /proc be moved elseware. The procfs filesystem was originally only for process related stuff. It was kind of lazy to put other things in it. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of John Summerfied Sent: Wednesday, October 12, 2005 4:55 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks Carsten Otte wrote: > McKown, John wrote: > >>This is likely a foolish question, but could the /sys/devices/diagnose >>be set up like the /dev/fd ? E.g. for pid 12345, there exists an entire >>tree /sys/devices/diagnose/12345. Then have "self" as a symlink to the >>current pid so that for any particular pid, it could reference >>/sys/devices/diagnose/self/... It might even be possible to "interlock" >>on /sys/devices/diagnose/self/8/command so that you could not cat to it >>a second time until you had read /sys/devices/diagnose/self/8/status or >>maybe even 'echo "1">/sys/devices/diagnose/self/8/active' where that >>pseudo-file gets changed to "0" when ../command is written to you cannot >>again write a line to ../command until you write a "1" to ../active (or >>something to that effect). Hope this makes sense. I'm not a kernel type >>person. > > Sounds terrible & complicated to me. What's wrong with the existing > soloution with vmcp? It's safe against races _because_ it splits the whole > thing into a userspace program that keeps an open file handle and a kernel > component that can identify subsequent calls by that handle. > I don't really get where the problem with that one is, could you elaborate > where you see the issue? _I_ think devices are ultimately for processing user data and preparing to process user data. So, partitioning & formatting disk, tape handling, communicating with users and other processes are in order (I've always wondered about network devices!). Where you are manipulating the environment, by turning fans on or off, by starting or stopping CPUs, by sending commands to the host OS, or by loading firmware into wireless and other cards and peripherals then something else should be done. In the past, the right thing has been to manipulate files in procfs. Whatever is done, it should be consistent with other virtual environments such as XEN and VMWARE. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Carsten Otte wrote: McKown, John wrote: This is likely a foolish question, but could the /sys/devices/diagnose be set up like the /dev/fd ? E.g. for pid 12345, there exists an entire tree /sys/devices/diagnose/12345. Then have "self" as a symlink to the current pid so that for any particular pid, it could reference /sys/devices/diagnose/self/... It might even be possible to "interlock" on /sys/devices/diagnose/self/8/command so that you could not cat to it a second time until you had read /sys/devices/diagnose/self/8/status or maybe even 'echo "1">/sys/devices/diagnose/self/8/active' where that pseudo-file gets changed to "0" when ../command is written to you cannot again write a line to ../command until you write a "1" to ../active (or something to that effect). Hope this makes sense. I'm not a kernel type person. Sounds terrible & complicated to me. What's wrong with the existing soloution with vmcp? It's safe against races _because_ it splits the whole thing into a userspace program that keeps an open file handle and a kernel component that can identify subsequent calls by that handle. I don't really get where the problem with that one is, could you elaborate where you see the issue? _I_ think devices are ultimately for processing user data and preparing to process user data. So, partitioning & formatting disk, tape handling, communicating with users and other processes are in order (I've always wondered about network devices!). Where you are manipulating the environment, by turning fans on or off, by starting or stopping CPUs, by sending commands to the host OS, or by loading firmware into wireless and other cards and peripherals then something else should be done. In the past, the right thing has been to manipulate files in procfs. Whatever is done, it should be consistent with other virtual environments such as XEN and VMWARE. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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: procfs [was DIAG ]
On Oct 12, 2005, at 6:38 PM, John Summerfied wrote: Rick's serialisation process, while it may lead to some head- scratching and syrup-taking, would at least alert to a race problem. "Taking?" I prefer "quaffing." Adam -- 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: procfs [was DIAG ]
Carsten Otte wrote: John Summerfied wrote: The nice thing about /proc and (apparently) /sys is that one can, at a pinch, control many functions by simply reading with cat and writing with echo. There are several things particular to my Toshiba laptop that I can control in this way, and if I can do that then I can write a script to automate something (eg choosing runlevel based on which of three buttons is used to boot the computer). I recall previous discussion on controlling DASD devices using similar entries (in /proc), and one commonly sees advice to turn (network) forwarding on or off using "echo >/proc/sys/net/ipv4/ip_forward 1" The cat&echo tactics is dangerous because it is racy: you echo your command into it. Becuase the file descriptor is closed between cat&echo, someone else may issue a different command or read your result before you cat the procfile. That cannot happen with the vmcp way to handle it, you'll always see _your_ response. I think the words "at a pinch" above are important. There are examples where it's not relevant - eg turning IP forwarding on/off; if you turn it on while I'm turning it off we have other problems. Whatever the dangers for particular examples, there are always cases and circumstances where otherwise dangerous cases are safe (think boot time, single-user operation for starters). Rick's serialisation process, while it may lead to some head-scratching and syrup-taking, would at least alert to a race problem. I imagine well-written tools (as opposed to scripts) would in fact lock the procedure; there could even be a lock pseudofile in the relevant directory which anyone, including a script-writer could use to lock for a time: echo >/sys/devices/diagnose/999/lock where token is some arbitraray string delay is the time in milliseconds (or other unit to be determined) nnn is the diagnose operation To signal completion echo >/sys/devices/diagnose/999/lock 0 -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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 -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ do not reply off-list -- 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: One of those things that make you go "hmmm..."
Hello from Gregg C Levine An expression said by Pogo comes to mind. "We have met the enemy. And he is us." --- Gregg C Levine [EMAIL PROTECTED] --- "Remember the Force will be with you. Always." Obi-Wan Kenobi > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > Post, Mark K > Sent: Wednesday, October 12, 2005 4:32 PM > To: LINUX-390@VM.MARIST.EDU > Subject: [LINUX-390] One of those things that make you go "hmmm..." > > In my daily review of the linuxvm.org web server logs, I discovered that > someone at Microsoft mirrored the entire web site. H. > > > Mark Post > > -- > 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Wednesday, 10/12/2005 at 07:01 CET, Alan Cox <[EMAIL PROTECTED]> wrote: > Which basically is the same as generic DIAG, the only difference being > that you are wrapping it in something. The more I follow this thread the > more generic diag seems right, even if it has a bitmask of "not > supported" diags that have "hard" features and a kernel side > table/function handlers for hard cases that people can contribute > updates to when they need a specific interface. Though this whole discussion, a few things have become obvious: - Linux needs access to some more native VM functions (diagnose, IUCV, VMCF, ...) - Some of these services have persistent state, some don't. - Some have inputs, some don't (i.e. read only). - Some have extremely complex inputs, most don't. - Some of these functions have already been provided, but are hidden under rocks in the /proc file system or in other zSeries-specific Linux commands (Did you know the output of diag 0 is already available in cpuinfo or some such?) - IBM hasn't done a very good job of telling VM-oriented Linux application developers about the aforementioned rocks. Delivering function without doc is not good. - Programs and scripts have different requirements (file descriptors vs. commands), so diags that might be useful in a script should come with userspace commands. - People have different philosophical views of how these services should be surfaced. - The diagnose instructions do not all have to surfaced as "diagnose" instructions. Consistency isn't important; integration into the Linux application model is. - The process of upstreaming should eliminate most Bad Ideas. - It's ok for CMS and Linux to do things differently; they have different pedigrees. 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
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
Hi, If good IUCV support was available, *SPL would be rather cool. It's better than DIAG14 because it is a defined asynchronous interface. DIAG D8 might also be a fun addition to Linux. Cheers, Arty -- 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
One of those things that make you go "hmmm..."
In my daily review of the linuxvm.org web server logs, I discovered that someone at Microsoft mirrored the entire web site. H. Mark Post -- 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: mksles9oot (again)
RC is short for Release Candidate, while GM means Golden Master. Usually, the last RC is declared to be the GM. Mit freundlichen Grüßen / with kind regards Martin Peschke IBM Deutschland Entwicklung GmbH Linux for zSeries Development Phone: +49-(0)7031-16-2349 |-+> | | Tom Duerbusch| | | <[EMAIL PROTECTED]| | | iscity.com> | | | Sent by: Linux on| | | 390 Port | | | <[EMAIL PROTECTED]| | | IST.EDU> | | || | || | | 12/10/2005 17:07 | | | Please respond to| | | Linux on 390 Port| | || |-+> >---| | | | To: LINUX-390@VM.MARIST.EDU | | cc: | | Subject: mksles9oot (again) | | | >---| Dumb quick question. I'm trying to add SP2 to my 64 bit install process. In mksles9root, the service packs are listed as: SLES-9-SP-2-s390x-GM-CD1.iso SLES-9-SP-2-s390x-GM-CD2.iso SLES-9-SP-2-s390x-GM-CD3.iso However, as just downloaded from Novell/Suse...where ever, the images are: SLES-9-SP-2-s390x-RC4a-CD1.iso SLES-9-SP-2-s390x-RC4a-CD2.iso SLES-9-SP-2-s390x-RC4a-CD3.iso Fine, looks like a simple rename process. But, in systems, sometimes things are not as easy as they look. Are the RC4a images, the right images? What are the GM images? Which images should I be using? Is it just as simple as rename them (in the proc or the actual iso images themselves)? What is the difference? Is one set, a valid licensed set (for those of us with support contracts) and the other, being the evaluation set? Thanks Tom Duerbusch THD Consulting -- 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: SLES9 64 bit without SP?
Where I thought it was something that would be fixed with a service pack, it turns out, it was a novice type error. In IPLing the text decks in CMS to start the Suse installation process, I was punching out the 31 bit text decks and not the 64 bit text decks. The install seemed to go normally, but somewhere in the "loading ram disk" process, I would get an error. IPL'ing the right text decks fixed this problem. Tom Duerbusch THD Consulting Been off on other things and our SUSE service contract was taken over by Novell (hence, networking is now paying for our SLES service contract on the mainframe). I don't know if that is good or not. I'm no longer in control. Anyway, while the contracts are straighten out (or at least my ability to use the maintenance side of suse), I wanted to start with SLES9 64 bit. We have: SLES7 SLES8 SLES9 31 bit running.. When I install SLES9 64 bit (z/890 with z/VM 5.1), during the load of the ram disk, I get an error and the install abends. I see from the FTP server that we are retrieving code, like we should be. Before I get too far into this Is a service pack for SLES9 64 bit required, in order to install? If so, I just stop until our maintenance stuff is worked out. If not, I can work on this problem while the maintenance stuff is worked out. The networking type, for this test, is IUCV. Thanks Tom Duerbusch THD Consulting -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Wednesday, 10/12/2005 at 01:20 AST, David Boyes <[EMAIL PROTECTED]> wrote: > > As Rob van der Heij comments in another post, we don't need > > the ability in Linux to be able to write a CP directory > > management product... > > Why not? Why shouldn't I write a directory management product as a Linux > appliance? Well, for one thing the object directory format is not documented. DIRECTXA is the only supported (by IBM) way to create a directory. On a philosphical level, I think the responsibility for managing the user defintions in the operating system should belong to the operating system. But there is no reason and CMS and Linux cannot coexist. You can have a Linux-based directory management application, but that doesn't mean Linux has to own and physically write the directory. All it has to do is cause the directory to be written or updated. The SSL server and RSCSDNS come to mind as useful co-processing appliances. An appliance that has basic physical directory management capability is all that is needed. 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
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
> Individual DIAGs can have their own variables in /sysfs/zvm/diag/nn as > appropriate. The lock mechanism is simple to implement in arbitrary > languages (works trivially in Fortran -- my favorite test), and is general > enough to accommodate arbitrary DIAGs. > > Once that basic structure is in place, then generating the individual > /dev/diag drivers are a plug-n-chug problem. Which basically is the same as generic DIAG, the only difference being that you are wrapping it in something. The more I follow this thread the more generic diag seems right, even if it has a bitmask of "not supported" diags that have "hard" features and a kernel side table/function handlers for hard cases that people can contribute updates to when they need a specific interface. Alan -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
> > If we are to no longer receive management (or any) function > added to > > CMS, we need the ability to perform the tasks CMS has traditionally > > performed within the Linux environment. The fundamental > problem is to > > enable all the existing architected communication paths between the > > guest OS and CP in a natural and usable manner in Linux. > > > I think that's a big "if".I don't believe that IBM has > ever made the statement that CMS is "functionally > stabilized", although I may have missed it. We are getting > new CMS-based management tools and features from IBM now > (e.g., Operations Manager, Archiver), and CMS PIPELINES is > certainly being enhanced and extended now. While I don't think there has been an "official" statement, it's been pretty clear that nothing major is going to happen to extend CMS function. We are getting some applications, but no real new function in CMS. > While I am in favor of integrating, where possible, virtual > Linux guests more closely to both CP and CMS, I don't want to > see the (limited?) resources IBM has available spent on > reinventing the CMS wheel in Linux. On the other hand, do you want new function and new capabilities quickly and at the same time as for other platforms, or do you want them to spend their time redesigning stuff to fit onto the CMS model? > We don't need all the features that CMS now offers to be > re-invented in the Linux environment; I agree. We need to be able to enhance the Linux environment to enable the good things that both environments can do. > As Rob van der Heij comments in another post, we don't need > the ability in Linux to be able to write a CP directory > management product... Why not? Why shouldn't I write a directory management product as a Linux appliance? > > APPC is harder. I've got code for it, but I don't think > I'll be giving > > it away. > > > Isn't the APPC protocol proprietary to IBM? One of the reasons why *I* won't be giving the code away. -- 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
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
> David Boyes wrote: > > There seems to be a clear customer requirement for making access to > > DIAG function available. > > The question we're debating is how, not why. The why is a foregone > > conclusion. > Maybe I missed that part of the thread, but would you mind > showing me the requirement? I mean, couple of diagnoses _are_ > exported, and for others I fail to see what they could be > useful for in a Linux application. Pardon my increasing frustration here... We out here in the outer darkness (very far away from Martin's office) see an architectural use for them, which, to me, constitutes a requirement for someone to fullfill. This may or may not be an IBM task. > Big mistake. You don't get CPs architectured interfaces in > Linux userland, Wrong. That's exactly what we are talking about -- how to surface CP interfaces in a useful way for Linux. For some functions, CMS utilities call CP interfaces to do things. Those interfaces are clearly defined and accessible by the methods we are discussing. If we no longer have CMS, we need access to those CP interfaces from Linux in order to write replacements for those tasks and utilities that CMS enables. > Running a CMS application requires _porting_ it to the new > interface scheme, which also means reworking its logic to fit > that quite different programming model. No one is promoting running CMS application modules as is. Grant me that I do know that much, please. We need to be able to access the same interfaces in CP that CMS uses in order to write replacements for the CMS utilities in Linux. We are discussing how to present those services to a Linux application in a useful and consistent way. Is that clear enough? If I want to write a replacement for DIRMAINT, then I need to be able to call the CP interface to update a directory entry or update in place. If I want to write a better tn3270 function, I need the ability to determine device characteristics. Etc, etc, etc. You don't have to anticipate every possible use or even whether they will be useful, because I'll think of some way to use them that you never even dreamed of. Count on it. > > Malcolm Beattie has written a VMCF driver (c'mon Malcolm, do the > > paperwork already, OK?). IUCV function is in a usable state > from us. > > DIAG function is next. APPC/C-PIC probably next after that. > IUCV functionality seems useful to me, because that's a > network protocol family which is used in z/VM today. As for > the others, I don't know what they do. IUCV is *not* innately a network protocol -- I don't know why everyone assumes it is. It can be used for carrying network traffic, but IUCV at the low level has the semantics of a point-to-point connection. It is a point-to-point message pipe between two virtual machines, possibly on more than one physical machine via ISFC or TSAF using distributed IUCV. > DIAG nn interface > This is troublesome as pointed out before: What if your > script that has aquired the lock crashes? How is that different from any other important locked file if the process crashes? You clear the lock and continue. > > > /sysfs/zvm/diag/nn/instance - for DIAGs that could > > logically have multiple sessions > > (not really applicable to > > DIAG 8, but would be a useful generic to have) > > open of the > 'instance' file > > would generate a session or instance of the > > desired DIAG, and > read from > > the file would return the path of the instance to > > communicate with. If the > > DIAG does not rationally support multiple > > sessions, always return a > > fixed string. > Not needed. Oh, nonsense. What about DIAG 250? > > /sysfs/zvm/diag/8/cmdstring - the command to be executed > > /sysfs/zvm/diag/8/cprc - the CP return code > Not safe for multiple parallel sessions, and does'nt fit > sysfs purpose. Wrong. Perfectly safe if the conventions described above are obeyed, and if properly implemented to check for the lock specified by being writable only by the process with the lock. I'll defer to others on whether it contravenes the purpose of sysfs -- I would interpret it as appropriate in that it is a system control function. > I really feel uncomfortable with that approach because it > does not fit the unix model at all. Given that the "Unix model" is incorporating useful concepts from Plan 9 and other systems as fast as it can absorb them, I'd say it anticipates the direction things are going rather nicely. Where do you think the idea behind pseudo-filesystems like proc and sysfs came from? It certainly didn't originate in Unix, you can be certain of that. > Also the overall idea of > running CMS applications in Linux instead of porting them > seems queer for me. As said before, that's not what I'm proposing.
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
Alan Altmark wrote: > Using VM for Linux authentication and access control purposes is an area > of intense interest to me. Good. That extends my personal "good ideas" list to: - reader/punch/printer device driver - set language support - IUCV network protocol family - PAM support for CP authentication -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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: DIAG
Neale Ferguson wrote: > Why the need to make IUCV a network device? IUCV is not just a > point-to-point beastie, it's a single-application-to-single-application > protocol. The fact that it was used to create a network protocol for VM > and Linux is because an extra layer to mux and demux application > (socket) streams was added. You should think of IUCV as a serial device > like a modem (or more like a winmodem). [It probably has a lot in common > with the TTY driver.] The intent of the fsiucv driver was to exploit > IUCV as it was first created. Having written many IUCV apps over the > past 25 years (some of which are still running in a couple of major > online systems) I attempted to take the semantics and map them to Linux. > The char approach fitted better than a network device. The excellent skb > handling routines that allow you to add headers/trailers etc. as you > build up the protocol layers is overkill for the base IUCV operation. If > I were to build an APPC driver then I'd definitely go the network driver > way (FMH5/FMH7 processing is tailored for socket buffers). > > Like I said, try and look at IUCV as a serial device like a modem. Am not sure if I understand that fully, probably because I lack 25 years of experience with IUCV in comparisation ;-). For what I do understand, you have an address range (the name of the machine) and a service identifier [program name] for IUCV. That would match the IP/PORT equivalent in the IP world. You can connect to the other side and basically you get a pipeline to send and receive messages [packets in the IP world]. Not all features of the network stack apply to IUCV, but a char device is lacking the connect/disconnect and addressing scheme that networking implies. For me, that sounds like network. What am I missing? -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Wednesday, 10/12/2005 at 05:24 ZE2, Carsten Otte <[EMAIL PROTECTED]> wrote: > Adam Thornton wrote: > > On Oct 12, 2005, at 8:50 AM, Alan Altmark wrote: > > > 88 == minidisk password validation > > >> It is actually a proxy-LINK function for multi-client SVMs. It > >> also has > >> logon password and LOGON-BY validation. This could have some value. > > > > Logon password and logonby validation would be very useful for me. > > Think of it as the foundation for pam_vmcp. > Hm. So what the diagnose does is check if a given user/pass combination > is valid for CP? Yes. However, if an ESM is active, you have to issue the CMS RPIVAL command since checking the CP directory isn't useful. I recognize that issuing RPIVAL is problematic for Linux and am working to address that problem in a future release of z/VM. Each ESM product does a product-specific thing inside the RPIVAL command. The RPIVAL program that comes with RACF/VM simply issues a diagnose 0xA0 subcode 4 (see the RACF/VM Macros and Interfaces book). What you do if another ESM is installed, is up to the vendor - ask them. And before you ask, no, there's no [programmatic] way to tell which ESM is installed. Diagnose 0xA0 subcode 8 only tells you an ESM is present - not which one. Using VM for Linux authentication and access control purposes is an area of intense interest to me. 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
Re: mksles9oot (again)
Yep, the md5sub values are the same. I updated the iso names in my copy of mksles9root and tried it out. No errors. So, it looks like I'm good to go. Thanks for the conformation. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 10/12/05 10:21 AM >>> Tom, Yes, you can just rename the files so mksles9root is happy. I'm not really sure of the differences. We get our ISO images from a common FTP server within IBM. Here are the details of mine: # ls -l *SP-2* -rw--- 1 root root 612798464 Jul 25 09:15 SLES-9-SP-2-s390x-GM-CD1.iso -rw--- 1 root root 609878016 Jul 25 09:16 SLES-9-SP-2-s390x-GM-CD2.iso -rw--- 1 root root 573409280 Jul 25 09:18 SLES-9-SP-2-s390x-GM-CD3.iso # cat MD5SUM-sles9x-sp2 77cf7413affb85badd9037b4b62c1e65 SLES-9-SP-2-s390x-GM-CD1.iso 86c63b8c99e4f3c09bc2b9b81d8bdf1a SLES-9-SP-2-s390x-GM-CD2.iso 22e4c3cf160910c2913c07e8ccc322eb SLES-9-SP-2-s390x-GM-CD3.iso Maybe you can create an MD5SUM file from the above three lines and run " md5sum -c MD5SUM-sles9x-sp2" to see if they're the same? "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Wednesday, 10/12/2005 at 09:48 EST, Adam Thornton <[EMAIL PROTECTED]> wrote: > Two objections here: > > 1) Those drivers are not easy to find. They're buried in a > supplementary rpm to a fairly obscure redbook, and you have to pick > apart the rpm by hand in order to rebuild the ur stuff. Who said anything about leaving them in a redbook? They need to be dragged out into the light of day, given a good bath, combed and shaved, and, if necessary, flea dipped. Or, forget them and start anew. Or those who have written other implementations could bring them forward. Barnard Software's NJE/IP bridge obviously has reader/punch/printer drivers in it. > 2) They're pretty slow; I imagine the DIAG interface would be a good > deal faster. In most normal cases, this is unlikely to be a > problem. In the case *we* tried to use it in, which was mail spam/ > virus scanning and delivery, the ur device was actually one of the > bottlenecks (not, granted, as bad as the content scanning, but still > significant). As I mention elsewhere, never read or write a single record from/to the spool if you can help it. Blocked I/O or Diag 0x14 to read. For bulk writes, use blocked I/O. > Oh, third objection: > > 3) I had to poll the machine's spool to see if anything had appeared, > because AFAIK, the ur device didn't offer interrupts to say "Hey! > Got something new here!" This may have been my own lack of knowledge > about how to drive them, though. A reader throws an unsolicited not-read-to-ready DEVICE END when a spool file arrives. (It is equivalent to pushing the START button on a real card reader.) This is how WAKEUP works. The details are in your always-handy 2821 Control Unit Description manual! :-) 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
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
Adam Thornton wrote: > On Oct 12, 2005, at 8:50 AM, Alan Altmark wrote: > 88 == minidisk password validation >> It is actually a proxy-LINK function for multi-client SVMs. It >> also has >> logon password and LOGON-BY validation. This could have some value. > > Logon password and logonby validation would be very useful for me. > Think of it as the foundation for pam_vmcp. Hm. So what the diagnose does is check if a given user/pass combination is valid for CP? -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
Dave Jones wrote: > And as Adm T. has mentioned, put them someplace where everybody can > easily find them, and add functionality so a user space application > could be notified (async.) when a file appears on the rdr queue. For the filesystem approach the notification comes for free (dnotify/inotify). For a device driver, sending a signal event (SIGIO) via kill_fasync() seems clean to me. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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: mksles9oot (again)
Tom, Yes, you can just rename the files so mksles9root is happy. I'm not really sure of the differences. We get our ISO images from a common FTP server within IBM. Here are the details of mine: # ls -l *SP-2* -rw--- 1 root root 612798464 Jul 25 09:15 SLES-9-SP-2-s390x-GM-CD1.iso -rw--- 1 root root 609878016 Jul 25 09:16 SLES-9-SP-2-s390x-GM-CD2.iso -rw--- 1 root root 573409280 Jul 25 09:18 SLES-9-SP-2-s390x-GM-CD3.iso # cat MD5SUM-sles9x-sp2 77cf7413affb85badd9037b4b62c1e65 SLES-9-SP-2-s390x-GM-CD1.iso 86c63b8c99e4f3c09bc2b9b81d8bdf1a SLES-9-SP-2-s390x-GM-CD2.iso 22e4c3cf160910c2913c07e8ccc322eb SLES-9-SP-2-s390x-GM-CD3.iso Maybe you can create an MD5SUM file from the above three lines and run " md5sum -c MD5SUM-sles9x-sp2" to see if they're the same? "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Wednesday, 10/12/2005 at 04:35 ZE2, Carsten Otte <[EMAIL PROTECTED]> wrote: > > /dev/mem examines guest memory, not CP. IMO: Dangerous Idea. The ability > > to read CP memory comes with the ability to change it. > Oh, CP memory not virtual guest storage. Is this fenced for non-privileged > guests? Is there use to debug CP from within a guest like with gdb or so? The ability to display/change CP memory requires class C. (If RACF is installed, STORE HOST requires additional authorization.) We find very few people other than ourselves bringing up 2nd-level VM systems and single-stepping through CP code with a listing a their side. The only practical use is the porting of a lot of live CP control block scanning tools to Linux. But as of 5.2, I've given up my efforts at cruising control blocks. The changes to DISPLAY HOST, the System Execution Space, knowing which address are 64-bit and which are 31-bit, which are logical addresses and which are real. Arg!!! Grown men everywhere are crying > >>> 88 == minidisk password validation > > > > It is actually a proxy-LINK function for multi-client SVMs. It also has > > logon password and LOGON-BY validation. This could have some value. > Alan, I don't have the slightest idea on what it does from your explanation. > Can you translate to that to linuxish? What are SVMs? Diag 0x88 is a special-purpose diagnose used by the FTP and NFS Service Virtual Machines (SVMs) to link to disks on behalf of other users rather than using the LINK command and to verify a login password. If you (e.g. ftp client) have LOGONBY permission to the user whose disks you are trying to link to, the link is permitted without further access checks. It is class G, but requires special directory authorization. > So far on my personal "good idea" list: > - reader/punch/printer device driver Don't sweat the small stuff. It doesn't have to map perfectly. The CMS reader driver reads multiple records from the reader at once for performance and doles out the cached records one at a time. (Reading one record at a time from the spool is a Really Really Bad Idea.) Since you need a cursor anyway, you can keep track of character position vs. record. Just make sure the app can extract the LRECL of the device so it can know where the record boundaries are. No magic on writing. Every write yields enough LRECL-sized records to hold the data. You don't have to pad the data on a write to a punch/printer. I suppose some effort on text with CRLF vs. binary as-is could be made. > - IUCV network protocol family Just be sure you're hooked into the work already done by Rick, David, et. al. 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
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Oct 12, 2005, at 8:50 AM, Alan Altmark wrote: 88 == minidisk password validation It is actually a proxy-LINK function for multi-client SVMs. It also has logon password and LOGON-BY validation. This could have some value. Logon password and logonby validation would be very useful for me. Think of it as the foundation for pam_vmcp. Adam -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
Carsten Otte wrote: > Alan Altmark wrote: > [snip] > > 4 == examine real storage (CP memory, ie: "hack VM from Linux"!) >>> >>>/dev/mem does that. >> >> >>/dev/mem examines guest memory, not CP. IMO: Dangerous Idea. The ability >>to read CP memory comes with the ability to change it. > > Oh, CP memory not virtual guest storage. Is this fenced for non-privileged > guests? Is there use to debug CP from within a guest like with gdb or so? > I can think of no reason to be able to examine CP real memory from Linux, and I think that doing so would be a terrible security exposure. >>>Would you care to answer the second part of my question for those >>>diagnoses we don't export (yet)? :: >>> >>> 14 == VM spool file manipulation B8 == spool file "XAB" manipulation >> >>These should be accessed via the reader/printer/punch device drivers >>Malcolm write a few years ago, not as diagnose calls. > > In fact we tried to implement a reader filesystem once but gave up because > we could'nt find a good way to map (VM-)records to (Linux-)character > stream. > A clean implementation of a device driver for those seems useful to me. > > And as Adm T. has mentioned, put them someplace where everybody can easily find them, and add functionality so a user space application could be notified (async.) when a file appears on the rdr queue. 88 == minidisk password validation >> >>It is actually a proxy-LINK function for multi-client SVMs. It also has >>logon password and LOGON-BY validation. This could have some value. > > Alan, I don't have the slightest idea on what it does from your explanation. > Can you translate to that to linuxish? What are SVMs? > > So far on my personal "good idea" list: > - reader/punch/printer device driver > - set language support > - IUCV network protocol family > -- > > Carsten Otte > IBM Linux technology center > ARCH=s390 > > -- > 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 -- Dave Jones V/Soft Software, Inc. Houston 281.578.7544 -- 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
mksles9oot (again)
Dumb quick question. I'm trying to add SP2 to my 64 bit install process. In mksles9root, the service packs are listed as: SLES-9-SP-2-s390x-GM-CD1.iso SLES-9-SP-2-s390x-GM-CD2.iso SLES-9-SP-2-s390x-GM-CD3.iso However, as just downloaded from Novell/Suse...where ever, the images are: SLES-9-SP-2-s390x-RC4a-CD1.iso SLES-9-SP-2-s390x-RC4a-CD2.iso SLES-9-SP-2-s390x-RC4a-CD3.iso Fine, looks like a simple rename process. But, in systems, sometimes things are not as easy as they look. Are the RC4a images, the right images? What are the GM images? Which images should I be using? Is it just as simple as rename them (in the proc or the actual iso images themselves)? What is the difference? Is one set, a valid licensed set (for those of us with support contracts) and the other, being the evaluation set? Thanks Tom Duerbusch THD Consulting -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
Carsten Otte wrote: > David Boyes wrote: > >>There seems to be a clear customer requirement for making access to DIAG >>function available. >>The question we're debating is how, not why. The why is a foregone >>conclusion. > > Maybe I missed that part of the thread, but would you mind showing me the > requirement? I mean, couple of diagnoses _are_ exported, and for others > I fail to see what they could be useful for in a Linux application. > > you're correct, Carsten. I see no requirement for making all DIAGs available to Linux, especially in a form that resembles that available to CMS applications. >>If we are to no longer receive management (or any) function added to CMS, we >>need the ability to perform the tasks CMS has traditionally performed within >>the Linux environment. The fundamental problem is to enable all the existing >>architected communication paths between the guest OS and CP in a natural and >>usable manner in Linux. > > Big mistake. You don't get CPs architectured interfaces in Linux userland, you > get Unix/Posix interfaces as you would expect from other *nixes as well. > Running a CMS application requires _porting_ it to the new interface scheme, > which also means reworking its logic to fit that quite different programming > model. > If there is _functionality_ you cannot get today, that's a point where we need > to think about a soloution to get that _functionality_ - not the interface. > > >>Malcolm Beattie has written a VMCF driver (c'mon Malcolm, do the paperwork >>already, OK?). IUCV function is in a usable state from us. DIAG function is >>next. APPC/C-PIC probably next after that. > > IUCV functionality seems useful to me, because that's a network protocol > family which is used in z/VM today. As for the others, I don't know what they > do. > VMCF == virtual machine communications facility. From the CP doc: The Virtual Machine Communication Facility (VMCF) is part of the CP component of VM. VMCF provides virtual machines with the ability to send data to and receive data from any other virtual machine. VMCF is made up of five data transfer functions, seven control functions, a special external interrupt (code X'4001') to asynchronously alert virtual machines to pending messages, and an external interrupt message header to pass control information (and data, at times) to another user. VMCF is implemented by means of functions invoked using the DIAGNOSE instruction code X'68' and a special 40-byte parameter list called VMCPARM. (VMCPARM DSECT is in HCPGPI MACLIB.) A VMCF function is indicated by a particular function subcode in the VMCPFUNC field in the parameter list. VMCF has fallen out of favor over the years but some IBM and vendor products still use it (e.g., Perf ToolKit for z/VM). APPC == Advanced Program to Program communications. APPC is (was?) part of IBM's grand plan called SNA. APPC is also known as LU6.2 > >>For DIAG support, I suggest: >> >>Each DIAG we choose to provide be implemented as a individual driver in >>/dev, with control interfaces presented in /sysfs/zvm/diag/nn/. Example: >>/dev/diag8, with control interface in /sysfs/zvm/diag/8. >> >>Suggestion, using DIAG 8 as an example: >> >>Implemented in all DIAG drivers: >> >>/sysfs/zvm/diag/nn/lock - semaphore to use as a >>reserve/release flag. Processes >> attempt to flock() this file. >>Success indicates acquisition of the >> DIAG nn interface > > This is troublesome as pointed out before: What if your script that has > aquired the lock crashes? > > >>/sysfs/zvm/diag/nn/instance - for DIAGs that could logically >>have multiple sessions >> (not really applicable to DIAG 8, >>but would be a useful generic to have) >> open of the 'instance' file would >>generate a session or instance of the >> desired DIAG, and read from the >>file would return the path of the instance to >> communicate with. If the DIAG does >>not rationally support multiple >> sessions, always return a fixed >>string. > > Not needed. Unix does already have means to represent multiple instances > using one entity: file descriptors. On open(), the kernel can also block users > if specific resource does not allow for multiple sessions at a time (-EBUSY > "device or resource busy", as you see from a tape device when trying to access > it from 2 applications at a time). > > >>Specific to DIAG 8: >> >>/sysfs/zvm/diag/8/cmdstring - the command to be executed >>/sysfs/zvm/diag/8/cprc - the CP return code > > Not safe for multiple parallel sessions, and does'nt fit sysfs purpose. > > >>If process acquires lock on /sysfs/zvm/diag/8/lock (ie flock succeeds), then >>write CP command into cmdstring to prepare for
Re: DIAG
Finishing last sentence... > - IUCV network protocol family Why the need to make IUCV a network device? IUCV is not just a point-to-point beastie, it's a single-application-to-single-application protocol. The fact that it was used to create a network protocol for VM and Linux is because an extra layer to mux and demux application (socket) streams was added. You should think of IUCV as a serial device like a modem (or more like a winmodem). [It probably has a lot in common with the TTY driver.] The intent of the fsiucv driver was to exploit IUCV as it was first created. Having written many IUCV apps over the past 25 years (some of which are still running in a couple of major online systems) I attempted to take the semantics and map them to Linux. The char approach fitted better than a network device. The excellent skb handling routines that allow you to add headers/trailers etc. as you build up the protocol layers is overkill for the base IUCV operation. If I were to build an APPC driver then I'd definitely go the network driver way (FMH5/FMH7 processing is tailored for socket buffers). Like I said, try and look at IUCV as a serial device like a modem. -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSerie s ...]
> - IUCV network protocol family Why the need to make IUCV a network device? IUCV is not just a point-to-point beastie, it's a single-application-to-single-application protocol. The fact that it was used to create a network protocol for VM and Linux is because an extra layer to mux and demux application (socket) streams was added. You should think of IUCV as a serial device like a modem (or more like a winmodem). [It probably has a lot in common with the TTY driver.] The intent of the fsiucv driver was to exploit IUCV as it was first created. Having written many IUCV apps over the past 25 years (some of which are still running in a couple of major online systems) I attempted to take the semantics and map them to Linux. The char approach fitted better than a network device. The excellent skb handling routines that allow you to add headers/trailers etc. as you build up the protocol layers is overkill for the base IUCV operation. If I were to build an APPC driver then I'd definitely go the network driver way (FMH5/FMH7 processing is tailored for socket buffers). Like I said, if -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Oct 12, 2005, at 8:50 AM, Alan Altmark wrote: 14 == VM spool file manipulation B8 == spool file "XAB" manipulation These should be accessed via the reader/printer/punch device drivers Malcolm write a few years ago, not as diagnose calls. Two objections here: 1) Those drivers are not easy to find. They're buried in a supplementary rpm to a fairly obscure redbook, and you have to pick apart the rpm by hand in order to rebuild the ur stuff. 2) They're pretty slow; I imagine the DIAG interface would be a good deal faster. In most normal cases, this is unlikely to be a problem. In the case *we* tried to use it in, which was mail spam/ virus scanning and delivery, the ur device was actually one of the bottlenecks (not, granted, as bad as the content scanning, but still significant). Oh, third objection: 3) I had to poll the machine's spool to see if anything had appeared, because AFAIK, the ur device didn't offer interrupts to say "Hey! Got something new here!" This may have been my own lack of knowledge about how to drive them, though. Adam -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
Alan Altmark wrote: > On Wednesday, 10/12/2005 at 01:56 ZE2, Carsten Otte <[EMAIL PROTECTED]> > wrote: > >>> C8 == CP "set language" function >> >>Afaics that can be done via diag8 as well!? > > > Actually, no. There is no CP SET LANGUAGE command. The diagnose is > useful so that the user's CP responses can be set to match the language in > use by the guest itself (based on locale or something). But it requires > support in the guest. Hm.. yea. Being able to set that would be cool, but the locale idea does'nt work out: there are multiple users and a user can have multiple sessions and the Locales are per session. Nevertheless I think exposing this diagnose would be a good extension. >>> 4 == examine real storage (CP memory, ie: "hack VM from Linux"!) >> >>/dev/mem does that. > > > /dev/mem examines guest memory, not CP. IMO: Dangerous Idea. The ability > to read CP memory comes with the ability to change it. Oh, CP memory not virtual guest storage. Is this fenced for non-privileged guests? Is there use to debug CP from within a guest like with gdb or so? >>Would you care to answer the second part of my question for those >>diagnoses we don't export (yet)? :: >> >>> 14 == VM spool file manipulation >>> B8 == spool file "XAB" manipulation > > These should be accessed via the reader/printer/punch device drivers > Malcolm write a few years ago, not as diagnose calls. In fact we tried to implement a reader filesystem once but gave up because we could'nt find a good way to map (VM-)records to (Linux-)character stream. A clean implementation of a device driver for those seems useful to me. >>> 88 == minidisk password validation > > It is actually a proxy-LINK function for multi-client SVMs. It also has > logon password and LOGON-BY validation. This could have some value. Alan, I don't have the slightest idea on what it does from your explanation. Can you translate to that to linuxish? What are SVMs? So far on my personal "good idea" list: - reader/punch/printer device driver - set language support - IUCV network protocol family -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
David Boyes wrote: >>I agree with Martin that its not feasible to support a diag >>pass-through. > > > There seems to be a clear customer requirement for making access to DIAG > function available. > The question we're debating is how, not why. The why is a foregone > conclusion. > > Making a "generic" /dev/diag is not practical. Presenting DIAG function in > another way is. See below. > > >> In most cases I have no idea, why >>do you need this diagnose in Linux. So lets go one step >>further and find out: >> >>"What problems or scenarios do we want to solve WITHIN linux?" > > > Please, let's not get bogged down in scenario thrashing. We get enough of > that from IBM SWG. At a high level, what we're trying to accomplish is: > > If we are to no longer receive management (or any) function added to CMS, we > need the ability to perform the tasks CMS has traditionally performed within > the Linux environment. The fundamental problem is to enable all the existing > architected communication paths between the guest OS and CP in a natural and > usable manner in Linux. > I think that's a big "if".I don't believe that IBM has ever made the statement that CMS is "functionally stabilized", although I may have missed it. We are getting new CMS-based management tools and features from IBM now (e.g., Operations Manager, Archiver), and CMS PIPELINES is certainly being enhanced and extended now. While I am in favor of integrating, where possible, virtual Linux guests more closely to both CP and CMS, I don't want to see the (limited?) resources IBM has available spent on reinventing the CMS wheel in Linux. We don't need all the features that CMS now offers to be re-invented in the Linux environment; we need the unique features that Linux brings to the table built upon and expanded. As we've seen with the recent DIAG discussion, some problems are more easily solved in the (simpler, single user) CMS environment than in the more complex Linux one. As Rob van der Heij comments in another post, we don't need the ability in Linux to be able to write a CP directory management product... > Malcolm Beattie has written a VMCF driver (c'mon Malcolm, do the paperwork > already, OK?). IUCV function is in a usable state from us. DIAG function is > next. APPC/C-PIC probably next after that. > Even though VMCF has been displaced by the newer and more efficient IUCV function, it still has its uses. As David says, c'mon Malcolm, go talk to the lawyers.:-) > For DIAG support, I suggest: > > Each DIAG we choose to provide be implemented as a individual driver in > /dev, with control interfaces presented in /sysfs/zvm/diag/nn/. Example: > /dev/diag8, with control interface in /sysfs/zvm/diag/8. > > Suggestion, using DIAG 8 as an example: > > Implemented in all DIAG drivers: > > /sysfs/zvm/diag/nn/lock - semaphore to use as a > reserve/release flag. Processes > attempt to flock() this file. > Success indicates acquisition of the > DIAG nn interface > /sysfs/zvm/diag/nn/instance - for DIAGs that could logically > have multiple sessions > (not really applicable to DIAG 8, > but would be a useful generic to have) > open of the 'instance' file would > generate a session or instance of the > desired DIAG, and read from the > file would return the path of the instance to > communicate with. If the DIAG does > not rationally support multiple > sessions, always return a fixed > string. > > Specific to DIAG 8: > > /sysfs/zvm/diag/8/cmdstring - the command to be executed > /sysfs/zvm/diag/8/cprc - the CP return code > > If process acquires lock on /sysfs/zvm/diag/8/lock (ie flock succeeds), then > write CP command into cmdstring to prepare for call. Once parameters are > loaded, open of /dev/diag8 and write a 1 to /dev/diag8 to execute the > preloaded command. Result of command is read from /dev/diag8 to EOF. Process > should close /dev/diag8 on EOF. Process can then load a new command into > /sysfs/zvm/diag/8/cmdstring and repeat, or release the lock. When process is > finished with the DIAG 8 interface, funlock /sysfs/zvm/diag/8/lock. > > Individual DIAGs can have their own variables in /sysfs/zvm/diag/nn as > appropriate. The lock mechanism is simple to implement in arbitrary > languages (works trivially in Fortran -- my favorite test), and is general > enough to accommodate arbitrary DIAGs. > > Once that basic structure is in place, then generating the individual > /dev/diag drivers are a plug-n-chug problem. > > APPC is harder. I've got code for it, but I don't think I'll be giving it > away. > Isn't the APPC protocol proprietary to IBM? > -- db > > -
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
David Boyes wrote: > There seems to be a clear customer requirement for making access to DIAG > function available. > The question we're debating is how, not why. The why is a foregone > conclusion. Maybe I missed that part of the thread, but would you mind showing me the requirement? I mean, couple of diagnoses _are_ exported, and for others I fail to see what they could be useful for in a Linux application. > If we are to no longer receive management (or any) function added to CMS, we > need the ability to perform the tasks CMS has traditionally performed within > the Linux environment. The fundamental problem is to enable all the existing > architected communication paths between the guest OS and CP in a natural and > usable manner in Linux. Big mistake. You don't get CPs architectured interfaces in Linux userland, you get Unix/Posix interfaces as you would expect from other *nixes as well. Running a CMS application requires _porting_ it to the new interface scheme, which also means reworking its logic to fit that quite different programming model. If there is _functionality_ you cannot get today, that's a point where we need to think about a soloution to get that _functionality_ - not the interface. > Malcolm Beattie has written a VMCF driver (c'mon Malcolm, do the paperwork > already, OK?). IUCV function is in a usable state from us. DIAG function is > next. APPC/C-PIC probably next after that. IUCV functionality seems useful to me, because that's a network protocol family which is used in z/VM today. As for the others, I don't know what they do. > For DIAG support, I suggest: > > Each DIAG we choose to provide be implemented as a individual driver in > /dev, with control interfaces presented in /sysfs/zvm/diag/nn/. Example: > /dev/diag8, with control interface in /sysfs/zvm/diag/8. > > Suggestion, using DIAG 8 as an example: > > Implemented in all DIAG drivers: > > /sysfs/zvm/diag/nn/lock - semaphore to use as a > reserve/release flag. Processes > attempt to flock() this file. > Success indicates acquisition of the > DIAG nn interface This is troublesome as pointed out before: What if your script that has aquired the lock crashes? > /sysfs/zvm/diag/nn/instance - for DIAGs that could logically > have multiple sessions > (not really applicable to DIAG 8, > but would be a useful generic to have) > open of the 'instance' file would > generate a session or instance of the > desired DIAG, and read from the > file would return the path of the instance to > communicate with. If the DIAG does > not rationally support multiple > sessions, always return a fixed > string. Not needed. Unix does already have means to represent multiple instances using one entity: file descriptors. On open(), the kernel can also block users if specific resource does not allow for multiple sessions at a time (-EBUSY "device or resource busy", as you see from a tape device when trying to access it from 2 applications at a time). > > Specific to DIAG 8: > > /sysfs/zvm/diag/8/cmdstring - the command to be executed > /sysfs/zvm/diag/8/cprc - the CP return code Not safe for multiple parallel sessions, and does'nt fit sysfs purpose. > If process acquires lock on /sysfs/zvm/diag/8/lock (ie flock succeeds), then > write CP command into cmdstring to prepare for call. Once parameters are > loaded, open of /dev/diag8 and write a 1 to /dev/diag8 to execute the > preloaded command. Result of command is read from /dev/diag8 to EOF. Process > should close /dev/diag8 on EOF. Process can then load a new command into > /sysfs/zvm/diag/8/cmdstring and repeat, or release the lock. When process is > finished with the DIAG 8 interface, funlock /sysfs/zvm/diag/8/lock. > > Individual DIAGs can have their own variables in /sysfs/zvm/diag/nn as > appropriate. The lock mechanism is simple to implement in arbitrary > languages (works trivially in Fortran -- my favorite test), and is general > enough to accommodate arbitrary DIAGs. > > Once that basic structure is in place, then generating the individual > /dev/diag drivers are a plug-n-chug problem. I really feel uncomfortable with that approach because it does not fit the unix model at all. Also the overall idea of running CMS applications in Linux instead of porting them seems queer for me. I don't think you will be able to integrate such thing into the vanilla kernel. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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/
Re: Temporarily adding DASD to SLES 9 systems
Ok. Thanks. I thought the chccwdev thing was all I really needed but wasn't 100% certain. I went forward using that as the replacement to echoing a command request ala sles 8 and it all was fine. Must say the device detection/allocation is much improved in SLES 9. "Post, Mark K" <[EMAIL PROTECTED] m> To Sent by: Linux on LINUX-390@VM.MARIST.EDU 390 Port cc <[EMAIL PROTECTED] IST.EDU> Subject Re: Temporarily adding DASD to SLES 9 systems 10/11/2005 04:43 PM Please respond to Linux on 390 Port <[EMAIL PROTECTED] IST.EDU> I wouldn't think there are any "gotchas," per se. The only thing you need to be aware of is the chccwdev command to bring the new volumes online after they've been attached or linked to the guest. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of James Melin Sent: Tuesday, October 11, 2005 12:44 PM To: LINUX-390@VM.MARIST.EDU Subject: Temporarily adding DASD to SLES 9 systems If one wants to add a couple volumes to reduce the footprint in cyl of a couple volumes that were re-sized incorrectly what is the best way to do that? Had it down pat in SLES 8 Anyway looking to bring 2 3000 cyl volumes in to replace a 8000 and 5000 cyl volume respectively, temporarily as devs 211 and 281, copy devs 201 and 280 to 211 and 281 via the procedure on the linuxvm.org website then so all the needed things like zipl etc, and then change the guest definition to get rid of the old 201 and 280 and reassign 211 and 281 as 201 and 280 respectively. Any gotchas in how to do this on sles 9? -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Wednesday, 10/12/2005 at 01:56 ZE2, Carsten Otte <[EMAIL PROTECTED]> wrote: > > C8 == CP "set language" function > Afaics that can be done via diag8 as well!? Actually, no. There is no CP SET LANGUAGE command. The diagnose is useful so that the user's CP responses can be set to match the language in use by the guest itself (based on locale or something). But it requires support in the guest. > >4 == examine real storage (CP memory, ie: "hack VM from Linux"!) > /dev/mem does that. /dev/mem examines guest memory, not CP. IMO: Dangerous Idea. The ability to read CP memory comes with the ability to change it. > Would you care to answer the second part of my question for those > diagnoses we don't export (yet)? :: > > 14 == VM spool file manipulation > > B8 == spool file "XAB" manipulation These should be accessed via the reader/printer/punch device drivers Malcolm write a few years ago, not as diagnose calls. > > A0 == ACI group (and ESM detection) What would Linux would do differently based on the results? The only proper use for ACIGROUP is its use in the construction of [privileged] RACROUTE calls. But since there's no RACROUTE for Linux > > D4 == alternate VM user (spool file origin and IUCV ID) Not good for a multitasking multiple-CPU environment. > > 3C == activate CP directory (after written to disk) Since the object directory is not a programming interface, it wouldn't be appropriate for Linux to be swapping directory pointers. > > 84 == CP Dir "update in place" (not written to disk) Also not a good idea. Leave directory management to the directory managers. > > 88 == minidisk password validation It is actually a proxy-LINK function for multi-client SVMs. It also has logon password and LOGON-BY validation. This could have some value. > > 34 == system dump reader DUMPLOAD in Linux? Ew > > E4 == minidisk info and "full pack overlay" I'm having trouble with this one, too. 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
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
> I agree with Martin that its not feasible to support a diag > pass-through. There seems to be a clear customer requirement for making access to DIAG function available. The question we're debating is how, not why. The why is a foregone conclusion. Making a "generic" /dev/diag is not practical. Presenting DIAG function in another way is. See below. > In most cases I have no idea, why > do you need this diagnose in Linux. So lets go one step > further and find out: > > "What problems or scenarios do we want to solve WITHIN linux?" Please, let's not get bogged down in scenario thrashing. We get enough of that from IBM SWG. At a high level, what we're trying to accomplish is: If we are to no longer receive management (or any) function added to CMS, we need the ability to perform the tasks CMS has traditionally performed within the Linux environment. The fundamental problem is to enable all the existing architected communication paths between the guest OS and CP in a natural and usable manner in Linux. Malcolm Beattie has written a VMCF driver (c'mon Malcolm, do the paperwork already, OK?). IUCV function is in a usable state from us. DIAG function is next. APPC/C-PIC probably next after that. For DIAG support, I suggest: Each DIAG we choose to provide be implemented as a individual driver in /dev, with control interfaces presented in /sysfs/zvm/diag/nn/. Example: /dev/diag8, with control interface in /sysfs/zvm/diag/8. Suggestion, using DIAG 8 as an example: Implemented in all DIAG drivers: /sysfs/zvm/diag/nn/lock - semaphore to use as a reserve/release flag. Processes attempt to flock() this file. Success indicates acquisition of the DIAG nn interface /sysfs/zvm/diag/nn/instance - for DIAGs that could logically have multiple sessions (not really applicable to DIAG 8, but would be a useful generic to have) open of the 'instance' file would generate a session or instance of the desired DIAG, and read from the file would return the path of the instance to communicate with. If the DIAG does not rationally support multiple sessions, always return a fixed string. Specific to DIAG 8: /sysfs/zvm/diag/8/cmdstring - the command to be executed /sysfs/zvm/diag/8/cprc - the CP return code If process acquires lock on /sysfs/zvm/diag/8/lock (ie flock succeeds), then write CP command into cmdstring to prepare for call. Once parameters are loaded, open of /dev/diag8 and write a 1 to /dev/diag8 to execute the preloaded command. Result of command is read from /dev/diag8 to EOF. Process should close /dev/diag8 on EOF. Process can then load a new command into /sysfs/zvm/diag/8/cmdstring and repeat, or release the lock. When process is finished with the DIAG 8 interface, funlock /sysfs/zvm/diag/8/lock. Individual DIAGs can have their own variables in /sysfs/zvm/diag/nn as appropriate. The lock mechanism is simple to implement in arbitrary languages (works trivially in Fortran -- my favorite test), and is general enough to accommodate arbitrary DIAGs. Once that basic structure is in place, then generating the individual /dev/diag drivers are a plug-n-chug problem. APPC is harder. I've got code for it, but I don't think I'll be giving it away. -- 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
Re: Problem Tracking Systems (Was: Problems building gcc 3.4.0)
An excellent CMS based problem tracking and reporting tool is Cornell University's PROBLEM system. It was developed in the early 1990s by Andrew Hanushevsky and has a ton of sophisticated features. There's a web interface available as well. Drop me a note off-list if you'd like a copy. Support is available as well. Post, Mark K wrote: > Mantis, and TUTOS might be worth a look. > > > Mark Post > > -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > Eric Chevalier > Sent: Tuesday, October 11, 2005 5:37 PM > To: LINUX-390@VM.MARIST.EDU > Subject: Problem Tracking Systems (Was: Problems building gcc 3.4.0) > > > Once again, I'd like to thank David Boyes, Mark Post and Adam Thornton > for your suggestions to forget about the Marist file system and install > a supported Linux release. I decided to go with Debian's mainframe > distro, and that has worked out well. Much better than trying to roll my > own system! > > Our shop is looking at replacing a home-grown problem/bug tracking > system. One of the reasons we decided to put up a Linux system was to > have a platform that would allow us to evaluate some of the open-source > packages that are available in this area. We now have Bugzilla, Gnats > and Trac installed on the system, and our user community is actively > giving all three some pretty good test drives. > > Are there any other systems which you folks might suggest that we take a > look at? > > Thanks in advance! > Eric > > -- > 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 -- Dave Jones V/Soft Software, Inc. Houston 281.578.7544 -- 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
2005-10-12 Recommended Linux on zSeries code drop to developerWorks
Please refer to: http://www.ibm.com/developerworks/linux/linux390/whatsnew.html for the 2005-10-12 change summary: > New OCOs for Red Hat: - tape_3590 for Red Hat Enterprise Linux 4 Update 2 (31-bit and 64-bit) kernel 2.6.9-22.EL (2005-10-05) Happy downloading! * end of message Mit freundlichem Gruß / Kind regards, Gerhard Hiller eServer Software Management, D4357 IBM Development Lab, Boeblingen/Germany Phone ext. +49-(0)7031 - 16 - 4388 Internet: [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
China Awards 140k Desktop Linux Rollout
China Awards 140k Desktop Linux Rollout http://www.outsourcingpipeline.com/news/171204321 -- Dave Jones V/Soft Software, Inc. Houston 281.578.7544 -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
Rick Troth wrote: > On Tue, 11 Oct 2005, Carsten Otte wrote: >>Which concrete diagnose codes do you think are useful to >>be called from Linux userspace different from diag8? > > > That's a terrific question, Carsten!! Thanks. > Some concrete useful diagnose codes would be: > >0 == extended system ID Exported via /proc/sysinfo. >8 == virtual console function (our current fuss) Exported via vmcp or cpint. > C8 == CP "set language" function Afaics that can be done via diag8 as well!? >4 == examine real storage (CP memory, ie: "hack VM from Linux"!) /dev/mem does that. > 24 == device info (deprecated, use DIAG 210 instead) > 210 == device info (both 24 and 210 supported by CMS REXX) This information is retrieved by our common IO layer and exported via sysfs. > 8C == 3270 device info Which of that functionality is missing on raw3270 access? Would you care to answer the second part of my question for those diagnoses we don't export (yet)? :: > 14 == VM spool file manipulation > B8 == spool file "XAB" manipulation > A0 == ACI group (and ESM detection) > D4 == alternate VM user (spool file origin and IUCV ID) > 3C == activate CP directory (after written to disk) > 84 == CP Dir "update in place" (not written to disk) > 88 == minidisk password validation > 34 == system dump reader > E4 == minidisk info and "full pack overlay" What use case do you see for that diagnose codes? What problem do you want to solve by calling them? -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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: procfs [was DIAG ]
John Summerfied wrote: > --w--- 1 root root 4096 Oct 12 08:02 > class/pcmcia_socket/pcmcia_socket0/card_eject PCMCIA socket is an excellent example for what /sys is useful: once you plug your card, you'll see it connected to that socket there just as you do see a qeth card connected to 3 subchannels on the mainframe. I fail to see your proposed connection to diag8, and which attributes one would modify on it (power state, online/offline and such does'nt apply). -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
John Summerfied wrote: > Rick Troth wrote: > >> 218 == real CPU ID info (for licensing, if nothing else) > > > In my ignorance, I'd expect to see that in /proc/cpuinfo Isn't that what cpuinfo displays today? If no, how does it differ? -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Rick Troth wrote: > Lock the file. > Or have the device driver enforce single access. But why lock? CP can handle multiple parralel diag8 calls from different processors just fine, and if the Linux userspace interface is done proper there is no race-issue at all. File locking is limited to super user "root" versus the existing implementation allows root to specify who can issue CP commands [default: only root is allowed to issue CP commands]. And what if a malfunctioning program does flock() and then ends up in an endless loop? That would leave the file locked and the diag8 service would be unavailable. All those issues don't exist with the current implementation. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
McKown, John wrote: > This is likely a foolish question, but could the /sys/devices/diagnose > be set up like the /dev/fd ? E.g. for pid 12345, there exists an entire > tree /sys/devices/diagnose/12345. Then have "self" as a symlink to the > current pid so that for any particular pid, it could reference > /sys/devices/diagnose/self/... It might even be possible to "interlock" > on /sys/devices/diagnose/self/8/command so that you could not cat to it > a second time until you had read /sys/devices/diagnose/self/8/status or > maybe even 'echo "1">/sys/devices/diagnose/self/8/active' where that > pseudo-file gets changed to "0" when ../command is written to you cannot > again write a line to ../command until you write a "1" to ../active (or > something to that effect). Hope this makes sense. I'm not a kernel type > person. Sounds terrible & complicated to me. What's wrong with the existing soloution with vmcp? It's safe against races _because_ it splits the whole thing into a userspace program that keeps an open file handle and a kernel component that can identify subsequent calls by that handle. I don't really get where the problem with that one is, could you elaborate where you see the issue? -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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
Adam Thornton wrote: > I don't know if this would be considered an abuse of sysfs, but, > presuming that you'd have something like > > /sys/devices/diagnose > > Then for this you could just > > cat /sys/devices/diagnose/8/status > > In the same directory, you could have buffer_size, command, and so > forth. That would be limited to a single user as far as I can see. What if script A wants to set buffer size to 1024 then execute its favorite command while script B wants to set buffer size to 4096 then execute its command? This is racy! -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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: procfs [was DIAG ]
John Summerfied wrote: > > The nice thing about /proc and (apparently) /sys is that one can, at a > pinch, control many functions by simply reading with cat and writing > with echo. There are several things particular to my Toshiba laptop that > I can control in this way, and if I can do that then I can write a > script to automate something (eg choosing runlevel based on which of > three buttons is used to boot the computer). I recall previous > discussion on controlling DASD devices using similar entries (in /proc), > and one commonly sees advice to turn (network) forwarding on or off > using "echo >/proc/sys/net/ipv4/ip_forward 1" The cat&echo tactics is dangerous because it is racy: you echo your command into it. Becuase the file descriptor is closed between cat&echo, someone else may issue a different command or read your result before you cat the procfile. That cannot happen with the vmcp way to handle it, you'll always see _your_ response. -- Carsten Otte IBM Linux technology center ARCH=s390 -- 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: IP Networks survive disasters?
> -Original Message- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of John Summerfied > Sent: Wednesday, October 12, 2005 12:24 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: IP Networks survive disasters? > > We have no public IP addresses on our side of the gateways, > so we can simplify the network to one Linux box, two gateways. > > If someone sends us mail and opens a connexion to > gw1.example.edu for that purpose, will my Linux stack keep > the conversation on gw1, or might some packets go out via > gw2? Routing is determined on a packet by packet basis, so it is technically possible for packets to travel over both paths if there were to be physical connectivity changes in between packets that was reflected in the routing tables. In most cases routing doesn't change *that* often, but it does happen. It's going to depend on how rapidly your routing protocol can propagate changes in topology. > I can't imagine _that_ working, so do we need some > public IP addresses internally? Actually, it does work (and rather well). TCP connections are stateful and are above the packet level, so as long as the endpoints have *some* path active, the TCP connection will stay up. TCP is responsible for retransmission if a packet goes lost or missing, so if the network topology changes out from under a TCP session, TCP is required to retransmit a lost packet if it does not get an explicit ACK. That retransmission will automagically take the path available in the routing table *at the time of transmission*, so in a situation where you have rapidly changing topology (and if your routing protocol can keep up), the packets will flow over both paths. So, provided your Linux system's IP address (or the outside address of the NAT gateways you're using) is still reachable by some means, you do not need public addresses inside your network. You may need more sophisticated NAT (eg NSRP + NAT) to preserve connection state, but it should still work. -- 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: IP Networks survive disasters?
A couple of months back we had a network outage in New Zealand. It turned out that someone in the capital had dug through one set of TelecomNZ's cables with a hole digger, and a rat had eaten the backup. Since TelecomNZ owns about 85 % of the NZ telecom capacity, that was most of the nation inconvenienced for over half a day until they got it fixed. And the only outfit, TelstraClear, that could've given much-needed peering backup service, had previously de-peered, thus depriving themselves of both a much-needed public boost of their status, and the economic fruits of stepping in when needed. Stupidity's gratuitous, stupidity's universal. Wesley Parish On Wed, 12 Oct 2005 05:15, Tom Duerbusch wrote: > It seems to me, that back in the '60s or so, IP was developed as a > communications method that can survive disasters. The disaster planned > for was nuclear warfare. Automatic routing was suppose to reroute > packets to the proper destination if there was still any communication > lines to that destination. > > Just where did we go wrong? > > I'm sitting here waiting for the network types to do some routing to > the new IP addresses they assigned to our IFL. Still nothing. Not that > it is high priority in their books, but wasn't this suppose to be > automatic? > > How can IP communications survive a nuclear bomb if we can't do it > within the same machine room? > > Perhaps survivability was a myth. > Perhaps it is money. Perhaps it costs too much to do it right when, > locally, there isn't a payback. > Perhaps doing it right puts too much of a workload on the network. > > We no longer have hubs. Everything has been replaced by switches. In > the City wide WAN, there is about 4,000 PCs, 500 printers, some 600 > servers, in competing departements with no single person in charge of > everything. (The City of St. Louis is also it's own County, not to be > confused with St. Louis County...that is another County ) So some of > this mess may be our own doing, either by some departement/division > going off on their own, or us trying to protect everyone from > departments/divisions that went out on their own. > > Or maybe, that is just not how IP networks work anymore. If so, I > didn't get the memo. > > So, my question is... > > In most shops, can you just plug in and it works? Or is it more like > the SNA world, where you had to wait for me to do the NCP gens and bring > it up and test and? > > Just frustrated... > > Tom Duerbusch > THD Consulting > > -- > 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 -- Clinersterton beademung, with all of love - RIP James Blish - Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people. -- 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
IP port range
Is it possible to force z/OS USS NFS client to use only restricted ports? I have to mount some NFS exports from z/Linux and I'd like to avoid using insecure flag in /etc/exports and I don't want to have nfsd message (connect from unprivileged port) whenever a client connects. Thanks: István -- 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: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
> Alan (Cox), Martin is right. The DIAG interface is complicated > and varies from one DIAG code to the next and requires "guest real" > addressing, which for Linux is kernel space. (And since CMS > has a flat addressing model, it can use pretty much any DIAG > function without pointer pains like Linux would suffer from.) Rick, I agree with Martin that its not feasible to support a diag pass-through. I have also seen your list of diagnoses which you consider interesting. In most cases I have no idea, why do you need this diagnose in Linux. So lets go one step further and find out: "What problems or scenarios do we want to solve WITHIN linux?" If we agree on the problem, we can then think about the solution and the appropriate abstraction. -- Mit freundlichen Grüßen / Best Regards / Un cordial saludo Christian Bornträger Linux Software Engineer zSeries Linux & Virtualization IBM Deutschland Entwicklung GmbH email: [EMAIL PROTECTED] Tel +49 7031 16 1975 -- 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
> Spin ... if the open() fails because of EBUSY, > then wait some fraction of a second and try again. > Or fail immediately with a "the hypervisor is busy". > If after a wait and re-try it fails again, then fail > with the busy error message, or wait a second interval. > > This is not rocket science. > It's not elegant either, but functional. No, imagine one of your automatic system maintenance scripts crashes for some reason. Then you have to solve the "vmcp is locked" situation manually or implement a "steal lock" method - ugly. I think, that the command/return code query should be as atomic as possible to prevent concurrent vmcp calls from disturbing each other. I think for application programmers this is quite simple, they can always use the device node, which guaqrantees to separate each call from others. The only open question is, how to solve our needs in scripts. I still like the stderr method, but will discuss this question with some colleagues if we can think of a better method. -- Mit freundlichen Grüßen / Best Regards / Un cordial saludo Christian Bornträger Linux Software Engineer zSeries Linux & Virtualization IBM Deutschland Entwicklung GmbH email: [EMAIL PROTECTED] Tel +49 7031 16 1975 -- 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
