On Thu, 31 May 2007 09:15:09 -0400, Peter Relson <[EMAIL PROTECTED]> wrote:
>Most 106-F abends are related to extents. > >Activating a new LNKLST set will result in that LNKLST set having all the >current extents in its DEB so no 106-F would occur when using that LNKLST >set unless the data set was subsequently extended. > >I hope you did not compress an in-use LNKLST data set. > Okay, I know I am going to feel stupid after this but since I must be suffering some form of memory overlay/corruption, I would like to understand this correctly. In (a somewhat old) post: http://bama.ua.edu/cgi-bin/wa?A2=ind0402&L=IBM- MAIN&P=R4072&X=790D902F51A97A500F-&Y=greg99999% 40myway.com&m=91723 it was stated: 'Unless you have ensured that no address space is using a LNKLST set that contains a specific data set, you must not rename or delete the data set.' I also thought I read on here somewhere that data sets in the IPL time linklist should never be deleted. I have always thought of a move like this as basically a 'copy' followed by 'delete' followed by 'catalog'. So I would have expected everyone to indicate not to do what the original poster did but many very sharp minds seem to be fine with it. So my questions (I know, there are a bunch so if you don't have time to explain I understand): Did something change since 2004 making this okay now? How is the move not doing a 'delete' of a data set in the IPL linklist or is it that this is permissible? and if permissible, does this mean it is okay to delete and reallocate a library on the same volume using the procedure described? if not, why not? How is a move less of a concern than compressing an in-use LNKLST dataset then doing an LLA refresh? I have in the past compressed vendor program libraries (with all jobs/STCs' for the product stopped) then LLA refresh then restarted the jobs/STC's without any problems. Anyway, I am certainly not trying to contradict anyone, just trying to fix an apparent memory overlay/corruption in my head. Thank you for any (educational) response you care to provide (okay, any response and I take the lumps), Greg ---------------------------------------------------------------------- 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
