Re: Clarification On Storage
On Sat, 7 Jan 2017 23:19:13 +0200, Binyamin Dissen wrote: >On Sat, 7 Jan 2017 16:57:05 + "Blaicher, Christopher Y." > wrote: > >:>Generally speaking, a page sized request will return a zeroed page, but >there is no guarantee for that unless you specify that on the GETMAIN. > >What is the case where it would not return a zeroed page? The case specified by the OP would do it. He hypothesized doing a GETMAIN for 4096 bytes and getting storage at address 01B00C00. As that is not on a page boundary, I think it could only occur if someone had done a GETMAIN for, e.g., 8192 bytes, gotten the storage from 01B0 through 01B01FFF, then freed 4096 bytes starting at 01B0C00. Whatever the application left at that address before the FREEMAIN would still be there when the GETMAIN returned that same, previously used storage. Nothing guarantees that a 4096-byte request will end up returing storage on a page boundary, unless you specify that on the request. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification On Storage
>From the Assembler Services Reference manual: Note: 1.When you obtain storage, the system clears the requested storage to zeros if you obtain either: 8192 bytes or more from a pageable, private storage subpool. 4096 bytes or more from a pageable, private storage subpool, with BNDRY=PAGE specified. In all other cases you must not assume that the storage is cleared to zeros. The caller can specify CHECKZERO=YES to detect these and other cases where the system clears the requested storage to zeros. Chris Blaicher Technical Architect Mainframe Development Syncsort Incorporated 2 Blue Hill Plaza #1563, Pearl River, NY 10965 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com www.syncsort.com CONNECTING BIG IRON TO BIG DATA -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Myers Sent: Saturday, January 7, 2017 4:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Clarification On Storage I don't know when it wouldn't. I personally wrote the code to zero out a page on its first reference after GETMAIN back in the '70s. But as has been discussed here, if it is part of a page that is FREEMAINed and then the same address is returned by a subsequent GETMAIN, data may likely be present from its last use. That is unless subsequent versions were modified to clear any newly GETMAINed storage. Mike Myers Mentor Services Corporation Technical Team Lead for VSM and RSM development for the first release of MVS On 01/07/2017 04:19 PM, Binyamin Dissen wrote: > On Sat, 7 Jan 2017 16:57:05 + "Blaicher, Christopher Y." > wrote: > > :>Generally speaking, a page sized request will return a zeroed page, but > there is no guarantee for that unless you specify that on the GETMAIN. > > What is the case where it would not return a zeroed page? > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification On Storage
I don't know when it wouldn't. I personally wrote the code to zero out a page on its first reference after GETMAIN back in the '70s. But as has been discussed here, if it is part of a page that is FREEMAINed and then the same address is returned by a subsequent GETMAIN, data may likely be present from its last use. That is unless subsequent versions were modified to clear any newly GETMAINed storage. Mike Myers Mentor Services Corporation Technical Team Lead for VSM and RSM development for the first release of MVS On 01/07/2017 04:19 PM, Binyamin Dissen wrote: On Sat, 7 Jan 2017 16:57:05 + "Blaicher, Christopher Y." wrote: :>Generally speaking, a page sized request will return a zeroed page, but there is no guarantee for that unless you specify that on the GETMAIN. What is the case where it would not return a zeroed page? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification On Storage
On Sat, 7 Jan 2017 16:57:05 + "Blaicher, Christopher Y." wrote: :>Generally speaking, a page sized request will return a zeroed page, but there is no guarantee for that unless you specify that on the GETMAIN. What is the case where it would not return a zeroed page? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification On Storage
The content of the getmained area is much depend on language command and options (COBOL initialize foe example). ITschak נשלח מה-iPad שלי ב-7 בינו׳ 2017, בשעה 21:57, Clark Morris כתב/ה: > [Default] On 7 Jan 2017 08:56:33 -0800, in bit.listserv.ibm-main > cblaic...@syncsort.com (Blaicher, Christopher Y.) wrote: > >> Your example of 4K is important because it is a page in size. A page can >> only have one key and can only have one sub-pool associated with it at a >> time. >> >> Common memory excepted, once the page is freed, it can be re-assigned into >> any key or sub-pool. Common memory has a whole different set of rules. >> >> Multiple GETMAIN requests for less than a page can be satisfied on one page >> as long as they are for the same key and sub-pool. Once all GETMAINed >> memory has been freed on that page, then the page can be re-used. >> >> Generally speaking, a page sized request will return a zeroed page, but >> there is no guarantee for that unless you specify that on the GETMAIN. Any >> GETMAIN for less than a page you need to zero the area yourself because >> there might be residual data from a previous GETMAIN/FREEMAIN request. In >> any case, it will never be data from another address space as that would >> violate security. > > If the "physical" page is not zeroed, what would be there other than > data left from a previous use. Actually the same concept would apply > to all reused storage. > > Clark Morris >> >> Chris Blaicher >> Technical Architect >> Mainframe Development >> Syncsort Incorporated >> 2 Blue Hill Plaza #1563, Pearl River, NY 10965 >> >> P: 201-930-8234 | M: 512-627-3803 >> E: cblaic...@syncsort.com >> >> www.syncsort.com >> >> CONNECTING BIG IRON TO BIG DATA >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Itschak Mugzach >> Sent: Saturday, January 7, 2017 11:40 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Clarification On Storage >> >> Paul >> Getmain (in private area as you described) in not a real memory frame (which >> is the term for real memory 4k). It get the key based on the subpool you >> specify in the macro. So, in short, it is only visible through your asid >> page tables. >> Once your asid ends, so does the page tables. This is why we still use the >> term mvs. It is complely virtual. >> Common area is a bit different as they pre allocated, but this is not what >> you was asking. >> >> ITschak >> >> ?? 7 2017 17:10,? "esst...@juno.com" ???: >> >>> . >>> I recently read a share presentation on system integrity by Karl Schmitz. >>> Being a CICS Sysprog I dont get much opportunity to do some of the >>> topics Karl discussed. >>> . >>> . >>> I do have a question or should I say clarification about STORAGE. >>> I also looked at the z/OS Authorized Assembler Services guide. >>> . >>> Lets say a Non Authorized program runs in Key 8 and issues a >>> STORAGE/GETMAIN macro for 4096 Byes and the system returns an address >>> of 01B00C00 (an arbitrary address). >>> This Non Authorized Program process its data, FREMMAINs the 4096 Bytes >>> of storage and returns. >>> , >>> . >>> At some time latter An Authorized Program is started and requests 4096 >>> Bytes of storage in KEY 4. The system returns the same address >>> 01B00C00 that the Non Authorized Program used. >>> . >>> After reviewing Principles of Operation My understanding is that every >>> page of storage also has a storage kry, which consists of access >>> control bits, fetch protection bit, reference bit, and a change bit. >>> . >>> . >>> In My scenario I suspect the Operating System changed the storage >>> access control bits to key 4 to satisfy this request. Assuming the >>> same address was returned by GETMAIN/STORAGE. >>> Is My assessment correct ? >>> . >>> Im not aware of the operating system pre-allocating Pages of storage >>> by key ? >>> Do I understand this correctly ? >>> . >>> . >>> I apologize if this is a novice questions, but Inquiring minds want to >>> know. >>> . >>> . >>> . >>> Thanks In Advance >>> Paul >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, send >>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send email >> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> >> >> >> ATTENTION: - >> >> The information contained in this message (including any files transmitted >> with this message) may contain proprietary, trade secret or other >> confidential and/or legally privileged information. Any pricing information >> contained in this message or in any files transmitted with this message is >> always confidential and cannot be sha
Re: Clarification On Storage
[Default] On 7 Jan 2017 08:56:33 -0800, in bit.listserv.ibm-main cblaic...@syncsort.com (Blaicher, Christopher Y.) wrote: >Your example of 4K is important because it is a page in size. A page can only >have one key and can only have one sub-pool associated with it at a time. > >Common memory excepted, once the page is freed, it can be re-assigned into any >key or sub-pool. Common memory has a whole different set of rules. > >Multiple GETMAIN requests for less than a page can be satisfied on one page as >long as they are for the same key and sub-pool. Once all GETMAINed memory has >been freed on that page, then the page can be re-used. > >Generally speaking, a page sized request will return a zeroed page, but there >is no guarantee for that unless you specify that on the GETMAIN. Any GETMAIN >for less than a page you need to zero the area yourself because there might be >residual data from a previous GETMAIN/FREEMAIN request. In any case, it will >never be data from another address space as that would violate security. If the "physical" page is not zeroed, what would be there other than data left from a previous use. Actually the same concept would apply to all reused storage. Clark Morris > >Chris Blaicher >Technical Architect >Mainframe Development >Syncsort Incorporated >2 Blue Hill Plaza #1563, Pearl River, NY 10965 > >P: 201-930-8234 | M: 512-627-3803 >E: cblaic...@syncsort.com > >www.syncsort.com > >CONNECTING BIG IRON TO BIG DATA > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Itschak Mugzach >Sent: Saturday, January 7, 2017 11:40 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Clarification On Storage > >Paul >Getmain (in private area as you described) in not a real memory frame (which >is the term for real memory 4k). It get the key based on the subpool you >specify in the macro. So, in short, it is only visible through your asid page >tables. >Once your asid ends, so does the page tables. This is why we still use the >term mvs. It is complely virtual. >Common area is a bit different as they pre allocated, but this is not what you >was asking. > >ITschak > >?? 7 2017 17:10,? "esst...@juno.com" ???: > >> . >> I recently read a share presentation on system integrity by Karl Schmitz. >> Being a CICS Sysprog I dont get much opportunity to do some of the >> topics Karl discussed. >> . >> . >> I do have a question or should I say clarification about STORAGE. >> I also looked at the z/OS Authorized Assembler Services guide. >> . >> Lets say a Non Authorized program runs in Key 8 and issues a >> STORAGE/GETMAIN macro for 4096 Byes and the system returns an address >> of 01B00C00 (an arbitrary address). >> This Non Authorized Program process its data, FREMMAINs the 4096 Bytes >> of storage and returns. >> , >> . >> At some time latter An Authorized Program is started and requests 4096 >> Bytes of storage in KEY 4. The system returns the same address >> 01B00C00 that the Non Authorized Program used. >> . >> After reviewing Principles of Operation My understanding is that every >> page of storage also has a storage kry, which consists of access >> control bits, fetch protection bit, reference bit, and a change bit. >> . >> . >> In My scenario I suspect the Operating System changed the storage >> access control bits to key 4 to satisfy this request. Assuming the >> same address was returned by GETMAIN/STORAGE. >> Is My assessment correct ? >> . >> Im not aware of the operating system pre-allocating Pages of storage >> by key ? >> Do I understand this correctly ? >> . >> . >> I apologize if this is a novice questions, but Inquiring minds want to >> know. >> . >> . >> . >> Thanks In Advance >> Paul >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, send email to >lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > >ATTENTION: - > >The information contained in this message (including any files transmitted >with this message) may contain proprietary, trade secret or other confidential >and/or legally privileged information. Any pricing information contained in >this message or in any files transmitted with this message is always >confidential and cannot be shared with any third parties without prior written >approval from Syncsort. This message is intended to be read only by the >individual or entity to whom it is addressed or by their designee. If the >reader of this message is not the intended recipient, you are on notice that >any use, disclosure, copying or distribution of this message, in any form, is >strictly prohibited. If you have received th
Re: Clarification On Storage
Your example of 4K is important because it is a page in size. A page can only have one key and can only have one sub-pool associated with it at a time. Common memory excepted, once the page is freed, it can be re-assigned into any key or sub-pool. Common memory has a whole different set of rules. Multiple GETMAIN requests for less than a page can be satisfied on one page as long as they are for the same key and sub-pool. Once all GETMAINed memory has been freed on that page, then the page can be re-used. Generally speaking, a page sized request will return a zeroed page, but there is no guarantee for that unless you specify that on the GETMAIN. Any GETMAIN for less than a page you need to zero the area yourself because there might be residual data from a previous GETMAIN/FREEMAIN request. In any case, it will never be data from another address space as that would violate security. Chris Blaicher Technical Architect Mainframe Development Syncsort Incorporated 2 Blue Hill Plaza #1563, Pearl River, NY 10965 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com www.syncsort.com CONNECTING BIG IRON TO BIG DATA -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Itschak Mugzach Sent: Saturday, January 7, 2017 11:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Clarification On Storage Paul Getmain (in private area as you described) in not a real memory frame (which is the term for real memory 4k). It get the key based on the subpool you specify in the macro. So, in short, it is only visible through your asid page tables. Once your asid ends, so does the page tables. This is why we still use the term mvs. It is complely virtual. Common area is a bit different as they pre allocated, but this is not what you was asking. ITschak בתאריך 7 בינו 2017 17:10, "esst...@juno.com" כתב: > . > I recently read a share presentation on system integrity by Karl Schmitz. > Being a CICS Sysprog I dont get much opportunity to do some of the > topics Karl discussed. > . > . > I do have a question or should I say clarification about STORAGE. > I also looked at the z/OS Authorized Assembler Services guide. > . > Lets say a Non Authorized program runs in Key 8 and issues a > STORAGE/GETMAIN macro for 4096 Byes and the system returns an address > of 01B00C00 (an arbitrary address). > This Non Authorized Program process its data, FREMMAINs the 4096 Bytes > of storage and returns. > , > . > At some time latter An Authorized Program is started and requests 4096 > Bytes of storage in KEY 4. The system returns the same address > 01B00C00 that the Non Authorized Program used. > . > After reviewing Principles of Operation My understanding is that every > page of storage also has a storage kry, which consists of access > control bits, fetch protection bit, reference bit, and a change bit. > . > . > In My scenario I suspect the Operating System changed the storage > access control bits to key 4 to satisfy this request. Assuming the > same address was returned by GETMAIN/STORAGE. > Is My assessment correct ? > . > Im not aware of the operating system pre-allocating Pages of storage > by key ? > Do I understand this correctly ? > . > . > I apologize if this is a novice questions, but Inquiring minds want to > know. > . > . > . > Thanks In Advance > Paul > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification On Storage
On 01/07/2017 09:07 AM, esst...@juno.com wrote: > . > I recently read a share presentation on system integrity by Karl Schmitz. > Being a CICS Sysprog I dont get much opportunity to do some of the topics > Karl discussed. > . > . > I do have a question or should I say clarification about STORAGE. > I also looked at the z/OS Authorized Assembler Services guide. > . > Lets say a Non Authorized program runs in Key 8 and issues a STORAGE/GETMAIN > macro > for 4096 Byes and the system returns an address of 01B00C00 (an arbitrary > address). > This Non Authorized Program process its data, FREMMAINs the 4096 Bytes of > storage and returns. > , > . > At some time latter An Authorized Program is started and requests 4096 Bytes > of storage > in KEY 4. The system returns the same address 01B00C00 that the Non > Authorized Program > used. > . > After reviewing Principles of Operation > My understanding is that every page of storage also has a storage kry, which > consists of > access control bits, fetch protection bit, reference bit, and a change bit. > . > . > In My scenario I suspect the Operating System changed the storage access > control bits > to key 4 to satisfy this request. Assuming the same address was returned by > GETMAIN/STORAGE. > Is My assessment correct ? > . > Im not aware of the operating system pre-allocating Pages of storage by key ? > Do I understand this correctly ? > . > . > I apologize if this is a novice questions, but Inquiring minds want to know. > . > . > . > Thanks In Advance > Paul > Storage requests implicitly or explicitly are from a specific storage pool based on key requirements and how long the data needs to persist, and some pools are restricted based on authorization of the requester. The rules for allowed storage key values are pool specific. Released storage may stay for a while as free storage in that same pool -- don't remember the exact rules here -- but the association with storage pools would reduce the likelihood that a subsequent program in that same address space would later get storage at the same virtual address as was used fora different storage key. Also keep in mind we are talking here about virtual storage, not real storage frames. My understanding is that when whole pages of virtual storage are released back to a pool the association with real page frames and related data is tossed; and when whole pages are allocated from a storage pool no real storage frames are actually associated with the pages until first reference to each new page, at which point it is associated with a zeroed real page. So even if unused virtual storage were released from one storage pool and reassigned to another and a range of virtual address space switched pools, the new storage pool wouldn't see any data related to the previous storage pool. And of course with MVS-z/OS the virtual storage of different address spaces or regions are isolated from each other(except for the shared "common" area which is controlled by authorized programs). Joel C. Ewing -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification On Storage
Paul Getmain (in private area as you described) in not a real memory frame (which is the term for real memory 4k). It get the key based on the subpool you specify in the macro. So, in short, it is only visible through your asid page tables. Once your asid ends, so does the page tables. This is why we still use the term mvs. It is complely virtual. Common area is a bit different as they pre allocated, but this is not what you was asking. ITschak בתאריך 7 בינו 2017 17:10, "esst...@juno.com" כתב: > . > I recently read a share presentation on system integrity by Karl Schmitz. > Being a CICS Sysprog I dont get much opportunity to do some of the topics > Karl discussed. > . > . > I do have a question or should I say clarification about STORAGE. > I also looked at the z/OS Authorized Assembler Services guide. > . > Lets say a Non Authorized program runs in Key 8 and issues a > STORAGE/GETMAIN macro > for 4096 Byes and the system returns an address of 01B00C00 (an arbitrary > address). > This Non Authorized Program process its data, FREMMAINs the 4096 Bytes of > storage and returns. > , > . > At some time latter An Authorized Program is started and requests 4096 > Bytes of storage > in KEY 4. The system returns the same address 01B00C00 that the Non > Authorized Program > used. > . > After reviewing Principles of Operation > My understanding is that every page of storage also has a storage kry, > which consists of > access control bits, fetch protection bit, reference bit, and a change bit. > . > . > In My scenario I suspect the Operating System changed the storage access > control bits > to key 4 to satisfy this request. Assuming the same address was returned > by GETMAIN/STORAGE. > Is My assessment correct ? > . > Im not aware of the operating system pre-allocating Pages of storage by > key ? > Do I understand this correctly ? > . > . > I apologize if this is a novice questions, but Inquiring minds want to > know. > . > . > . > Thanks In Advance > Paul > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Clarification On Storage
. I recently read a share presentation on system integrity by Karl Schmitz. Being a CICS Sysprog I dont get much opportunity to do some of the topics Karl discussed. . . I do have a question or should I say clarification about STORAGE. I also looked at the z/OS Authorized Assembler Services guide. . Lets say a Non Authorized program runs in Key 8 and issues a STORAGE/GETMAIN macro for 4096 Byes and the system returns an address of 01B00C00 (an arbitrary address). This Non Authorized Program process its data, FREMMAINs the 4096 Bytes of storage and returns. , . At some time latter An Authorized Program is started and requests 4096 Bytes of storage in KEY 4. The system returns the same address 01B00C00 that the Non Authorized Program used. . After reviewing Principles of Operation My understanding is that every page of storage also has a storage kry, which consists of access control bits, fetch protection bit, reference bit, and a change bit. . . In My scenario I suspect the Operating System changed the storage access control bits to key 4 to satisfy this request. Assuming the same address was returned by GETMAIN/STORAGE. Is My assessment correct ? . Im not aware of the operating system pre-allocating Pages of storage by key ? Do I understand this correctly ? . . I apologize if this is a novice questions, but Inquiring minds want to know. . . . Thanks In Advance Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DNS, Resolver, and /etc/hosts
Steve Horein wrote: >Something like this? >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3b0/2.5.9 Good link, but that is for z/OS v1.13. >I imagine the same (or similar) topic is documented for z/OS Comm Server 2.x, >... Try this for z/OS v2.1, first URL is for UNIX environment and second URL is for 'native MVS': http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halz002/resolver_srch_orders_unix.htm http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halz002/resolver_srch_orders_mvs.htm Or just start here 'Resolver processing of the setup file when the resolver is started' : http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halz002/resolver_setup_file_processing_at_startup.htm HTH! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DNS, Resolver, and /etc/hosts
Something like this? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3b0/2.5.9 I imagine the same (or similar) topic is documented for z/OS Comm Server 2.x, but I tend to avoid KnowledgeCenter searches in favor of *useful* search interfaces. On Fri, Jan 6, 2017 at 12:16 PM, Phil Smith wrote: > Anyone got a pointer to a coherent discussion of these three options for > name resolution? I know how DNS and /etc/hosts work, and know enough about > the Resolver to use and configure it for hosts that aren't in DNS. > > What I want to understand is (at least): > > 1) Is the Resolver always involved? That is, is it the equivalent of > named on *ix? > > 2) How is the hierarchy determined? I *think* I've read that you can > have z/OS use more than one of these; can you use all three? In which order? > > I've spent some time looking thru doc but haven't found this, though I'm > sure it's there. > > Thanks. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Multiprise 3000
blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important; padding-left:1ex !important; background-color:white !important; } Anyone has a Multiprise and is planning to sell it?I need one to backup parts. Thank youDan Sent from Yahoo Mail for iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Apache Spark on z listserver or forum?
Saw this in the LinkedIn "Performance & Optimization News..." group: http://linkd.in/2i03y7v - "Spark Analytics on the Mainframe Interesting article by Stephen D. Bartlett at the Clipper Group about running Spark on the mainframe: IBM z Systems Get a Big Charge Out of Spark Analytics." Roger Lowe wrote: > Our site is currently in the very early stages of dabbling with > Apache Spark on z and was wondering if there is a Listserver > or Forum specifically for Apache Spark on z. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN