At SUB^XUTMK, a call is made to %ZTMS5 as follows:
SUB ;Sync the SUB nodes D SUBCHK^%ZTMS5($G(DILOCKTM,2)) Q
But the called routine looks like this:
SUBCHK ;Check for lost submanagers, Update Count N %C,%N,%J,ZT2,ZT3 S %N=""
Note that it doesn't accept parameters. So that is the source of the crash.
I seem to recall that %* routines are implementation specific routines, i.e GT.M is different that Cache'. And I think that these % routines are some created during a setup procedure. Is this the "Christening" process?? Or is that only for Fileman's initialization? During installing of one of the patches, I think I accidentally skipped over an installation process for the patch, and I couldn't go back and do it again.
Any idea how I can get an up to date version of %ZTMS5?
Go ahead and shut things down and run ZTMGRSET. That is what makes the proper non- % routines into % routines. Needless to say, you might want to back up your system before trying this, but I think you should be fine doing it anytime.
> At SUB^XUTMK, a call is made to %ZTMS5 as follows:
> SUB ;Sync the SUB nodes
> D SUBCHK^%ZTMS5($G(DILOCKTM,2))
> Q
> But the called routine looks like this:
> SUBCHK ;Check for lost submanagers, Update Count
> N %C,%N,%J,ZT2,ZT3
> S %N=""
> Note that it doesn't accept parameters. So that is the source of the
> crash.
> I seem to recall that %* routines are implementation specific routines, i.e
> GT.M is different that Cache'. And I think that these % routines are some
> created during a setup procedure. Is this the "Christening" process?? Or
> is that only for Fileman's initialization? During installing of one of the
> patches, I think I accidentally skipped over an installation process for
> the patch, and I couldn't go back and do it again.
> Any idea how I can get an up to date version of %ZTMS5?
To temporarily stop the crashing, I changed my SUBCHK^%ZTMS5 so that it accepts an input variable of DILOCKTM. I put comments in the code to show that I had modified it, using my moniker "//kt"
I then got everyone off the gtm system, shut down taskman, and did DO ^ZTMGRSET. I went through all the questions, and was told that it was loading many different files. And finally the process exited normally.
I then went back and looked at %ZTMS5 using the GTM command line entry 'zedit "_ZTMS5". But the file was unchanged. It had not been recreated. My "//kt" was still there.
On Sunday, August 26, 2012 10:38:47 PM UTC-4, Nancy Anthracite wrote:
> Go ahead and shut things down and run ZTMGRSET. That is what makes the > proper > non- % routines into % routines. Needless to say, you might want to back > up > your system before trying this, but I think you should be fine doing it > anytime.
> -- > Nancy Anthracite
> On Sunday, August 26, 2012, Kevin Toppenberg wrote: > > I have been applying patches, and now my taskman is crashing.
> > At SUB^XUTMK, a call is made to %ZTMS5 as follows:
> > SUB ;Sync the SUB nodes > > D SUBCHK^%ZTMS5($G(DILOCKTM,2)) > > Q
> > But the called routine looks like this:
> > SUBCHK ;Check for lost submanagers, Update Count > > N %C,%N,%J,ZT2,ZT3 > > S %N=""
> > Note that it doesn't accept parameters. So that is the source of the > > crash.
> > I seem to recall that %* routines are implementation specific routines, > i.e > > GT.M is different that Cache'. And I think that these % routines are > some > > created during a setup procedure. Is this the "Christening" process?? > Or > > is that only for Fileman's initialization? During installing of one of > the > > patches, I think I accidentally skipped over an installation process for > > the patch, and I couldn't go back and do it again.
> > Any idea how I can get an up to date version of %ZTMS5?
On Monday, August 27, 2012, Kevin Toppenberg wrote:
> To temporarily stop the crashing, I changed my SUBCHK^%ZTMS5 so that it
> accepts an input variable of DILOCKTM. I put comments in the code to show
> that I had modified it, using my moniker "//kt"
> I then got everyone off the gtm system, shut down taskman, and did DO
> ^ZTMGRSET. I went through all the questions, and was told that it was
> loading many different files. And finally the process exited normally.
> I then went back and looked at %ZTMS5 using the GTM command line entry
> 'zedit "_ZTMS5". But the file was unchanged. It had not been recreated.
> My "//kt" was still there.
> Kevin
> On Sunday, August 26, 2012 10:38:47 PM UTC-4, Nancy Anthracite wrote:
> > Go ahead and shut things down and run ZTMGRSET. That is what makes the
> > proper
> > non- % routines into % routines. Needless to say, you might want to back
> > up
> > your system before trying this, but I think you should be fine doing it
> > anytime.
> > On Sunday, August 26, 2012, Kevin Toppenberg wrote:
> > > I have been applying patches, and now my taskman is crashing.
Supporting Thom's statement, this is the first few lines of %ZTMS5 on my
system
which apparently came from the April 2010 multibuild.
%ZTMS5 ;ISF/RWF - TaskMan utility ;2/19/08 13:46
;;8.0;KERNEL;**275,446**;Jul 10, 1995;Build 36
;Per VHA Directive 2004-038, this routine should not be modified.
Q
;Called from ZTMON1, Jobed from %ZTM5.
SUBCHK(DILOCKTM) ;Check for lost submanagers, Update Count
N %C,%N,%J,ZT2,ZT3,TO
I '$D(DILOCKTM) S DILOCKTM=+$G(^DD("DILOCKTM"),0) ;p446
Select OPTION: PRINT FILE ENTRIES
OUTPUT FROM WHAT FILE: INSTALL//
SORT BY: NAME// ROUTIN
1 ROUTINE INSTALL TIME
2 ROUTINES (multiple)
CHOOSE 1-2: 2 ROUTINES (multiple)
ROUTINES SUB-FIELD: .01 ROUTINES
START WITH ROUTINES: FIRST// ZTMS5
GO TO ROUTINES: LAST// ZTMS5
WITHIN ROUTINES, SORT BY:
FIRST PRINT FIELD: .01 NAME
THEN PRINT FIELD: FILE COMMENT
THEN PRINT FIELD:
Heading (S/C): INSTALL LIST//
START AT PAGE: 1//
DEVICE: TELNET
...EXCUSE ME, HOLD ON...
INSTALL LIST AUG 27,2012 09:44 PAGE 1
NAME
FILE COMMENT
--------------------------------------------------------------------------- -----
ROUTINES: ZTMS5
XU*8.0*275
Released XU*8*275 SEQ #285
XU*8.0*446
WorldVistA Multibuild for April 2010 ;Created on Dec 26, 2011@11:29:51
Thank you Nancy, Thom, and Dave for your replies so far.
I think I may have found part of the problem: My routines folder has a file named "ZTMS5.m" that has the new, correct version, and a "_ZTMS5.m" that has the old version.
So the part that saves the files to _*.m is somehow messed up.
Now to see if I am the one that messed this up or not.
Kevin
== first draft below (before I caught the difference in file names) ===== This is getting even more confusing to me. Here is my $ZROUTINES variable
When I search in /opt/worldvista/EHR/p, there is no _ZTMS5.m file. There is a one in /opt/worldvista/EHR/r. When I bring that file up in an editor (launched from Linux), I get the new, corrrect version of the file.
But when I type ZEDIT "_ZTMS5" from the mumps command line, it brings up the OLD version.
And $TEXT brings up the old version too. ASTRON>for i=1:1:2 write $T(+i^%ZTMS5),! %ZTMS5 ;ISF/RWF - SubManager Utilities ;10/29/2003 ;11/03/2003 13:45 ;;8.0;KERNEL;**275**;Jul 10, 1995;
So I did a ZLINK and repeated the above line, with identical results.
So something is making GT.M hold onto the old version of the module/routine. We reboot our computer ever weekday evening. That will happen tonight. Perhaps there is a process that is holding on.
Nancy asked if I had exited mumps and came back in. Yes, I have, but I haven't rebooted yet. And there are 3 other processes still running (Job 19665 is the process calling ^ZJOB)
ASTRON>do ^ZJOB ...
GT.M Mumps users on 27-Aug-12 19:16:36
Proc. id Proc. name PS Device Routine MODE CPU time -------- --------------- --- -------- -------- ------- 2301 hib -direct00:00:59 2343 hib -direct00:00:05 2355 hib -direct00:01:43 19665 S+ pts/1 JOBSET+9^ZSY -dir 00:00:00 /dev/pts/1 OPEN TERMINAL CTRA=$C(3) NOPAST NOESCA N OREADS TYPE WIDTH=80 LENG=... /tmp/_gtm_sy_19665.tmp OPEN RMS READ :
On Monday, August 27, 2012 9:47:46 AM UTC-4, David Whitten wrote:
> Supporting Thom's statement, this is the first few lines of %ZTMS5 on my > system > which apparently came from the April 2010 multibuild.
> %ZTMS5 ;ISF/RWF - TaskMan utility ;2/19/08 13:46 > ;;8.0;KERNEL;**275,446**;Jul 10, 1995;Build 36 > ;Per VHA Directive 2004-038, this routine should not be modified. > Q > ;Called from ZTMON1, Jobed from %ZTM5. > SUBCHK(DILOCKTM) ;Check for lost submanagers, Update Count > N %C,%N,%J,ZT2,ZT3,TO > I '$D(DILOCKTM) S DILOCKTM=+$G(^DD("DILOCKTM"),0) ;p446
> Select OPTION: PRINT FILE ENTRIES
> OUTPUT FROM WHAT FILE: INSTALL// > SORT BY: NAME// ROUTIN > 1 ROUTINE INSTALL TIME > 2 ROUTINES (multiple) > CHOOSE 1-2: 2 ROUTINES (multiple) > ROUTINES SUB-FIELD: .01 ROUTINES > START WITH ROUTINES: FIRST// ZTMS5 > GO TO ROUTINES: LAST// ZTMS5 > WITHIN ROUTINES, SORT BY: > FIRST PRINT FIELD: .01 NAME > THEN PRINT FIELD: FILE COMMENT > THEN PRINT FIELD: > Heading (S/C): INSTALL LIST// > START AT PAGE: 1// > DEVICE: TELNET
> ...EXCUSE ME, HOLD ON... > INSTALL LIST AUG 27,2012 09:44 PAGE 1 > NAME > FILE COMMENT
When patching, I forgot to launch VistA with a special startup script that changes $ZRO such that it doesn't make reference to the /p folder, and instead has just the /r folder.
@#^&*!!
This means that all my patches have gone into my /p folder and left the old versions in the /r folder.
So I have backed up the relevant namespaced routines from my /r folder, and am moving the recently added files from /p to /r.
I'm going to have to change my patch helper to look at the $ZRO and warn me next time.
Now, let's see if that fixed the problem that made Taskman crash repeatedly during my workday today.
On Monday, August 27, 2012 7:25:02 PM UTC-4, Kevin Toppenberg wrote:
> Thank you Nancy, Thom, and Dave for your replies so far.
> I think I may have found part of the problem: My routines folder has a > file named "ZTMS5.m" that has the new, correct version, and a "_ZTMS5.m" > that has the old version.
> So the part that saves the files to _*.m is somehow messed up.
> Now to see if I am the one that messed this up or not.
> Kevin
> == first draft below (before I caught the difference in file names) ===== > This is getting even more confusing to me. Here is my $ZROUTINES variable
> When I search in /opt/worldvista/EHR/p, there is no _ZTMS5.m file. There > is a one in /opt/worldvista/EHR/r. When I bring that file up in an editor > (launched from Linux), I get the new, corrrect version of the file.
> But when I type ZEDIT "_ZTMS5" from the mumps command line, it brings up > the OLD version.
> And $TEXT brings up the old version too. > ASTRON>for i=1:1:2 write $T(+i^%ZTMS5),! > %ZTMS5 ;ISF/RWF - SubManager Utilities ;10/29/2003 ;11/03/2003 13:45 > ;;8.0;KERNEL;**275**;Jul 10, 1995;
> So I did a ZLINK and repeated the above line, with identical results.
> So something is making GT.M hold onto the old version of the > module/routine. We reboot our computer ever weekday evening. That will > happen tonight. Perhaps there is a process that is holding on.
> Nancy asked if I had exited mumps and came back in. Yes, I have, but I > haven't rebooted yet. And there are 3 other processes still running (Job > 19665 is the process calling ^ZJOB)
> ASTRON>do ^ZJOB > ...
> GT.M Mumps users on 27-Aug-12 19:16:36
> Proc. id Proc. name PS Device Routine MODE CPU time > -------- --------------- --- -------- -------- ------- > 2301 hib -direct00:00:59 > 2343 hib -direct00:00:05 > 2355 hib -direct00:01:43 > 19665 S+ pts/1 JOBSET+9^ZSY -dir 00:00:00 > /dev/pts/1 OPEN TERMINAL CTRA=$C(3) NOPAST > NOESCA N > OREADS TYPE WIDTH=80 LENG=... > /tmp/_gtm_sy_19665.tmp OPEN RMS READ :
> So, are the Taskman files somehow different because Taskman is always > keeping them active. Before, a ZLINK would force a recompile.
> Still a bit confused.
> Kevin
> On Monday, August 27, 2012 9:47:46 AM UTC-4, David Whitten wrote:
>> Supporting Thom's statement, this is the first few lines of %ZTMS5 on my >> system >> which apparently came from the April 2010 multibuild.
>> %ZTMS5 ;ISF/RWF - TaskMan utility ;2/19/08 13:46 >> ;;8.0;KERNEL;**275,446**;Jul 10, 1995;Build 36 >> ;Per VHA Directive 2004-038, this routine should not be modified. >> Q >> ;Called from ZTMON1, Jobed from %ZTM5. >> SUBCHK(DILOCKTM) ;Check for lost submanagers, Update Count >> N %C,%N,%J,ZT2,ZT3,TO >> I '$D(DILOCKTM) S DILOCKTM=+$G(^DD("DILOCKTM"),0) ;p446
>> Select OPTION: PRINT FILE ENTRIES
>> OUTPUT FROM WHAT FILE: INSTALL// >> SORT BY: NAME// ROUTIN >> 1 ROUTINE INSTALL TIME >> 2 ROUTINES (multiple) >> CHOOSE 1-2: 2 ROUTINES (multiple) >> ROUTINES SUB-FIELD: .01 ROUTINES >> START WITH ROUTINES: FIRST// ZTMS5 >> GO TO ROUTINES: LAST// ZTMS5 >> WITHIN ROUTINES, SORT BY: >> FIRST PRINT FIELD: .01 NAME >> THEN PRINT FIELD: FILE COMMENT >> THEN PRINT FIELD: >> Heading (S/C): INSTALL LIST// >> START AT PAGE: 1// >> DEVICE: TELNET
>> ...EXCUSE ME, HOLD ON... >> INSTALL LIST AUG 27,2012 09:44 PAGE >> 1 >> NAME >> FILE COMMENT
>> ROUTINES: ZTMS5 >> XU*8.0*275 >> Released XU*8*275 SEQ #285 >> XU*8.0*446 >> WorldVistA Multibuild for April 2010 ;Created on Dec 26, 2011@11:29:51
>> On Mon, Aug 27, 2012 at 8:48 AM, Thom H. <th...@mindspring.com> wrote:
>>> Kevin,
>>> The current version of %ZTMS5 indicates that it was patched with >>> Kernel patch XU*8.0*446 and the SUBCHK subroutine does accept a >>> parameter.
On Mon, Aug 27, 2012 at 4:59 PM, Kevin Toppenberg <kdt...@gmail.com> wrote:
> OK. I think I found the problem.
> When patching, I forgot to launch VistA with a special startup script that
> changes $ZRO such that it doesn't make reference to the /p folder, and
> instead has just the /r folder.
> @#^&*!!
> This means that all my patches have gone into my /p folder and left the
> old versions in the /r folder.
> So I have backed up the relevant namespaced routines from my /r folder,
> and am moving the recently added files from /p to /r.
> I'm going to have to change my patch helper to look at the $ZRO and warn
> me next time.
> Now, let's see if that fixed the problem that made Taskman crash
> repeatedly during my workday today.
> Kevin
> On Monday, August 27, 2012 7:25:02 PM UTC-4, Kevin Toppenberg wrote:
>> Thank you Nancy, Thom, and Dave for your replies so far.
>> I think I may have found part of the problem: My routines folder has a
>> file named "ZTMS5.m" that has the new, correct version, and a "_ZTMS5.m"
>> that has the old version.
>> So the part that saves the files to _*.m is somehow messed up.
>> Now to see if I am the one that messed this up or not.
>> Kevin
>> == first draft below (before I caught the difference in file names) =====
>> This is getting even more confusing to me. Here is my $ZROUTINES variable
>> When I search in /opt/worldvista/EHR/p, there is no _ZTMS5.m file. There
>> is a one in /opt/worldvista/EHR/r. When I bring that file up in an editor
>> (launched from Linux), I get the new, corrrect version of the file.
>> But when I type ZEDIT "_ZTMS5" from the mumps command line, it brings up
>> the OLD version.
>> And $TEXT brings up the old version too.
>> ASTRON>for i=1:1:2 write $T(+i^%ZTMS5),!
>> %ZTMS5 ;ISF/RWF - SubManager Utilities ;10/29/2003 ;11/03/2003 13:45
>> ;;8.0;KERNEL;**275**;Jul 10, 1995;
>> So I did a ZLINK and repeated the above line, with identical results.
>> So something is making GT.M hold onto the old version of the
>> module/routine. We reboot our computer ever weekday evening. That will
>> happen tonight. Perhaps there is a process that is holding on.
>> Nancy asked if I had exited mumps and came back in. Yes, I have, but I
>> haven't rebooted yet. And there are 3 other processes still running (Job
>> 19665 is the process calling ^ZJOB)
>> ASTRON>do ^ZJOB
>> ...
>> GT.M Mumps users on 27-Aug-12 19:16:36
>> Proc. id Proc. name PS Device Routine MODE CPU time
>> -------- --------------- --- -------- -------- -------
>> 2301 hib -direct00:00:59
>> 2343 hib -direct00:00:05
>> 2355 hib -direct00:01:43
>> 19665 S+ pts/1 JOBSET+9^ZSY -dir 00:00:00
>> /dev/pts/1 OPEN TERMINAL CTRA=$C(3) NOPAST
>> NOESCA N
>> OREADS TYPE WIDTH=80 LENG=...
>> /tmp/_gtm_sy_19665.tmp OPEN RMS READ :
>> So, are the Taskman files somehow different because Taskman is always
>> keeping them active. Before, a ZLINK would force a recompile.
>> Still a bit confused.
>> Kevin
>> On Monday, August 27, 2012 9:47:46 AM UTC-4, David Whitten wrote:
>>> Supporting Thom's statement, this is the first few lines of %ZTMS5 on my
>>> system
>>> which apparently came from the April 2010 multibuild.
>>> %ZTMS5 ;ISF/RWF - TaskMan utility ;2/19/08 13:46
>>> ;;8.0;KERNEL;**275,446**;Jul 10, 1995;Build 36
>>> ;Per VHA Directive 2004-038, this routine should not be modified.
>>> Q
>>> ;Called from ZTMON1, Jobed from %ZTM5.
>>> SUBCHK(DILOCKTM) ;Check for lost submanagers, Update Count
>>> N %C,%N,%J,ZT2,ZT3,TO
>>> I '$D(DILOCKTM) S DILOCKTM=+$G(^DD("DILOCKTM"),**0) ;p446
>>> Select OPTION: PRINT FILE ENTRIES
>>> OUTPUT FROM WHAT FILE: INSTALL//
>>> SORT BY: NAME// ROUTIN
>>> 1 ROUTINE INSTALL TIME
>>> 2 ROUTINES (multiple)
>>> CHOOSE 1-2: 2 ROUTINES (multiple)
>>> ROUTINES SUB-FIELD: .01 ROUTINES
>>> START WITH ROUTINES: FIRST// ZTMS5
>>> GO TO ROUTINES: LAST// ZTMS5
>>> WITHIN ROUTINES, SORT BY:
>>> FIRST PRINT FIELD: .01 NAME
>>> THEN PRINT FIELD: FILE COMMENT
>>> THEN PRINT FIELD:
>>> Heading (S/C): INSTALL LIST//
>>> START AT PAGE: 1//
>>> DEVICE: TELNET
>>> ...EXCUSE ME, HOLD ON...
>>> INSTALL LIST AUG 27,2012 09:44
>>> PAGE 1
>>> NAME
>>> FILE COMMENT
>>> ------------------------------**------------------------------**
>>> --------------------
>>> ROUTINES: ZTMS5
>>> XU*8.0*275
>>> Released XU*8*275 SEQ #285
>>> XU*8.0*446
>>> WorldVistA Multibuild for April 2010 ;Created on Dec 26, 2011@11:29:51
>>> On Mon, Aug 27, 2012 at 8:48 AM, Thom H. <th...@mindspring.com> wrote:
>>>> Kevin,
>>>> The current version of %ZTMS5 indicates that it was patched with
>>>> Kernel patch XU*8.0*446 and the SUBCHK subroutine does accept a
>>>> parameter.
Just for the record, Dave is my hero. He just spent an extensive amount of time helping me uncrash my system.
Apparently what happened was, that while I was trying to get patched up to a level that I could use the WorldVistA multibuilds with, I installed VA patches. And one of these messed up the routine %ZTLOAD1. It overwrote a WorldVistA bug/fix.
Then, when I was trying to run ^ZTMGRSET, I didn't realize that once you start, you can't stop (with out CTRL-C). It asked me for my UCI,VOL name. I tried to enter"^" to get out, and then it set my system UCI,VOL name to "^". Big problems, because then Taskman parameters aren't matching and Taskman won't run. So we checked and found what it used to be and got it reset.
There is still a problem with Fileman crashing when I try to edit my Taskman parameters file. But I am going to make another post about that.
On Monday, August 27, 2012 9:47:46 AM UTC-4, David Whitten wrote:
> Supporting Thom's statement, this is the first few lines of %ZTMS5 on my > system > which apparently came from the April 2010 multibuild.
> %ZTMS5 ;ISF/RWF - TaskMan utility ;2/19/08 13:46 > ;;8.0;KERNEL;**275,446**;Jul 10, 1995;Build 36 > ;Per VHA Directive 2004-038, this routine should not be modified. > Q > ;Called from ZTMON1, Jobed from %ZTM5. > SUBCHK(DILOCKTM) ;Check for lost submanagers, Update Count > N %C,%N,%J,ZT2,ZT3,TO > I '$D(DILOCKTM) S DILOCKTM=+$G(^DD("DILOCKTM"),0) ;p446
> Select OPTION: PRINT FILE ENTRIES
> OUTPUT FROM WHAT FILE: INSTALL// > SORT BY: NAME// ROUTIN > 1 ROUTINE INSTALL TIME > 2 ROUTINES (multiple) > CHOOSE 1-2: 2 ROUTINES (multiple) > ROUTINES SUB-FIELD: .01 ROUTINES > START WITH ROUTINES: FIRST// ZTMS5 > GO TO ROUTINES: LAST// ZTMS5 > WITHIN ROUTINES, SORT BY: > FIRST PRINT FIELD: .01 NAME > THEN PRINT FIELD: FILE COMMENT > THEN PRINT FIELD: > Heading (S/C): INSTALL LIST// > START AT PAGE: 1// > DEVICE: TELNET
> ...EXCUSE ME, HOLD ON... > INSTALL LIST AUG 27,2012 09:44 PAGE 1 > NAME > FILE COMMENT
