I've seen this happen before (a number of times, actually). By way of background, KIDS gives you the opportunity to disable logins when installing patches or packages, and the installation instructions often tell you to do so. The danger in not doing so is that it is possible that someone will attempt to run a rountine while it is being updated, resulting in a fatal error (or a "hard error" as it is often called in the VistA world).
Unfortunately, there are times when errors occur when KIDS runs, too, and it's possible for the insztallation process to terminate abnormally before re-enabling logins. A thought: Why notstart a background job (not a task) that goes into a loop, repeaetedly sleeping (say 10 seconds), waking up and checking to see if KIDS is still running, and if it is, going back to sleep? If KIDS terminates abnormally, this job could do whatever housecleaning is deemed appropriate. I suspect many people would prefer to leave logins disabled until IRM has a chance to investigate, but there are a lot of people that don't know what to look for. The last time I saw this error, an install was queued (under Taskman), and looking for unsuccessful tasks quickly led us to both the task number and specific error. Greg's opinion: This kind of thing happens far too easily. --- Luke Johnson <[EMAIL PROTECTED]> wrote: > Just thought I'd post a followup. Thanks for the suggestion offered > too! > It was definitely 'weird'... > > Background: previously we had a site license of Cache, and were used > to > bumping into our license limit of ~180 users on the system > simultaneously, and then not being allowed access. However, recently > we > got under the IHS umbrella, and now have a 400 concurrent user > license > for Cache. > This morning, logons to RPMS started blowing up, as I mentioned, and > we > couldn't figure out why. It was obvious that there weren't anywhere > near 400 users on the system. Nor could we get into RPMS to use the > system routines the 'easy' way. > Eventually ITSC (and Jawad) suggested starting Task Man manually (D > ^ZTMB), which we did. We still couldn't immediately get in, but the > machine got VERY busy (it was all disk, but I can honestly say when > our > Solaris9 box hit a run level of 285.6, I was impressed/nervous). A > bit > later apparently a device or two free'd up, and we got a RPMS session > > started. It seems MailMan was doing 'something', and had consumed > all > of our 400 allowed devices after TaskMan restarted. Strange. We > presume MM was delivering some sort of data (Lab Interface, MFI, > ???), > but we're still sorting that out. In the end the box was > inaccessible > for about 3hrs, but all seems normal now. There were about 1200 > tasks > in TaskMan listed as 'unknown' but they don't seem to be affecting > anything now? Guess we'll clear them up later... > > Guess we'll chalk it up to experience... > > Thanks... > > Luke Johnson wrote: > > > Looking for a lead here... our Vista/RPMS system started something > new > > to us this morning... > > > > SEARHC>D ^XUS > > > > Volume set: AKM:SEARHC UCI: SEARHC Device: /dev/pts/5 > > > > Device: /dev/pts/5 > > > > Signons not currently allowed on this processor. > > > > The Solaris server seems fine, Cache seems fine, but it seems like > > RPMS/Vista doesn't want people to log on. We can run most > utilities > > from the Cache prompt; e.g. Taskman start/stop, fileman, etc. > > But it won't let anyone attempt access/verify... From the prompt > we > > can get to programmer mode (D ^XUP)... but when trying to run an > > option it throws this error: > > > > SEARHC>D ^XUP > > > > Setting up programmer environment > > Terminal Type set to: C-VT100 > > > > You have 3146 new messages. > > Select OPTION NAME: TASK MANAGER ZTMMGR Task Manager > > > > WARNING -- TASK MANAGER DOESN'T SEEM TO BE RUNNING!!!! > > > > ==> Sorry, all activity on this volume set is being halted! Try > > again later. > > > > Halting at 9:03 am > > SEARHC> > > > > I've found references to the kernel code (via google) that have the > > > error messages, but it's not clear where to go / what to do to > resolve > > them: > > http://vista.vmth.ucdavis.edu/rtn/XUS3.html > > http://vista.vmth.ucdavis.edu/rtn/XUSCLEAN.html > > > > No idea what precipitated this behavior, system has been stable and > > > the most recent patch was 4-5 days ago. Also, we've tried hauling > the > > database to a second Cache server, and it has the same results, so > it > > definitely seems to be 'within' RPMS. > > > > Thoughts? Thanks, > > Luke > > > > > > > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Judge a man by his questions not his answers." --Voltaire Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
