|
View previous topic :: View next topic
|
| Author |
Message |
farhad_evan
New User
Joined: 30 Aug 2014
Posts: 24
Location: UK
|
|
|
|
Hi
Do to kack of space I need to redefine SYS1.PROOCLIB .Do i need to consider about something before do it ?
Regards |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| Do i need to consider about something before do it ? |
How many LPARs share the SYS1.PROCLIB data set? Is SYS1.PROCLIB indirectly cataloged? Are you planning on bringing JES2 / JES3 down before redefining SYS1.PROCLIB? If not, how will you prevent JES problems? From APAR II04595:
| Quote: |
THE CUSTOMER'S PROBLEM STARTS WHEN HE PREPARES FOR THE IPL
BY BRINGING JES2 DOWN GRACEFULLY. THE CLOSE FUNCTION PERFORMED
AT END OF JOB WILL CAUSE INDIRECTLY CATALOGED NONVSAM DATASETS
(PROCLIB) TO BE RECATALOGED. WHEN THE DATASET WAS OPENED, NO
TTR WAS PASSED TO OPEN, SO A FULL VTOC SEARCH WAS DONE AND THE
TTR OF THE FORMAT 1 DSCB (FORMAT1) WAS SAVED IN THE JFCB. IN
ADDITION, AN INDICATOR WAS TURNED ON IN THE JFCB TO TELL
TERMINATION TO RECATALOG THE DATASET. TERMINATION DOES A
CAMLST RECATALOG WHICH GETS TRANSLATED TO A VSAM/ICF CATALOG
PARMLIST ALTER NEWNAME WITH THE NEW AND OLD NAME THE SAME, BUT
USING THE TTR PASSED IN THE VOLUME LIST.
SO THE CATALOG-DIRECT WHICH WAS DONE EARLIER IS UNDONE
AND THE DATASET IS NOW CATALOGED DIRECTLY TO THE VOLUME WHERE
IT ORIGINALLY RESIDED. WHEN JES2 IS RESTARTED, THE OPEN FAILURE
OCCURS TRYING TOP OPEN THE MOVED DATASET. |
If the lack of space (which is what I assume you meant by "kack of space" in your post) is no secondary allocation, you can override the secondary allocation in a job and let it go into secondary extents. If the lack of space is no directory space, and you have PDS86 installed at your site, use that to add directory space to the data set. If you feel you have no choice but to move SYS1.PROCLIB to another volume to give it more space, be aware that you could have problems from doing so and I would HIGHLY recommend an IPL immediately after SYS1.PROCLIB has been moved. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Robert Sample wrote: |
| ... If the lack of space (which is what I assume you meant by "kack of space" in your post) is no secondary allocation, you can override the secondary allocation in a job and let it go into secondary extents. ... |
Personal opinion here. This is not a good idea for a permanently open data set such as SYS1.PROCLIB, as the other job (or jobs) that have the data set open will not see the additional extent, which will cause an I/O error if the job attempts to use the additional extent. At least with JES2, you may be able to persuade it to reopen the data set, though this procedure would have to be repeated with every JES2 in the complex that shares the data set.
| Robert Sample wrote: |
| ... If the lack of space is no directory space, and you have PDS86 installed at your site, use that to add directory space to the data set. ... |
Agreed. There may be other methods to add directory blocks in place beyond the PDS86 program Mr. Sample suggests. Adding directory blocks in place should be regarded the same as a PDS "compress:" back it up first.
| Robert Sample wrote: |
| ... If you feel you have no choice but to move SYS1.PROCLIB to another volume to give it more space, be aware that you could have problems from doing so and I would HIGHLY recommend an IPL immediately after SYS1.PROCLIB has been moved. |
Agreed. At least, force JES2 down with $PJES2,ABEND and restart JES2.
Several years ago I thought to write a standalone utility to add directory blocks. I think I know exactly how to do this, but for all that I got lost actually writing the process. Since I, personally, had no immediate need to add directory blocks, and had a possible, though untested, process for this task if I ever needed it, I decided to quit. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| Do i need to consider about something before do it ? |
I think you've got your answer -- if you redefine SYS1.PROCLIB, there are things to consider BEFORE embarking on the task. JES uses SYS1.PROCLIB and hence keeps it open; changing the data set without considering JES implications could lead to an unstable JES system at best, repeated IPLs at worst.
You didn't provide much information for us to help you, but depending upon why you want to redefine SYS1.PROCLIB, whether you're using JES2 or JES3, how many LPARs are sharing the SYSRES volume SYS1.PROCLIB is on, and whether or not SYS1.PROCLIB is indirectly cataloged -- you could potentially have an easy time redefining it or a very difficult time redefining it. |
|
| Back to top |
|
|
farhad_evan
New User
Joined: 30 Aug 2014
Posts: 24
Location: UK
|
|
|
|
Hi
Thanks for your suggestion and sorry if the post not clear enough.
SYS1.PROCLIB is on one LPAR and it isn't indirectly cataloged.
| Quote: |
| If the lack of space is no directory space |
Yes lack of directory space is our problem and we don't have PDS86 on our site. So I think stop JES2 before change is best way.
Is there any document or manual to do it ?
thanks |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
check if SYS1.PROCLIB members have the ISPF statistics and delete them
( the statistics )
IMO the infrastructure is less than perfect
the SYS1.* things should be left alone
zOS and JES provide quite a good support for user libraries
so there is no need to muck around with the installation provided libraries |
|
| Back to top |
|
|
Willy Jensen
Active Member
Joined: 01 Sep 2015
Posts: 712
Location: Denmark
|
|
|
|
Do you have your JES2 set up with dynamic PROCLIB? Then you could create a new one and add it in flight, then move procedures from SYS1.PROCLIB to the new one. I strongly recommend dynamic proclibs. Another option is to have a JES2 procedure with proclib definitions with volser defined with a variable because then you can specify the volser in the start command. Also remember that you can cancel and start JES2 while keeping you TSO up and running.
Finally I agree that you should leave SYS1.PROCLIB alone. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| farhad_evan wrote: |
Hi
Thanks for your suggestion and sorry if the post not clear enough. ... we don't have PDS86 on our site. So I think stop JES2 before change is best way.
Is there any document or manual to do it ?
thanks |
Evidently you did not read read these posts. One of them tells you exactly one method to take down JES2. |
|
| Back to top |
|
|
farhad_evan
New User
Joined: 30 Aug 2014
Posts: 24
Location: UK
|
|
|
|
@enrico-sorichett
Thanks for your reply
Could you please explain me why I must to delete statistics of SYS1.PROCLIB members ?
@Willy Jensen
Thanks for your reply
Unfortunately we don't use of dynamic PROCLIB. I read a little about it thanks for your recommendation.
@steve-myers
Thanks for your reply
I know how I must to stop JES. when I said:
| Quote: |
| Is there any document or manual to do it ? |
I mean I looking for some documents for redefine SYS1.PROCLIB.
Sorry if I have been too ambiguous. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| Could you please explain me why I must to delete statistics of SYS1.PROCLIB members ? |
so that the same number of directory blocks will be able to handle 3 times the number of members
generally a directory entry is
8 bytes for the member name
3 bytes for the TTR ( 2 bytes for the track 1 byte for the record ) offset
1 byte for flags and the length of the user data
for load dataset is a bit more complicated
( some load module related info is contained in the user data part of the directory entry)
for fb/vb datasets the entry size depends on the ispf statistics being there or not
each entry will be
12 bytes without statistics
42 bytes with statistics
the ispf statistics are 15 halfords, 30 bytes
so each directory block will contain ..
21 entries without statistics
6 entries with statistics
anything between for the mixed case |
|
| Back to top |
|
|
Willy Jensen
Active Member
Joined: 01 Sep 2015
Posts: 712
Location: Denmark
|
|
|
|
Something like this:
- make a copy of SYS1.PROCLIB with a new name and bigger space,
- keep your TSO logon active !!!
- stop as much work on the system as you can.
- stop JES2 using command $PJES2,ABEND.
- rename SYS1.PROCLIB.
- rename new dataset to SYS1.PROCLIB.
- start JES2 normally.
I don't think this is documented, but I have done it in the distant past and I know others have too.
You might also want to check the JES2 procedure to see if there are other proclibs where you could move procedures to. You should probably compress SYS1.PROCLIB afterwards. And do a backup beforehand.
And as said earlier see if the JES2 procedure have volser as variables. Some JES2 procedures even have the datasetname as symbolic, which means that you can copy SYS1.PROCLIB and start JES2 using the new name. Then you have a fallback if something goes wong. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
| enrico-sorichetti wrote: |
12 bytes without statistics
42 bytes with statistics
the ispf statistics are 15 halfords, 30 bytes |
And you're forgetting the new and shine extended statistics, potentially gobbling up even more directory space... |
|
| Back to top |
|
|
farhad_evan
New User
Joined: 30 Aug 2014
Posts: 24
Location: UK
|
|
|
|
Thanks a lot everyone for helping me.
We will do it on weekend. |
|
| Back to top |
|
|
|
|
