Re: 32 bit and 64 bit libraries of the same product

2011-06-21 Thread Alan Altmark
On Sunday, 06/19/2011 at 05:06 EDT, John McKown wrote: > Even IBM now knows this is a bother to others. IIRC, a recent MCL allows > a 32 bit data address (not instruction tho.) IBM uses it in their > current z/OS JVM to store byte code data "inside the bar" in the 32 bit > "bar". This allows JVM t

Re: z/VM page space

2011-06-21 Thread Rob van der Heij
On Tue, Jun 21, 2011 at 10:31 PM, Bill Holder wrote: > and it also > won't help with CP system-owned pages (including vdisk pages, for what it's > worth), which > cannot be locked via the CP LOCK command. But since Linux does know how to evacuate swap space, you can define a new VDISK for swap a

Re: z/VM page space

2011-06-21 Thread Bill Holder
> I think that would probably break NSS/DCSS processing, since those can appe= > ar in multiple address spaces, and you'd need to fix all those references t= > oo. That does indeed add complexity, but is solvable - for shared NSS/DCSS pages, the "owning entity" is the NSS/DCSS itself, that's what

Re: z/VM page space

2011-06-21 Thread Bill Holder
> Just a perhaps crazy idea. > - Add new page volumes > - drain all old page vlumes to stop adding new data there > - for each Linux, one at a time change the reserved memory to the same as m= > emsize > (for this to work, z/VM now must restore all paged memory into real memor= > y) > - wait unti

Re: z/VM page space

2011-06-21 Thread Bill Holder
> Just a idea, but what if we put the "back link" on the DASD page (I don't > know much about the structure of the page, but I think there's a header > there somewhere), not on central memory? We would only have to read the back > link on the page header on DASD and we would know where the page is,

Re: z/VM page space

2011-06-21 Thread David Boyes
> -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Agblad Tore > Sent: Tuesday, June 21, 2011 9:37 AM > To: LINUX-390@VM.MARIST.EDU > Subject: Re: z/VM page space > > Just a perhaps crazy idea. > - Add new page volumes > - drain all old page vlum

Re: z/VM page space

2011-06-21 Thread David Boyes
> Just a idea, but what if we put the "back link" on the DASD page (I > don't > know much about the structure of the page, but I think there's a header > there somewhere), not on central memory? We would only have to read the > back > link on the page header on DASD and we would know where the page

Re: CMS commands from Linux

2011-06-21 Thread Scott Rohling
I built a provisioning server this way once.. on the Linux side - just a 'wget' and pass a bunch of parms: wget http://x.x.x.x/cgi-bin/makelnx?lnx001+WEBAPP+1G+4G+VSWITCH2+.. .. Running Webshare on z/VM and the 'makelnx' CGI was a REXX EXEC that did all the dirmaint/racf/cloning stuff..

Re: z/VM page space

2011-06-21 Thread Agblad Tore
Just a perhaps crazy idea. - Add new page volumes - drain all old page vlumes to stop adding new data there - for each Linux, one at a time change the reserved memory to the same as memsize (for this to work, z/VM now must restore all paged memory into real memory) - wait until this is done (heh

Re: CMS commands from Linux

2011-06-21 Thread Agblad Tore
setup a webserver in z/VM, and allow the Linux to run a rexx inside the webserver via http :) Cordialement / Vriendelijke Groeten / Best Regards / Med Vänliga Hälsningar Tore Agblad Tore Agblad System programmer, Volvo IT certified IT Architect V

Re: z/VM page space

2011-06-21 Thread Mauro Souza
Just a idea, but what if we put the "back link" on the DASD page (I don't know much about the structure of the page, but I think there's a header there somewhere), not on central memory? We would only have to read the back link on the page header on DASD and we would know where the page is, migrate