Fun with KIDS patching, including a question
kdt...@gmail.com
Well, I am trying to become more familiar with patching, so I can get
my system up to patch eventually.
I have automated getting the next relevant patch for a given package
from the VA ftp server. So all I have to do is tell it what package
and version to work on, and it will determine the last sequence
number, find the next available patch, download it, and then pass that
file name into the KIDS system to start the loading of the
distribution.
The first 2 fileman patches went OK. Then on the third one, it
STRONGLY recommended that I turn off taskman and inhibit logins, which
I did. I then installed the patch, and got an error flashed up on the
screen. I had told it to ouput errors to the screen, not a printer.
Then the page got cleared, and the error was gone. I noticed that I
had an alert, so tried to view it. I was told that login were
inhibited, and dropped to a GTM prompt! Attempts to log back in were
unsuccessful. Now what to do? I finally used my debugger to trace
through ^XUS, until I found that it was looking at the VOLUME SET
file, and that there was a field in there that stored the flag to
inhibit logins. So a fileman edit fixed that problem. I'm not sure
how I was supposed to figure that out without tracing through the
code. It seems to me that KIDS should have allowed logins again even
after an error was encountered. I found that the error was a
permissions problem when saving the new files to the HFS. But that
wasn't easy to find either.
When was the last time that KIDS had any work on it? I am taking the
code as I go, copying it to my namespace, and then tweaking it to make
it better, but being sure to not make any fundamental changes.
One I have done so far is to allow the text file to be in either UNIX
or DOS end-of-line format. One I want to work on is allowing for
GT.M's setup for different directories for user vs. system files. It
keeps wanting to put the new patches in the user directory instead of
the system directory. Then one has two copies of the code floating
around.
Here is my questions:
When I select the option for "Display Patches for a Package", I get
back this...
PACKAGE: VA FILEMAN Sep 21, 2008 3:06 pm
PAGE 8
PATCH # INSTALLED INSTALLED BY
---------------------------------------------------------------------------------------------------
129 SEQ #120 MAR 02, 2004 IRM,MGR
136 SEQ #121 MAR 02, 2004 IRM,MGR
138 SEP 20, 2008 TOPPENBERG,KEVIN S
133 SEP 20, 2008 TOPPENBERG,KEVIN S
135 SEP 21, 2008 TOPPENBERG,KEVIN S
Notice that the three I have added don't display a SEQuence number.
Looking at the DD for the INSTALLATION file, I found field 42001 that
returns sequence number. It is a computed field that pulls from the
File Comment field, as far as I can tell.
So I can print a Fileman report showing the fields: .01 NAME, 42001
SEQUENCE, and FILE COMMENT, and it will display the proper sequence #.
SEQ# NAME FILE COMMENT
114 DI*22.0*122 Released DI*22*122 SEQ #114
119 DI*22.0*123 Released DI*22*123 SEQ #119
117 DI*22.0*128 Released DI*22*128 SEQ #117
120 DI*22.0*129 Released DI*22*129 SEQ #120
2 DI*22.0*13 Released DI*22*13 SEQ #2
118 DI*22.0*131 Released DI*22*131 SEQ #118
123 DI*22.0*133 Released DI*22*133 SEQ #123 <-- notice SEQ
is OK
124 DI*22.0*135 Released DI*22*135 SEQ #124 <-- notice SEQ
is OK
121 DI*22.0*136 Released DI*22*136 SEQ #121
122 DI*22.0*138 Released DI*22*138 SEQ #122 <-- notice SEQ
is OK
4 DI*22.0*14 Released DI*22*14 SEQ #4
7 DI*22.0*15 Released DI*22*15 SEQ #7
So, can anyone tell me why the first report above doesn't show the SEQ
#? Where is that pulling from that it empty?
Thanks
Kevin
David Whitten
The sequence number is USUALLY in the File Comment, but there is a
separate field named SEQ# that isn't always filled in. Generally, the
File Comment does not have the SEQ# in cases where multiple patches
are loaded in the same KIDS file.
We are only using KIDS version 1.0, the "soon to be released" version
2.0 was never developed, to my knowledge.
In my opinion, a fully functional VistA software development life
cycle is going to require the community to work on KIDS and fix the
things that were promised over 15 years ago.
David
Nancy Anthracite
the environment variables need to be set up to reflect that when patching.
--
Nancy Anthracite
Nancy Anthracite
the reason that the sequence numbers do not display in WV EHR. Note they
stopped displaying about the time of the VistAOffice project.
594 SEQ #531 SEP 17, 2004 SCHLEHUBER,CAMERON
520 SEQ #532 SEP 17, 2004 SCHLEHUBER,CAMERON
589 JAN 28, 2005 MANAGER,SYSTEM
607 SEQ #534 APR 05, 2005 USER,PATCH
615 SEQ #536 APR 07, 2005 USER,PATCH
625 SEQ #537 APR 07, 2005 USER,PATCH
582 SEQ #538 APR 07, 2005 USER,PATCH
605 SEQ #541 APR 07, 2005 USER,PATCH
604 SEQ #542 APR 07, 2005 USER,PATCH
600 SEQ #540 APR 07, 2005 USER,PATCH
598 SEQ #544 APR 07, 2005 USER,PATCH
485 SEQ #547 APR 07, 2005 USER,PATCH
621 SEQ #551 APR 07, 2005 USER,PATCH
623 SEQ #552 APR 07, 2005 USER,PATCH
626 SEQ #553 APR 07, 2005 USER,PATCH
639 SEQ #555 APR 07, 2005 USER,PATCH
646 SEQ #556 APR 07, 2005 USER,PATCH
584 SEQ #558 APR 07, 2005 USER,PATCH
564 APR 07, 2005 USER,PATCH
478 APR 07, 2005 USER,PATCH
606 APR 07, 2005 USER,PATCH
617 APR 07, 2005 USER,PATCH
568 APR 07, 2005 USER,PATCH
637 APR 07, 2005 USER,PATCH
628 SEQ #548 APR 07, 2005 USER,PATCH
570 SEQ #549 APR 07, 2005 USER,PATCH
632 SEQ #550 APR 07, 2005 USER,PATCH
563 APR 07, 2005 USER,PATCH
585 SEQ #557 APR 07, 2005 USER,PATCH
609 SEQ #559 APR 07, 2005 USER,PATCH
633 SEQ #560 JUL 19, 2005 USER,PATCH
610 NOV 28, 2005 MARSHALL,RICK
627 NOV 29, 2005 STOXEN,JAMES H
622 NOV 29, 2005 STOXEN,JAMES H
642 DEC 02, 2005 STOXEN,JAMES H
629 DEC 02, 2005 STOXEN,JAMES H
638 DEC 02, 2005 STOXEN,JAMES H
640 DEC 02, 2005 STOXEN,JAMES H
618 DEC 04, 2005 STOXEN,JAMES H
643 DEC 04, 2005 STOXEN,JAMES H
614 DEC 04, 2005 STOXEN,JAMES H
620 DEC 04, 2005 STOXEN,JAMES H
651 DEC 06, 2005 STOXEN,JAMES H
645 DEC 08, 2005 STOXEN,JAMES H
670 DEC 08, 2005 STOXEN,JAMES H
641 DEC 08, 2005 STOXEN,JAMES H
630 DEC 08, 2005 STOXEN,JAMES H
636 DEC 08, 2005 STOXEN,JAMES H
665 DEC 08, 2005 STOXEN,JAMES H
666 DEC 12, 2005 STOXEN,JAMES H
662 DEC 12, 2005 STOXEN,JAMES H
647 DEC 12, 2005 STOXEN,JAMES H
624 DEC 18, 2005 STOXEN,JAMES H
677 DEC 27, 2005 STOXEN,JAMES H
655 DEC 28, 2005 STOXEN,JAMES H
658 DEC 28, 2005 STOXEN,JAMES H
654 DEC 28, 2005 STOXEN,JAMES H
635 DEC 28, 2005 STOXEN,JAMES H
649 APR 03, 2006 MARSHALL,RICK
631 APR 03, 2006 MARSHALL,RICK
678 APR 03, 2006 MARSHALL,RICK
680 APR 03, 2006 MARSHALL,RICK
684 APR 03, 2006 MARSHALL,RICK
681 APR 03, 2006 MARSHALL,RICK
686 APR 03, 2006 MARSHALL,RICK
685 APR 03, 2006 MARSHALL,RICK
675 APR 03, 2006 MARSHALL,RICK
648 APR 03, 2006 MARSHALL,RICK
682 APR 03, 2006 MARSHALL,RICK
669 APR 03, 2006 MARSHALL,RICK
672 APR 03, 2006 MARSHALL,RICK
687 APR 21, 2006 MARSHALL,RICK
690 APR 21, 2006 MARSHALL,RICK
698 APR 21, 2006 MARSHALL,RICK
709 MAY 10, 2006 MARSHALL,RICK
695 MAY 11, 2006 MARSHALL,RICK
692 MAY 11, 2006 MARSHALL,RICK
554 OCT 02, 2006 MARSHALL,RICK
679 OCT 02, 2006 MARSHALL,RICK
697 OCT 02, 2006 MARSHALL,RICK
704 OCT 08, 2006 SCHLEHUBER,CAMERON
538 OCT 08, 2006 SCHLEHUBER,CAMERON
557 OCT 08, 2006 SCHLEHUBER,CAMERON
703 OCT 08, 2006 SCHLEHUBER,CAMERON
706 OCT 08, 2006 SCHLEHUBER,CAMERON
611 OCT 08, 2006 SCHLEHUBER,CAMERON
683 OCT 08, 2006 SCHLEHUBER,CAMERON
700 OCT 08, 2006 SCHLEHUBER,CAMERON
711 OCT 08, 2006 SCHLEHUBER,CAMERON
702 OCT 08, 2006 SCHLEHUBER,CAMERON
705 OCT 08, 2006 SCHLEHUBER,CAMERON
715 OCT 08, 2006 SCHLEHUBER,CAMERON
694 OCT 08, 2006 SCHLEHUBER,CAMERON
701 OCT 08, 2006 SCHLEHUBER,CAMERON
699 OCT 08, 2006 SCHLEHUBER,CAMERON
718 OCT 08, 2006 SCHLEHUBER,CAMERON
719 OCT 08, 2006 SCHLEHUBER,CAMERON
726 OCT 08, 2006 SCHLEHUBER,CAMERON
673 OCT 08, 2006 SCHLEHUBER,CAMERON
727 OCT 08, 2006 SCHLEHUBER,CAMERON
696 OCT 08, 2006@04:24:49 SCHLEHUBER,CAMERON
634 AUG 29, 2007 SCHLEHUBER,CAMERON
717 NOV 06, 2006@15:11:19 SCHLEHUBER,CAMERON
720 NOV 06, 2006@15:11:28 SCHLEHUBER,CAMERON
689 NOV 06, 2006@15:11:29 SCHLEHUBER,CAMERON
656 NOV 06, 2006@15:11:31 SCHLEHUBER,CAMERON
716 NOV 06, 2006@15:11:33 SCHLEHUBER,CAMERON
708 NOV 06, 2006@15:11:51 SCHLEHUBER,CAMERON
721 NOV 06, 2006@15:11:53 SCHLEHUBER,CAMERON
659 DEC 25, 2006@18:00:20 SCHLEHUBER,CAMERON
728 DEC 25, 2006@18:00:20 SCHLEHUBER,CAMERON
650 DEC 25, 2006@18:00:46 SCHLEHUBER,CAMERON
714 DEC 25, 2006@18:00:58 SCHLEHUBER,CAMERON
731 DEC 25, 2006@18:00:58 SCHLEHUBER,CAMERON
735 DEC 25, 2006@18:01:02 SCHLEHUBER,CAMERON
734 JAN 18, 2007@17:43:57 SCHLEHUBER,CAMERON
583 JAN 18, 2007@17:45:37 SCHLEHUBER,CAMERON
713 JAN 18, 2007@17:46:28 SCHLEHUBER,CAMERON
733 JAN 18, 2007@17:46:29 SCHLEHUBER,CAMERON
657 MAR 16, 2007@12:53:16 SCHLEHUBER,CAMERON
730 MAR 16, 2007@12:53:18 SCHLEHUBER,CAMERON
732 MAR 16, 2007@12:56:05 SCHLEHUBER,CAMERON
725 MAR 16, 2007@13:04:23 SCHLEHUBER,CAMERON
746 MAR 16, 2007@13:04:29 SCHLEHUBER,CAMERON
747 MAR 16, 2007@13:07:21 SCHLEHUBER,CAMERON
739 JUN 13, 2007@09:12:07 SCHLEHUBER,CAMERON
738 JUN 13, 2007@09:12:08 SCHLEHUBER,CAMERON
751 JUN 13, 2007@09:17:31 SCHLEHUBER,CAMERON
740 JUN 13, 2007@09:17:31 SCHLEHUBER,CAMERON
674 JUN 13, 2007@09:56:03 SCHLEHUBER,CAMERON
737 JUN 13, 2007@09:56:27 SCHLEHUBER,CAMERON
707 AUG 29, 2007@21:15:59 SCHLEHUBER,CAMERON
744 AUG 29, 2007@21:16 SCHLEHUBER,CAMERON
653 AUG 29, 2007@21:16:02 SCHLEHUBER,CAMERON
742 AUG 29, 2007@21:16:04 SCHLEHUBER,CAMERON
761 AUG 29, 2007@21:36:56 SCHLEHUBER,CAMERON
758 AUG 29, 2007@21:36:59 SCHLEHUBER,CAMERON
756 OCT 11, 2007@19:54:14 SCHLEHUBER,CAMERON
729 OCT 11, 2007@19:54:16 SCHLEHUBER,CAMERON
757 OCT 11, 2007@19:54:40 SCHLEHUBER,CAMERON
--
Nancy Anthracite
kdt...@gmail.com
on. But when it comes to writing out files, VistA just picks one to
write to.
Options to handle this are:
1. Put all the routines into one folder.
2. Have a special script that launches GTM with special environmental
variables setup when planning to use KIDS
3. Modify the KIDS system to make it smarter.
Of course, I am for option #3
Kevin
Woodhouse Gregory
kdt...@gmail.com
It is my understanding that patches should be applied in numerical
order of their release sequence, not their patch number. So this
seems like a substantial problem if the SEQ number is missing from
patches that one downloads from the FTP server.
But actually, the SEQ number IS stored in the patch. But I think it
is just in a different place that KIDS is not expecting.
Kevin
On Sep 21, 6:23 pm, Woodhouse Gregory <gregory.woodho...@gmail.com>
wrote:
> create a "patch" by transporting a distribution as a Mailman message,
> there is no sequence number. t's when the patch is *released* (on
> Forum) that the sequence number is added.
>
> "We may with advantage at times forget what we know."
> --Publilius Cyrus, c. 100 B.C.
>
Woodhouse Gregory
kdt...@gmail.com
On Sep 21, 3:41 pm, "David Whitten" <whit...@worldvista.org> wrote:
...
> separate field named SEQ# that isn't always filled in. Generally, the
> File Comment does not have the SEQ# in cases where multiple patches
> are loaded in the same KIDS file.
The line that prints out the SEQ # is in PNT^XPDDPCHK
W !?3,$P(XPD,U),?20, ...
When I traced through this, and got this line out
27 SEQ #15 JAN 25, 2000 IRM,MGR
then XPD was: 27 SEQ #15^3000125^1
F S XPDI=$O(^DIC(9.4,XPD0,22,XPDV,"PAH",XPDI)) Q:'XPDI S XPD=
$G(^(XPDI,0)) Q:$$CHK(4) D Q:$D(DIRUT)
So I it seems that this is coming from the .01 field PATCH APPLICATION
HISTORY, in file 9.4901 (in file 9.4 PACKAGE)
This field just holds the text: '27 SEQ #15'
Now I have to see why this isn't getting filled with current patches.
Kevin
kdt...@gmail.com
'138' --> '138 SEQ #122 '
'133' --> '133 SEQ #123'
'135' --> ''135 SEQ #124'
and re-ran the report. Now it is OK.
Kevin
PACKAGE: VA FILEMAN Sep 21, 2008 7:06 pm
PATCH # INSTALLED INSTALLED BY
---------------------------------------------------------------------------------------------------
129 SEQ #120 MAR 02, 2004 IRM,MGR
136 SEQ #121 MAR 02, 2004 IRM,MGR
133 SEQ #123 SEP 20, 2008 TOPPENBERG,KEVIN S
135 SEQ #124 SEP 21, 2008 TOPPENBERG,KEVIN S
kdt...@gmail.com
"offending" code is in ^DD("OS",19,"ZS")
Which contains
N %I,%F,%S S %I=$I,%F=$P($P($ZRO,")"),"(",2)_"/"_X_".m" O %F:
(NEWVERSION) U %F X "S %S=0 F S %S=$O(^UTILITY($J,0,%S)) Q:%S=""""
Q:'$D(^(%S)) S %=^UTILITY($J,0,%S) I $E(%)'="";"" W %,!" C %F U %I
Which I know is all easy reading for you mumpsters. But for us
newbies, I'm going to expand and comment. I moved all this into a
separate routine, ZSAVE^TMGKERNL to give myself some working room.
new %I,%F,%S
set %I=$I
set %F=$P($P($ZRO,")"),"(",2)_"/"_X_".m"
open %F:(NEWVERSION)
use %F
set %S=0
for set %S=$O(^UTILITY($J,0,%S)) Q:%S="""" Q:'$D(^(%S)) do
. set %=^UTILITY($J,0,%S)
. if $E(%)'=";" W %,!
close %F
use %I
QUIT
The problem line is the set %F=
Unless, as Nancy posted, there is just one directory for all your
routines, then you get a $ZROUTINES value of something like this
/usr/local/OpenVistA/o(/var/local/OpenVistA_UserData/r /usr/local/gtm /
usr/local/OpenVistA/r) /usr/local/gtm() /usr/local/m2web/o(/usr/local/
m2web/w)
And this can be decoded as follows
object directory #1=/usr/local/OpenVistA/o
source directory#1=/var/local/OpenVistA_UserData/r
source directory#2=/usr/local/gtm
source directory#3=/usr/local/OpenVistA/r
object directory #2=/usr/local/gtm()
object directory #3=/usr/local/m2web/o
source directory=/usr/local/m2web/w
So when the S %F= line tries to parse out directories, it gets 3
directories, not 1. And this leads to a crash upon trying to open a
malformed filename.
I am going to solve this problem by replacing that line with
new %DIR set %DIR=$P($P($ZRO,")"),"(",2)
set %DIR=$piece(%DIR," ",$length(%DIR," ")) ;<-- get last one
set %F=_%DIR"/"_X_".m"
This will get the LAST source directory in the path. I am picking
that because I think that the path should be set up to search for
source *.m files first fromusers files, then system files. So the
last one would be the one to store new system patches into. This is a
bit arbitrary, but at least it does allow for multiple directories.
Perhaps a better solution would be to reference the linux
environmental variable the 'gtm_vista_prod' but that might cause more
problems then it solves.
Kevin
kdt...@gmail.com
On Sep 21, 9:02 pm, "kdt...@gmail.com" <kdt...@gmail.com> wrote:
...> I moved all this into a
1) ^DD("OS",19,0) = GT.M(UNIX)^^250^10000^^1^250
2) ^DD("OS",19,1) = U @("$I:"_$P("NO",1,'X)_"CENABLE")
3) ^DD("OS",19,8) = X ^DD("$O") ;D DOLRO^%ZOSV
4) ^DD("OS",19,18) = I $L($T(^@X))
5) ^DD("OS",19,"SDP") = O DIO F U DIO R % Q:%="#$#" U IO W:
$A(%)'=12 ! W %
6) ^DD("OS",19,"SDPEND") = W !,"#$#",! C IO
7) ^DD("OS",19,"XY") = S $X=IOX,$Y=IOY
8) ^DD("OS",19,"ZS") = D ZSAVE^TMGKERNL
Kevin
K.S. Bhaskar
If you have questions, you know where I hang out...
Regards
-- Bhaskar
GT.M's $ZROutines search path consists of a series of "chunks", each of which is of one of the following forms:
- A directory, e.g., /opt/lsb-gtm/V5.3-002_i686
- A directory followed by another directory in parentheses, e.g., myVistA/gtm_V5.3-002_i686/o(myVistA/r)
- A directory followed by a parenthesized list of directories, e.g., myVistA/gtm_V5.3-002_i686/o(myVistA/p myVistA/r)
- On some platforms, but not 32-bit Linux, a shared library file name, e.g., myVistA/routines.so
- It will look for both in the same directory.
- It will look for the object routine in the directory outside the parentheses, and the source routine in the directory inside the parentheses.
- It will look for the object routine in the
directory outside the parentheses, and the source routine in the first
directory inside the parentheses, then in the second if it is not in
the first, etc. - i.e., for that object directory, the directories
inside the parentheses form a search path for source routines.
Behavior of the current VistA patching code
Current VistA patching code handles $ZROutine chunk types 1 and 2, but not 3 and 4. Of course, it cannot handle type 4 (which must be handled by a system utility program such as ld).
Recommended behavior of the patching routine
Let me introduce the concept of the "first source directory" - the first directory in $ZROutines which can contain source routines, which will be in the first chunk. If the first chunk is case 1, it is just that directory. If it is case 2, it is the sole directory inside parentheses. If it is case 3, it is the first directory inside parentheses.
There are three cases:
- Adding a new routine.
- Modifying an existing routine, possibly giving it a new name
(copying an existing routine, e.g., ZOSVGUX.m
to _ZOSV.m is a special case of
this).
- Deleting a routine.
When modifying / copying a routine the original source should be located with the aid of SILENT^%RSEL (see http://www.sanchez-gtm.com/user_documentation/targets/GTM_V5.1-000_Release_Notes.html#ch.hi.id.03 and description of ^%RSEL in the Programmers Guide), and the modified routine should be saved in the first source directory. This way, even though the old source continues to exist, any program will simply link the new one.
When deleting a routine, a stub routine of the same name as the one being deleted, but which generates an error if called should be placed in the first source directory. You can use the ZMessage command to generate an error. If a routine XYZ is being deleted by a patch, simply create a 2-line routine called XYZ.m as below in the first source directory. Any attempt to run XYZ (e.g,. D ^XYZ) will generate an error that XYZ.m does not exist (yes, I know this is insufferably cute, but it is very useful!):
kbhaskar@bhaskark:~/demo$ cat XYZ.m
ZMESSAGE 150374338:$PIECE($ZPOSITION,"^",2)
QUIT
kbhaskar@bhaskark:~/demo$ mumps -run ^XYZ
%GTM-E-FILENOTFND, File XYZ not found
At M source location +1^XYZ
GTM>
This is a simple, but relatively general purpose, behavior that will work for a simple production environment as well as for more complex development environments.
The information contained in this message is proprietary and/or confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition,
please be aware that any message addressed to our domain is subject to archiving and review by
persons other than the intended recipient. Thank you.
_____________
kdt...@gmail.com
for set %S=$O(^UTILITY($J,0,%S)) Q:%S="""" Q:'$D(^(%S)) do
for set %S=$O(^UTILITY($J,0,%S)) Q:%S="" Q:'$D(^(%S)) do
K.S. Bhaskar
That said, it looks like a 1 line change will do the trick. If you consider the "unrolled" form of the code, the line:
set %F=$P($P($ZRO,")"),"(",2)_"/"_X_".m"
can be changed to:
set %F=$P($S($F($ZRO," ")>$F($ZRO,"(")&$F($ZRO,"("):$P($P($ZRO,")"),"(",2),1:$ZRO)," ")_"/"_X_".m"
Or, in the "rolled up" version of the code:
N %I,%F,%S S %I=$I,%F=$P($P($ZRO,")"),"(",2)_"/"_X_".m" O %F:(NEWVERSION) U %F X "S %S=0 F S %S=$O(^UTILITY($J,0,%S)) Q:%S=""""Q:'$D(^(%S)) S %=^UTILITY($J,0,%S) I $E(%)'="";"" W %,!" C %F U %I
can read
N %I,%F,%S S %I=$I,%F=$P($S($F($ZRO," ")>$F($ZRO,"(")&$F($ZRO,"("):$P($P($ZRO,")"),"(",2),1:$ZRO)," ")_"/"_X_".m" O %F:(NEWVERSION) U %F X "S %S=0 F S %S=$O(^UTILITY($J,0,%S)) Q:%S=""""Q:'$D(^(%S)) S %=^UTILITY($J,0,%S) I $E(%)'="";"" W %,!" C %F U %I
I would be glad to answer any questions about the change.
Regards
-- Bhaskar
K.S. Bhaskar
Any review of comments on the following are gratefully appreciated. Thank you very much.
-- Bhaskar
In ZOSFGUX.m
Change the two lines;;DEL
;;D DEL^%ZOSV2(X) ;N %RD,%OD S %RD=$P($S($ZRO["(":$P($P($ZRO,"(",2),")"),1:$ZRO)," ")_"/",%OD=$S($ZRO["(":$P($ZRO,"(",1)_"/",1:%RD) ZSYSTEM "rm -f "_%RD_X_".m" ZSYSTEM "rm -f "_%OD_X_".o"
to
;;DEL
;;D DEL^%ZOSV2(X) ;N %I%F S %I=$I,%F=$P($S($F($ZRO," ")>$F($ZRO,"(")&$F($ZRO,"("):$P($P($ZRO,")"),"(",2),1:$ZRO)," ")_"/"_X_".m" O %F:(NEWVERSION) U %F W " ZM 150374338:$P($ZPOS,""^"",2) Q",! C %F U %I
Change the two lines
;;SAVE
;;D SAVE^%ZOSV2(X) ;N %I,%F S %I=$I,%F=$P($S($ZRO["(":$P($P($ZRO,"(",2),")"),1:$ZRO)," ")_"/"_X_".m" O %F:(NEWVERSION) U %F X "F S XCN=$O(@(DIE_XCN_"")"")) Q:+XCN'=XCN S %=@(DIE_XCN_"",0)"") Q:$E(%,1)=""$"" I $E(%)'="";"" W %,!" C %F U %I
to
;;SAVE
;;D SAVE^%ZOSV2(X) ;N %I,%F S %I=$I,%F=$P($S($F($ZRO," ")>$F($ZRO,"(")&$F($ZRO,"("):$P($P($ZRO,")"),"(",2),1:$ZRO)," ")_"/"_X_".m" O %F:(NEWVERSION) U %F X "F S XCN=$O(@(DIE_XCN_"")"")) Q:+XCN'=XCN S %=@(DIE_XCN_"",0)"") Q:$E(%,1)=""$"" I $E(%)'="";"" W %,!" C %F U %I
In ZOSFGTM.m
Change the two lines
;;DEL
;;D DEL^%ZOSV2(X) ;N %DIR S %DIR=$P($ZRO,",") ZSYSTEM "DEL "_%DIR_X_".m;*" ZSYSTEM "DEL "_%DIR_X_".obj;*"
to
;;DEL
;;D DEL^%ZOSV2(X) ;N %I%F S %I=$I,%F=$P($S($F($ZRO," ")>$F($ZRO,"(")&$F($ZRO,"("):$P($P($ZRO,")"),"(",2),1:$ZRO)," ")_"/"_X_".m" O %F:(NEWVERSION) U %F W " ZM 150374338:$P($ZPOS,""^"",2) Q",! C %F U %I
Change the two lines
;;SAVE
;;D SAVE^%ZOSV2(X) ;N %I,%F,SP S %I=$I,SP=" ",%F=$P($ZRO,",")_X_".m" O %F:(NEWVERSION) U %F X "F S XCN=$O(@(DIE_XCN_"")"")) Q:XCN'>0 S %=@(DIE_XCN_"",0)"") Q:$E(%,1)=""$"" I $E(%)'="";"" W $P(%,SP)_$C(9)_$P(%,SP,2,99999),!" C %F U %I
to
;;SAVE
;;D SAVE^%ZOSV2(X) ;N %I,%F,SP S %I=$I,SP=" ",%F=$P($S($F($ZRO," ")>$F($ZRO,"(")&$F($ZRO,"("):$P($P($ZRO,")"),"(",2),1:$ZRO)," ")_X_".m" O %F:(NEWVERSION) U %F X "F S XCN=$O(@(DIE_XCN_"")"")) Q:XCN'>0 S %=@(DIE_XCN_"",0)"") Q:$E(%,1)=""$"" I $E(%)'="";"" W $P(%,SP)_$C(9)_$P(%,SP,2,99999),!" C %F U %I
On 09/22/2008 02:07 PM, K.S. Bhaskar wrote:
I think the patch should go in the FIRST directory. Consider the case where there is a common set of routines shared by 2 institutions. Since each institution has a separate database, and since patches change both routines and databases, you want to apply the patch twice, once to each institution. Later, you can move common routines to the shared area. But this way, each institution can be patched at a different time, and can run at different patch levels.
That said, it looks like a 1 line change will do the trick. If you consider the "unrolled" form of the code, the line:
set %F=$P($P($ZRO,")"),"(",2)_"/"_X_".m"
can be changed to:
set %F=$P($S($F($ZRO," ")>$F($ZRO,"(")&$F($ZRO,"("):$P($P($ZRO,")"),"(",2),1:$ZRO)," ")_"/"_X_".m"
Or, in the "rolled up" version of the code:
N %I,%F,%S S %I=$I,%F=$P($P($ZRO,")"),"(",2)_"/"_X_".m" O %F:(NEWVERSION) U %F X "S %S=0 F S %S=$O(^UTILITY($J,0,%S)) Q:%S=""""Q:'$D(^(%S)) S %=^UTILITY($J,0,%S) I $E(%)'="";"" W %,!" C %F U %I
can read
N %I,%F,%S S %I=$I,%F=$P($S($F($ZRO," ")>$F($ZRO,"(")&$F($ZRO,"("):$P($P($ZRO,")"),"(",2),1:$ZRO)," ")_"/"_X_".m" O %F:(NEWVERSION) U %F X "S %S=0 F S %S=$O(^UTILITY($J,0,%S)) Q:%S=""""Q:'$D(^(%S)) S %=^UTILITY($J,0,%S) I $E(%)'="";"" W %,!" C %F U %I
I would be glad to answer any questions about the change.
Regards
-- Bhaskar
Greg Woodhouse
Chris U
http://www2.hawaii.edu/~ckuyehar/KIDS/CKU*1.0*001.KID ; granted it was
my first I couldn't figure out how to have KIDS update ^DD globals.
VistA Gurus - how do you build a KIDS patch for a FileMan file whose
number is less than 2? Ie, .7?
Mahalo,
Chris
Skip Ormsby
ZB *DIC::"$L(DIC(""S""))>0" <-- get a few extra hits, but it beat trying to get all of the quotes correct.
Then every time DIC("S") is set I would kill it off and the called: D REFRESH^DDSUTL (I think) so the screen wasn't so messy.
-skip "we have met the enemy and he is us." - Pogo
K.S. Bhaskar
-- Bhaskar
In ZOSVGUX.m
Change the lines
RTNDIR() ; primary routine source directory
;Assume /home/xxx/o(/home/xxx/r /home/gtm)
Q $P($S($ZRO["(":$P($P($ZRO,"(",2),")"),1:$ZRO)," ")_"/"
to
RTNDIR() ; primary routine source directory
Q $P($S($F($ZRO," ")>$F($ZRO,"(")&$F($ZRO,"("):$P($P($ZRO,")"),"(",2),1:$ZRO)_"/"
Greg Woodhouse
David Whitten
$ZRO="r-directory1 space r-directory2"
and
$ZRO="o-directory1 open-paren r-directory1 close-paren space r-directory2"
the code selects the r-directory1 in both cases.
And as to the rare use of $FIND, I simply have to say Wally believes in using all of
MUMPS, not just the common parts. And of course, he is a very good,
long-experienced, professional VistA programmer.
David Whitten
713-870-3834
Greg Woodhouse
Bhaskar, KS
On the contrary, as long as I have been associated with GT.M (I joined Greystone in 1995), $ZRO on UNIX/Linux has consisted of one or more "chunks" separated by spaces with each chunk having one of the following forms:
1. obj&srcdirectory
2. objdirectory(srcdirectory)
3. objdirectory(srcdirectory1 srcdirectory2 ...)
The fourth form, which we added circa 2003 was for a chunk to be the name of a shared library file. From the first (or only) chunk of $ZRO, depending on the form of the chunk, the code has to pull out either obj&srcdirectory, srcdirectory, or srcdirectory1.
Regards
-- Bhaskar
-----Original Message-----
From: Hard...@googlegroups.com on behalf of David Whitten
Sent: Mon 9/22/2008 7:33 PM
To: Hard...@googlegroups.com
Subject: [Hardhats] Re: Fun with KIDS patching, including a question
At the time the code was written there were two possible flavors of $ZRO in the wild.
$ZRO="r-directory1 space r-directory2"
and
$ZRO="o-directory1 open-paren r-directory1 close-paren space r-directory2"
the code selects the r-directory1 in both cases.
And as to the rare use of $FIND, I simply have to say Wally believes in using all of
MUMPS, not just the common parts. And of course, he is a very good,
long-experienced, professional VistA programmer.
David Whitten
713-870-3834
_____________
Bhaskar, KS
1. $ZRO contains parentheses and an open paren occurs before the first space: the source directory is the first space separated piece in the second open paren separated piece.
2. $ZRO doesn't contain parenthesis or space occurs in $ZRO before an open paren: the source directory is the first piece with space as the piece separator (this handles the case of only one directory in $ZRO).
GT.M doesn't handle directories with spaces or parentheses in their names, even though UNIX/Linux permits it.
-- Bhaskar
P.S. Never trust code written by a manager.
-----Original Message-----
From: Hard...@googlegroups.com on behalf of Greg Woodhouse
Sent: Mon 9/22/2008 7:01 PM
To: Hard...@googlegroups.com
Woodhouse Gregory
There are two cases to consider:
1. $ZRO contains parentheses and an open paren occurs before the first space: the source directory is the first space separated piece in the second open paren separated piece.
2. $ZRO doesn't contain parenthesis or space occurs in $ZRO before an open paren: the source directory is the first piece with space as the piece separator (this handles the case of only one directory in $ZRO).
GT.M doesn't handle directories with spaces or parentheses in their names, even though UNIX/Linux permits it.
Bhaskar, KS
From: Hard...@googlegroups.com on behalf of Woodhouse Gregory
Sent: Mon 9/22/2008 9:36 PM
To: Hard...@googlegroups.com
Subject: [Hardhats] Re: Fun with KIDS patching, including a question
On Sep 22, 2008, at 6:17 PM, Bhaskar, KS wrote:
There are two cases to consider:
1. $ZRO contains parentheses and an open paren occurs before the first space: the source directory is the first space separated piece in the second open paren separated piece.
I'm trying to follow this. One value matching your description is aaa(bbb ccc). Are you saying bbb is the source directory? Is aaa ever non-null? What is ccc?
[KSB] aaa is the object directory. There is a search path for source directories inside the parentheses. If this construct is used, VistA should put the source in bbb, and GT.M will automatically compile it the next time it is linked (automatically or manually) and place the new object in aaa because the source in bbb will be newer than the object, if any, in aaa, and any source in bbb will precede any source in ccc.
2. $ZRO doesn't contain parenthesis or space occurs in $ZRO before an open paren: the source directory is the first piece with space as the piece separator (this handles the case of only one directory in $ZRO).
So, in aaa we have just the source directory, but what about aaa (bbb) or aaa (bbb ccc)?
[KSB] In the case where it is just aaa, the source and object code go in the same directory, aaa. The constructs (bbb) and (bbb ccc) are invalid - there must be a directory just before the open paren, no spaces.
GT.M doesn't handle directories with spaces or parentheses in their names, even though UNIX/Linux permits it.
That could be an issue for OS X, though I usually set up symbolic links for traditional Unix applications (or just to make typing easier).
[KSB] Well, it is (historically) unusual to have parentheses and spaces in file names. Let's just call it a GT.M limitation for now, even though it is a cultural limitation as well.
Woodhouse Gregory
That could be an issue for OS X, though I usually set up symbolic links for traditional Unix applications (or just to make typing easier).
[KSB] Well, it is (historically) unusual to have parentheses and spaces in file names. Let's just call it a GT.M limitation for now, even though it is a cultural limitation as well.
Regards
-- Bhaskar
kdt...@gmail.com
Thank you for your feedback. I don't want it to be that way for my
site, but your logic is sound for the situation you describe.
The next question is how to apply what you have written, rather than
this discussion to die on the vine until it comes up again in another
year or so. I think you should make this into a patch that can be
applied to the WorldVistA server code. Have you done that before?
Kevin
K.S. Bhaskar
Regards
-- Bhaskar
kdt...@gmail.com
about the VistA server code? Who is the keeper of the code?
Kevin
Woodhouse Gregory
kdt...@gmail.com
minimize the number of modifications for just this reason. But it
does leave us with parts of the system that don't work as well as we
know that they could. This example of changing the ZSAVE
functionality to work properly with GT.M is a prime example. To a
certain degree, I have given up trying to fix up WV's version and just
worry about my system.
Kevin
On Sep 23, 7:06 pm, Woodhouse Gregory <gregory.woodho...@gmail.com>
wrote:
K.S. Bhaskar
Regards
-- Bhaskar
On 09/22/2008 03:33 PM, K.S. Bhaskar wrote:
I would like to suggest some tweaks to get VistA patching to exploit GT.M's $ZROutines better than it does today. Apologies for the long lines and possible line breaks. I will send the files as attachments to anyone who requests them. Also, what are RTNDIR^ZOSVGUX and RTNDIR^ZOSVGTM supposed to do? I may want to suggest some changes to them too.
Any review of comments on the following are gratefully appreciated. Thank you very much.
-- Bhaskar