Thanks to John and others for advice
and extra special thanks to Leland for contributed code. Nice work!
CMS FS 1.1.8 supports loopback mount.
This means that you can have an image of an EXT2 filesystem
on a CMS minidisk and mount it with "-o loop". Very exciting.
As always, no warranty sta
I'm looking for a generic way to find the size of a block special.
To determine the size of a regular file, we use stat() or fstat().
But how does one determine the size of a partition? Both stat()
and fstat() return zero length (Solaris says the st_blocks field
is indeterminate) for a block s
I found out, to my dismay, that the CMS FS driver
lacks needed functionality for 'mount -o loop' to work.
What I mean is that you cannot at this time have an EXT2 FS image
on a CMS minidisk and mount that with "-o loop". You can *copy*
the FS image file to another filesystem, so I know it's
> V=R - then why run under VM at all? As an old MVS production hand,
> I have to at least smirk at that ;)
As an old VM hand, I can understand the why,
though I doubt I will succeed in conveying it. But here goes.
I see little value in LPAR other than marketting:
"it's a hardware feecher, so
I can hear Bitner now: "it depends".
-- R;
...
> been receiving a lot of rejection messages for mail I've not sent
...
At home I've been hit by the "you're on a dial-up" type bounce.
Not true, but I'm small enough to have no means to fight it.
Eventually I will have to get an msn.net account to do e-mail.
It seems right and just: we
FYI, for those who care about such things,
this list is being tracked by http://www.mail-archive.com/.
Sorry for the duplicate info if this was mentioned before.
Why should you care?
Such tracking is easy fodder for e-mail address harvesters. BAD
Tracking services make web search of the list e
> http://www.observer.co.uk/business/story/0,6903,982275,00.html
Thanks, Phil, for posting that.
I cannot help but notice this bit in the article:
> Another interesting aspect of the Munich decision is that it was
> not driven simply by cost savings, because industry gossip has it
> that Ballm
Thanks for the kudos, y'all.
I am blessed to have such gracious friends.
For the record, Rick did not attend Rice, but was employed there.
Rick's degree is from Texas A&M, as is (as Dr. Boyes mentioned) VNIX.
The UTSGlobal folks might enjoy this: VNIX was done first with UTS
on Amdahl hard
What WINE does is intercept the Windows system calls.
(gross simplification) WINE runs on any x86 Unix because they
share the same instruction set. The Windows programs execute
whatever x86 code they contain, but when a system call is made
it traps to WINE and is handled with Unix resouces.
W
Oh ... and you will want to run a 'getty' on the 62x tubes.
Sign on to Linux that way, and there will be a /dev/ttyxx
as well as a /dev/tubxx for your session.
> ned is supported only on 3270 terminals
The problem you encountered is that Linux doesn't see a 3270
for the connection you are using.
I recommend you define a half dozen virtual GRAFs (as root)
hcp DEF GRAF 620
hcp DEF GRAF 621
hcp DEF GRAF 622
hcp DEF GRAF 623
on your Linux guest. (Above commands issued from the shell.)
Then when usint TN3270 (or X3270, or whatever 3270 emulator you like)
ra
On Tue, 17 Jun 2003, Tzafrir Cohen wrote:
> Why xdmcp? This means that thy have to run the whole X desktop on the
> server. This means much more traffic on the network. Why not let them
> run just the programs they need?
Oh, I quite agree!
But I got the impression from the thread and Tom's questi
> Is taking 20% of an H30 processor just to keep it idling.
I use VNC all the time on my PC based X desktop.
I do not see the high idle time. But there may be one or two
processes started by KDE that are not completely happy with VNC.
VNC does lack certain extensions that KDE wants.
There may b
Tom ...
The semantics break down. Not sure I'll do any better, but here goes!
Client and server terminology is often reversed in X speak.
I'll repeat this below. And a lot of this you know already.
VNC gives you what-appears-to-be a bitmapped display.
X clients connect to that. But there's
> Umm, no. That's what started this whole thread. Mainframe clocks
> drift as much as, if not more than, PC clocks, ...
Uhh... okay, well then I may be sorry for what I just posted.
See my other note about the [X]NTPD drift file. Why would that be
better on the mainframe? (Even on VM whe
I note that the zSeries clock is (800, 900, even 9672s)
is awfully accurate compared to even the newest PCs.
(Have not compared it to Sun or HP mid-range hardware.)
I'm talking about watching the drift file NTPD maintains.
It goes below 1.000 on the mainframe. Not seen that elsewhere.
I mention
Well ... it's a little messy. Could be more than I'm suspecting.
> ../../gcc-3.3/gcc/tsystem.h:75:23: sys/types.h:
> No such file or directory
> ../../gcc-3.3/gcc/tsystem.h:78:19: errno.h:
> No such file or directory
Missing kernel headers?
Looks like
> > Unlike other internet packages, there is no configure script.
> > (Big hint to Neale. Even just a dummy.)
>
> Why?
Because I would like to treat CPINT the same as
the bazillion other packages I use when I [re]build Linux.
A dummy configure script is harmless
and leaves the door open for cha
> When module versioning is being used, there are files that keep track
> of what symbols get what mangled names in ./include/linux/modules/,
> as well as ".stamp" files that are generated by the "make dep" process.
> To get these files regenerated with the correct information,
> I needed to delete
Steve ...
Linux/390 will synch time with NTP
just as effectively as Linux on a PC will.
VM does not benefit from this (but is not harmed by it).
I have *not* found NTP to be a resource hog; in fact, it is
designed to be kind of low impact. (Seems to sleep a lot
waiting for time to pass and th
> And under VM, of course, the translation should follow the 3215 HW
> capabilities, requiring at least as many kernel tables as there could
> be legitimate "consoles" for it to talk to, I would think. That or VM
> needs to provide an HMC virtual device (I know, that one's a lot less
> likely to g
> I notice, though, that the translations on the page you point out are
> not symmetrical. In particular, the ascii->ebcdic translate table
> converts ascii square brackets (x'5B', x'5D') to ebcdic x'AD' and
> x'BD', but the ebcdic->ascii translation presumes square brackets are
> at x'BA' and x'B
> Dave Jones of Sine Nomine has written an EXEC that will do
> just what you want, in the guest's CMS startup phase:
> http://www.sinenomine.net/downloads/SWAPGEN.EXEC
Mr. Nit Picky sez that Jones' EXEC does exactly the right thing.
There is no reason to CMS FORMAT an FBA volume. Unless you're
u
> Not that it's any of my business, but wouldn't Wi-Fi be more
> appropriate? Reeling out the cable behind you as you drive
> has to be annoying.
You silly English person! [insert the rest of that monologue here]
The ethernet connects the various lap-tops in the Suburban
with each other and wi
> > The night Marilyn and I had some stew Dave had made
> > (it was really good!) she went into labor with our first child.
>
> Presumably not *every* member of the L/390 community is going to meet
> the pre-reqs necessary for those conditions to apply.
Pre-reqs ... isn't that RPM's job to handle
On Thu, 20 Mar 2003, Post, Mark K wrote:
> Have you considering completely scrapping telnet and using SSH instead?
> See recent threads about why telnet should not be used for any reason,
> any time.
Just to be nit-picky, the telnet *client* is still very useful.
A great number of other protocols
Warning to all:
The night Marilyn and I had some stew Dave had made
(it was really good!) she went into labor with our first child.
-- RMT
On Thu, 20 Mar 2003, Post, Mark K wrote:
> Because most of us don't work for ISV's that support products on UNIX as
> well as Linux, and any script we write will only be running on Linux? I
> frequently code my scripts that way because I want them to be treated as
> bash scripts and not sh scripts
> > Why would we code things for Linux
> > that are intentionally incompatible with other UNIX?
>
> Because 'test 'x' = "x$var";' is less readable than 'if [ -z "$var" ];
Don't need BASH for that. Any contemporary Bourne will do.
This is getting silly: I feel like I'm bashing BASH, as if I
we
On Thu, 20 Mar 2003, John Summerfield wrote:
> I suspect it won't run on a stock non-Linux UNIX host (Solaris, AIX, HP,
> ...). OTOH, we're talking about Linux.
Why would we code things for Linux
that are intentionally incompatible with other UNIX?
This is a really bad idea!
-- RMT
On Thu, 20 Mar 2003, John Summerfield wrote:
> Change the first line of a shell script to
> #!/bin/bash -x
Not if you ever EVER want to run that shell script
on a stock non-Linux UNIX host (Solaris, AIX, HP, ...).
Don't code shell scripts that way, gang.
(John was only joking. Yeah, that's it
> # .profile is read for all login shells
> # all other interactive shells will read .bashrc
> # So read .bashrc also from .profile and make all changes to .bashrc.
> # Then you should always have your correct setup.
I can only guess that whoever wrote this is trying to cover
the X based shells,
> When I want to change environment variables for a user I put them in
> .bashrc in there home directory.
Wait! Don't do this.
Figure out how to get .profile (or .login or both) and .xinitrc
to work the way you need.
> I wanted to change root's environment variables but I did not find a
> .bash
I will visit DeveloperWorks and be sure I've got the latest patches.
Thanks!
-- RMT
A couple weeks ago, in messages with subject "Subchannel
not Operational", Joseph Higgins and Jay Brenneman discussed some
peculiar behaviour with Linux and multipath I/O. I've got a
worse scenario and was hoping it might jog someone's grey matter:
Two VM hosts sharing a couple of DASD string
XEDIT is a combination full-screen and command-line editor
yet without mode switching. There is no "insert mode" in the
VI sense. (There *are* two insert modes: one on your 3270 terminal
or emulator, and another for entering lots of lines of text
that is more properly called inPUT mode.)
U
> It's possible as the same interface used to get the LOADPARM can be used to
> send/receive info to the HMC. Something that I'm not clear on is what
Right. And VM traps that call too.
> happens under VM when a guest attempts to write to the HMC. Does it get
> intercepted and rerouted to the
What I had in mind was to hand off the handling of LOADPARM to
the kernel parm string processing: append a "loadparm=" token
to the parm string, with or without the VM IPL PARM appendage.
(That is, PARM (VM only) and LOADPARM (VM also) would
operate independently of each other.)
This does sev
> How does the command 'which' work?
'which' walks through the PATH string looking for a match.
-- RMT
On Fri, 7 Mar 2003, Ronald Van Der Laan wrote:
> /* */
> Call Diag 8, 'CP IPL LINUX PARM VMPOFF="ipl cms" MEM=64M'
We're presenting examples and omitting context.
What works in REXX on CMS might not work from a Linux shell
and probably will *not* work from the un-aided CP command line.
Ronald, I
Support for VMPOFF and VMHALT in the Linux parm line
should remain isolated from the VM IPL PARM support.
I would argue that VMPOFF and VMHALT processing should up-case.
But it needs to be a separate patch 1) because some might really
need case sensitive processing, and 2) because some might
A bigger question might be
why must vmpoff be in upper case??
> debian:/devel/kernel/scratch/linux-2.4.19/arch/s390/kernel#
> cmsfscat -a -f /dev/dasd/0191/disc ipllin.exec
Nice to see someone is using CMS FS!;-)
> /* */
> iplline = 'CP IPL DEB24M PARM LINE vmpoff="IPL CMS"'
>
Leland ...
Another thing to consider is non-printables.
The kinds of parameters we're likely to enter for Linux
would consist entirely of printable characters. So anything below
0x40 (EBCDIC blank space) would imply that it is *not* parm data.
This goes for the high byte as well as all the rest.
gang ...
I have placed cmsfs-1.1.7.tar.gz on ftp.bmc.com.
The utility is still largely the same, but now should build
on OpenVM as well as on ASCII based UNIX (Linux, Solaris, etc).
The driver works with the 2.4.19 kernel. Sadly, the driver
in this release does NOT work with 2.4.7 or 2.2.x ker
> This approach does not work if the program is being exec'd
> and the exec() call sets argv[0] to something strange.
Leaving argv[0] set to the original command (then exec())
or setting it to "something strange" are very useful features
of the UNIX API. Good stuff. (But doesn't help Nea
Good question!!
Strictly speaking,
to be able to connect, you do not have to re-generate these keys.
But that results in the same key fingerprinting multiple hosts,
which is really not what you want: each host should have a
unique fingerprint.
Re-creating them is easy: ssh-keygen
ssh-
Leland,
The effect of PARMREGS=0-15 on the DEFSYS
is the default for DEFSYS if no PARMREGS was specified,
and the behaviour of your NSS then is similar to IPL from device,
*except* that omitting PARMREGS from DEFSYS sets up an NSS for which
the regs are not zeroed out before filling with PARM cont
I found that your patch applied cleanly after the IBM patches
(to the 2.4.19 kernel source tree). My automation applies patches
in order based on their timestamp (which thankfully is preserved
because IBM delivers them in TAR). This is so clean that I would
hate for IBM to miss the opportunity
Outstanding!
> This was forwarded to me by a coworker. I particularly like the cover of
> the hardcopy version of the magazine. A penguin eyeing the MSN butterfly,
> with a fly swatter behind his back.
Can ya FAX that to me? ;-) (Until I make it to B&N to buy it.)
I especially like the McN
[resent; lost in queue for a week]
On Fri, 21 Feb 2003, I said:
> You indicate that you have tested this with s390x.
> I will test with s390 and get back to the group.
Works! Works just fine on 31-bit. (And you already tested 64.)
I was able to switch root volumes in a pinch with
ipl
On Wed, 19 Feb 2003, Lucius, Leland wrote:
> In case anyone's interested, here's a small kernel patch
> that gives you the ability to supply kernel command line parameters
> via the PARM parameter of the VM IPL command.
This is great! Works really well. Very effective.
One thing that would ma
> In case anyone's interested, here's a small kernel patch that gives you the
> ability to supply kernel command line parameters via the PARM parameter of
> the VM IPL command.
Bless you!
> http://www.homerow.net/projects/zlinux/vmparms.htm
You indicate that you have tested this with s390x.
I wi
501 - 553 of 553 matches
Mail list logo
