Bug#504878: Support for 3215 console in zipl
I just did a little more research and discovered that a 3215 doesn't support the sense id command; so scanning the subchannels looking for it won't work. But here's what you can do: 1. Determine if you are running under VM. Do this by executing a STIDP instruction. If the first byte of the CPU id is X'FF', then you are running under VM, otherwise not. 2. If running under VM, issue the following CP command via DIAG X'8', with output directed to a buffer. QUERY VIRTUAL CONSOLE Parse the command output to determine the subchannel number and device type of the virtual console. There can only be one virtual console. If there is no virtual console, or if the virtual console is device type 3270, use the SCLP interface that you are currently using. 3. If the virtual console is device type 3215, then enable the corresponding subchannel, if necessary. (STSCH, turn on enable bit, MSCH). 4. Write out the boot menu and read the user's reply using S/390 I/O to the 3215 console. The following channel commands should suffice: X'01' WRITE NO RETURN X'03' NOP X'04' SENSE X'09' WRITE WITH RETURN X'0A' READ X'0B' ALARM I believe that the SCLP interface is designed to emulate a 3215; so it shouldn't be too hard. The interface, of course, is quite different (SSCH and I/O interruptions vs. SERVC and external interruptions). -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
z/VM 5.3 SSL Server using Debian GNU/Linux
I am a z/VM systems programmer by profession. My job is to install and maintain z/VM at my installation. We currently run z/VM 5.3. One of my tasks is to provide a TLS/SSL-secured FTP server and TELNET 3270 server for our VM system. To do so requires first configuring an SSL server (virtual machine SSLSERV by default). Under z/VM 5.3, this means creating a virtual Linux server to run on the SSLSERV virtual machine. (I've heard rumors that plans are to eliminate this requirement in a future release, but under 5.3 this is a requirement.) The problem is, IBM only supports their SSL-related code on two specific distribution/release combinations of Linux: Redhat Enterprise Linux AS4 U4 (kernel version 2.6.9-42.EL) SuSE SLES 9 (kernel version 2.6.5-7.244) And that's it. These are both commercial distributions. I wondered if I could get it to work with Debian. Well, to make a long story short, I did. Of course, it's unsupported by IBM. And there is no official support for Debian in any case, except by third parties. And it's certainly not supported by me. But it does seem to work. I have created detailed instructions for how to set up a z/VM 5.3 SSL server using Debian. But I don't know what to to with them. I don't have a web site of my own to post it on, and my employer is a government agency and we don't do that sort of thing here. Is anybody interested? Does anyone have a suggestion about where this kind of information could or should be posted? IBM's z/VM web site is not an option. IBM won't post anything like that without proof of authorship, signing releases, permission from my employer, etc. (Have you ever tried to get permission from the government to do something not covered in the policies and procedures manual?) A typical Linux HOWTO doesn't seem appropriate either, since it has a limited target audience and is distribution-specific. Ideas anyone? -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499833: chccwdev cannot set device offline in Lenny
Package: s390-tools Version: 1.6.2-1 This works just fine in Etch, but fails in Lenny. A device cannot be taken offline dynamically. In my case, I have a separate dasd device for use as a boot partition. The device number is 0201, which Linux references as 0.0.0201. The device node name for this device is /dev/dasdb. The device has a single partition, /dev/dasdb1, is formatted using the ext3 file system, and is mounted as /boot in /etc/fstab. The device normally uses the dasd_diag_mod driver, but in order to get zipl to work, I have to switch to the dasd_eckd_mod driver. The following sequence of commands (logged in as root) is what I normally use in Etch with my custom kernel: umount /boot echo 0 /sys/bus/ccw/devices/0.0.0201/online echo 0 /sys/bus/ccw/devices/0.0.0201/use_diag echo 1 /sys/bus/ccw/devices/0.0.0201/online mount -t ext3 /dev/dasdb1 /boot . . invoke zipl (or update-initramfs, or aptitude dist-upgrade, or whatever) . umount /boot echo 0 /sys/bus/ccw/devices/0.0.0201/online echo 1 /sys/bus/ccw/devices/0.0.0201/use_diag echo 1 /sys/bus/ccw/devices/0.0.0201/online mount -t ext3 /dev/dasdb1 /boot When I do this under recent versions of Lenny, though, the device never goes offline, as verified by cat /sys/bus/ccw/devices/0.0.0201/online which still shows 1 after supposedly setting the device offline. Another way of telling is to issue cat /proc/dasd/devices which still shows the device online using the original DIAG driver. I tried using chccwdev -d 0.0.0201 also, and it says that it did it, but in reality nothing has changed. The device is still online. Just for grins, I tried setting a device offline dynamically which was using the ECKD driver, but that doesn't work either. Kernel is stock Lenny kernel linux-image-2.6.24-1-s390, Version 2.6.24-7. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
