What about IOSFBA and FCP connected SCSI drives?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Peter Vander Woude [pwo...@harristeeter.com] Sent: Tuesday, May 11, 2021 9:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage Zoning clarification I can comment on this, as I do san admin (along with z/OS and a couple of other things). >From the z/OS perspective, it only deals with 3390 dasd architecture, and >3490/3590 tapes, and is connected via FICON, which may or may not go thru a >FICON director. On the ficon director there is a configuration that tells the >director, that traffic coming in/out of port x needs to go in/out of port y to >get to the device on the other end of the channel configuration. The ficon >director can also be used for FCTC connections between lpars. If you running a linux image on an IFL, that linux image could be using normal 3390 DASD, in which case configuration is the same as with z/OS. If, however, you are configuring the linux on z vm's to use SAN storage, then there will be zone definitions that use the wwpn's for that vm's and define a mapping of which device(s), those wwpn's are allowed to communicate with. That method is called "soft zoning", as if the cable for either the target device, or source hardware needs to be moved to another port, the systems will recognize that and just keep going (there are some O/S's that don't handle it that nicely, but I don't know if linux on z is one of them). Soft zoning, to me, is the preferred way to go. The other method of zoning that can be done is "hard zoning", where you define the zone members being the physical ports on the san switch/director. If the cable for any of the devices in the zone gets moved, you have to update the zone and install the updated zoneset for those devices to be able to communicate to each other. not having any zoning at all in a san configuration is defintely not recommended, as that would mean that any system could possibly see storage and/or devices that they are not supposed to see. On san attached storage arrays, you typically define a host and it's wwpn's, so that does help reduce the possibility of a server, that's not supposed to see that disk, accessing that disk storage. Tape devices are wide open, as there generallyif there is no zoneset defined, so that could cause problems, such as a system that isn't supposed to use tape, could possibly read data from the tape library, or write data to the tape library. I hope that helps Peter On Mon, 10 May 2021 20:57:15 +0200, Radoslaw Skorupka <r.skoru...@hotmail.com> wrote: >I think, there is some misunderstanding here. >First, basics: >DAS - Direct Attached Storage - a disk connected directly, like your HDD >in your PC. This model can be used in mainframe world - DASD array >connected over FICON links to the host. No switches/directors between. >SAN - In this case there is some switch/director between host and DASD >array. > >Now, the switch - let's think about Ethernet switch. You plugged the >following devices: PC #1, PC #2, printer, laptop. Usually any device can >talk to any another device. Of course this is Ethernet level, maybe PC >#2 won't accept any "Hello" from laptop. >If fact SAN switch works very similar - any port can talk to any other >port. No, not a port - device attached to the port. What device? follow >the cable and you fill find something of the other end - it can be DASD >array port or z15 CHPID or some tape controller, etc. > >Now we have zoning. By default "any can talk to any", so there is no >zoning. And let's be honest: should you block communication between tape >controller and DASD? Why? Or maybe CPC A should not see CPC B? >However you may create zones. However my experience is zoning may >provide you troubles only. >Of course things may be more complex, but this is topic for SAN specialist. > >HTH > >-- >Radoslaw Skorupka >(looking for new job) >Lodz, Poland > > > > >W dniu 10.05.2021 o 17:09, Jake Anderson pisze: >> Hi >> >> So from the mainframe perspective zoning is done even if the connectivity >> passes through SAN ? Sorry if my understanding is incorrect ? >> >> Jake >> >> On Mon, 10 May, 2021, 2:32 pm Radoslaw Skorupka, <r.skoru...@hotmail.com> >> wrote: >> >>> W dniu 10.05.2021 o 06:36, Jake Anderson pisze: >>>> Hello All, >>>> >>>> Good evening >>>> >>>> I am trying to understand on how the ZONING part works when the >>>> connectivity to storage box or the tape device goes through a SAN switch. >>>> How does the ZONING is done and is there any documentation with an >>> example >>>> to understand better. I am trying to google to see if I can find the one >>> am >>>> looking but I am not successful yet. >>>> >>>> Is there any pointer or example if someone can help me with ? It will be >>> of >>>> a big help to proceed further. >>> Zoning is needed for distributed systems world and "discovery" of >>> storage devices connected to the SAN. It is just to isolate/hide devices >>> not intended to use with given server. >>> In CKD world there is IODF/IOCDS configuration file which says what is >>> accessible to given LPAR or OS Config. >>> Of course your SAN can be used for various purposes like ISL, DASD array >>> remote copy (usually FC, not FICON) and maybe some FCP devices and servers. >>> >>> -- >>> Radoslaw Skorupka >>> (looking for new job) >>> Lodz, Poland >>> >>> ---------------------------------------------------------------------- >>> 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 > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
