Re: Local MCS Console Solutions
I worked with a local of customer who faced the same challenge. We investigated the market and it really came down to 2 options, previously mentioned. ESCON-FICON converters, or replace the Visara nnL (11L-20L-22L-25L) SCON that doesn’t support FICON, with the CCA-3074, with native FICON support. We worked with the Visara folks on a basis of those 2 cost options, and the fact that one of their products was effectively obsolete with the zEC12 processor, and for us, it was a lower cost solution to go with Visara, after some negotiation. For LPAR support via FICON, 12 for Dual FICON or 20 for Quad FICON as standard, where maximum LPAR’s supported, via license key upgrades, were 20 for Dual FICON and 44 for Quad FICON. BMC MainView Console Management for zEnterprise (AKA ioEnterprise) is seemingly still ESCON only. Bus-Tech had a solution, zCON, that was also ESCON initially, but since Bus-tech were acquired by EMC, I doubt whether zCON is still available. Subject:Local MCS Console Solutions From: Ed Jaffe edja...@phoenixsoftware.com We run a small, mostly lights out operation. When we do turn the lights on, there are local, MCS consoles (Visara NCTs) coax-attached to a Visara SCON-11L controller which multiplexes channel connections for eight LPARs over a single point-to-point ESCON attachment. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local MCS Console Solutions
Good points which is why I don't setup them up as NIP consoles and we only allow access inside our firewall. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Saturday, June 01, 2013 8:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local MCS Console Solutions W dniu 2013-06-02 01:53, Don Williams pisze: The OSA-C configuration works well for us as well. In our case, we have two OSA-C cards for redundancy. Each LPAR has 4 consoles, -0003. Consoles and 0001 (one on each OSA-C card) are our systems programmer consoles that are usually offline. Consoles 0002 and 0003 are the operator consoles. The OSA-C cards have a configuration that assigns each TN3270 session to a particular LPAR and address. We have 44 TN3270 sessions for 11 LPARs. Access to the consoles can be controlled via OSA-C configuration options, normal firewall rules, and SAF logon. SAF logon depends on CONSOLxx settings, but NIP console provide no means of security (*). The most funny thing which can happed is when someone started ICC console, locked his PC and went home. And his console is upper on th NIP console list than yours. Of course the lsit of suspected persons is usually short... Another disadvantage: TCP/IP traffic is not encrypted. (*) Small exception: session definition can contain workstation address, so only the address can connect to the session. A network can be configured in a way where IP counterfeld is not working. BTW: maybe ICC is functionally stabilized, but not dead or moribound, since there is nothing newer to replace ICC. Functionally stabilized could mean we don't think there is room for improvement and we don't want to create bells and whistles. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526- 021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- 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: Unable to mount ZFS
On 5/31/2013 1:08 PM, ibmmain wrote: Well, that the open failed took me by surprise completely. It doesn't fail on the other system that is (almost) identical. There is certainly no access allowed on that system for the ZFS userid. In addition, nothing in the IBM installation docs for z/OS says to authorize the ZFS address space to the data set profiles for the ZFS that are explicitly defined by their customization (and their RACF job goes into ridiculous detail to make sure everything is covered). So it must be something else that causes this 'requirement' on my current system. Is the rest of the world routinely defining at least READ access for the ZFS userid to each and every ZFS dataset that might get mounted? Barbara, From (watch the wrap) http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.ioea700/ioea7d0021001588.htm Note: The DFS user ID must have at least ALTER authority to all VSAM LDS that contain zFS aggregates. A user ID other than DFS can be used to run the zFS started task if it is defined with the same RACF characteristics as shown for the DFS user ID. As an alternative to PERMIT ALTER authority to all VSAM LDS that contain zFS aggregates, you can assign the zFS started task the TRUSTED attribute or you can assign the user ID of the zFS started task the OPERATIONS attribute. For details, see z/OS Security Server RACF Security Administrator's Guide. We chose to go the TRUSTED route. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
Nope. + ICM R2,B'',0(14) IS A BUFFER AVAILABLE + BZ*+10NO,RETURN ZERO + MVC 0(4,14),0(R2) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Saturday, June 01, 2013 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage On Thu, 30 May 2013 19:12:54 -0400, Micheal Butz wrote: Would anyone have examples of Getbuf used with BSAM read I think it might help my problem Are your buffer addresses above the line? If so, they shouldn't be. GETBUF gets a 24-bit BUFCB address from the DCB using ICM 14,7,21(1). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
Look one line above that. This is copied from one of your earlier posts: + ICM 14,7,21(1) LOAD BUFCB ADDRESS Bill On Sun, 2 Jun 2013 18:28:07 -0400, Charles Mills wrote: Nope. + ICM R2,B'',0(14) IS A BUFFER AVAILABLE + BZ*+10NO,RETURN ZERO + MVC 0(4,14),0(R2) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Saturday, June 01, 2013 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage On Thu, 30 May 2013 19:12:54 -0400, Micheal Butz wrote: Would anyone have examples of Getbuf used with BSAM read I think it might help my problem Are your buffer addresses above the line? If so, they shouldn't be. GETBUF gets a 24-bit BUFCB address from the DCB using ICM 14,7,21(1). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
On Sat, 1 Jun 2013 08:30:15 -0500, Bill Godfrey yak36...@yahoo.com wrote: On Thu, 30 May 2013 19:12:54 -0400, Micheal Butz wrote: Would anyone have examples of Getbuf used with BSAM read I think it might help my problem Are your buffer addresses above the line? If so, they shouldn't be. GETBUF gets a 24-bit BUFCB address from the DCB using ICM 14,7,21(1). Also, programs that use BUILD and GETBUF should either have BUFCB coded in the DCB macro, or put the address of the BUFCB created by BUILD into the DCB (as a 24-bit address) before using GETBUF. Check that your program is doing either. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
The BUFCB has to be below the line. Not the buffer addresses. I am actually using it with buffers above the line, so this is not a theoretical conjecture. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Sunday, June 02, 2013 6:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage Look one line above that. This is copied from one of your earlier posts: + ICM 14,7,21(1) LOAD BUFCB ADDRESS Bill On Sun, 2 Jun 2013 18:28:07 -0400, Charles Mills wrote: Nope. + ICM R2,B'',0(14) IS A BUFFER AVAILABLE + BZ*+10NO,RETURN ZERO + MVC 0(4,14),0(R2) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Saturday, June 01, 2013 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage On Thu, 30 May 2013 19:12:54 -0400, Micheal Butz wrote: Would anyone have examples of Getbuf used with BSAM read I think it might help my problem Are your buffer addresses above the line? If so, they shouldn't be. GETBUF gets a 24-bit BUFCB address from the DCB using ICM 14,7,21(1). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Examples of getbuf and build usage
It can be done that way, you are right, but I figure if the OP's program is using BUILD and GETBUF then my statements may prove to help him with his problem, and that's my reason for posting what I did, to help the OP. I could have qualified my statement by adding saying unless the program is copying the BUFCB (and not the buffers) below the line but I thought but who does that? Well, now I know who does that, or something like that. Bill On Sun, 2 Jun 2013 21:55:51 -0400, Charles Mills wrote: The BUFCB has to be below the line. Not the buffer addresses. I am actually using it with buffers above the line, so this is not a theoretical conjecture. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Sunday, June 02, 2013 6:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage Look one line above that. This is copied from one of your earlier posts: + ICM 14,7,21(1) LOAD BUFCB ADDRESS Bill On Sun, 2 Jun 2013 18:28:07 -0400, Charles Mills wrote: Nope. + ICM R2,B'',0(14) IS A BUFFER AVAILABLE + BZ*+10NO,RETURN ZERO + MVC 0(4,14),0(R2) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Godfrey Sent: Saturday, June 01, 2013 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Examples of getbuf and build usage On Thu, 30 May 2013 19:12:54 -0400, Micheal Butz wrote: Would anyone have examples of Getbuf used with BSAM read I think it might help my problem Are your buffer addresses above the line? If so, they shouldn't be. GETBUF gets a 24-bit BUFCB address from the DCB using ICM 14,7,21(1). -- 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: Unable to mount ZFS
Richard, http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.ioea700/ioea7d0021001588.htm After someone had pointed it out, I read it and now I know it needs to be done. That doesn't change the fact that without TRUSTED and without explicit access, the ZFS address space can mount these RDT files just fine on my old ADCD system. No DFS there, either. In the original ADCD RACF database, userid DFS was assigned to ZFS, but it was certainly NOT made trusted. Which nobody noticed, since no RACF profiles are defined for any 'system data sets' on an ADCD system. What bothers me with this is that the RACF documentation (Sysprog Guide) refers me specifically to chapter 1.7 of the InitTuning reference called Assigning the RACF TRUSTED attribute (which I know from previous audits to be the 'bible' that the auditors won't question if followed). The CEA address space made it into that list as of 1.13, so I had every faith that the list is complete. I had consulted that list when I cleaned up the ADCD setup for the STARTED class about half a year ago. I just checked again, ZFS is NOT in that list (that contains names of address spaces, not userids). DFS is in that list, but we don't even have a DFS address space. I am 'surprised' about this incomplete documentation, given how much IBM pushes ZFS. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
