You can define a console to automatically logon to the console name, and use, e.g., RACF, to control what commands it will accept. Normally you will define the consol userids with minimal authority and require the operator to log on if he needs more authority.
Anything that supports real local non-SNA 3270s should support OSA-ICC. That includes MVS applications using EXCP[VR], STARTIO or VTAM for the display; z/VM logon and console; z/VM guest that supports local non-SNA 3270; stand-alone utilities. ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of John S. Giltner, Jr. <gil...@gmail.com> Sent: Thursday, July 13, 2023 7:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OSA-ICC question In a z/OS environment OSA-ICC's can be used two ways. One way is as a z/OS system console. I know you can require a login on a console, but I'm not sure what you may be able to see or do if you are not logged in. I don't think you can issue commands, you may just be able to see messages roll across the console. If you don't require console login's then whomever can "telnet" to the OSA-ICC has console access. This does NOT require Communication Server to be active. The other way is as a non-SNA 3270 terminal controlled by VTAM. Which requires Communication Server to be active and for the devices to be configured in VTAM as non-SNA terminals. In both cases you need to know the IP address and port that the OSA-ICC is listening on at a minimum. In most (maybe all) you also need to know what LU name to request. If you are running z/VM, I'm not sure how it may deal with OSA-ICC's as I don't have z/VM experience with OSA-ICC's. On Wed, 12 Jul 2023 08:06:51 -0500, Joe Monk <joemon...@gmail.com> wrote: >I think he was asking about the hosting company. > >They will always have access via the HMC. In addition, since their network >will be used to access the OSA-ICC port, they will have access via that >method. > >Joe > >On Wed, Jul 12, 2023 at 8:01 AM Tom Longfellow < >000003e29b607131-dmarc-requ...@listserv.ua.edu> wrote: > >> I am confused about which 'access' is at question. >> >> There is access to the card and access to the lpars using the card. >> Basically the wires in and out of the physical OSA-ICC card. >> >> ANYONE that has connectivity to the Ethernet port on the OSA is >> 'accessing' the OSA. >> The 'OSA Specific Utilities' under HMC control then controls what LPARS >> the people who 'access' the OSA can see within your mainframe.. >> The LPARS must also be told about the OSA-ICC. >> >> None of this will give them 'Access' to your operating systems or >> applications. In other words, they will still have to authenticate and >> login just like any users of the systems. >> >> It boils down to the trust you have in your outsourcer. They are the >> fox in charge of this hen house. IF they are sharing the physical OSA >> across all customers, then the OSA-ICC configuration becomes your >> gatekeeper/firewall to keep everyone isolated. >> >> Makes me wonder what the concerns are and what 'accesses' are being >> question. Also, what access? physically, to the applications and data? >> etc. >> >> ---------------------------------------------------------------------- >> 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
