For conventional devices, the application constructs a channel program, either 
directly or via an access method. The application, either directly or via an 
access method, uses STARTIO to initiate the I/O, and it is ther STASRTIO 
service that actually does the Start Subchannel (SSCH) instruction.

EXCP and EXCPVR are supported access methods, and with them the application is 
responsible for constructing the CCWs.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [[email protected]] on behalf of 
Laurence Chiu [[email protected]]
Sent: Wednesday, June 15, 2022 1:35 AM
To: [email protected]
Subject: Re: RIsks of sharing FICON adapters between LPARs on the same host

Thanks. That sounds like a really good explanation to me.  From way distant
memory as each LPAR initiates an I/O eventually a CCW must be created
though these days I can't imagine any application program worrying about
that.  Something you might do in Assembler even though you would probably
invoke a MACRO.

It was an academic debate and I doubt if I would raise it with the security
team :-(

On Wed, Jun 15, 2022 at 3:02 PM Ken Bloom <[email protected]> wrote:

> The risk is not with the ficon channels as the way CCW’s are sequenced it
> would be virtually impossible for info to bleed across lpar’s.  Since Dasd
> is now virtual in all systems (IBM, EMC, Visara ,Hitachi) there is a
> greater chance of the shared file system causing data to be “misplaced”.
> Even so, it’s highly unlikely.
>
> Kenneth A. Bloom
> CEO
> Avenir Technologies Inc
> /d/b/a Visara International
> 203-984-2235<tel:203-984-2235>
> [email protected]<mailto:[email protected]>
> http://secure-web.cisco.com/1UNCxtp1BQi2jN7M3ossMR_pNHB_6xoh8tXOLHS6w_9p89kwm5ihrgk2nJBpH5bs-MWC2X4aYc30i5SAomma7jusnrjy2FuNKEJEtdg2OBkOimIi_QG-t-WRZVfs9Y0zDFSa28Q5_4kouOVEiuTEYvmzk9tOMTYSSDPqtjU6asdrWfQHeotNuXO5klq31Fh1O9jcUEfq4HOo_4r8QzHauncukFh4o4Ab2LYayVk39cs4clZASm8UDnkumhQ0vFAoEMMrc7U3EWKWI45fG8cRXhWNpvACj6HQuqLqdtt4DtXLTjAVBjr3ZJhCQoyB9f8IKfUwNZvaEZ9hg0gxMysd2vVHUOvzAhQwv25lTNQ7KP3ya6AmzJ1C6i80xgaORJZJSng2S94znoPfZnakchu-cL8B0pHEy0BmGKjwxPQ0vog0FsF7c1sJMlLr_tOHGyBDM/http%3A%2F%2Fwww.visara.com<http://secure-web.cisco.com/14CVod4jorQBuCb_868NrxKnF0qeweS-DbpUhXyRagBu3AB4YVxC7-ylhCKdJKq2cYlnBsBmy4POvlItyaF5vN675CIn5pqjQXg3N3KDs3wu5zHk2YBwN6fuydnb_ZLiWIWAwDv5_zBp0ZXqawTOmQd9EEB3h7K3gjqDZIs8wSQqKerJWyBeZK-HokUU0fDdomeJh8fT-741A43OXq0kU5ukCUU9QFyznSxw-7H57iy6JCpzBCw2JedzwdZg1LAdaPyA87gb1Mx4POIdila-aPv0d6vEqM5dOv3UZrCT74dFUPaDPZR4bm91L4AeptDp5BI5fhmGzNmB3RW1yG0m4zhp6ZZVpH09i5Q7z3KjncHAoEMA0rMr7S_CmLmGhmpNDJRXr9d3SGSA0p4Z4Aj26SbJtNYIj7ncmMm1RCHMkbjqzZtle19r80fFW-9uA3jZM/http%3A%2F%2Fwww.visara.com%2F>
>
>
> On Jun 14, 2022, at 10:38 PM, Mike Schwab <[email protected]> wrote:
>
> z/VM can share PCHPIDs.  But we always had 4 FICON for every LPAR for
> DASD.
>
> On Tue, Jun 14, 2022 at 9:07 PM Laurence Chiu <[email protected]> wrote:
>
> We had an interesting question raised recently in my work place by our
> security team.
>
> They said, if you have multiple LPARs on a Z box and you share FICON
> adapters going to the same DS8K is there any data leak issue that could
> occur? That is,  could LPAR1 inadvertently see traffic to the SAN that is
> defined for LPAR2 but sharing the same FICON adapter. Maybe somebody mixed
> up the IODF or something like that?
>
> I thought not and said, isn't that how VMware and Hiper-V work. The
> hypervisors share out FC cards etc. to the various VM's and it doesn't seem
> to be an issue and z/OS (or is PR/SM) is likely to be a much hardier OS
> security wise.
>
> Anyway I would get the view of the experts on the forum.
>
> Thanks
>
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to