Re: Use of zCX

2022-04-21 Thread Michael W. Moss
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?

2021-10-20 Thread Michael W. Moss
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

2019-09-10 Thread Michael W. Moss
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

2013-06-06 Thread Michael W. Moss
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

2013-06-05 Thread Michael W. Moss
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

2013-06-02 Thread Michael W. Moss
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