Is it possible to IPL z/VM 6.1 using an Integrated Facility for Linux 'IFL' engine(s) on an IBM zEC12 - then create a Linux on z host using Red Hat Enterprise Linux 7.0 and install RD&T 9.1 (on RHEL) to host RDz 9.0.1?  

Why would you want to run a System z architecture emulator on hardware that already supports the System z architecture?   Simple answer is RD&T runs on Intel hardware only.  It will never run on an IFL, ever.

RDzJohn

I'm not sure about the OP but we would like to be able to IPL the RDz Volumes on real hardware not the emulator.   You provide a almost ready to use system that actually would allow for provisioning of development system on z quickly.   personally with all the cloud talk I'm surprised IBM hasn't pushed this as a potential offering beyond RD&T itself for its customers.

I know technically this doable,   IPL the system on x, dump the volumes and ftp to real hardware then restore them, build a user directory to match and IPL or build an LPAR to match.   it's not hard

I don't know if that was what the OP wanted or not but it has value for deploying copies of the image you provide on real hardware which has value.

Assuming your RD&T volumes (you said RDz, but I think you meant RD&T,) represent an entire, IPLable system, you could ipl them on real z/OS hardware assuming you moved the volumes to real CKD devices.  You would of course need to be licensed to do so.

The RD&T system z architecture emulator implements 100% of the System z architecture.  Given that, I don't see any advantage to running on System z hardware other than performance and scale.

Bottom line is the emulator runs on Intel Linux.  I see almost no chance it will ever run on Linux on z. 

RDzJohn

Why run a System z architecture emulator on hardware that already supports the System z architecture?  

1) The environment has idle IFL's looking for a workload

2) It presents the opportunity to create a complete IDE on a platform that provides 'performance and scale'

3) Moving legacy development and unit test off the existing z/OS LPARs allows the remaining validation test environment to be configured to look more like Production

4) Moving legacy development to IFLs free's up GP's which allows the integration test environment to move off the Production host

There doesn't appear to be a licensing issue that would negate the possibility.  That being said, is there a technical reason why it would not work?

First the technical - the emulator as currently implemented, converts System z instructions to equivalent Intel instructions.  If it was to run on System z hardware, I'm not sure what it would convert - System z instructions to ??  System z instructions?  Doesn't make alot of sense.

Our intention with RD&T is to provide additional flexibility for development by providing alternate platforms for development.   To the extent this frees up System z MIPS for other things, that is a good thing.  It was never our intention to provide a means for moving MLC z/OS MIPS to OTC IFL MIPS.  What you are really asking for is a way to run z/OS on an IFL.  I don't see that happening any time soon.

RDzJohn

Again, thanks for your reply.  If I am provided the opportunity to experiment with this , I'll be sure to update you with the results.

Hello,

If anyone following this thread wants to try running the RD&T z volumes on anything other than the RD&T System z emulator installed on the specified hardware required (i.e. x86 Intel/Linux, etc), you really need to talk to an IBM sales representative first. The product license agreement is restrictive to described authorized use, but does recommend working with IBM to obtain permission if what you want to do is outside of such authorized use. You can find an online version of the license agreement here: http://www-03.ibm.com/software/sla/sladb.nsf/search/  If you search for "development and test", you can quickly get to the RD&T license for the release you purchased. Note that the z volumes referenced in this thread are licensed as supporting programs, with limits on what you may do with those programs.

Regards,

Stephen