On Tuesday, 02/17/2004 at 12:03 CET, Rob van der Heij <[EMAIL PROTECTED]> wrote:
> 2. The alternative approach is hat you first save a dummy DCSS. So take > a MAINT user with large enough virtual machine size and issue the DEFSEG > and SAVESEG just to save the DCSS with garbage). The Linux guest > responsible for maintaining the DCSS (with virtual machine size smaller > than the start of the segment) will load the DCSS in non-shared mode (a > special option on diag64 triggered by the 0 into the /proc entry) which > requires the segment to be listed on a NAMESAVE statement in the CP > directory for the Linux server (this prevents other Linux servers from > messing with the contents). Be aware that loading the segment in exclusive-write mode will purge the existing segment, preventing any *subsequent* loading of the segment, read OR write. Existing users of the segment are unaffected. >The dcss block device can ow be mounted R/W > and the files inside can be updated. The first time the block device has > garbage in, so if you want to have a filesystem there you run mke2fs to > start with. When you're done with the updates you unmount the device and > have someone with class E issue a DEFSEG again for the DCSS. After that > Linux can write the 1 into the corresponding save entry in /proc to > issue the SAVESEG command under the covers SAVESEG also requires class E. The /save function of the driver was designed assuming the Linux machine has class E privileges (from my reading of the code), as it automatically issues the DEFSEG and SAVESEG for you. If you don't want to give the Linux image class E, then the DEFSEG and SAVESEG both have to be done manually elsewhere. Alan Altmark Sr. Software Engineer IBM z/VM Development
