R.S. wrote:
Roy Hewitt wrote:
R.S. wrote:
Not necessarily. 1000 FICON connections sounds seriously, but in fact
it means 2000 connectors "clicks". It has to be done be some human -
hasn't it? So the only additional task for the human is to note cable
number and port number. 2000 records. IMHO spreadsheet is sufficient
as an application.
Not sure exactly what you mean by 2000 clicks..
Each FICON cable has two ends. Each end is to be plugged. When you plug
LC connector correctly you hear "click".
but if it were that simple yes a spreadsheet would suffice..
In case of cables - YES, it is simple. Number of connections doesn't
matter, it's still "two ends of the cable" multiply number of
connections. No complexity added. Even 1000 is not to much for Excel
spreadsheet.
ok, understand, I wasnt really referring to cable records. But even that isn't as simple as
recording the two end points.. ok it is.. but to be effective you needd to record the full end to
end connection across patch panels/Switches/DWDM etc.. Also it needs to tie up with the other config
data.
in fact it's what I end up using (with the data extracted out of SAS).
But my issue is trying to get all the relevant data together and most
*importantly* keeping it up to date without lots of manual updating.
That's a pain. Miscellaneous data sources and records and manual update.
However I wouldn't name the amount of updating as lots.
We'll just have to agree to differ on "lots"... For example say you install a DASD subsystem
connected to 8 CECs via 8 ficon switches.. oh and your also going to install 4 of these in the next
3 months inbetween upgrading 6 of the CECs to Z9 over the next 6 months.. oh did I say replace all
the Ficon directors at the same time.. and you don't have enough free ficon on existing machines, so
you have to juggle around connections from the decomissioned boxes. Oh and then there are the CF
links...Documenting that is time consuming, and also very prone to human error.
The other aspect of large sites that I didn't mention is that the
hardware config tends to change on a very regular basis. The hardware
upgrade process, ie DASD, zbox, is such a continual task that they
typically have dedicated teams with perhaps 3 or 4 staff just doing
hardware planning and HCD! Keeping it all updated is very time consuming!
IMHO not. What's time consuming is process of change - planning, HCD,
physical connections, etc. Documentation adds little effort to the process.
Yes the planning does take time, but it's very dependant on config data and how easy it is to
access. For example within HCD you can't get an overall view of how Pchids are allocated across CSS,
you have to look at each CSS in turn (yes you can scroll right and see Pchid allocation in another
CSS, but only if it is the CSS you are viewing). So you have to extract the data to manipulate it.
Same for relating Pchid to phsical location (STI/Book).. it's in another place, so more time added
to planning.
Well yes, nice in theory.. and it's what we have to do now and then.
Not only does it take a very long time, but tracing fibres is prone to
causing error - have you ever seen fully populated IBM FTS cabinets!
I'm talking about *practice*. BTDT. Again: well signed cables are the key.
I agree, but finding the label is usually the hard bit ;-) especially on IBM fibre jumpers as the
label has a habit of sliding down the fibre leaving a sticky mess!!
My point is that we shouldn't have to do all this manual collating of
data. If I can use the HCD API to extract other HMC type information
such as IOCDS detail, LPAR IPL Details (albeit unsupported!) why cant
the same interface be used to get all the physical hardware details
such as IO Cards installed and how they connect to STIs and Books. It
would be so much easier and more accurate than looking on
ResourceLink. And for new installs, the CFR files could just be loaded
into HCD. In fact I never really understood why the Chpid Mapping tool
was never integrated with HCD.
100% agreed.
Regards
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
