%ROUTINE mismatch. How to fix?

[Kevin Toppenberg]

I have been applying patches, and now my taskman is crashing.

I have these two files:

XUTMK   ;SEA/RDS - Taskman: Option, ZTMCLEAN/ZTMQCLEAN ;11/1/07  14:44

        ;;8.0;KERNEL;**49,67,118,169,222,275,446**;Jul 10, 1995;Build 36

        ;

%ZTMS5 ;ISF/RWF - SubManager Utilities ;10/29/2003 ;11/03/2003  13:45

 ;;8.0;KERNEL;**275**;Jul 10, 1995;

 Q

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?

Thanks

Kevin

[Nancy Anthracite]

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

[Kevin Toppenberg]

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

[Thom H.]

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.

[Nancy Anthracite]

Did you exit GTM and come back in?

--
Nancy Anthracite

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.
> >

[David Whitten]

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

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

[Kevin Toppenberg]

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

 

ASTRON>w $ZRO

/opt/worldvista/EHR/o(/opt/worldvista/EHR/p /opt/worldvista/EHR/r) /opt/worldvista/EHR/m

ASTRON>

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 :

Total 4 users.

Enter JOB number:

===================================================

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

[Kevin Toppenberg]

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

[Sam Habiel]

Yes, exactly. I feel totally @#^&*!! the same way.

[Kevin Toppenberg]

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.

Kevin

On Monday, August 27, 2012 9:47:46 AM UTC-4, David Whitten wrote: