RE: [Hardhats-members] Fileman drop-out on pointer update
The requirements have just been posted and announced to be on the CMS web site for the Physician Focused Quality Initiative page at http://www.cms.hhs.gov/quality/pfqi.asp#Vista-Office%20EHR. Browse under the VistA-Office EHR section to the Version 1.0 Requirements at http://www.cms.hhs.gov/quality/EHRRequirements.pdf. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Kreis Sent: Monday, April 04, 2005 10:18 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Fileman drop-out on pointer update Does anyone know details on how the VistA-Office EHR is being created? It would be interesting to see the requirements, both functional and technical, that are driving the process. Maury Pepper wrote: VistA in the news: www.ama-assn.org/amednews/2005/04/11/bisa0411.htm
RE: [Hardhats-members] Fileman drop-out on pointer update
Maybe this should be posted with a different subject line. :-) Kevin --- Cameron Schlehuber [EMAIL PROTECTED] wrote: The requirements have just been posted and announced to be on the CMS web site for the Physician Focused Quality Initiative page at http://www.cms.hhs.gov/quality/pfqi.asp#Vista-Office%20EHR. Browse under the VistA-Office EHR section to the Version 1.0 Requirements at http://www.cms.hhs.gov/quality/EHRRequirements.pdf. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Kreis Sent: Monday, April 04, 2005 10:18 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Fileman drop-out on pointer update Does anyone know details on how the VistA-Office EHR is being created? It would be interesting to see the requirements, both functional and technical, that are driving the process. Maury Pepper wrote: VistA in the news: www.ama-assn.org/amednews/2005/04/11/bisa0411.htm Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Fileman drop-out on pointer update
I am not in a situation where I can look at the DD's for file 2 and file 901 so I am not sure about the nodes that are causing the problem. I do not see how not having the $G is what could have caused the situation of not having the ^DPT entry. I would like to see how having the $G would have allowed the data to update correctly.In principlethere are better ways of writing code than to allow Merrors to detect corrupt data, but merely preventing the M error may also allow the code to do things that will further corrupt the data as well. Either way is a risk. The VA uses a X-ref on the SSN field to keep files 2 and 901 in synch. Normally it works well. It does assume that the SSN field is required. You can get into trouble if you make the SSN field optional. IHS keeps the two files in synch via code in the special Fileman lookup routine on file 2. That way they get around the problem of SSN being not a required field. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Monday, April 04, 2005 12:45 PM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G.Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer updateIt should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTMzwr ^AUPNPAT(0) ^AUPNPAT(0)="PATIENT/IHS^901sIP^14861^1510" GTMzwr ^DD(901,0,"SCR") ^DD(901,0,"SCR")="X ""I '$P(^DPT(Y,0),U,19)"" W $E(^AUPNPAT(Y,0),0)" So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the "^DPT(Y,0)" ought to be "$G(^DPT(Y,0))" So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: A quick look at the DI* routines I have (which are old), leads me to suggest that you look at the DD for the file defining ^AUPNPAT. Look at ^AUPNPAT(0) to find the file number and then look at ^DD(file number,0,"SCR") and I'm guessing you'll find the culprit there as "I '$P(^DPT(Y,0),U,19)". If that is the problem then someone should review the "SCR" nodes to ensure there are no similar problems lurkin
Re: [Hardhats-members] Fileman drop-out on pointer update
Well, the long and the short of it is that I should NOT have tried to kill one of the two duplicate records. Thus I am doing something not supported, so a crash is not technically a bug/problem. (You put your fingers into the spinning gears, you have to put up with getting pinched!) So I am going to read up (all 200 pages in the manual) on how to merge patients. I sure hope that as I blunder my way to a better understanding that I don't do something really bad Kevin --- James Gray [EMAIL PROTECTED] wrote: I am not in a situation where I can look at the DD's for file 2 and file 901 so I am not sure about the nodes that are causing the problem. I do not see how not having the $G is what could have caused the situation of not having the ^DPT entry. I would like to see how having the $G would have allowed the data to update correctly. In principle there are better ways of writing code than to allow M errors to detect corrupt data, but merely preventing the M error may also allow the code to do things that will further corrupt the data as well. Either way is a risk. The VA uses a X-ref on the SSN field to keep files 2 and 901 in synch. Normally it works well. It does assume that the SSN field is required. You can get into trouble if you make the SSN field optional. IHS keeps the two files in synch via code in the special Fileman lookup routine on file 2. That way they get around the problem of SSN being not a required field. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Monday, April 04, 2005 12:45 PM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTMzwr ^AUPNPAT(0) ^AUPNPAT(0)=PATIENT/IHS^901sIP^14861^1510 GTMzwr ^DD(901,0,SCR) ^DD(901,0,SCR)=X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: A quick look at the DI* routines I have
Re: [Hardhats-members] Fileman drop-out on pointer update
When I worked in both the VA and in IHS we did not try to delete bad patient records that showed up in the database. Instead we ZZ'd them by putting the letters ZZ at the beginning of the name. It is an ugly kludge, but it prevents big problems. Jim Gray - Original Message - From: Kevin Toppenberg [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Tuesday, April 05, 2005 10:34 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update Well, the long and the short of it is that I should NOT have tried to kill one of the two duplicate records. Thus I am doing something not supported, so a crash is not technically a bug/problem. (You put your fingers into the spinning gears, you have to put up with getting pinched!) So I am going to read up (all 200 pages in the manual) on how to merge patients. I sure hope that as I blunder my way to a better understanding that I don't do something really bad Kevin --- James Gray [EMAIL PROTECTED] wrote: I am not in a situation where I can look at the DD's for file 2 and file 901 so I am not sure about the nodes that are causing the problem. I do not see how not having the $G is what could have caused the situation of not having the ^DPT entry. I would like to see how having the $G would have allowed the data to update correctly. In principle there are better ways of writing code than to allow M errors to detect corrupt data, but merely preventing the M error may also allow the code to do things that will further corrupt the data as well. Either way is a risk. The VA uses a X-ref on the SSN field to keep files 2 and 901 in synch. Normally it works well. It does assume that the SSN field is required. You can get into trouble if you make the SSN field optional. IHS keeps the two files in synch via code in the special Fileman lookup routine on file 2. That way they get around the problem of SSN being not a required field. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Monday, April 04, 2005 12:45 PM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTMzwr ^AUPNPAT(0) ^AUPNPAT(0)=PATIENT/IHS^901sIP^14861^1510 GTMzwr ^DD(901,0,SCR) ^DD(901,0,SCR)=X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) So I could put that change here. But I'm note sure if that would have other unforseen
Re: [Hardhats-members] Fileman drop-out on pointer update
That is what we have had to do with our old system. And it is an ugly kludge. I was hoping to not have to do that. As programmers, can't we overcome such a thing. I don't know yet if vista will show the stub entry that is left behind. I hope not. Kevin --- James Gray [EMAIL PROTECTED] wrote: When I worked in both the VA and in IHS we did not try to delete bad patient records that showed up in the database. Instead we ZZ'd them by putting the letters ZZ at the beginning of the name. It is an ugly kludge, but it prevents big problems. Jim Gray - Original Message - From: Kevin Toppenberg [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Tuesday, April 05, 2005 10:34 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update Well, the long and the short of it is that I should NOT have tried to kill one of the two duplicate records. Thus I am doing something not supported, so a crash is not technically a bug/problem. (You put your fingers into the spinning gears, you have to put up with getting pinched!) So I am going to read up (all 200 pages in the manual) on how to merge patients. I sure hope that as I blunder my way to a better understanding that I don't do something really bad Kevin --- James Gray [EMAIL PROTECTED] wrote: I am not in a situation where I can look at the DD's for file 2 and file 901 so I am not sure about the nodes that are causing the problem. I do not see how not having the $G is what could have caused the situation of not having the ^DPT entry. I would like to see how having the $G would have allowed the data to update correctly. In principle there are better ways of writing code than to allow M errors to detect corrupt data, but merely preventing the M error may also allow the code to do things that will further corrupt the data as well. Either way is a risk. The VA uses a X-ref on the SSN field to keep files 2 and 901 in synch. Normally it works well. It does assume that the SSN field is required. You can get into trouble if you make the SSN field optional. IHS keeps the two files in synch via code in the special Fileman lookup routine on file 2. That way they get around the problem of SSN being not a required field. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Monday, April 04, 2005 12:45 PM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg
Re: [Hardhats-members] Fileman drop-out on pointer update
Here's a thought (not necessarily a good one): Delete the existing B cross-reference and replace it with a new style cross-reference with a set condition so that stub entries will not be indexed. --- Kevin Toppenberg [EMAIL PROTECTED] wrote: That is what we have had to do with our old system. And it is an ugly kludge. I was hoping to not have to do that. As programmers, can't we overcome such a thing. I don't know yet if vista will show the stub entry that is left behind. I hope not. Kevin --- James Gray [EMAIL PROTECTED] wrote: When I worked in both the VA and in IHS we did not try to delete bad patient records that showed up in the database. Instead we ZZ'd them by putting the letters ZZ at the beginning of the name. It is an ugly kludge, but it prevents big problems. Jim Gray - Original Message - From: Kevin Toppenberg [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Tuesday, April 05, 2005 10:34 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update Well, the long and the short of it is that I should NOT have tried to kill one of the two duplicate records. Thus I am doing something not supported, so a crash is not technically a bug/problem. (You put your fingers into the spinning gears, you have to put up with getting pinched!) So I am going to read up (all 200 pages in the manual) on how to merge patients. I sure hope that as I blunder my way to a better understanding that I don't do something really bad Kevin --- James Gray [EMAIL PROTECTED] wrote: I am not in a situation where I can look at the DD's for file 2 and file 901 so I am not sure about the nodes that are causing the problem. I do not see how not having the $G is what could have caused the situation of not having the ^DPT entry. I would like to see how having the $G would have allowed the data to update correctly. In principle there are better ways of writing code than to allow M errors to detect corrupt data, but merely preventing the M error may also allow the code to do things that will further corrupt the data as well. Either way is a risk. The VA uses a X-ref on the SSN field to keep files 2 and 901 in synch. Normally it works well. It does assume that the SSN field is required. You can get into trouble if you make the SSN field optional. IHS keeps the two files in synch via code in the special Fileman lookup routine on file 2. That way they get around the problem of SSN being not a required field. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Monday, April 04, 2005 12:45 PM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update
Re: [Hardhats-members] Fileman drop-out on pointer update
There may not be such a need. I would have to check to verify this. But I believe that ^DIC may check for the archive flag and filter out those records automatically. I have not actually looked at all of this routine to see if that indeed is what it is doing. But on the surface, it appears to be: DIC3+2 ;Per VHA Directive 10-93-142, this routine should not be modified. MN+6I D=B,'DZ,'$D(DO(SCR)),$L(DIX)30,'$D(DIC(S)),'$D(@(DIC_Y,-9) )),'$G(DINDEX(OLDSUB)) D ADDKEY I 1 Q S+1 I $D(@(DIC_Y,0))),'$D(^(-9)) S DIY=$P(^(0),U) - Original Message - From: Greg Woodhouse [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Tuesday, April 05, 2005 3:42 PM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update Here's a thought (not necessarily a good one): Delete the existing B cross-reference and replace it with a new style cross-reference with a set condition so that stub entries will not be indexed. --- Kevin Toppenberg [EMAIL PROTECTED] wrote: That is what we have had to do with our old system. And it is an ugly kludge. I was hoping to not have to do that. As programmers, can't we overcome such a thing. I don't know yet if vista will show the stub entry that is left behind. I hope not. Kevin --- James Gray [EMAIL PROTECTED] wrote: When I worked in both the VA and in IHS we did not try to delete bad patient records that showed up in the database. Instead we ZZ'd them by putting the letters ZZ at the beginning of the name. It is an ugly kludge, but it prevents big problems. Jim Gray - Original Message - From: Kevin Toppenberg [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Tuesday, April 05, 2005 10:34 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update Well, the long and the short of it is that I should NOT have tried to kill one of the two duplicate records. Thus I am doing something not supported, so a crash is not technically a bug/problem. (You put your fingers into the spinning gears, you have to put up with getting pinched!) So I am going to read up (all 200 pages in the manual) on how to merge patients. I sure hope that as I blunder my way to a better understanding that I don't do something really bad Kevin --- James Gray [EMAIL PROTECTED] wrote: I am not in a situation where I can look at the DD's for file 2 and file 901 so I am not sure about the nodes that are causing the problem. I do not see how not having the $G is what could have caused the situation of not having the ^DPT entry. I would like to see how having the $G would have allowed the data to update correctly. In principle there are better ways of writing code than to allow M errors to detect corrupt data, but merely preventing the M error may also allow the code to do things that will further corrupt the data as well. Either way is a risk. The VA uses a X-ref on the SSN field to keep files 2 and 901 in synch. Normally it works well. It does assume that the SSN field is required. You can get into trouble if you make the SSN field optional. IHS keeps the two files in synch via code in the special Fileman lookup routine on file 2. That way they get around the problem of SSN being not a required field. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Monday, April 04, 2005 12:45 PM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening
Re: [Hardhats-members] Fileman drop-out on pointer update
Did you kill it or have FileMan kill it? If FileMan did it, then
I don't think you did anything 'not supported'.
Anyway, I just looked at this more closely and there is another
issue we haven't addressed yet. I still maintain that the $G is the
correct way to go (and checked out that it would not abend with that in
there in this situation) for most situations. Unfortunately, there
is another wrinkle here, since these are files that are being kept in sync
with the IEN being the same for the ^DPT and ^AUPNPAT. In that case,
repointing won't be appropriate and FileMan didn't notice that for some
reason. I'm guessing that the DD(901,.01,0) for the ^AUPNPAT
file has code that sets DINUM or it is set by software. I just tried
a similar exercise (with a $G in place) and FileMan beeped at the attempt
to change the pointer, thus there was a dangling pointer left in place,
which is also not desireable. Neither a crash nor this is optimal,
so I hope the merge software deals with things more throughly and deals
with such insync files. [So easy to be a Tuesday night quarterback
;-)]
Meanwhile, I am somewhat puzzled by the seeming lack of the SCR
node I set up to have any effect during lookups (only during repointing),
and yes, I did add "s" to the 0 node of the file. Sigh...
Marianne
Kevin Toppenberg wrote:
Well, the long and the short of it is that I should
NOT have tried to kill one of the two duplicate
records. Thus I am doing something not supported, so
a crash is not technically a bug/problem. ("You put
your fingers into the spinning gears, you have to put
up with getting pinched!")
So I am going to read up (all 200 pages in the manual)
on how to merge patients.
I sure hope that as I blunder my way to a better
understanding that I don't do something really bad
Kevin
--- James Gray [EMAIL PROTECTED]> wrote:
> I am not in a situation where I can look at the DD's
> for file 2 and file 901 so I am not sure about
> the nodes that are causing the problem. I do not
> see how not having the $G is what could have caused
> the situation of not having the ^DPT entry. I would
> like to see how having the $G would have allowed the
> data to update correctly. In principle there are
> better ways of writing code than to allow M errors
> to detect corrupt data, but merely preventing the M
> error may also allow the code to do things that will
> further corrupt the data as well. Either way is a
> risk.
>
> The VA uses a X-ref on the SSN field to keep files 2
> and 901 in synch. Normally it works well. It
> does assume that the SSN field is required. You can
> get into trouble if you make the SSN field optional.
> IHS keeps the two files in synch via code in the
> special Fileman lookup routine on file 2. That way
> they get around the problem of SSN being not a
> required field.
>
> Jim Gray
> - Original Message -
> From: Marianne Susaanti Follingstad
> To: hardhats-members@lists.sourceforge.net
> Sent: Monday, April 04, 2005 12:45 PM
> Subject: Re: [Hardhats-members] Fileman drop-out
> on pointer update
>
>
> What then do you suggest? In this case, NOT
> having the $G is what created the situation of NOT
> having a ^DPT entry that is pointed to. In other
> words, if the $G had been there, the data would have
> updated correctly and avoided the data integrity
> problem that now exists. There has to be better
> ways to detect missing or corrupt data than having
> an application crash, which risks further corruption
> of more data.
> I'm curious as to what the VA does for duplicate
> records; anyone know? If there is a merge
> capability or deletion and repointing of duplicates
> and it uses the standard FileMan functionality, then
> it too could have the same issue.
>
> In this instance, the file on which things blew
> was an IHS Patient file, so maybe the VA avoided
> such pitfalls. It is interesting to note that the
> SCR node (which is meant to screen entries) is also
> being used here to display info, which does not seem
> like a great idea; however, there could still be
> valid reasons to need to look at info in a pointed
> to file during a screening.
>
> Marianne
>
> James Gray wrote:
>
> One could argue that it is not fine to put
the
> $G there. There should never be a case in a good
> database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0)
> does not exist. If that happens something is wrong
> in your database and it needs to be cleaned up. I
> have seen ^AUPNPAT(Y,0) nodes exist when the
> corresponding ^DPT(Y,0) nodes did not exist on a
> system running Cache just for the record. If you
> put the $G in you may never know that you have a bad
> node and who knows what else that bad node may do?
> I would suggest not putting in the $G. Jim Gray
> - Original Message
Re: [Hardhats-members] Fileman drop-out on pointer update
The code that keeps the two files in synch in IHS
code is in a cross reference on the SSN field. The code that keeps the two
files in synch in IHS code is in the special fileman lookup routine on file
2. In IHS code that is in the ^AUPNLK* routines.
Jim Gray
- Original Message -
From:
Marianne
Susaanti Follingstad
To: hardhats-members@lists.sourceforge.net
Sent: Tuesday, April 05, 2005 4:35
PM
Subject: Re: [Hardhats-members] Fileman
drop-out on pointer update
Did you kill it or have FileMan kill it? If FileMan
did it, then I don't think you did anything 'not supported'.
Anyway, I just looked at this more closely and there is another issue
we haven't addressed yet. I still maintain that the $G is the correct
way to go (and checked out that it would not abend with that in there in this
situation) for most situations. Unfortunately, there is another wrinkle
here, since these are files that are being kept in sync with the IEN being the
same for the ^DPT and ^AUPNPAT. In that case, repointing won't be
appropriate and FileMan didn't notice that for some reason. I'm guessing
that the DD(901,.01,0) for the ^AUPNPAT file has code that sets DINUM or
it is set by software. I just tried a similar exercise (with a $G in
place) and FileMan beeped at the attempt to change the pointer, thus there was
a dangling pointer left in place, which is also not desireable. Neither
a crash nor this is optimal, so I hope the merge software deals with things
more throughly and deals with such insync files. [So easy to be a
Tuesday night quarterback ;-)]
Meanwhile, I am somewhat puzzled by the seeming lack of the SCR node I
set up to have any effect during lookups (only during repointing), and yes, I
did add "s" to the 0 node of the file. Sigh...
Marianne
Kevin Toppenberg wrote:
Well, the long and the short of it is that I should
NOT have tried to kill one of the two duplicate records. Thus
I am doing something not supported, so a crash is not technically a
bug/problem. ("You put your fingers into the spinning gears, you
have to put up with getting pinched!")
So I am going to read up (all 200 pages in the manual) on how to
merge patients.
I sure hope that as I blunder my way to a better understanding that I
don't do something really bad
Kevin
--- James Gray [EMAIL PROTECTED] wrote:
I am not in a situation where I can look at the DD's for
file 2 and file 901 so I am not sure about the nodes that are
causing the problem. I do not see how not having the $G is
what could have caused the situation of not having the ^DPT
entry. I would like to see how having the $G would have
allowed the data to update correctly. In principle there are
better ways of writing code than to allow M errors to
detect corrupt data, but merely preventing the M error may also
allow the code to do things that will further corrupt the data as
well. Either way is a risk. The VA uses a
X-ref on the SSN field to keep files 2 and 901 in synch.
Normally it works well. It does assume that the SSN field is
required. You can get into trouble if you make the SSN field
optional. IHS keeps the two files in synch via code in the
special Fileman lookup routine on file 2. That way
they get around the problem of SSN being not a required field.
Jim Gray - Original Message -
From: Marianne Susaanti Follingstad
To: hardhats-members@lists.sourceforge.net
Sent: Monday, April 04, 2005 12:45 PM
Subject: Re: [Hardhats-members] Fileman drop-out
on pointer updateWhat then
do you suggest? In this case, NOT having the $G is what
created the situation of NOT having a ^DPT entry that is pointed
to. In other words, if the $G had been there, the data would
have updated correctly and avoided the data integrity
problem that now exists. There has to be better ways to
detect missing or corrupt data than having an application crash,
which risks further corruption of more data.
I'm curious as to what the VA does for duplicate records; anyone
know? If there is a merge capability or deletion and
repointing of duplicates and it uses the standard FileMan
functionality, then it too could have the same issue.
In this instance, the file on which things blew
was an IHS Patient file, so maybe the VA avoided such
pitfalls. It is interesting to note that the SCR node (which
is meant to screen entries) is also being used here to display
info, which does not seem like a great idea; however, there could
still be valid reasons to need to look at info in a pointed
to file during a screening. Marianne
James Gray wrote:
One could argue that it is not fine
Re: [Hardhats-members] Fileman drop-out on pointer update
It could be overcome, but it would not be easy. If it was easy, I doubt the VA would have been doing the Kludge for 20 years. Jim Gray - Original Message - From: Kevin Toppenberg [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Tuesday, April 05, 2005 11:26 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update That is what we have had to do with our old system. And it is an ugly kludge. I was hoping to not have to do that. As programmers, can't we overcome such a thing. I don't know yet if vista will show the stub entry that is left behind. I hope not. Kevin --- James Gray [EMAIL PROTECTED] wrote: When I worked in both the VA and in IHS we did not try to delete bad patient records that showed up in the database. Instead we ZZ'd them by putting the letters ZZ at the beginning of the name. It is an ugly kludge, but it prevents big problems. Jim Gray - Original Message - From: Kevin Toppenberg [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Tuesday, April 05, 2005 10:34 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update Well, the long and the short of it is that I should NOT have tried to kill one of the two duplicate records. Thus I am doing something not supported, so a crash is not technically a bug/problem. (You put your fingers into the spinning gears, you have to put up with getting pinched!) So I am going to read up (all 200 pages in the manual) on how to merge patients. I sure hope that as I blunder my way to a better understanding that I don't do something really bad Kevin --- James Gray [EMAIL PROTECTED] wrote: I am not in a situation where I can look at the DD's for file 2 and file 901 so I am not sure about the nodes that are causing the problem. I do not see how not having the $G is what could have caused the situation of not having the ^DPT entry. I would like to see how having the $G would have allowed the data to update correctly. In principle there are better ways of writing code than to allow M errors to detect corrupt data, but merely preventing the M error may also allow the code to do things that will further corrupt the data as well. Either way is a risk. The VA uses a X-ref on the SSN field to keep files 2 and 901 in synch. Normally it works well. It does assume that the SSN field is required. You can get into trouble if you make the SSN field optional. IHS keeps the two files in synch via code in the special Fileman lookup routine on file 2. That way they get around the problem of SSN being not a required field. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Monday, April 04, 2005 12:45 PM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned
Re: [Hardhats-members] Fileman drop-out on pointer update
One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G. Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTMzwr ^AUPNPAT(0) ^AUPNPAT(0)="PATIENT/IHS^901sIP^14861^1510" GTMzwr ^DD(901,0,"SCR") ^DD(901,0,"SCR")="X ""I '$P(^DPT(Y,0),U,19)"" W $E(^AUPNPAT(Y,0),0)" So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the "^DPT(Y,0)" ought to be "$G(^DPT(Y,0))" So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: A quick look at the DI* routines I have (which are old), leads me to suggest that you look at the DD for the file defining ^AUPNPAT. Look at ^AUPNPAT(0) to find the file number and then look at ^DD(file number,0,"SCR") and I'm guessing you'll find the culprit there as "I '$P(^DPT(Y,0),U,19)". If that is the problem then someone should review the "SCR" nodes to ensure there are no similar problems lurking... Of course the other problem is how to restart the process, and unfortunately I don't have any suggestions on that issue. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote:I had two patients that were duplicates--i.e. the same person, but with two different married names. So I deleted one, and told fileman to change all pointers from the former to the later. (I had to take off a guard to do this) It then scans through all the appropriate places and changes the pointers. But then it drops out after about 20-30 files. I never knew what was happening before, but I have recently studied a bit on GTM debugging techniques, and here is what I have come up with: Screen log: ROES ELIGIBILITY CONFIRMATION entries whose 'PATIENT' pointers have been changed MAR 29,2005 20:12 PAGE 1 *** NO RECORDS TO PRINT *** GTMw $ECODE notice drop-out ,M7,Z150372994, GTMw $ZSTATUS 150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global variable undefined: ^DPT(75002,0) GTMzprint SCR+1^DIO2 X DIS(0) Q:'$T G PASS:'$D(DIS(1)) GTMw DIS(0) S Y=D0 I $D(^AUPNPAT(Y,0)) X "I '$P(^DPT(Y,0),U,19)" W $E(^AUPNPAT(Y,0),0) GTMw Y 75002 GTM It looks like the "^DPT(Y,0)" ought to be "$G(^DPT(Y,0))" Kevin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/hardhats-members __ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com --- SF e
Re: [Hardhats-members] Fileman drop-out on pointer update
What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G.Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTM>zwr ^AUPNPAT(0) ^AUPNPAT(0)="PATIENT/IHS^901sIP^14861^1510" GTM>zwr ^DD(901,0,"SCR") ^DD(901,0,"SCR")="X ""I '$P(^DPT(Y,0),U,19)"" W $E(^AUPNPAT(Y,0),0)" So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the "^DPT(Y,0)" ought to be "$G(^DPT(Y,0))" So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED]> wrote: > A quick look at the DI* routines I have (which are > old), leads me to suggest that > you look at the DD for the file defining ^AUPNPAT. > Look at ^AUPNPAT(0) to find the > file number and then look at ^DD(file > number,0,"SCR") and I'm guessing you'll find > the culprit there as "I '$P(^DPT(Y,0),U,19)". If > that is the problem then someone > should review the "SCR" nodes to ensure there are no > similar problems lurking... > > Of course the other problem is how to restart the > process, and unfortunately I don't > have any suggestions on that issue. > > Marianne Follingstad > 301 251 0139 > > Kevin Toppenberg wrote: > > > I had two patients that were duplicates--i.e. the > same > > person, but with two different married names. > > > > So I deleted one, and told fileman to change all > > pointers from the former to the later. > > > > (I had to take off a guard to do this) > > > > It then scans through all the appropriate places > and > > changes the pointers. > > > > But then it drops out after about 20-30 files. I > > never knew what was happening before, but I have > > recently studied a bit on GTM debugging > techniques, > > and here is what I have come up with: > > > > Screen log: > > > > ROES ELIGIBILITY CONFIRMATION entries whose > 'PATIENT' > > pointers have been changed > > MAR > > 29,2005 20:12 PAGE 1 > > > > > > > *** NO RECORDS TO PRINT *** > > GTM>w $ECODE notice > drop-out > > ,M7,Z150372994, > > GTM>w $ZSTATUS > > 150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global > variable > > undefined: ^DPT(75002,0) > > GTM>zprint SCR+1^DIO2 > > X DIS(0) Q:'$T G PASS:'$D(DIS(1)) > > > > GTM>w DIS(0) > > S Y=D0 I $D(^AUPNPAT(Y,0)
RE: [Hardhats-members] Fileman drop-out on pointer update
After a merge of patient data, a stub is left behind. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marianne Susaanti Follingstad Sent: Monday, April 04, 2005 11:46 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G.Jim Gray - Original Message - From: Marianne Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTMzwr ^AUPNPAT(0) ^AUPNPAT(0)=PATIENT/IHS^901sIP^14861^1510 GTMzwr ^DD(901,0,SCR) ^DD(901,0,SCR)=X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: A quick look at the DI* routines I have (which are old), leads me to suggest that you look at the DD for the file defining ^AUPNPAT. Look at ^AUPNPAT(0) to find the file number and then look at ^DD(file number,0,SCR) and I'm guessing you'll find the culprit there as I '$P(^DPT(Y,0),U,19). If that is the problem then someone should review the SCR nodes to ensure there are no similar problems lurking... Of course the other problem is how to restart the process, and unfortunately I don't have any suggestions on that issue. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: I had two patients that were duplicates--i.e. the same person, but with two different married names. So I deleted one, and told fileman to change all pointers from the former to the later. (I had to take off a guard to do this) It then scans through all the appropriate places and changes the pointers. But then it drops out after about 20-30 files. I never knew what was happening before, but I have recently studied a bit on GTM debugging techniques, and here is what I have come up with: Screen log: ROES ELIGIBILITY CONFIRMATION entries whose 'PATIENT' pointers have been changed MAR 29,2005 20:12 PAGE 1 *** NO RECORDS TO PRINT *** GTMw $ECODE notice drop-out ,M7,Z150372994, GTMw $ZSTATUS 150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global variable undefined: ^DPT(75002,0) GTMzprint SCR+1^DIO2 X DIS(0) Q:'$T G PASS:'$D(DIS(1)) GTMw DIS(0) S Y=D0 I $D(^AUPNPAT(Y,0)) X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) GTMw Y 75002 GTM
RE: [Hardhats-members] Fileman drop-out on pointer update
What data should such a stub contain? Kevin --- Cameron Schlehuber [EMAIL PROTECTED] wrote: After a merge of patient data, a stub is left behind. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marianne Susaanti Follingstad Sent: Monday, April 04, 2005 11:46 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G. Jim Gray - Original Message - From: Marianne mailto:[EMAIL PROTECTED] Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTMzwr ^AUPNPAT(0) ^AUPNPAT(0)=PATIENT/IHS^901sIP^14861^1510 GTMzwr ^DD(901,0,SCR) ^DD(901,0,SCR)=X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: A quick look at the DI* routines I have (which are old), leads me to suggest that you look at the DD for the file defining ^AUPNPAT. Look at ^AUPNPAT(0) to find the file number and then look at ^DD(file number,0,SCR) and I'm guessing you'll find the culprit there as I '$P(^DPT(Y,0),U,19). If that is the problem then someone should review the SCR nodes to ensure there are no similar problems lurking... Of course the other problem is how to restart the process, and unfortunately I don't have any suggestions on that issue. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: I had two patients that were duplicates--i.e. the same person, but with two different married names. So I deleted one, and told fileman to change all pointers from the former to the later. (I had to take off a guard to do this) It then scans through all the appropriate places and changes the pointers. But then it drops out after about 20-30 files. I never knew what was happening before, but I have recently studied a bit on GTM debugging techniques, and here is what I have come up with: Screen log: ROES ELIGIBILITY CONFIRMATION entries whose 'PATIENT' pointers have been changed MAR 29,2005 20:12PAGE 1
RE: [Hardhats-members] Fileman drop-out on pointer update
From page 78 at www.va.gov/vdl/VistA_Lib/Infrastructure/Dupl_Rec_Merge/xt_73_p23_um.doc After the merge completes the FROM record is deleted. A stub record containing only the .01 field and a -9 node is then inserted in the PATIENT file (#2). The -9 node has a value equal to the internal entry number of the TO entry. If anyone tries to access the FROM entry while the merge is in progress, or any time after that, the expected value will be returned without an undefined error. Additionally, the Name and the Social Security Number fields originally contained in the FROM record are moved into the ALIAS subfile in the TO record. (The PDF version of the user manual seems to be corrupted.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Toppenberg Sent: Monday, April 04, 2005 12:32 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] Fileman drop-out on pointer update What data should such a stub contain? Kevin --- Cameron Schlehuber [EMAIL PROTECTED] wrote: After a merge of patient data, a stub is left behind. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marianne Susaanti Follingstad Sent: Monday, April 04, 2005 11:46 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Fileman drop-out on pointer update What then do you suggest? In this case, NOT having the $G is what created the situation of NOT having a ^DPT entry that is pointed to. In other words, if the $G had been there, the data would have updated correctly and avoided the data integrity problem that now exists. There has to be better ways to detect missing or corrupt data than having an application crash, which risks further corruption of more data. I'm curious as to what the VA does for duplicate records; anyone know? If there is a merge capability or deletion and repointing of duplicates and it uses the standard FileMan functionality, then it too could have the same issue. In this instance, the file on which things blew was an IHS Patient file, so maybe the VA avoided such pitfalls. It is interesting to note that the SCR node (which is meant to screen entries) is also being used here to display info, which does not seem like a great idea; however, there could still be valid reasons to need to look at info in a pointed to file during a screening. Marianne James Gray wrote: One could argue that it is not fine to put the $G there. There should never be a case in a good database that ^AUPNPAT(Y,0) exists and ^DPT(Y,0) does not exist. If that happens something is wrong in your database and it needs to be cleaned up. I have seen ^AUPNPAT(Y,0) nodes exist when the corresponding ^DPT(Y,0) nodes did not exist on a system running Cache just for the record. If you put the $G in you may never know that you have a bad node and who knows what else that bad node may do? I would suggest not putting in the $G. Jim Gray - Original Message - From: Marianne mailto:[EMAIL PROTECTED] Susaanti Follingstad To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 11:08 AM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTMzwr ^AUPNPAT(0) ^AUPNPAT(0)=PATIENT/IHS^901sIP^14861^1510 GTMzwr ^DD(901,0,SCR) ^DD(901,0,SCR)=X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: A quick look at the DI* routines I have (which are old), leads me to suggest that you look at the DD for the file defining ^AUPNPAT. Look at ^AUPNPAT(0) to find the file number and then look at ^DD(file number,0,SCR) and I'm guessing you'll find the culprit there as I '$P(^DPT(Y,0),U,19). If that is the problem then someone should review the SCR nodes to ensure there are no similar problems lurking... Of course the other problem is how to restart the process, and unfortunately I don't have any suggestions on that issue
Re: [Hardhats-members] Fileman drop-out on pointer update
This one entry isn't quite the same situation, since 3.5 is the file
found at ^%ZIS(1, so I don't believe that it would be necessary to change
the node. FileMan is definitely smart enough to know not to try to
access the file entry it had just deleted. The one that caused you
problems was in a file referenced by the entry you were deleting which
in turn was going back to try to use the original entry that was just deleted.
I'm impressed that you were so prompt in reviewing the "SCR" nodes...
Marianne
Kevin Toppenberg wrote:
Marianne,
I wrote this short code to show all the "SCR" nodes
ShowSCR
new I
set I=$order(^DD(""))
for do quit:(I="")
. if $data(^DD(I,0,"SCR"))
zwr ^DD(I,0,"SCR")
. set I=$order(^DD(I))
I then looked at them all, and they all seemed ok
except for this one:
^DD(3.5,0,"SCR")="I 1 Q:$G(D)'=""LSYN""
Q:'$D(^%ZOSF(""VOL"")) I
$P(^%ZIS(1,Y,0),U,9)=^%ZOSF(""VOL"")!($P(^%ZIS(1,Y,0),U,9)=)"
It looks like that ^%ZIS ought to be in a $G().
Think I should change it?
Kevin
--- Marianne Susaanti Follingstad
[EMAIL PROTECTED]> wrote:
> It should be fine to put the $G in there. There
> can't be any unforeseen
> consequences to having it there. In fact, as you
> found, there are unforeseen
> consequences to NOT having it there. As I
> mentioned, it would be good to have
> someone review these SCR nodes to see if there are
> any other potential problems.
>
> Marianne Follingstad
> 301 251 0139
>
> Kevin Toppenberg wrote:
>
> > Marianne,
> >
> > Thanks for your help.
> >
> > Following your instructions:
> > GTM>zwr ^AUPNPAT(0)
> > ^AUPNPAT(0)="PATIENT/IHS^901sIP^14861^1510"
> >
> > GTM>zwr ^DD(901,0,"SCR")
> > ^DD(901,0,"SCR")="X ""I '$P(^DPT(Y,0),U,19)""
> W
> > $E(^AUPNPAT(Y,0),0)"
> >
> >
> > So you are right. This is the source of the line
> that
> > caused the drop-out.
> >
> > I had suggested: It looks like the "^DPT(Y,0)"
> ought
> > to be "$G(^DPT(Y,0))"
> >
> > So I could put that change here. But I'm note
> sure if
> > that would have other unforseen consequenses.
> >
> > Is this really a 'bug'? Or is it one of those
> funny
> > database-needs-to-be-rundown type situations?
> >
> > Thanks
> > Kevin
> >
> > --- Marianne Susaanti Follingstad
> > [EMAIL PROTECTED]> wrote:
> >
> > > A quick look at the DI* routines I have (which
> are
> > > old), leads me to suggest that
> > > you look at the DD for the file defining
> ^AUPNPAT.
> > > Look at ^AUPNPAT(0) to find the
> > > file number and then look at ^DD(file
> > > number,0,"SCR") and I'm guessing you'll find
> > > the culprit there as "I '$P(^DPT(Y,0),U,19)".
> If
> > > that is the problem then someone
> > > should review the "SCR" nodes to ensure there
> are no
> > > similar problems lurking...
> > >
> > > Of course the other problem is how to restart
> the
> > > process, and unfortunately I don't
> > > have any suggestions on that issue.
> > >
> > > Marianne Follingstad
> > > 301 251 0139
> > >
> > > Kevin Toppenberg wrote:
> > >
> > > > I had two patients that were duplicates--i.e.
> the
> > > same
> > > > person, but with two different married names.
> > > >
> > > > So I deleted one, and told fileman to change
> all
> > > > pointers from the former to the later.
> > > >
> > > > (I had to take off a guard to do this)
> > > >
> > > > It then scans through all the appropriate
> places
> > > and
> > > > changes the pointers.
> > > >
> > > > But then it drops out after about 20-30 files.
> I
> > > > never knew what was happening before, but I
> have
> > > > recently studied a bit on GTM debugging
> > > techniques,
> > > > and here is what I have come up with:
> > > >
> > > > Screen log:
> > > >
> > > > ROES ELIGIBILITY CONFIRMATION entries whose
> > > 'PATIENT'
> > > > pointers have been changed
> > > >
> MAR
> > > > 29,2005 20:12 PAGE 1
> > > >
> > >
> >
>
> > > >
> > > >
*** NO RECORDS TO PRINT ***
> > > > GTM>w $ECODE
notice
> > > drop-out
> > > > ,M7,Z150372994,
> > > > GTM>w $ZSTATUS
> > > > 150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global
> > > variable
> > > > undefined: ^DPT(75002,0)
> > > > GTM>zprint SCR+1^DIO2
> > > > X DIS(0) Q:'$T
G PASS:'$D(DIS(1))
> > > >
> > > > GTM>w DIS(0)
> > > > S Y=D0 I $D(^AUPNPAT(Y,0)) X "I
> > > '$P(^DPT(Y,0),U,19)" W
> > > > $E(^AUPNPAT(Y,0),0)
> > > > GTM>w Y
> > > > 75002
> > > > GTM>
> > > >
> > > > It looks like the "^DPT(Y,0)" ought to be
> > > > "$G(^DPT(Y,0))"
> > > >
> > > > Kevin
> > > >
> > > >
> __
> > > > Do You Yahoo!?
> > > > Tired of spam? Yahoo! Mail has the best spam
> > > protection around
> > > > http://mail.yahoo.com
> > > >
> > > >
> > >
> >
>
---
> > > > SF email is sponsored by - The IT Product
> Guide
> > > > Read honest candid reviews on hundreds of IT
> > > Products from real users.
> > > > Discover which products truly live up to the
> hype.
> > > Start reading now.
> > > >
> > >
Re: [Hardhats-members] Fileman drop-out on pointer update
Thanks, But don't be too impressed. I don't have a clue what SCR nodes do. I was just looking for code that referenced globals without a $get() or $data() guard. Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: This one entry isn't quite the same situation, since 3.5 is the file found at ^%ZIS(1, so I don't believe that it would be necessary to change the node. FileMan is definitely smart enough to know not to try to access the file entry it had just deleted. The one that caused you problems was in a file referenced by the entry you were deleting which in turn was going back to try to use the original entry that was just deleted. I'm impressed that you were so prompt in reviewing the SCR nodes... Marianne Kevin Toppenberg wrote: Marianne, I wrote this short code to show all the SCR nodes ShowSCR new I set I=$order(^DD()) for do quit:(I=) . if $data(^DD(I,0,SCR)) zwr ^DD(I,0,SCR) . set I=$order(^DD(I)) I then looked at them all, and they all seemed ok except for this one: ^DD(3.5,0,SCR)=I 1 Q:$G(D)'=LSYN Q:'$D(^%ZOSF(VOL)) I $P(^%ZIS(1,Y,0),U,9)=^%ZOSF(VOL)!($P(^%ZIS(1,Y,0),U,9)=) It looks like that ^%ZIS ought to be in a $G(). Think I should change it? Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTMzwr ^AUPNPAT(0) ^AUPNPAT(0)=PATIENT/IHS^901sIP^14861^1510 GTMzwr ^DD(901,0,SCR) ^DD(901,0,SCR)=X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: A quick look at the DI* routines I have (which are old), leads me to suggest that you look at the DD for the file defining ^AUPNPAT. Look at ^AUPNPAT(0) to find the file number and then look at ^DD(file number,0,SCR) and I'm guessing you'll find the culprit there as I '$P(^DPT(Y,0),U,19). If that is the problem then someone should review the SCR nodes to ensure there are no similar problems lurking... Of course the other problem is how to restart the process, and unfortunately I don't have any suggestions on that issue. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: I had two patients that were duplicates--i.e. the same person, but with two different married names. So I deleted one, and told fileman to change all pointers from the former to the later. (I had to take off a guard to do this) It then scans through all the appropriate places and changes the pointers. But then it drops out after about 20-30 files. I never knew what was happening before, but I have recently studied a bit on GTM debugging techniques, and here is what I have come up with: Screen log: ROES ELIGIBILITY CONFIRMATION entries whose 'PATIENT' pointers have been changed MAR 29,2005 20:12PAGE 1 *** NO RECORDS TO PRINT *** GTMw $ECODE notice drop-out ,M7,Z150372994, GTMw $ZSTATUS 150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global variable undefined: ^DPT(75002,0) GTMzprint SCR+1^DIO2 X DIS(0) Q:'$T G PASS:'$D(DIS(1)) GTMw DIS(0) S Y=D0 I $D(^AUPNPAT(Y,0)) X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) GTMw Y 75002 GTM It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) === message truncated === __ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest ---
Re: [Hardhats-members] Fileman drop-out on pointer update
Marianne, Thanks for your help. Following your instructions: GTMzwr ^AUPNPAT(0) ^AUPNPAT(0)=PATIENT/IHS^901sIP^14861^1510 GTMzwr ^DD(901,0,SCR) ^DD(901,0,SCR)=X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED] wrote: A quick look at the DI* routines I have (which are old), leads me to suggest that you look at the DD for the file defining ^AUPNPAT. Look at ^AUPNPAT(0) to find the file number and then look at ^DD(file number,0,SCR) and I'm guessing you'll find the culprit there as I '$P(^DPT(Y,0),U,19). If that is the problem then someone should review the SCR nodes to ensure there are no similar problems lurking... Of course the other problem is how to restart the process, and unfortunately I don't have any suggestions on that issue. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: I had two patients that were duplicates--i.e. the same person, but with two different married names. So I deleted one, and told fileman to change all pointers from the former to the later. (I had to take off a guard to do this) It then scans through all the appropriate places and changes the pointers. But then it drops out after about 20-30 files. I never knew what was happening before, but I have recently studied a bit on GTM debugging techniques, and here is what I have come up with: Screen log: ROES ELIGIBILITY CONFIRMATION entries whose 'PATIENT' pointers have been changed MAR 29,2005 20:12PAGE 1 *** NO RECORDS TO PRINT *** GTMw $ECODE notice drop-out ,M7,Z150372994, GTMw $ZSTATUS 150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global variable undefined: ^DPT(75002,0) GTMzprint SCR+1^DIO2 X DIS(0) Q:'$T G PASS:'$D(DIS(1)) GTMw DIS(0) S Y=D0 I $D(^AUPNPAT(Y,0)) X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) GTMw Y 75002 GTM It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) Kevin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members __ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Fileman drop-out on pointer update
It should be fine to put the $G in there. There can't be any unforeseen consequences to having it there. In fact, as you found, there are unforeseen consequences to NOT having it there. As I mentioned, it would be good to have someone review these SCR nodes to see if there are any other potential problems. Marianne Follingstad 301 251 0139 Kevin Toppenberg wrote: Marianne, Thanks for your help. Following your instructions: GTM>zwr ^AUPNPAT(0) ^AUPNPAT(0)="PATIENT/IHS^901sIP^14861^1510" GTM>zwr ^DD(901,0,"SCR") ^DD(901,0,"SCR")="X ""I '$P(^DPT(Y,0),U,19)"" W $E(^AUPNPAT(Y,0),0)" So you are right. This is the source of the line that caused the drop-out. I had suggested: It looks like the "^DPT(Y,0)" ought to be "$G(^DPT(Y,0))" So I could put that change here. But I'm note sure if that would have other unforseen consequenses. Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? Thanks Kevin --- Marianne Susaanti Follingstad [EMAIL PROTECTED]> wrote: > A quick look at the DI* routines I have (which are > old), leads me to suggest that > you look at the DD for the file defining ^AUPNPAT. > Look at ^AUPNPAT(0) to find the > file number and then look at ^DD(file > number,0,"SCR") and I'm guessing you'll find > the culprit there as "I '$P(^DPT(Y,0),U,19)". If > that is the problem then someone > should review the "SCR" nodes to ensure there are no > similar problems lurking... > > Of course the other problem is how to restart the > process, and unfortunately I don't > have any suggestions on that issue. > > Marianne Follingstad > 301 251 0139 > > Kevin Toppenberg wrote: > > > I had two patients that were duplicates--i.e. the > same > > person, but with two different married names. > > > > So I deleted one, and told fileman to change all > > pointers from the former to the later. > > > > (I had to take off a guard to do this) > > > > It then scans through all the appropriate places > and > > changes the pointers. > > > > But then it drops out after about 20-30 files. I > > never knew what was happening before, but I have > > recently studied a bit on GTM debugging > techniques, > > and here is what I have come up with: > > > > Screen log: > > > > ROES ELIGIBILITY CONFIRMATION entries whose > 'PATIENT' > > pointers have been changed > > MAR > > 29,2005 20:12 PAGE 1 > > > > > > > *** NO RECORDS TO PRINT *** > > GTM>w $ECODE notice > drop-out > > ,M7,Z150372994, > > GTM>w $ZSTATUS > > 150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global > variable > > undefined: ^DPT(75002,0) > > GTM>zprint SCR+1^DIO2 > > X DIS(0) Q:'$T G PASS:'$D(DIS(1)) > > > > GTM>w DIS(0) > > S Y=D0 I $D(^AUPNPAT(Y,0)) X "I > '$P(^DPT(Y,0),U,19)" W > > $E(^AUPNPAT(Y,0),0) > > GTM>w Y > > 75002 > > GTM> > > > > It looks like the "^DPT(Y,0)" ought to be > > "$G(^DPT(Y,0))" > > > > Kevin > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > --- > > SF email is sponsored by - The IT Product Guide > > Read honest candid reviews on hundreds of IT > Products from real users. > > Discover which products truly live up to the hype. > Start reading now. > > > http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click > > ___ > > Hardhats-members mailing list > > Hardhats-members@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > __ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Fileman drop-out on pointer update
Yeah, but it is the nature of the weak minded to look for answers in superstition. LOL. Actually, my production system rarely needs to be rundown. But that is probably because I am now quite careful with it. But when I am configuring a new system, I often have crashes that lead to the funny behavior that I hinted at. Kevin --- Bhaskar, KS [EMAIL PROTECTED] wrote: Comment below. -- Bhaskar -Original Message- From: [EMAIL PROTECTED] on behalf of Kevin Toppenberg Sent: Fri 4/1/2005 12:59 PM To: hardhats-members@lists.sourceforge.net Cc: Subject: Re: [Hardhats-members] Fileman drop-out on pointer update Marianne, [KSB] ...snip... Is this really a 'bug'? Or is it one of those funny database-needs-to-be-rundown type situations? [KSB] Kevin, you are invoking rundown as if it is a lucky rabbit's foot to be kept in the pocket and touched for good luck. Unless something is fundamentally flawed in how you operate GT.M, you should not need rundown. Fortunately, it's harmless (the only time not to try it is when you are bringing up the computer after a crash like a power failure and you are about to do a mupip journal -recover -backward, and even there it's usually harmless). The only time you would need it is when you are bringing up a database when something has gone wrong - like a system crash, and you didn't have journaling turned on, or when the last process accessing a database terminated abnormally (e.g., someone issued a kill -9 on it). It's also a quick way to see whether anyone is in the database, when you are powering down the system, or replacing one GT.M version with another. At other times, it is no more than that rabbit's foot. -- Bhaskar __ Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. http://www.advision.webevents.yahoo.com/emoticontest --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Fileman drop-out on pointer update
-Original Message- From: [EMAIL PROTECTED] on behalf of Kevin Toppenberg Sent: Sat 4/2/2005 3:46 PM To: hardhats-members@lists.sourceforge.net Cc: Subject:RE: [Hardhats-members] Fileman drop-out on pointer update Yeah, but it is the nature of the weak minded to look for answers in superstition. LOL. Actually, my production system rarely needs to be rundown. But that is probably because I am now quite careful with it. But when I am configuring a new system, I often have crashes that lead to the funny behavior that I hinted at. Kevin [KSB] OK, if there are system crashes, and you are not running journaling, then rundown makes sense. Remember to run a mupip integ periodically, because the database can be structurally damaged by a crash. -- Bhaskar winmail.dat
Re: [Hardhats-members] Fileman drop-out on pointer update
When Rick was helping to port the VA Demo to GTM, I noticed he did a rundown on the database every time he shut it down and since then, I have done that as well. True that at the time he was tinkering with its innards, but I figured I ought to take a hint and do the same. On Saturday 02 April 2005 04:10 pm, Bhaskar, KS wrote: -Original Message- From: [EMAIL PROTECTED] on behalf of Kevin Toppenberg Sent: Sat 4/2/2005 3:46 PM To: hardhats-members@lists.sourceforge.net Cc: Subject: RE: [Hardhats-members] Fileman drop-out on pointer update Yeah, but it is the nature of the weak minded to look for answers in superstition. LOL. Actually, my production system rarely needs to be rundown. But that is probably because I am now quite careful with it. But when I am configuring a new system, I often have crashes that lead to the funny behavior that I hinted at. Kevin [KSB] OK, if there are system crashes, and you are not running journaling, then rundown makes sense. Remember to run a mupip integ periodically, because the database can be structurally damaged by a crash. -- Bhaskar -- Nancy Anthracite --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Fileman drop-out on pointer update
Nancy; He was only tickling the VistA innards which is an abstraction from the MUMPS environment. There is no magic really, but if one is shutting down, it is best to do the rundown first (especially if you are the only user). Best wishes; Chris - Original Message - From: Nancy Anthracite [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Saturday, April 02, 2005 1:20 PM Subject: Re: [Hardhats-members] Fileman drop-out on pointer update When Rick was helping to port the VA Demo to GTM, I noticed he did a rundown on the database every time he shut it down and since then, I have done that as well. True that at the time he was tinkering with its innards, but I figured I ought to take a hint and do the same. On Saturday 02 April 2005 04:10 pm, Bhaskar, KS wrote: -Original Message- From: [EMAIL PROTECTED] on behalf of Kevin Toppenberg Sent: Sat 4/2/2005 3:46 PM To: hardhats-members@lists.sourceforge.net Cc: Subject: RE: [Hardhats-members] Fileman drop-out on pointer update Yeah, but it is the nature of the weak minded to look for answers in superstition. LOL. Actually, my production system rarely needs to be rundown. But that is probably because I am now quite careful with it. But when I am configuring a new system, I often have crashes that lead to the funny behavior that I hinted at. Kevin [KSB] OK, if there are system crashes, and you are not running journaling, then rundown makes sense. Remember to run a mupip integ periodically, because the database can be structurally damaged by a crash. -- Bhaskar -- Nancy Anthracite --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] Fileman drop-out on pointer update
In a former life I did QA for the Kernel team. At the time, I ran MSM on my workstation (a 486, if that tells you anything) and I did inegrity checks as part of my testing process. I think I found an integrity problem -- once. This error is due to a dangling pointer (no patient exists with a DFN of Y) and I hav to agree that dangling pointers are much more likely to be due to something going wrong at the VistA level than in the underlying MUMPS system. Yes, it's possible that one or more global nodes could be lost, but I have to agree that we're looking a little too reflexively for GTM errors. --- Bhaskar, KS [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] on behalf of Kevin Toppenberg Sent: Sat 4/2/2005 3:46 PM To: hardhats-members@lists.sourceforge.net Cc: Subject: RE: [Hardhats-members] Fileman drop-out on pointer update Yeah, but it is the nature of the weak minded to look for answers in superstition. LOL. Actually, my production system rarely needs to be rundown. But that is probably because I am now quite careful with it. But when I am configuring a new system, I often have crashes that lead to the funny behavior that I hinted at. Kevin [KSB] OK, if there are system crashes, and you are not running journaling, then rundown makes sense. Remember to run a mupip integ periodically, because the database can be structurally damaged by a crash. -- Bhaskar A practical man is a man who practices the errors of his forefathers. --Benjamin Disraeli Greg Woodhouse [EMAIL PROTECTED] [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] Fileman drop-out on pointer update
All you will do is postpone the inevitable. The zero node of a record
is essential and shouldn't be missing. It is a sign that something is
wrong. (I can think of one case in the 3.9 file where I believe the
zero node's non-existence is a 'sign' that the record is being built
and not ready yet, but I am only inferring this reading.)
Kevin Toppenberg wrote:
Marianne,
I wrote this short code to show all the "SCR" nodes
ShowSCR
new I
set I=$order(^DD(""))
for do quit:(I="")
. if $data(^DD(I,0,"SCR")) zwr ^DD(I,0,"SCR")
. set I=$order(^DD(I))
I then looked at them all, and they all seemed ok
except for this one:
^DD(3.5,0,"SCR")="I 1 Q:$G(D)'=""LSYN""
Q:'$D(^%ZOSF(""VOL"")) I
$P(^%ZIS(1,Y,0),U,9)=^%ZOSF(""VOL"")!($P(^%ZIS(1,Y,0),U,9)=)"
It looks like that ^%ZIS ought to be in a $G().
Think I should change it?
Kevin
--- Marianne Susaanti Follingstad
[EMAIL PROTECTED] wrote:
It should be fine to put the $G in there. There
can't be any unforeseen
consequences to having it there. In fact, as you
found, there are unforeseen
consequences to NOT having it there. As I
mentioned, it would be good to have
someone review these SCR nodes to see if there are
any other potential problems.
Marianne Follingstad
301 251 0139
Kevin Toppenberg wrote:
Marianne,
Thanks for your help.
Following your instructions:
GTMzwr ^AUPNPAT(0)
^AUPNPAT(0)="PATIENT/IHS^901sIP^14861^1510"
GTMzwr ^DD(901,0,"SCR")
^DD(901,0,"SCR")="X ""I '$P(^DPT(Y,0),U,19)""
W
$E(^AUPNPAT(Y,0),0)"
So you are right. This is the source of the line
that
caused the drop-out.
I had suggested: It looks like the "^DPT(Y,0)"
ought
to be "$G(^DPT(Y,0))"
So I could put that change here. But I'm note
sure if
that would have other unforseen consequenses.
Is this really a 'bug'? Or is it one of those
funny
database-needs-to-be-rundown type situations?
Thanks
Kevin
--- Marianne Susaanti Follingstad
[EMAIL PROTECTED] wrote:
A quick look at the DI* routines I have (which
are
old), leads me to suggest that
you look at the DD for the file defining
^AUPNPAT.
Look at ^AUPNPAT(0) to find the
file number and then look at ^DD(file
number,0,"SCR") and I'm guessing you'll find
the culprit there as "I '$P(^DPT(Y,0),U,19)".
If
that is the problem then someone
should review the "SCR" nodes to ensure there
are no
similar problems lurking...
Of course the other problem is how to restart
the
process, and unfortunately I don't
have any suggestions on that issue.
Marianne Follingstad
301 251 0139
Kevin Toppenberg wrote:
I had two patients that were duplicates--i.e.
the
same
person, but with two different married names.
So I deleted one, and told fileman to change
all
pointers from the former to the later.
(I had to take off a guard to do this)
It then scans through all the appropriate
places
and
changes the pointers.
But then it drops out after about 20-30 files.
I
never knew what was happening before, but I
have
recently studied a bit on GTM debugging
techniques,
and here is what I have come up with:
Screen log:
ROES ELIGIBILITY CONFIRMATION entries whose
'PATIENT'
pointers have been changed
MAR
29,2005 20:12PAGE 1
*** NO RECORDS TO PRINT ***
GTMw $ECODE notice
drop-out
,M7,Z150372994,
GTMw $ZSTATUS
150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global
variable
undefined: ^DPT(75002,0)
GTMzprint SCR+1^DIO2
X DIS(0) Q:'$T G PASS:'$D(DIS(1))
GTMw DIS(0)
S Y=D0 I $D(^AUPNPAT(Y,0)) X "I
'$P(^DPT(Y,0),U,19)" W
$E(^AUPNPAT(Y,0),0)
GTMw Y
75002
[Hardhats-members] Fileman drop-out on pointer update
I had two patients that were duplicates--i.e. the same person, but with two different married names. So I deleted one, and told fileman to change all pointers from the former to the later. (I had to take off a guard to do this) It then scans through all the appropriate places and changes the pointers. But then it drops out after about 20-30 files. I never knew what was happening before, but I have recently studied a bit on GTM debugging techniques, and here is what I have come up with: Screen log: ROES ELIGIBILITY CONFIRMATION entries whose 'PATIENT' pointers have been changed MAR 29,2005 20:12PAGE 1 *** NO RECORDS TO PRINT *** GTMw $ECODE notice drop-out ,M7,Z150372994, GTMw $ZSTATUS 150372994,SCR+1^DIO2,%GTM-E-GVUNDEF, Global variable undefined: ^DPT(75002,0) GTMzprint SCR+1^DIO2 X DIS(0) Q:'$T G PASS:'$D(DIS(1)) GTMw DIS(0) S Y=D0 I $D(^AUPNPAT(Y,0)) X I '$P(^DPT(Y,0),U,19) W $E(^AUPNPAT(Y,0),0) GTMw Y 75002 GTM It looks like the ^DPT(Y,0) ought to be $G(^DPT(Y,0)) Kevin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
