Rob, This write-up, along with the subsequent exchange between you and Alan, would make a really nice addition to the HOWTOs page. Would you be willing to write this up in HTML format for that?
Mark Post -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Rob van der Heij Sent: Tuesday, February 17, 2004 6:04 AM To: [EMAIL PROTECTED] Subject: Re: DCSS permission question Argh. I wish I would have been more stubborn and unfriendly towards the developer when I explained to him that both the way of working and the documentation were unlike what we use to do on VM and thus would confuse people and make them do things they don't want to do. Let me start from the beginning and apologize for writing this long note. The space type code in the DEFSEG command indicates how the servers use it, not how you manage it. SR: When you want Linux machines to share the block device R/O you use the code SR. Doing this avoids the I/O to read the data, but it does not avoid Linux to keep copies of the data in its own page cache. SW: When you define a segment as SW anyone accessing the DCSS can read and write everything. There may be applications that could deal with such a shared block device (I believe that application would use the block device in raw mode). If you simply define an ext2 filesystem in it and have everyone write in there, things will be as unpleasant as using MW disks in CMS. When you have a useful application you could make the segment restricted and use NAMESAVE statements to limit the audience. EW: You can also define the segment as EW which gives everyone his own copy of the DCSS in write mode. The most obvious use I see for this is a ready-to-use swap disk or device to hold temporary files (I measured such a thing for swapping in the past and found it to be slightly faster than VDISK). There is two ways to save the contents of the DCSS. Both work, but one may fit your local procedures better. 1. Build a big file on disk that is the same size as the DCSS and fill it with the data that needs to go in there. If you want to make a filesystem in it you can with mke2fs, mount it with --loop, and when you're done you unmount the loop device. Thenb run zipl with the -s option to write the IPL records on it. You then take a class E userid large enough to overlap the DCSS (that does not otherwise run Linux) and link the disk R/O. Define the DCSS to create the sekeleton and IPL the disk. When the boot code loads a disabled wait you have loaded the contents of that big file into virtual memory and can issue a SAVESEG to have CP copy the pages into the special spool file (this may take pretty long because the DCSS files for Linux tend to be big). Also be prepared to have enough spool space to handle pending purge copies of those big files, and make sure that your existing spool backup (or SDF backup) does not get messed up. To update the contents of the DCSS you mount the big file again in Linux through --loop and repeat the subsequent steps. This approach does not require special privileges for the Linux server and allows the MAINT user to decide when you create a new DCSS and whether you encourage people to stop using the old one etc. 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). 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. All other Linux servers that now mount the block device get the shared copy R/O (because they have not flipped the 'shared' flag) of the segment. If the owner Linux servers want to continue to *use* the data (rather than update it) you can write the 1 into the 'shared' entry to reset the flag and mount the block device again. If you're unsure you can use the class E user to issue Q NSS USERS <segment> and such. Again, be aware that you create a new big spool file with each time you go through the 'save' process and if people are sticking to these versions you fill up spool space and make the sharing less effective. If you trust root on the Linux server you could give that guest class E and have it use 'hcp' to issue the defseg command itself (this also removes the need for the NAMESAVE in the directory). This is like handing the root user there a loaded gun, and you only do that when you trust that person he would not point it at you. If you run PROP in your System Operator userid you could also arrange it that the Linux server can issue a MSG OP DEFSEG .. to create a skeleton (but only the ones that it owns). I hope this clarifies the workings (and I do welcome feedback on what causes confusion). Rob
