> There are versions of VSE, MVS and VM available for free (think late 1970s). The
> only recent no-charge OSs are the various Linux distros.
>
> The others will run, the trick is getting the licences. It has been done, I
> gather.
Once only, as far as I know - an AD/CD. Very unlikely to happen
> 06.05.2002 21:48:09 John Summerfield wrote:
>
> >
> >The Athlon is good for building software on. It's also good fur running
> >Hercules.
>
> BTW, which OS are You going to run on Hercules? If it is OS/390, do You
> have to pay to IBM?
> If answer is "yes" i don't think it is very cheap :) Or I
06.05.2002 21:48:09 John Summerfield wrote:
>
>The Athlon is good for building software on. It's also good fur running
>Hercules.
BTW, which OS are You going to run on Hercules? If it is OS/390, do You
have to pay to IBM?
If answer is "yes" i don't think it is very cheap :) Or I don't know
some
> If they ( the developers ) were trying to target a product for the Linux/390
> community, I would hope that they would not try to develop and test those
> products just willy nilly even in the uncontrolled environment where they
> are not getting what they think that they need.
>
> When we buy a
On Fri, 3 May 2002, Rich Blair wrote:
> 1. Give each development group their own Linux. ...
> 2. We (IBM syprogs) micromanage each Linux - ...
I'm very much in the #1 camp.
In fact, I would not stop at the group level
but would go so far as to give every *user* their own Linux.
(This does
[EMAIL PROTECTED] said:
> I'm unclear as to why any Hercules engines would pop up at all...
I think a flock of penguins on emulated S/390 is a good way to go for
development and it's in this context I think it's worth looking at.
As others have noted, S/390 is an expensive source of CPU power.
> that the vendor produced that product on, or reasonably near, the target. Or
> is Linux so smooth to allow a vendor to be able to develop and test on
> Linux/Intel and then sell to Linux/390?
Varies by codebase. You certainly need to test on /390 but a very large
amount of code required no fixe
ter, MN 55905
>
> "In theory, theory and practice are the same,
> but in practice, theory and practice are different."
>
>
> > -Original Message-
> > From: Nick Laflamme [SMTP:[EMAIL PROTECTED]]
> > Sent: Monday, May 06, 2002 8:11 AM
>
5-3450
Rochester, MN 55905
"In theory, theory and practice are the same,
but in practice, theory and practice are different."
> -Original Message-
> From: Nick Laflamme [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 06, 2002 8:11 AM
> To: [EMAIL PROTECTED]
> S
by going to
Linux guests under VM.
In other words, if he doesn't offer a "full control" option he won't have as many
"Linux guests under vm. how to manage", which is, after all, the subject of the
note.
The question isn't whether there's anything wrong wit
[EMAIL PROTECTED] said:
> Some of your users, I'm sure, need complete control of their Linux
> image to make sure they know how real live customers would work with
> their product. You have to offer these users this option, or they'll
> go behind your back to get this kind of access. Do you reall
> > We're a Software company and have many products and many developers.
> > We'd be interested in hearing your thoughts on ways to manage
> > many Linux
> > guests in a development environment.
> >
> > Options we've considered:
> > 1. Give each development group their own Linux. Possibly a coupl
0 Port
> Sent: Friday, May 3, 2002 11:30 AM
> To: [EMAIL PROTECTED]
> Subject: many Linux guests under vm. how to manage.
>
> We're a Software company and have many products and many developers.
> We'd be interested in hearing your thoughts on w
From:
|
| Subject: many Linux guests und
Rich Blair wrote:
> We're a Software company and have many products and many developers.
> We'd be interested in hearing your thoughts on ways to manage many Linux
> guests in a development environment.
>
> Options we've considered:
> 1. Give each development group their own Linux. Possibly a co
We're a Software company and have many products and many developers.
We'd be interested in hearing your thoughts on ways to manage many Linux
guests in a development environment.
Options we've considered:
1. Give each development group their own Linux. Possibly a couple of
members of the group s
> We're a Software company and have many products and many developers.
> We'd be interested in hearing your thoughts on ways to manage
> many Linux
> guests in a development environment.
>
> Options we've considered:
> 1. Give each development group their own Linux. Possibly a couple of
> members
17 matches
Mail list logo
