Re: Use of zCX
I messed about with this back in the day; it worked well. http://gsf-soft.com/Documents/ISX390.html Subject: Re: Use of zCX From: "PINION, RICHARD W." Date: Thu, 21 Apr 2022 18:52:08 + Does anybody hear remember a software product from a Russian company that allowed one to run Linux as an address space under OS/390? If memory serves me correctly, I think this was in the 1990's, possible early 2000's. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM dates?
If I recall correctly HSM tape support was ~1983, as per: https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS283-141/index.html_locale=en "Hierarchical Storage Manager (5740-XRB) support to utilize the tape OPEN/EOV exits for volume selection and volume verification" Lots of tape advancements in this DFP release... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMSrmm and DFHSM - Tape Expirations
Basically DFSMShsm is an EDM (External Data Manager) and manages its own tapes and needs to communicate with the TMS (Tape Management Subsystem), in this case DFSMSrmm that the tape has changed status, in this case from private to scratch. There's a nice summary @ https://www.ibm.com/support/pages/tapes-released-scratch-without-hsm. Put simply, safeguard in an DFSMSrmm environment, the EDGTVEXT exit is used, the sample provided in the DFSMSrmm product resources works well. If you're using another TMS (E.g. CA-1, TLMS, et al), even in a DFSMSrmm migration scenario, use the ARCTVEXT exit. In a DFSMSrmm migration scenario, ARCTVEXT would take preference and would need to call EDGTVEXT once its processing was complete, to update DFSMSrmm, while running both TMS in parallel during the migration process. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FCP CHIP id
For the zEC12, each FCP channel (CHPID) can support up to 480 subchannels, where each subchannel represents a communication path between software and the FCP channel. Each FCP channel can support up to 480 QDIO queue pairs. This allows each FCP channel to be shared among 480 operating system instances. http://www-01.ibm.com/support/docview.wss?uid=isg2a7ff43cc0a86a31a85257a620052a0a7aid=1 OK, so you had 4 LPAR’s with 120 devices, and you’re trying to add 6 LPAR’s, with the same 120 devices, hence the increase from 480 to 1200 (E.g. 4 LPARs * 120 Devices = 480 10 * 120 = 1200). If you need 10 LPAR’s, then the maximum number of devices per FCP would be 48. If you need 120 devices per FCP, you will have to consider increasing the number of FCP (channels) you’re using. Then you would have to divide 1200 (10 LPARs @ 120 Devices) by 480 (Maximum Number of Devices Supported), which would be 3, rounded up. Subject:Re: FCP CHIP id From: Jake anderson justmainfra...@gmail.com Message Snip We are actually migrating z10(2097-E26) to zEC12( 2827-H43) Mainframe. So, I have updated the Machine type model as well in HCD along with new LPAR defination. Initial I had 4 LPAR but I have added 6 more new LPAR. Also below are my defination of FCP chip id . Can you please suggest what changes I should make to add these FCP chip id's in the access list of these new 6 LPAR's. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FCP CHIP id
If you add an LPAR, you typically increase the number of devices by 100%, and if you add 2 LPAR’s, then by 200% and so on. So, if you have 64 devices defined on your FCP channel, 1 LPAR is 64 devices, 20 LPAR’s is 1280 devices. In this instance, your limit is 480 devices, as per the CBDA291I message. Scratching my head a little, I think 480 is the maximum number of devices/sub-channels/QDIO queue pairs for a single FCP channel on a z10 Mainframe, but as you have specified what you configuration is (E.g. Server Type, FCP SCSI device mapping, number of LPARs. Number of channels, et al), it’s difficult to comment further. http://www-01.ibm.com/support/docview.wss?uid=isg2bb83cb638fd821d985257481006549d9aid=1 Basically you can only define devices/sub-channels/QDIO queue pairs devices to an FCP channel and the message says you’re trying to define 1200… Message Snip Subject:FCP CHIP id From: Jake anderson justmainfra...@gmail.com I was in process of modifying my current IODF and did below changes. 1) Added few more Chip id's including type of FC, OSD 2) added few more partition. 3) All these CHIP id, where I am getting below issue belong to FCP type now when I am trying to active this new changes, I am getting below error. / Sev Msg. ID Message Text _ E CBDA291I Maximum number of 480 device(s) on channel path 0.50 of # processor Z10A exceeded. Actually defined: 1200. -- 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
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