Hi Charles, It does not affect Windows. At this point, we are not *planning* any further 11.1.x releases so we can focus on the 11.2.x and .NEXT releases of UniVerse and moving the technology forward.
I also misspoke on 11.2.4 as it was a mistake in our issue system. It is actually 11.2.3. Regards, Dan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Charles Stevenson Sent: Friday, February 28, 2014 9:31 AM To: U2 Users List Subject: Re: [U2] Recommended 11.1.point release to upgrade to. is this unix-, linux-specific or windows, too? Fix in 11.2.4, but in 11.1.16 too? That's the usual practice, isn't it? On 2/28/2014 6:50 PM, Daniel McGrath wrote: > As an FYI, I'm sitting in a meeting now were we are pulling a check-in to use > a re-entrant version of the function for our latest build to fix this issue. > You should expect a fix in 11.2.4 unless something goes wrong. > > Regards, > Dan > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of John Hester > Sent: Thursday, February 27, 2014 4:59 PM > To: U2 Users List > Subject: Re: [U2] Recommended 11.1.point release to upgrade to. > > We migrated from UV 10.2.7 on RedHat 5.1 x86 to 11.1.13 on RedHat 6.4 x64 > last November. I've since run into a bug that can reveal itself when tty > processes are terminated. It could be unique to linux, but you may want to > watch for it. The symptoms are that terminated UV tty processes disappear > from LISTU and PORT.STATUS, but continue to exist in the process table and > consume a UV per-seat license. I discovered the issue when we ran out of > licenses after a couple of months of uptime and I initially couldn't figure > out where they went. Running the "ps" command at the OS level revealed their > existence. I'm guessing the issue occurs on maybe 1 out of 200 or 300 tty > sessions. > > The root cause of the issue is the localtime() function being called from the > signal handler. The localtime() function is not POSIX async-signal-safe, > which means it can't be safely called from there. The function acquires a > lock which may already be held by the process that was interrupted by the > signal if it too was in localtime(). When this happens, a deadlock is the > result and the process is in limbo forever. I was able to easily work around > the issue by having cron run a script after hours every day to clean up any > hung UV processes and recover the licenses. I opened a ticket with Rocket, > and they're planning to include a fix for the issue in 11.2.4. > > I'm happy to provide my workaround script to anyone who runs into this on a > linux or unix box. Unfortunately, I'm not sure how one would craft a > workaround on Windows. > > -John > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Charles Stevenson > Sent: Thursday, February 27, 2014 12:34 PM > To: U2 Users List > Subject: Re: [U2] Recommended 11.1.point release to upgrade to. > > Reporting back on a question I asked a few months ago. > > We finally upgraded from uv10.2.10 to uv11.1.15 mid-February. > Delays were for internal business reasons having nothing to do with UV or the > upgrade project itself. > > Platform is Windows 2003, which will be upgraded later this year. I'm pushing > for Linux but not holding my breath. > > Primary goal was fear of falling off the back end of maintenance. > > I would have liked 11.2, but it is too new. There is no pressing business > need to be an early adapter. Stability overrides. > > Because several years ago many here on both business & IT sides suffered a UV > upgrade that caused the worst disaster I've ever seen a production system > take. We restored from backup, losing 2 days of production data. That is > the only problem I have ever seen with any UV upgrade. > But I performed the one that went bad so I, personally, can't afford a 2nd > with this same audience. > > So reluctance, nay, fear was high; regression testing, extensive; time > between upgrades, long. (I won't get 11.2 for years unless we migrate > to Linux.) > > Since every point release potentially introduces new bugs as well as fixes, > I hesitated going to the latest 11.1.x, and toyed with going to > a lesser one that more people are running on, pain-free. In the end we > opted for the newest at that time, 11.1.13. If we ever have an issue, Rocket > would probably put the fix in the next release & we'd have to install the > cummulative changes, anyway. So we might as well test for as much as > possible up front. > > Most regression testing was on 11.1.13. By the time we were ready to > install, 11.1.15 was available. There did not appear to be much that > affected us in -.14 & -.15, so I installed -.15 on the test system. > Then mid-February I moved production from 10.2.10 to 11.1.15. > > Due to prior disaster, rollback-readiness to return to 10.2.10 was important. > I exercised that a couple times on dev. > > Issues, comments: > > No issues during regression testing. > > The (default) uvhome is now c:\u2\uv instead of c:\ibm\uv. > I chose to do a "new install" instead of upgrade. > Permissions when installing 11.1.15 on production were tighter than when > I installed 11.1.13 on dev. I don't know why. I like tight > permissions, so I left them & it's ok. Had to be careful to allow update > permissionw wher I created the new uv\errlog. > > MAKE.MAP.FILE had errors on both dev & prod after 11.1.15 install. I > re-catalogued a couple subroutines it cared about and it seems to be ok. It > wasn't a permissions problem. > > Gracious thanks to those on this list who offered advice, Chuck Stevenson > > > On 9/25/2013 12:27 AM, Charles Stevenson wrote: >> We're finally going to upgrade from 10.2.10 to 11.1.[something]. >> >> But which point release? >> >> We're on Win2003. (Linux next year. Baby steps.) . . . _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
