Re: LINKLST into EXTENTS
Thanks to all you responded to my post. No ill effects occurred during the LLA,REFRESH. Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Friday, May 05, 2006 3:01 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS In [EMAIL PROTECTED], on 05/04/2006 at 05:05 PM, (IBM Mainframe Discussion List) [EMAIL PROTECTED] said: Sounds as if refresh means re-read the member pointed to by the original TTR pointer. No, it rereads the directory information. The x06 risk occurs when you compress a linklist library while LLA is still active for it or if someone fetches it at precisely the wrong time. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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 -- 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
Re: LINKLST into EXTENTS
What does the system allow? I was vague, but basically you are *supposed* to use DISP=OLD for an output data set of compress. If you don't, then you are asking for trouble, and you may well get it. The allocations done by the system are simply DISP=SHR so that if you truly use DISP=OLD your allocation will wait. Peter Relson z/OS Core Technology Design -- 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
Re: LINKLST into EXTENTS
At 15:52 -0400 on 05/04/2006, Leverette, Melvin K. wrote about Re: LINKLST into EXTENTS: My recollection is that when you zap a module, the module is updated in place in the load library. Only if it is a PDS - If it is a PDSE then the ZAPPED version is rewritten to a new location which would case problems if the PDSE went into a new extent (due to the available free space being less then the size of the module - space that gets recovered and reusable after the save, BTW) except that a PDSE counts as only one extent and thus would not cause any problem except for anyone who has an old pointer to the location of the pre-zapped version and tries to use it after/if the freed space gets reused. -- 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
Re: LINKLST into EXTENTS
At 17:19 -0400 on 05/04/2006, (IBM Mainframe Discussion List) wrote about Re: LINKLST into EXTENTS: And what does LLA do when the directory entry's TTR points to a new location that is beyond the end of the last extent which existed at the time the library was added to the linklist set? It will save the pointer to an extent that in not in the DEB. Any attempt to access that module will lead to an ABEND due to the bad TTR (either because it spotted the attempt to reference a non-existent extent or due to resolving into a location in extent 1 of the next PDS/PDSE - If the latter, you will probably be pointing into the middle of a load module). BIG GOTCHA WARNING - IF the extension of the PDS makes the new extent look like it maps to extent 1 of the next file in the concatenation then ANY attempt to access not only files in the new extent but ANY file in subsequent PDS Files will x06 ABEND since the TTR will point to the wrong location due to the use of the old DEB (which does not show the new extent). -- 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
Re: LINKLST into EXTENTS
IBM recommends no secondary extents for LNKLST data sets. There will be a health check within the IBM Health Checker for z/OS that checks for exactly that to alert you where you might have an exposure. Someone mentioned compress and hope. You'd better do more than hope. z/OS allocates the libraries so that if you do a legitimate compress it won't go through. If you compress a library outside the bounds of what the system allows, please don't ask for help if things don't work any longer for that library. If you refresh LLA (or UPDATE a library in LLA), LLA will update its directory information for all the members of the library. If you then get LLA to cache the member, subsequent LLA fetches of the member will work. That is a big difficult dangerous if even if you use LLA exits. The reason it is even conceivable is because, when LLA updates an entire library, it also closes and re-opens a DCB that it keeps just for that individual library, and when staging a module into its cache it uses that DCB rather than the LNKLST itself for fetching. Thus the staging of a module can use new extents. But first you have to get it to do that and in most cases, that will only be after several non-LLA fetches have been done (and those, it sounds like, would fail). As has been discussed before, if you have modules in new extents BUT you don't need those modules accessed from existing address spaces (or can recycle those existing address spaces), then dynamic LNKLST is for you. SETPROG LNKLST DEFINE NAME(NEW) COPYFROM(CURRENT) SETPROG LNKLST ACTIVATE NAME(NEW) all done. Peter Relson z/OS Core Technology Design -- 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
Re: LINKLST into EXTENTS
Ted, What sort of performance problem did multiple extents for a PDS ever cause? From the IO point of view PDS access is a skip-sequential operation. You read the directory and then access the member directly at its CCHHRR. Seeking across other members is no different to seeking across extents of other datasets is it? Or is there some history that I'm not aware of? Ron There is no issue if the libraries have gone into extents. There used to be performance issues, but with modern disks, there are no longer any. -- 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
Re: LINKLST into EXTENTS
All, A few (IMHO) clever syprogs I've worked with simply had a small, empty emergency PDS at the head of linklist. New or zapped modules were simply put there followed by an LLA refresh. Subsequent linklist searches would pick up the new modules from this library. The changed modules would be retrofitted to the appropriate library and the emergency library emptied at next maintenance IPL. Is this still a valid practice? Something that is not clear to me. A zapped module is updated in place, therefore it seems to me that an LLA Refresh is not required as the directory has not changed. Is this correct? Another thing that is not clear to me: an LLA Refresh does not cause VLF you throw away all it's cached linklist members, correct? If so, then how is a zapped module invalidated in VLF if the directory is not changed? Is there some sort of notify event from the Zap? Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: Friday, 5 May 2006 7:39 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS IBM recommends no secondary extents for LNKLST data sets. There will be a health check within the IBM Health Checker for z/OS that checks for exactly that to alert you where you might have an exposure. Someone mentioned compress and hope. You'd better do more than hope. z/OS allocates the libraries so that if you do a legitimate compress it won't go through. If you compress a library outside the bounds of what the system allows, please don't ask for help if things don't work any longer for that library. If you refresh LLA (or UPDATE a library in LLA), LLA will update its directory information for all the members of the library. If you then get LLA to cache the member, subsequent LLA fetches of the member will work. That is a big difficult dangerous if even if you use LLA exits. The reason it is even conceivable is because, when LLA updates an entire library, it also closes and re-opens a DCB that it keeps just for that individual library, and when staging a module into its cache it uses that DCB rather than the LNKLST itself for fetching. Thus the staging of a module can use new extents. But first you have to get it to do that and in most cases, that will only be after several non-LLA fetches have been done (and those, it sounds like, would fail). As has been discussed before, if you have modules in new extents BUT you don't need those modules accessed from existing address spaces (or can recycle those existing address spaces), then dynamic LNKLST is for you. SETPROG LNKLST DEFINE NAME(NEW) COPYFROM(CURRENT) SETPROG LNKLST ACTIVATE NAME(NEW) all done. Peter Relson z/OS Core Technology Design -- 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 -- 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
Re: LINKLST into EXTENTS
If I recall, there is end of extents checking that happens whenever you cross an extent boundary; plus in the old days extents would cause seek time as you moved to the location of the new extent. If the PDS was on a very active pack and poorly allocated, you could have the first extent at the beginning of the pack, the second near the end, then the third back near the beginning, etcetera, resulting in what was called thrashing the heads. In the days before our volumes were cached and virtualized we seemed to spend some time and money on dataset placement. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- 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
Re: LINKLST into EXTENTS
On Thu, 4 May 2006 14:38:08 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: IBM recommends no secondary extent allocation for data sets on LNKLST. I have allowed them at times to be allocated with a secondary so SMP/E maintenance doesn't have space problems. COMPRESS(ALL) only does so much on apply.But then I run post apply FDR COMPAKTOR jobs to release unused space, combine extents, etc. prior to cloning a production sysres.It has all depended on how full my sysres or sysres set of volumes have been - which is always changing with new OS versions and sysres device type (3380/1/2/3, 3390/1/2/3, etc.). Anyone using a mod-27 or custom size larger than a 3390-3 for their sysres to keep it on 1 volume? I haven't had an issue with too many DSNs/extents in the LNKLST since prior to DFSMS/MVS 1.3. And since no one updates the MVS data sets on the live sysres, I don't see the harm. Well.. at least until a rookie comes along. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://expertanswercenter.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: LINKLST into EXTENTS
In a recent note, Peter Relson said: Date: Fri, 5 May 2006 07:39:27 -0400 Someone mentioned compress and hope. You'd better do more than hope. z/OS allocates the libraries so that if you do a legitimate compress it won't go through. If you compress a library outside the bounds of what the system allows, please don't ask for help if things don't work any longer for that library. What does the system allow? I was astonished to learn lately that IEBCOPY will compress a data set allocated DISP=SHR, even while another job has it allocated, also SHR. Does the system maintain some sort of exclusive ENQ on LNKLST data sets to disallow their being compressed while in use? Or does it simply rely on the conscientiousness of administrators? -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: LINKLST into EXTENTS
I'm using single Mod-27's for my sysres, and keep all the SMPE target zone, target datasets serverpack supplied HFS datasets, plus a DFDSS dump'd copy of the Serverpack supplied HFS's that matches that maintenance level. The main reason why I dump the HFS's to flat file is because we clone between datacenters(different sysplexes), and this is the easiest(and safest) way to transport the HFS datasets. Those volume average about 85% utilization. Of course, 15% of a Mod-27 is still a lot of space. Dave Dave Jousma Principal Systems Programmer [EMAIL PROTECTED] 616.653.8429 snip Anyone using a mod-27 or custom size larger than a 3390-3 for their sysres to keep it on 1 volume? I haven't had an issue with too many DSNs/extents in the LNKLST since prior to DFSMS/MVS 1.3. And since no one updates the MVS data sets on the live sysres, I don't see the harm. Well.. at least until a rookie comes along. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://expertanswercenter.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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
Re: LINKLST into EXTENTS
In a message dated 5/5/2006 9:08:28 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: If I recall, there is end of extents checking that happens whenever you cross an extent boundary; Limits were always and still are placed on how far a multi-track search key command could search while looking for the directory block that should contain the member info if that member is within that given PDS (in case of concatenating more than one PDS). The end of extent checking is done in the control unit. The only real software performance hit inside the LPAR would occur if the extent containing the directory were not allocated on a cylinder boundary and CKD channel programs were used (they were in the old days). The exact nature of the hit was that on average 1/2 track revolution was necessary before the search could begin; then the whole track had to be searched; end of track was sensed before the directory block was found; an I/O error was signalled; I/O error recovery issued a Sense command and found the condition was an expected one rather than a hard error; the seek address was updated to the next track X+1 in the directory extent; the I/O was restarted; maybe you would be lucky and get that next I/O started before the track had rotated very far, but if not then on average 1/2 of a revolution would occur before the next full track search could be started; etc. So each track in the directory resulted in 1.5 track revolutions if you were lucky, as the directory was searched one track at a time. If on cylinder boundaries, the same series of events occurred at the end of each cylinder in a multi-cylinder directory, but the performance-impacting events occurred much less often. If there were Y tracks in a cylinder, the time to search a whole cylinder was roughly equal to (Y+1/2)*(track revolution time) + minimum seek time to the next cylinder (lots and lots of milliseconds in those old days). Nowadays an ECKD channel program is built that will never stop searching until it comes to the end of the directory, although seek time from one cylinder to the next is involved, with a subsequent necessary extra revolution of the first track of each cylinder (since the minimum seek time is greater than the track revolution time from index point to the beginning of the first directory block). That all assumes SLED. RAID is known only to the DASD vendors. plus in the old days extents would cause seek time as you moved to the location of the new extent. If the PDS was on a very active pack and poorly allocated, you could have the first extent at the beginning of the pack, the second near the end, then the third back near the beginning, etcetera, resulting in what was called thrashing the heads. You can still have seek time performance degradation, although now such impact is impossible to predict with the RAIDing of all DASD. It was also possible in the old days to allocate a huge first extent, a small secondary extent could end up just before the first extent containing the directory, and the seek time to move the arm from the directory block containing the member's beginning TTR could be very low if the member were in the second extent as opposed to very high if that member were at the end of the first extent. The number of extents was irrelevant to this component of total I/O time. The only thing that mattered was the absolute number of cylinders to move the arm from the member's directory entry to where that member began. Another part of the total member read time that was impacted by multiple extents is when the member to be read is not wholly contained within one extent. A seek is necessary (assuming cylinder alignment of the extent) to move to the next extent containing part two of the member. A PDS member can be spread across all extents of the PDS, but the directory must be wholly contained within the first extent. Bill Fairchild -- 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
Re: LINKLST into EXTENTS
Nowadays an ECKD channel program is built that will never stop searching until it comes to the end of the directory, although seek time from one cylinder to the next is involved, I used to believe this was true, but it turns out it is not. A SEARCH KEY CCW cannot execute in the domain of a LOCATE RECORD, so the chain is not strictly ECKD. The description of multi-track SEARCH ID and SEARCH KEY in the 2105 command manual clearly says that they stop at End-of-Cylinder. We recently had a need to study this, and I confirmed this with a GTF trace. It gets a EOC at the end of each cylinder, and ERP restarts it for the next cylinder until the extent is exhausted. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: LINKLST into EXTENTS
In a message dated 5/5/2006 10:24:18 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: I used to believe this was true, but it turns out it is not. A SEARCH KEY CCW cannot execute in the domain of a LOCATE RECORD, so the chain is not strictly ECKD. The description of multi-track SEARCH ID and SEARCH KEY in the 2105 command manual clearly says that they stop at End-of-Cylinder. Right. My error. ECKD will operate as I indicated on multi-track read operations and even on some write operations (e.g., Write CKD Next Track), but there is no way to include any kind of search loop within a Locate Record Domain. The Locate Record operands may define an ID to be searched for by the controller during the Locate Record positioning, but you cannot have your own search commands within a LRD. If a Define Extent or Prefix command begins a chain, then the chain becomes, in my unofficial terminology, ECKD-capable. The controller only enters the true ECKD mode (another unofficial private term) when a Locate Record or Locate Record Extended command is encountered. An ECKD-capable chain may go in and out of true ECKD mode any number of times. Bill Fairchild -- 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
Re: LINKLST into EXTENTS
In [EMAIL PROTECTED], on 05/04/2006 at 12:30 PM, Desi de la Garza [EMAIL PROTECTED] said: Our LINKLIB has gone into extents and are gun shy about doing the REFRESH. If there any way to define a new LINKLIB and make it hot without having to IPL? Create and activate a new linklist set, modeled on the old one. New address spaces will pick up the new extents. You can update the linklist used by existing address spaces, but I'd advise against it. I don't see a secondary extent in the output that you included in your message, so why are you gun shy about doing the REFRESH? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: LINKLST into EXTENTS
In [EMAIL PROTECTED], on 05/04/2006 at 05:05 PM, (IBM Mainframe Discussion List) [EMAIL PROTECTED] said: Sounds as if refresh means re-read the member pointed to by the original TTR pointer. No, it rereads the directory information. The x06 risk occurs when you compress a linklist library while LLA is still active for it or if someone fetches it at precisely the wrong time. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: LINKLST into EXTENTS
In [EMAIL PROTECTED], on 05/04/2006 at 05:19 PM, (IBM Mainframe Discussion List) [EMAIL PROTECTED] said: And what does LLA do when the directory entry's TTR points to a new location that is beyond the end of the last extent which existed at the time the library was added to the linklist set? Notifies your next of kin :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: LINKLST into EXTENTS
In [EMAIL PROTECTED], on 05/04/2006 at 12:00 AM, Ted MacNEIL [EMAIL PROTECTED] said: There is no issue if the libraries have gone into extents. Sure there is; LLA refresh only rereads the directories; it does not rebuild the DEB. However, creating a new linklist set *does* create a new DEB and therefor picks up any new extents. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: LINKLST into EXTENTS
In [EMAIL PROTECTED], on 05/05/2006 at 08:12 AM, Paul Gilmartin [EMAIL PROTECTED] said: I was astonished to learn lately that IEBCOPY will compress a data set allocated DISP=SHR, even while another job has it allocated, also SHR. Does the system maintain some sort of exclusive ENQ on LNKLST data sets to disallow their being compressed while in use? Or does it simply rely on the conscientiousness of administrators? Neither; you can invoke IEBCOPY from a program that does its own ENQ. There have also been OPEN changes in the last decade to minimze the damage. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: LINKLST into EXTENTS
Why not just add the member into another link list library until you fix the extent issue. Do the refresh on only that library. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Desi de la Garza Sent: Thursday, May 04, 2006 1:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: LINKLST into EXTENTS Fellow Listeners, We have applied a super zap to one of our 3rd party products and are required to do a LLA,REFRESH to activate the zap. Our LINKLIB has gone into extents and are gun shy about doing the REFRESH. If there any way to define a new LINKLIB and make it hot without having to IPL? Data Set Name . . . : SYS2.LINKLIB General Data Current Allocation Volume serial . . . : O2APRD Allocated cylinders : 20 Device type . . . . : 3390 Allocated extents . : 1 Organization . . . : PO Maximum dir. blocks : 44 Record format . . . : U Record length . . . : 0 Block size . . . . : 32760 Current Utilization 1st extent cylinders: 20 Used cylinders . . : 14 Secondary cylinders : 20 Used extents . . . : 1 Used dir. blocks . : 12 Creation date . . . : 2001/01/02Number of members . : 75 Referenced date . . : 2006/05/04 Expiration date . . : ***None*** Thanks, Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -- 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 -- 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
Re: LINKLST into EXTENTS
Unless, I'm missing something, I don't see where you have gone into extents. You allocated a primary of 20, and using 14. Dave Dave Jousma Principal Systems Programmer [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark, Kevin D, HRC-Alexandria/EDS Sent: Thursday, May 04, 2006 2:08 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS Why not just add the member into another link list library until you fix the extent issue. Do the refresh on only that library. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Desi de la Garza Sent: Thursday, May 04, 2006 1:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: LINKLST into EXTENTS Fellow Listeners, We have applied a super zap to one of our 3rd party products and are required to do a LLA,REFRESH to activate the zap. Our LINKLIB has gone into extents and are gun shy about doing the REFRESH. If there any way to define a new LINKLIB and make it hot without having to IPL? Data Set Name . . . : SYS2.LINKLIB General Data Current Allocation Volume serial . . . : O2APRD Allocated cylinders : 20 Device type . . . . : 3390 Allocated extents . : 1 Organization . . . : PO Maximum dir. blocks : 44 Record format . . . : U Record length . . . : 0 Block size . . . . : 32760 Current Utilization 1st extent cylinders: 20 Used cylinders . . : 14 Secondary cylinders : 20 Used extents . . . : 1 Used dir. blocks . : 12 Creation date . . . : 2001/01/02Number of members . : 75 Referenced date . . : 2006/05/04 Expiration date . . : ***None*** Thanks, Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -- 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 -- 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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
Re: LINKLST into EXTENTS
Hey Dave, You are rightonly 1 extent. Used extents . . . : 1 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jousma, David Sent: Thursday, May 04, 2006 2:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS Unless, I'm missing something, I don't see where you have gone into extents. You allocated a primary of 20, and using 14. Dave Dave Jousma Principal Systems Programmer [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark, Kevin D, HRC-Alexandria/EDS Sent: Thursday, May 04, 2006 2:08 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS Why not just add the member into another link list library until you fix the extent issue. Do the refresh on only that library. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Desi de la Garza Sent: Thursday, May 04, 2006 1:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: LINKLST into EXTENTS Fellow Listeners, We have applied a super zap to one of our 3rd party products and are required to do a LLA,REFRESH to activate the zap. Our LINKLIB has gone into extents and are gun shy about doing the REFRESH. If there any way to define a new LINKLIB and make it hot without having to IPL? Data Set Name . . . : SYS2.LINKLIB General Data Current Allocation Volume serial . . . : O2APRD Allocated cylinders : 20 Device type . . . . : 3390 Allocated extents . : 1 Organization . . . : PO Maximum dir. blocks : 44 Record format . . . : U Record length . . . : 0 Block size . . . . : 32760 Current Utilization 1st extent cylinders: 20 Used cylinders . . : 14 Secondary cylinders : 20 Used extents . . . : 1 Used dir. blocks . : 12 Creation date . . . : 2001/01/02Number of members . : 75 Referenced date . . : 2006/05/04 Expiration date . . : ***None*** Thanks, Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -- 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 -- 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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 -- 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
Re: LINKLST into EXTENTS
Your display only shows 1 used extent - i.e. primary only. No problem. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- 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
Re: LINKLST into EXTENTS
On Thu, 4 May 2006 14:11:48 -0400 Jousma, David [EMAIL PROTECTED] wrote: :Unless, I'm missing something, I don't see where you have gone into :extents. You allocated a primary of 20, and using 14. Correct. Also, ZAP alone will not require a new extent. :-Original Message- :From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On :Behalf Of Clark, Kevin D, HRC-Alexandria/EDS :Sent: Thursday, May 04, 2006 2:08 PM :To: IBM-MAIN@BAMA.UA.EDU :Subject: Re: LINKLST into EXTENTS : :Why not just add the member into another link list library until you fix :the extent issue. Do the refresh on only that library. : :-Original Message- :From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On :Behalf Of Desi de la Garza :Sent: Thursday, May 04, 2006 1:31 PM :To: IBM-MAIN@BAMA.UA.EDU :Subject: LINKLST into EXTENTS : : :Fellow Listeners, : :We have applied a super zap to one of our 3rd party products and are :required to do a LLA,REFRESH to activate the zap. : :Our LINKLIB has gone into extents and are gun shy about doing the :REFRESH. :If there any way to define a new LINKLIB and make it hot without having :to IPL? : :Data Set Name . . . : SYS2.LINKLIB : :General Data Current Allocation : : Volume serial . . . : O2APRD Allocated cylinders : 20 : Device type . . . . : 3390 Allocated extents . : 1 : Organization . . . : PO Maximum dir. blocks : 44 : Record format . . . : U : Record length . . . : 0 : Block size . . . . : 32760 Current Utilization : 1st extent cylinders: 20 Used cylinders . . : 14 : Secondary cylinders : 20 Used extents . . . : 1 : Used dir. :blocks . :: 12 : Creation date . . . : 2001/01/02Number of members . : 75 : Referenced date . . : 2006/05/04 : Expiration date . . : ***None*** -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: LINKLST into EXTENTS
In a message dated 5/4/2006 12:30:48 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Our LINKLIB has gone into extents and are gun shy about doing the REFRESH. If there any way to define a new LINKLIB and make it hot without having to IPL? The display shows only one extent, so no problem. But what if it showed more? I would think that a REFRESH was totally safe (if the zapped product were the only thing in the linklib that had been changed), but defining a new LINKLIB and making it hot without an IPL would be either dangerous or impossible. Bill Fairchild -- 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
Re: LINKLST into EXTENTS
Our LINKLIB has gone into extents and are gun shy about doing the REFRESH. There is no issue if the libraries have gone into extents. There used to be performance issues, but with modern disks, there are no longer any. The linklist, like any library concatenation, has to be less than 256 extents. Each library counts as one. Each additional PDS extent counts, as well. PDSE's count as a single extent, regardless. This 'issue' was posted, last week, almost word for word. The answer hasn't changed. - -teD O-KAY! BLUE! JAYS! Let's PLAY! BALL! -- 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
Re: LINKLST into EXTENTS
If it has gone into extents since the linklist set was activated, then there are concerns. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, May 03, 2006 8:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS Our LINKLIB has gone into extents and are gun shy about doing the REFRESH. There is no issue if the libraries have gone into extents. There used to be performance issues, but with modern disks, there are no longer any. The linklist, like any library concatenation, has to be less than 256 extents. Each library counts as one. Each additional PDS extent counts, as well. PDSE's count as a single extent, regardless. This 'issue' was posted, last week, almost word for word. The answer hasn't changed. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: LINKLST into EXTENTS
In a message dated 5/4/2006 2:49:11 P.M. Central Standard Time, [EMAIL PROTECTED] writes: If it has gone into extents since the linklist set was activated, then there are concerns. Right. My scenario was that they copied the module(probably a big one) to see if the VER/REP worked and the checksum was valid. Then they were gonna copy it back into it's usual resting place but would cause the PDS to take an extent. Always something.. -- 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
Re: LINKLST into EXTENTS
My recollection is that when you zap a module, the module is updated in place in the load library. The module remains at the same location, so the pointer in the LNKLST is still correct. If the module is cached in VLF, then it takes a refresh to pick up the change. If the module is not cached in VLF but is a module that is read at start up by a subsystem or started task, then the subsystem may need to be restarted. If you update a module with a linkedit or copy it from another library, then it is re-written and the library may go into extents. The new extent would not be known by LNKLST and you will get an 806 abend when the program is called. Depending on what is in the library, you may be able to compress and LLA refresh to get it back within the known extents (i.e. this can be dangerous to disastrous, it requires an in-depth knowledge of what is in the library and how it is used). We have replaced entire versions of products in production by building a new LNKLST, activating it, and making it the system default. There is a risk, but if you have a tired and true process to follow and have tested in a systems programmer test LPAR before hand, it can save IPL'es. We get maybe six IPL'es a year. Ken -- 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
Re: LINKLST into EXTENTS
OK. Thanks to everyone that has responded. Everyone was been extremely helpful. I forwarded some of the responses to the vendor(Fischer Intn'l -IOF) and they have agreed that the -- ZAP rewrites the tracks in the original location. IMASPZAP uses no extra space, hence will never cause a new extent. I am now waiting for mgmt to give the go-ahead for the LLA,REFRESH. Thanks, Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [ mailto:IBM-MAIN@BAMA.UA.EDU mailto:[EMAIL PROTECTED] On Behalf Of Leverette, Melvin K. Sent: Thursday, May 04, 2006 2:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS My recollection is that when you zap a module, the module is updated in place in the load library. The module remains at the same location, so the pointer in the LNKLST is still correct. If the module is cached in VLF, then it takes a refresh to pick up the change. If the module is not cached in VLF but is a module that is read at start up by a subsystem or started task, then the subsystem may need to be restarted. If you update a module with a linkedit or copy it from another library, then it is re-written and the library may go into extents. The new extent would not be known by LNKLST and you will get an 806 abend when the program is called. Depending on what is in the library, you may be able to compress and LLA refresh to get it back within the known extents (i.e. this can be dangerous to disastrous, it requires an in-depth knowledge of what is in the library and how it is used). We have replaced entire versions of products in production by building a new LNKLST, activating it, and making it the system default. There is a risk, but if you have a tired and true process to follow and have tested in a systems programmer test LPAR before hand, it can save IPL'es. We get maybe six IPL'es a year. Ken -- 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 http://bama.ua.edu/archives/ibm-main.html -- 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
Re: LINKLST into EXTENTS
Less disruptive than LLA REFRESH is to code a CSVLLAxx member in PARMLIB to selectively refresh just the one library. If you create CSVLLAIO, then issue command F LLA,UPDATE=IO to refresh just that one. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Desi de la Garza Sent: Thursday, May 04, 2006 4:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS OK. Thanks to everyone that has responded. Everyone was been extremely helpful. I forwarded some of the responses to the vendor(Fischer Intn'l -IOF) and they have agreed that the -- ZAP rewrites the tracks in the original location. IMASPZAP uses no extra space, hence will never cause a new extent. I am now waiting for mgmt to give the go-ahead for the LLA,REFRESH. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: LINKLST into EXTENTS
The one thought I had is: Are there any application libraries in the Linklst? Or are there any updates in this library other than the one you did? Would you be bringing into the environment new changes that the applications are not expecting. I have had a couple of situations where someone added something on the fly, did not tell anyone and then BOOM we had a fun time trying to determine what changed and how to back it out. Lizette Koehler -- 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
Re: LINKLST into EXTENTS
If it has gone into extents since the linklist set was activated, then there are concerns. Okay? What are they? That is the whole purpose of the refresh. If you don't do the refresh, then there are definitely issues. - -teD O-KAY! BLUE! JAYS! Let's PLAY! BALL! -- 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
Re: LINKLST into EXTENTS
Ted MacNEIL wrote: If it has gone into extents since the linklist set was activated, then there are concerns. Okay? What are they? That is the whole purpose of the refresh. If you don't do the refresh, then there are definitely issues. LLA refresh does not pick up new LNKLST extents. Only building/activating/updating a new LNKLST set can do that. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: LINKLST into EXTENTS
Correct. ZAP rewrites the tracks in the original location. IMASPZAP uses no extra space, hence will never cause a new extent. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday, May 04, 2006 3:56 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS Ted MacNEIL wrote: If it has gone into extents since the linklist set was activated, then there are concerns. Okay? What are they? That is the whole purpose of the refresh. If you don't do the refresh, then there are definitely issues. LLA refresh does not pick up new LNKLST extents. Only building/activating/updating a new LNKLST set can do that. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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 -- 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
Re: LINKLST into EXTENTS
LLA refresh does not pick up new LNKLST extents. Only building/activating/updating a new LNKLST set can do that. Okay. Any day you learn something new is a good day. I can't believe I didn't know that. At the Bank I used to work at, we didn't allow for secondary extents in link list libraries. - -teD O-KAY! BLUE! JAYS! Let's PLAY! BALL! -- 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
Re: LINKLST into EXTENTS
In a message dated 5/4/2006 3:56:07 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: LLA refresh does not pick up new LNKLST extents. Sounds as if refresh means re-read the member pointed to by the original TTR pointer. So a refresh will only read in a changed member if that member was superzapped in place? It won't go to the directory to pull in a possibly new TTR which could possibly point to a new extent? LLA would have to re-OPEN its DCB in that case. Sounds as if it must keep its extent list in sync with the linklist extents in the pseudo-opened DCB pointed to by CVT. Bill Fairchild -- 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
Re: LINKLST into EXTENTS
Not allowing secondary allocation for linklisted libraries is definitely a good practice. It can help to avoid so many headaches, such as the potential one described by the OP. With DASD cheap today, it's good practice to just over-allocate linklisted libraries so maintenance can be applied or new modules introduced without causing new extents to be taken. This is especially true for those shops where IPLs are few and far between. Otherwise you're looking at creating new linklist sets and activating them and facing the issue of different tasks using different linklist sets which can possibly be 'fixed' with the potentially dangerous SETPROG LNKLST,UPDATE,JOB= command. The only time you might be able to get away with a linklisted library going into extents, is to compress it and hope it goes back to the original number of extents which existed when the linklist set was activated. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, May 03, 2006 8:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS LLA refresh does not pick up new LNKLST extents. Only building/activating/updating a new LNKLST set can do that. Okay. Any day you learn something new is a good day. I can't believe I didn't know that. At the Bank I used to work at, we didn't allow for secondary extents in link list libraries. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: LINKLST into EXTENTS
The refresh/update will re-read the directory, but subsequently only has access to the extents which existed at the time the library was added to the linklist set. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Thursday, May 04, 2006 5:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS In a message dated 5/4/2006 3:56:07 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: LLA refresh does not pick up new LNKLST extents. Sounds as if refresh means re-read the member pointed to by the original TTR pointer. So a refresh will only read in a changed member if that member was superzapped in place? It won't go to the directory to pull in a possibly new TTR which could possibly point to a new extent? LLA would have to re-OPEN its DCB in that case. Sounds as if it must keep its extent list in sync with the linklist extents in the pseudo-opened DCB pointed to by CVT. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: LINKLST into EXTENTS
(IBM Mainframe Discussion List) wrote: LLA refresh does not pick up new LNKLST extents. Sounds as if refresh means re-read the member pointed to by the original TTR pointer. So a refresh will only read in a changed member if that member was superzapped in place? It won't go to the directory to pull in a possibly new TTR which could possibly point to a new extent? LLA would have to re-OPEN its DCB in that case. Sounds as if it must keep its extent list in sync with the linklist extents in the pseudo-opened DCB pointed to by CVT. LLA is a directory cache. Refresh means re-read the directory. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: LINKLST into EXTENTS
In a message dated 5/4/2006 4:15:58 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: The refresh/update will re-read the directory, but subsequently only has access to the extents which existed at the time the library was added to the linklist set. And what does LLA do when the directory entry's TTR points to a new location that is beyond the end of the last extent which existed at the time the library was added to the linklist set? Bill Fairchild -- 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
Re: LINKLST into EXTENTS
I did learn something new. Thanks listers And here after we build the new linklst, 2ndry extents will no longer be allowed also. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, May 03, 2006 7:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS LLA refresh does not pick up new LNKLST extents. Only building/activating/updating a new LNKLST set can do that. Okay. Any day you learn something new is a good day. I can't believe I didn't know that. At the Bank I used to work at, we didn't allow for secondary extents in link list libraries. - -teD O-KAY! BLUE! JAYS! Let's PLAY! BALL! -- 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 -- 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
Re: LINKLST into EXTENTS
Some flavor of x06 abend (106, 806). Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Thursday, May 04, 2006 5:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS In a message dated 5/4/2006 4:15:58 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: The refresh/update will re-read the directory, but subsequently only has access to the extents which existed at the time the library was added to the linklist set. And what does LLA do when the directory entry's TTR points to a new location that is beyond the end of the last extent which existed at the time the library was added to the linklist set? *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: LINKLST into EXTENTS
(IBM Mainframe Discussion List) wrote: And what does LLA do when the directory entry's TTR points to a new location that is beyond the end of the last extent which existed at the time the library was added to the linklist set? It simply caches the new TTR value -- like always. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: LINKLST into EXTENTS
. . . and the result is fetch failures when someone needs the modules in question. Jon == bitten before snip (IBM Mainframe Discussion List) wrote: And what does LLA do when the directory entry's TTR points to a new location that is beyond the end of the last extent which existed at the time the library was added to the linklist set? It simply caches the new TTR value -- like always. /snip -- 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
Re: LINKLST into EXTENTS
Imbriale, Donald (Exchange) wrote: Some flavor of x06 abend (106, 806). No! (You were fine until then.) LLA will refresh the directory cache without incident. The abends you speak of will occur only if/when some program attempts to use that cached TTR value to load a module. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: LINKLST into EXTENTS
In a message dated 5/4/2006 4:27:20 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: It simply caches the new TTR value -- like always. It would seem that a validation against the maximal TTR would be friendlier than simply caching the new value and letting program fetch break some unpredictable time later. Bill Fairchild -- 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
Re: LINKLST into EXTENTS
Been there, OUCH!!! -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Thursday, May 04, 2006 4:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS . . . and the result is fetch failures when someone needs the modules in question. Jon == bitten before snip (IBM Mainframe Discussion List) wrote: And what does LLA do when the directory entry's TTR points to a new location that is beyond the end of the last extent which existed at the time the library was added to the linklist set? It simply caches the new TTR value -- like always. /snip -- 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 -- 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
Re: LINKLST into EXTENTS
Just got a little ahead of myself in the process. I was checking my scars from past episodes and skipped over the refresh OK one and went right to the x06 one. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday, May 04, 2006 5:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: LINKLST into EXTENTS Imbriale, Donald (Exchange) wrote: Some flavor of x06 abend (106, 806). No! (You were fine until then.) LLA will refresh the directory cache without incident. The abends you speak of will occur only if/when some program attempts to use that cached TTR value to load a module. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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
Re: LINKLST into EXTENTS
(IBM Mainframe Discussion List) wrote: It simply caches the new TTR value -- like always. It would seem that a validation against the maximal TTR would be friendlier than simply caching the new value and letting program fetch break some unpredictable time later. IBM recommends no secondary extent allocation for data sets on LNKLST. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: LINKLST into EXTENTS
In a message dated 5/4/2006 4:38:32 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: IBM recommends no secondary extent allocation for data sets on LNKLST. Problem solved! Enhance the documentation. Bill Fairchild -- 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
