Unsolved
This post is more than 5 years old
207 Posts
0
1801
July 21st, 2009 09:00
z9 Mainframe and dmx4
Hello, my background is open systems. However we now have 2 IBM mainframes connected to our dmx4s. EMC set up the intial bin file for the mainframes.
Now we need to add new disk for new IBM projects. If this were for open systems I would usually handle the config myself with SE and SMC - create devices, create striped metas, mapping, masking etc.
Is is possible or normal for customers like me to do the dmx4 config for these new drives that will be used for the z9? I would have to get up on issues like SSIDs, CUs, mod3, mod9 etc. Will SE and SMC handle all the mainframe issues? Or is it better to just let EMC handle all bin changes related to the mainframe.
Now we need to add new disk for new IBM projects. If this were for open systems I would usually handle the config myself with SE and SMC - create devices, create striped metas, mapping, masking etc.
Is is possible or normal for customers like me to do the dmx4 config for these new drives that will be used for the z9? I would have to get up on issues like SSIDs, CUs, mod3, mod9 etc. Will SE and SMC handle all the mainframe issues? Or is it better to just let EMC handle all bin changes related to the mainframe.
No Events found!
brad12341
207 Posts
0
July 21st, 2009 09:00
RobertDudley
2 Intern
•
448 Posts
0
July 21st, 2009 10:00
Allen Ward
4 Operator
•
2.1K Posts
0
July 21st, 2009 10:00
On the Open Systems side we have always taken advantage of EMC to do the initial config of devices, but stopped at that point. Everything beyond that (e.g. Metas, mapping, attributes) we have handled ourselves through CLI and SMC.
On the mainframe side though, our MF storage resources have always found it more effective to plan the config with EMC and then let them do the work with the BIN file. Since the BIN file config is included in the cost of the capacity acquisition, it just makes sense to let them do the heavy lifting.
Overall there is a difference in how we use storage though. MF storage is configured and made visible to the system on initial configuration, then allocated out as required. Open Systems storage is configured on an as needed basis and mapped/masked on demand.
In the end it will be up to you to decide what is most appropriate, but I can tell you that with EMC implementing a BIN load they can somehow squeeze that last little bit more usable capacity out of the drives that we can't seem to access when we have tried configuring our own devices.
xe2sdc
2 Intern
•
2.8K Posts
0
July 22nd, 2009 05:00
brad12341
207 Posts
0
July 22nd, 2009 10:00
MikeMac1
2 Intern
•
292 Posts
0
July 22nd, 2009 11:00
smbl
48 Posts
0
July 23rd, 2009 00:00
I work with DMX-3 in pure MF environment. When we need to add some new volumes (disks) to the system we:
1. make some plans about: CU, SSID, model and emulation, PAV.
2. we need to decide what kind of protection we want to use (RAID), type of replication (SRDF flag), etc.
3. then we prepare HCD definition (hardware configuration definition on z/OS system) with fit to our plans.
4. finally, we send our requirement to EMC support, and ask for new BIN file.
5. EMC send to me ¿draft¿ of configuration to final confirmation.
Probably you can make this definition without EMC support, but in my opinion much easy is to ask EMC. My experience is very positive using this kind of cooperation.
Remember that some settings (I¿m not sure) you can¿t set up as a customer. Example: setting MIDAW=ON (default is off, only in MF environment), setting CFW, ¿
Marcin
P.S.
If you have some question about specific settings in MF, do net hesitate to ask me.
smbl
48 Posts
0
July 23rd, 2009 01:00
It is hard to explain in few words what is CU, PAV, etc.
In MF you can define any devices (disk, tapes, telecommunication devices, etc) using CU (control unit). Each kind of devices use different type of CU. Types of CU you have ¿predefined¿ in z/OS. In each type of CU you can define many types of devices.
When you define DASD volumes you can choose many different emulation (types) of CU (some are very obsolete). For you (z/9 and DMX-4) you can choose:
3390-6 (if you don¿t plan use PAV, or you haven¿t PAV license on DMX)
2105 or 2107 (if you plan to use PAV, and have lic.). 2107 is preferred but check what version of z/OS system you use.
From historical point of view in one CU you can define max 256 devices. Because now DASD boxes can emulate thousands of devices ¿ IBM (for compatibility reason) use ¿logical CU¿. So you can define (as I remember on DMX-4) max 256 LCU, and in each of then 256 devices.
Inside CU you can define devices. Because there are other historical limitation of using devices parallel ¿ IBM introduced several year ago PAV feature. It allows to ¿see¿ one volumes as for example 5 volumes at the same time for the system z/OS. From the beginning, there was static PAV. You assign static: for example 3 PAV to 1 real devices. Then IBM introduces dynamic PAV. System (WLM) assign as many PAV as is needed at the moment dynamically. Now you can use hyperPAV. Generally it works as dynamic PAV but ¿PAV assign process¿ is more effective and you don¿t need waste as many PAV devices.
Each of this feature is available:
a. on specific z/OS version
b. on specific DMX family with specific microcode level and license
There are more interesting publications about PAV (in Power Link too).
Summarize:
Because IBM try to be compatible ¿down¿, many solutions, parameters looks a little bit obsolete, strange, difficult, but it really works: 20 years ago and now
Marcin
P.S.
When you assign SSID to new LCU, you should remember that SSID MUST be unique on each DASD box connected to MF (not only inside one DMX).