TSAF - Supported Links
Dear all, I have two z/VM running on different CPCs. They are joined in a CSE compl ex. The DASD is shared but spool not since I do not have VM/Pass Through facility. I want to connect now both systems via TSAF as I need to interconnect IUCV and SFS services. After reading the Connectivity Guide (GC24-6118-02) I found out that TSAF would be the right component for doing this. As far as I can understand t he setting up of TSAF is quite straight forward. Nevertheless I would need some explanation about the IEEE 802.3 LAN subsystem on rack-mounted processors. This is in my opinion a quite vague description of a feature. What does it mean? Does that mean that the OSA Express2 adapters on my z990s are not supported for TSAF? Aside from CTCs and since I do not have VTAM, Token Ring and BSC stuff, the Ethernet link would be the easiest solution. I would need some confirmation on this. Thank you very much in advance. Best regards, Fox
REXEC question
Dear all, I set up the REXEC daemon on z/VM 5.3 and wanted to do a logon of a useri d RVMCP with my own credentials. For this the RVMCP directory entry has a LOGONBY option that names my own userid. When I do a LOGON RVMCP BY myuser then it works well. However when I do t his via rexec such as rexec -l rvmcp.by.myuser remote.host q names this gives me a return code of 1 saying that myuser may not login as RVMCP. I didn't find any additional information for eventual additional configuration of REXECD on this in the documentation, so maybe somebody h as experienced a similar problem and could give me a hint. I have RSU 0801 applied on the system. Thanks in advance. Best regards, Fox
Re: How to see which mdisks are linked by whom
Rob, Thank you very much. This is exactly what i needed. Best Regards, Fox.
How to see which mdisks are linked by whom
Dear all, May be a stupid beginners question: Is it possible to see who (which virt ual machine) actually links currently to mdisks on a certain physical volume? For example: I do a q dasd VMUSR7 and get DASD 312E CP System VMUSR7 4. That means 4 machines have a link t o this volume. But which ones??? In the directory the VOLUME is not assigend to any MDISK any more. So it must be something that was changed. Is there a way to access this informa tion? Thanks a lot Fox
Re: SIZE of CSE area for dasd models bigger 3390-9
That is clear now, thank's a lot. BR Fox
SIZE of CSE area for dasd models bigger 3390-9
Dear all, I am not sure how big the CSE Area need to be on DASD bigger than 3390-9. The planing manual shows only 3390-9, which has in fact 9 cylinders. How big the CSA Area need to be on 3390-27 and 3390-54? Thank you very much. Best regards, Fox
Re: Real device number assignments
Also in our organisation we have the same real device numbers on all CECs and LPARs. In order to reduce the number of addresses we are consolidating data on bigger volumes. Best regards, Fox
Move multiple minidisks via dirmaint
Dear all, I would like to move multiple minidisks from several userids to another physical volume. I used DIRMAINT CMDISK operator for doing this. However what makes me wondering is, if there is a possibility not to re-specify the size of the respective minidisk. I want only to move the minidisk and not to change the size. To specify t he size can cause mistakes as one has to refere to the DIRMAP in order to en ter this parameter. Is there an easy way such as to specify a '=' or '*' in order to keep t he same size of the minidisk? I didn't find it in the documentation or what would be the best procedure. Thank you very much in advance. Best regards, Fox
Moving multiple minidisk to new volume
Dear all, I have a question regarding the moving of multiple minidisks of several users via DIRMAINT. I saw in the documentation that I have always to respecify the size of th e minidisk in the CMDISK command. I think this is quite errorprone since I have first to check the size from the dirmap. Is there a posibility just only to move the address to a new volume with the same characteristics? Best regards, Fox
Re: Extension of MAINT 190 (S-DISK)
Kris, I would also be interested in SESCOMP. Regards, Fox On Mon, 19 May 2008 18:09:43 +0200, Kris Buelens <[EMAIL PROTECTED]> wrote: >You forget the VMSES PARTCAT: I've got entries in VMSES PARTCAT for >all the things I store on 19E, even y own code gets a dummy prodid. >VMFCOPY can then be used to copy all files of a "prodid". And, I >wouldn't be me if I hadn't coded an exec to help with the task: my >SESCOMP first compares VMSES PARTCAT with LISTFILE and helps you to >add missing entries in VMSES PARTCAT. You do that for the old and new >disk. The you can tell SESCOMP to compare the PARTCATs of two >minidisks; it produces a list prodids and number of files; PF-keys >allow to copy or FILELIST files of a prodid. This way, merging two >minidisks is quickly done. Ask and you shall be given. > >But, indeed: most products live on a separate minidisk (like GDDM 191, >DITTO 191, ...), only stuff that needs to be available to everyone >lives on our 19E. Examples: RAC, VMBACKUP, VMTAPE, some local >helpfiles. > >-- >Kris Buelens, >IBM Belgium, VM customer support > =
Re: Extension of MAINT 190 (S-DISK)
Hi Mike, Thank you for this hint. Well I am also much more in favour to do the installation on a separate disks, however in my case IBM install instructions of the SDO (Semi-VMSES/E Licenced Products) tell to install it on MAINT 19E. Therefore I do it in the recommended way but only for IBM products ;-) Regards, Fox On Mon, 19 May 2008 09:28:11 -0400, Michael Coffin <[EMAIL PROTECTED] om> wrote: >FWIW, I try to keep both the 190 and 19E pretty much as shipped by IBM. >All "public" programs and files (i.e. other vendor products, locally >developed programs and files, etc. etc.) all go on a disk accessed by >all users via an exit in the SYSPROF EXEC (i.e. in my case they live on >PUBLIC 191). This way you don't have to worry about trivial file >changes making a LOT more work for you. Don't forget, in order to >change a file on either the 190 or 19E you are SUPPOSED to make the >changes to the 490 or 49E, test them, and then promote the changes to >the 190 or 19E. If you skip this and make your changes directly to the >190/19E they could be OVERLAID (or lost) the next time you do any kind >of service that does PUT2PROD and copies the 490/49E to 190/19E. > >Consider a local PUBLIC disk and save your self the grief of resizing >CMS system minidisks, keeping test/prod CMS disks in synch, and >constantly resaving the CMS minidisk FST's in NSS. > >-Mike >
Re: Extension of MAINT 190 (S-DISK)
Kris, thank you very much for the info. Focusing now on Y-DISK. Is a simple cop y of the files enough after formating the new Y-DISK or are there onher pit falls? Fox >Extending the S-disk is seldom done, because not that easy. Most >people would place extra >products on the Y-disk (19E), or yet another disks, accessed by >SYSPROF. But, if you insist: >- FORMAT the new minidisk e.g. as B >- FORMAT newcuu B nnn (RECOMP > makes room for the CMS nucleus, "nnn" is the size of the new >minidisk minus 7 cylinders > (a CMS nuclues is supposed to take at most 7 cylinders nowadays) >- update DMSNGP, adapt CYLADDR=100 to CYLADDR=nnn > regenerate DMSNGP >- VMFBLD PPF ZVM CMS CMSLOAD (ALL > to build the new nucleus load deck in your reader >- DET 190 #DEF newcuu 190#IPL 00C CLEAR > >As this is not for dummies, I explained briefly. > >Kris > > > >-- >Kris Buelens, >IBM Belgium, VM customer support > =
Re: Extension of MAINT 190 (S-DISK)
On Mon, 19 May 2008 14:43:09 +0200, Rob van der Heij <[EMAIL PROTECTED]> wrote: OK thank you, correct. But then I would like to extend the question with regard of the Y-Disk. Is a simple CMS copy enough or is special attention needed. Fox >On Mon, May 19, 2008 at 2:38 PM, Fox Blue <[EMAIL PROTECTED]> wrote : > >> it. It can be that we install some products (like DCF) that reside on the >> S-Disk. > >One does not normally install those on the S-disk but on the Y-disk. >(the S-disk is being DDR-ed from the 490) > >Rob
Extension of MAINT 190 (S-DISK)
Dear all, What is the correct procedure for extending the MAINT 190 (S-Disk)? My MA INT 190 is 82% full and I would like to prepare myself for the case of extend ing it. It can be that we install some products (like DCF) that reside on the S-Disk. Is allocation of a new mini disk and a DDR to that enough or do I have to make a CMS format and a copy of all files to that new disk? Please advise on this. Thank you very much in advance. Best regards, Fox
RSU Plans
Dear all, I think it would be nice when IBM would update the page regarding availability of the next RSUs. (http://www.vm.ibm.com/service/rsu/rsuplan .HTML) Would be interested when for DIRMAINT or RACF an RSU level will be made available. BR Fox
Re: Adding temp space
Dear all, You were right, of course. I overlooked this totally as my emulation wind ow was overlayed by another window. Because of the lot of comments in the MA INT directory it is bigger than all my other enties. Thanks so much for this help. BR Florian
DIRMAINT and MAINT
Dear all, I have DIRMAINT now running and try to get familiar with it. I encountere d the following problem with it: I use MAINT to issue the dirm commnd to retrieve MAINT directory entry. D IRM punches me the directory entry to MAINT's reader but it has NO MDISK statements in it. For all other users I get the complete directory entrie s so this is working. Is there some configuration I am lacking or what is wrong with it? BR Fox
Questions on DIRMAINT
Hello all, I have just set up the DIRMAINT on my system and have following question regarding the definition of full pack minidisk. Up to now (without DIRMAINT) I defined dummy users to own the special are as like cylinder 0 of Volumes, SPACE and SPOOL areas. In the USER DIRECT file I coded for example for TEMP disk space: USER $TDISK$ NOLOG MDISK 50A0 3390 001 END TDSK01 R * The address 50A0 is a 3390-3 and so coding END should in my opinion cover the 3338 cylinders of this volume. After importing my USER DIRECT and executing a DIRMAP I get following rep ort: TDSK01 3390 $ALLOC$ 50A0 * 0 0 1 $TDISK$ 50A0 * 1 1112 1112Over lap .TDISK. 50A0 * 1 3338 3338 This means that the coded statement derived from the USER DIRECT is interpreted as 3390-1 model having only 1112 cylinders. This is true for all the full pack minidisks. As the .TDISK. shows the entry should be 3338. My question is this works as designed or a bug? Another question would be how DIRMAINT handles an adding of a minidisk. F or example: I want to add a new volume to the system. I protect the cylinder 0 to add a minidisk to the $ALLOC$ user. Would there by a RACF profile be automatically be created? I thought this would be done. Maybe somebody ca n point me to the required parameters in the DIRMAINT config files. Thank you very much in advance. BR Fox.
Re: VM source code
I succeed to install the source code feature some weeks ago. My question would be, if there is some guidence to start working with it? For instance: how is do I know which source file does what, where to star t. Guessing some example: Write code supporting access of a LINUX filesystem (EXT2/3) in CMS. I mean accessing a minidisk formatted with ext3 and usin g it like e.g. an OS formatted disk. This is a feature I would really like to see in CMS in order to make maintenance of LINUX installations easier. As far as I know such thing from a third party vendor exists for accessin g it by REXX. BR Fox.
X Disk in SFS
Dear all, Thank you very much indeed for your great contributions and hints on this issue. I appreciate them very much. And I must say that I am very impress ed about this mailing list. It will help me really to improve my knowledge o n z/VM. Thanks a lot. Fox
X Disk in SFS
Dear all, I am currently busy to understand the capabilities of SFS. Started in the late 80ies as system programmer we had VM/SP but there was no SFS. Since one year I am working on a z/VM installation and have to catch up with all th e new facilities in VM. I am wondering what would be best approach to define an X Disk in the SFS . I mean, normally one puts the files accessible to all users on a mini disk that everybody can access. How can you do that with SFS? Should it be a directory in the file space of MAINT or should I define an extra Virtual Machine for that? What would be the most common way of achieving this? Thanks very much in advance. Fox
Re: CMS Programming: How to sort files entries retrieved by DMSGETDF
On Mon, 28 Jan 2008 09:28:10 -0600, RPN01 <[EMAIL PROTECTED]> wrote: This is the problem. Normally you can expect that the list is sorted. Therefore a small hint (usage note) telling that you can not guarantee th at the list is sorted would have been useful. BR Fox >The obvious answer being overlooked by everyone is Sort the list. > >If the disk has a small number of files (say, less than 1,000), just wri te a >bubble sort and put the list in order yourself. If the number of files i s >large, then you might have to write a more complex sort to do it >efficiently. > >I'm not sure what "LISTFILE" you're using, but mine, for my 191 minidisk , >does produce a sorted list of files. > >Also, I just read through the documentation for DMSOPDIR... Nowhere in t he >documentation does it suggest or imply that it might return the list of >files in any specific order whatsoever. Where did you get the impression >that it should return them in sorted order? > >-- > .~.Robert P. Nix Mayo Foundation > /V\RO-OE-5-55200 First Street SW > /( )\ 507-284-0844 Rochester, MN 55905 > ^^-^^ - >"In theory, theory and practice are the same, but > in practice, theory and practice are different." > > > > >On 1/27/08 2:04 AM, "Fox Blue" <[EMAIL PROTECTED]> wrote: > >> Kris, >> >> Well it is a R/W minidisk. It is the 191 of the machine. >> >> Yesterday, I was also playing around with the LISTFILE command. It see ms >> that it retrieves the file names in the same unordered way. >> >> Regarding to your proposal, I wanted to program a CMS module that shou ld >> not >> become dependent on external REXX EXEC(s). >> >> I think the documentation (CMS Application Development Guide SC24-6069 -02 >> ) >> should reflect that the directory is not sorted. I was browsing throug h i >> t >> and could not find any hint on this issue. Also the CMS Callable Servi ces >> >> Reference (SC24-6072-02) should contain a usage note referring to this . >> >> Thanks anyway for your proposal to overcome this problem. >> >> BR Fox. >> >> >> On Sat, 26 Jan 2008 20:11:25 +0100, Kris Buelens <[EMAIL PROTECTED] om> >> wrote: >> >>> I have no experience with DMSGETDF... >>> Is this a R/W minidisk? Only for R/O minidisks CMS keeps the FST's s ort >> ed. >>> >>> I would make the program call a REXX EXEC that in its turn executes a >>> PIPE that contains a LISTFILE and SORT stage. The PIPE could pass th e >>> sorted list of files in the stack where your program retrieves them. >>> Or, more elegant, your assembler program allocates a buffer large >>> enough to store the result of the LISTFILE, prepares the PIPE command >>> with the LISTFILE and SORT, the last stage would be a STORAGE stage t o >>> write the result in your program's buffer. >>> >>> Kris Buelens, >>> IBM Belgium, VM customer support >>> === = >> = >>
Re: CMS Programming: How to sort files entries retrieved by DMSGETDF
>The directory entries MAY be sorted. The documentation for DMSGETDF is >silent on the subject of file ordering, so a usage note that say they ar e >NOT sorted would be as inappropriate as one that says they ARE sorted. > >CMS sorts the directory only on ACCESS and RELEASE. New files added >always appear at the end of the list. But this is how you formulate the usage note. It should point out that the sequence is NOT guaranteed. It is in case wh en there was no update on the directory. BR Fox
Re: CMS Programming: How to sort files entries retrieved by DMSGETDF
Kris, This is very kind of you. Well sure it can wait a week. Thanks, BR Fox
Re: CMS Programming: How to sort files entries retrieved by DMSGETDF
On Sun, 27 Jan 2008 07:42:57 -0600, Mike Walter <[EMAIL PROTECTED]> wrote: Hi Mike, This is true. I encountered the following: Since I am still programming, I am using cms command run to start the program. This produces a LOAD MAP f ile and therefore it changes the file directory of the 191 disk. And then the sorted sequence is destroyed. Now making a module with GENMOD and re-accessing 191 disk retrieves the files in sorted sequence. It is a pity that the DMSOPDIR doesn't have an option to retireve the fil es in sorted sequence. >The CMS command ACCESS re-sorts the active file table. Try issuing, tha t >then running your program. > >If that works, you could just issue the ACCESS command from inside your >program via a CMSCALL (?). > >Mike Walter >Hewitt Associates > > > >The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deem ed to have accepted these risks if you communicate with us by email. > =
Re: CMS Programming: How to sort files entries retrieved by DMSGETDF
Kris, Well it is a R/W minidisk. It is the 191 of the machine. Yesterday, I was also playing around with the LISTFILE command. It seems that it retrieves the file names in the same unordered way. Regarding to your proposal, I wanted to program a CMS module that should not become dependent on external REXX EXEC(s). I think the documentation (CMS Application Development Guide SC24-6069-02 ) should reflect that the directory is not sorted. I was browsing through i t and could not find any hint on this issue. Also the CMS Callable Services Reference (SC24-6072-02) should contain a usage note referring to this. Thanks anyway for your proposal to overcome this problem. BR Fox. On Sat, 26 Jan 2008 20:11:25 +0100, Kris Buelens <[EMAIL PROTECTED]> wrote: >I have no experience with DMSGETDF... >Is this a R/W minidisk? Only for R/O minidisks CMS keeps the FST's sort ed. > >I would make the program call a REXX EXEC that in its turn executes a >PIPE that contains a LISTFILE and SORT stage. The PIPE could pass the >sorted list of files in the stack where your program retrieves them. >Or, more elegant, your assembler program allocates a buffer large >enough to store the result of the LISTFILE, prepares the PIPE command >with the LISTFILE and SORT, the last stage would be a STORAGE stage to >write the result in your program's buffer. > >Kris Buelens, >IBM Belgium, VM customer support > =
