Re: Alternate Channel Set information and Startio considerations
Hi Jim, Thank you for the very helpful answer. I got sidetracked with work and travel, and did not get back here for a little while. I do appreciate your response. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Alternate Channel Set information and Startio considerations
I am doing Alternate Channel Set research and cannot find much that references it, and nothing in the IBM docs about programming considerations. Not much here on IBM-MAIN in the archives, either. I can't seem to find a field in the UCB that alludes to being the current (sub-)channel set for a device. There is an IOS service to get the Channel Set, but it returns the value at IPL/NIP time. Unfortunately, after a HYPERSWAP, that will be - wrong. Obviously, MVS can find it for console commands and displays, etc. so it must be somewhere. Anyone out there that could share some expertise, please? Also, I have code that builds its own channel programs and issues STARTIO. It is unclear what changes need to be made to detect that a HYPERSWAP has occurred, that the device is now on another Channel Set, and how to successfully access the device under this circumstance. Insights or contacts welcome. Thank you. John Sullivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FRR Parameter Area too small
Thank you all for the insightful comments. John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FRR Parameter Area too small
I have a problem in that the FRR Parameter Area (24 bytes) returned in SETFRR A,PARMAD= is too small! I am having to re-work some code to support 64-bit (and prior 31-bit) callers in SRB mode and am curious what others do in this situation. The 24 byte FRR Parameter area used to hold 6 registers but now only 3 for 64-bit support. The thought of getting storage and later freeing it seems expensive, just to have an Extended FRR Parameter Area. FRR STACK size is fairly small, so not sure if getting 2 areas (2 SETFRR requests) and chaining them is likely to run out and lead to disaster. Also probably frowned upon, i.e. it is both ugly and asking for problems, especially if there is recursion (occasionally can happen). Anyone else hit this? And what have you done to get around it? Thanks, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ANTMAIN takes a lot of CPU
I am glad that the problem was alleviated by reducing the number of volumes in the Storage Group. I would like to add that XBM and the associated BMC Utilities do have options available to turn off the use of Flashcopy. BMC Support would be happy to work with you if you would like assistance to do so. John Sullivan, Sr. Product Developer on XBM with BMC Software, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
