>Is anyone using this and if so, have you seen any downside? Certainly. Allowing z/OS to alter any structure at will can cause loss of signalling paths, for instance. Which health checker will dutifully report as an exception. A lot later.
XES decided that my signalling structures are too big (when I shut down one system), so it started rearranging entries and elements. Then the system came back into the plex, and now the number of paths was insufficient to provide full signalling connectivity. It still had connectivity, but not full connectivity. At the time, I reported that to IBM, and they fobbed me off saying that my structures weren't allocated according to the cfsizer. That was due to the fact that the cfsizer was already migrated to a higher cflevel requiring *a lot* more storage, which we were not using yet. The structures were most certainly sized correctly according to our cflevel (as indicated by the IPL messages from the prior IPL). So IBM refused to even look at the bug (and I still consider this a bug). I have since coded an explicit allowautoalt(NO) on all signalling structures or rather, on all list structures. Also, I have heard (not my experience directly) that the autoalter algorithm kicks in directly after an application is taken down (in that case it was an MQS structure with that MQ being taken down). It could not be restarted because XES had changed the structure (autoaltered) in such a way as to prevent that MQS from starting. These days, I consider allowautoalter a dangerous parm with unpredictable results. Best regards, Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
