|
View previous topic :: View next topic
|
| Author |
Message |
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
| How does an esoteric unit (SYSDA, DISK, 3390) know where to point to. I'm using SYSDA in my jobs (under Hercules) and they all go to one of the "system" packs, which is not what I really want. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
I guess that the reason id that You have only one storage pack ( ZASYS1 )
I added stor01/stor02/stor03/stor04 with mount attribute STORAGE
a work01/work02/work03/work04 with mount attribute public
and everything gets allocated as it should
all non specific permanent requests are allocated on the storxx volumes
all the non specific temporary are allocated on the workxx volumes
( if You want we can continue the discussion privately ) |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 580
Location: London
|
|
|
|
These 'generic' and 'esoterics' unit names are defined in the IODF configuration by the Sysprogs or Hardware people who assign particular unit addresses to the esoteric name.
You need to talk to your Storage people to see what they do with these unit names in the ACS routines as these can determine if the dataset becomes SMS managed or not. If they're managed then the unit name is irrelevent as SMS determines where the data will go, i.e. what Storgrp.
It sounds like your dataset name may be NONSMS and in that case the system will just look for any volume mounted as STORAGE status that is on a device defined to the esoteric or generic unit name you're using.
You need to find out why your data is not being SMS managed and whether it should be or not. Talking to your Storage people would be a good start. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Pete,
Please notice this a Hercules install/implementation (runs on a PC). . . 
Probably not a storage person involved (other than Robert).
One thing about Hercules, you get to do literally everything. . . |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 580
Location: London
|
|
|
|
Thanks Dick, I missed that!
Never had any experience with Hercules so I'll run away now! |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
You're welcome.
Hercules is free - you too can have your own mvs system at home. . .
d |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
| enrico-sorichetti wrote: |
I guess that the reason id that You have only one storage pack ( ZASYS1 )
I added stor01/stor02/stor03/stor04 with mount attribute STORAGE
a work01/work02/work03/work04 with mount attribute public
and everything gets allocated as it should
all non specific permanent requests are allocated on the storxx volumes
all the non specific temporary are allocated on the workxx volumes |
I've added three storage (ZSTOR1/2/3) and three public (ZWORK1/2/3) volumes, and I've also managed to change the IODF configuration so that it no longer maps SYSDA to VIO, which was also causing problems - it's quite fun and intellectually challenging to be thrown in the very deep!
By the way, why is SYS1.IPLPARM not cataloged? |
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
| Quote: |
By the way, why is SYS1.IPLPARM not cataloged?
|
No reason for it to be cataloged as when it is used the Catalog Address Space is not yet active.It should be on the same disk as the IODF dataset |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| SYSn.IPLPARM can be cataloged to make it easier to reference for the system programmer, but the system will not use the catalog to find it since the catalog address space doesn't show up quite that early. And if you do catalog it, don't go changing the LOAD parameter for the IPL without changing the catalog entry appropriately -- or you might be wondering why the IPL didn't go as you thought it would! |
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
| Quote: |
| if you do catalog it, don't go changing the LOAD parameter for the IPL without changing the catalog entry appropriately |
Coud you explain, this seems to directly contradict the following statement
| Quote: |
| but the system will not use the catalog to find it |
|
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
cataloging "SYS1.IPLPARM" will make it easier to find it under TSO
it is not needed at IPL time because the volume where it resides is specified by the IPL LOADPARM
in this case IPL from device A80
"SYS1.IPLPARM" is on device A82 so the loadparm is 0A82xx
where xx is the suffix of the LOADxx member to be used |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| I didn't explain clearly enough -- if the system programmer uses the cataloged SYS0.IPLPARM (or SYS1.IPLPARM or ...) on disk pack IPL000, but then copies everything to disk pack IPL001 to test something, getting to the SYSn.IPLPARM data set through the catalog would get you the old data set, not the new one on pack IPL001. This could lead to IPL problems. The system will always use the load parameter address to find the SYSn.IPLPARM not the catalog. |
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
Robert Thanks for the clarification now I understand exactly what you meant .
| Quote: |
it is not needed at IPL time because the volume where it resides is specified by the IPL LOADPARM
|
Enrico this is not strictly correct the loadparm specifies the address of the disk from where the system will load the IODF. If the IPLPARM exists it will also be on this disk |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| dick scherrer wrote: |
| One thing about Hercules, you get to do literally everything. . . |
Ask me - doing it every day and yet not succeeded, trying to get it up and running! IPLs are not like installing some software for windows, i understad now...and when you had been just an Application Developer for zOS- these things are not that friendly! But for sure, they are fun! |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Anuj, there's nothing quite like the feeling of updating z/OS, doing an IPL and having the machine go into a wait state! Especially if it is your production LPAR that just went into the wait state! And since it is 0 dark 30 when you get to IPL production, of course, that just raises the tension level since those production jobs have to complete by morning .... |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| There is always the possibility to fall back to another (the old) sysres. |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 580
Location: London
|
|
|
|
| For SYS1.IPLPARM you can catalog it to VOLUME(******) which means the system will look for it on the current active SYSRES volume by default. |
|
| Back to top |
|
|
nevilh
Active User
Joined: 01 Sep 2006
Posts: 262
|
|
|
|
| Quote: |
| For SYS1.IPLPARM you can catalog it to VOLUME(******) |
Yes you could but as Robert so correctly pointed out earlier
| Quote: |
This could lead to IPL problems. The system will always use the load parameter address to find the SYSn.IPLPARM not the catalog
|
|
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 580
Location: London
|
|
|
|
Yes but if you have a standard of putting it on the SYSRES it shouldn't be an issue.
You could also use symbolics from the IEASYM* member of parmlib in the volser field so it corresponds to the appropriate SYSRES volser or a different volser. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| Yes but if you have a standard of putting it on the SYSRES it shouldn't be an issue. |
poor standard IMHO!
we are heading toward a lengthy and heated discussion here 
the SYSx.IPLPARM must reside in the same volume as the IODF dataset
and putting the IODF on the sysres volume is a bad practice
( what about sysres switching after maintenance ??? )
if You choose not to go the IPLPARM dataset route the parameters will be in SYS1.PARMLIB ...
and and and we could talk for hours about the quirks of system volumes setup |
|
| Back to top |
|
|
|
|
