Bhaskar
I didn't have the oppurtunity to go through the whole manual but this is
waht I found out.
The error that I was getting was GVDATAFAIL with the code ZZZZ which there
are some "record errors" in my database and I should refer to Section - "O2"
for rectifying it. The block is level 0. So I turned to Section "O3".
[EMAIL PROTECTED] vista]$ mupip
MUPIP> integ
File or Region: OpenVistA/g/mumps.dat
Block:Offset Level
%GTM-E-DBBADNSUB,
998:B8 0 Bad numeric subscript
Directory Path: 1:8, 2:1ED
Path: 305:119, 932:ED, 998:B8
Keys from ^DD(200.0747430015+41,"ADDRESS 2",1.1) to ^DD(200.07476,1.8) are
suspect.
Total error count from integ: 1.
Type Blocks Records % Used Adjacent
Directory 2 334 48.901 NA
Index 670 68968 45.267 1
Data 68631 13203486 98.055 66961
Free 697 NA NA NA
Total 70000 13272788 NA 66962
%GTM-E-INTEGERRS, Database integrity errors
I REMOVEd the specified block's offset (block 998, offset B8, level 0), till
the error count became 0.
This has solved the GTM problem but I still can't see the providers created
before creating an entry in the DG SECURITY LOG file.
Usha
----- Original Message -----
From: "Bhaskar, KS" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, February 22, 2005 7:45 PM
Subject: Re: [Hardhats-members] Re: Unable to access providers
> Usha --
>
> In your environment, I would guess that integrity errors are entirely
> due to powering down the PC while GT.M processes were actively using the
> database. You should shut down cleanly from a GT.M point of view before
> powering down the PC - or run journaling.
>
> Note that even if you shut down cleanly from a GT.M point of view, the
> database may be inconsistent from a VistA application point of view
> (e.g., there may be Taskman process ids in the database). So, when
> shutting down, you should shut down VistA cleanly.
>
> More comments below.
>
> -- Bhaskar
>
> On Tue, 2005-02-22 at 10:37 +0530, Usha Kiran wrote:
> > Bhaskar
> > Are these integrity problems due to improper settings file?
> > Usha
>
> [KSB] <...snip...>
>
> > >
> > > > From the previous error message encountered
> > > > "%GTM-E-GVDATAFAIL, Global variable $DATA
> > > > function failed. Failure code: ZZZZ.,%GTM-I-GVIS,
Global
> > > > variable: ^DD(200.074745,.01,9)
> > > > At M source location DR+3^DIA1"
> > > >
> > > > I tried to check the global (^DD(200.074745,.01,9)) it was
referring
> > > to (did
> > > > not let me see the value in the global) and got the following
message
> > > >
> > > > NOTE: You"ve discovered an error in VGL/I.
> > > > Error: 150372962,LOOP1+3^%ZVEMGI,%GTM-E-GVORDERFAIL, Global
variable
> > > $ORDER
> > > > or $
> > > > NEXT function failed. Failure code: ZZZZ.,%GTM-I-GVIS,
> > > > Global variable: ^DD(2
> > > > 00.074745,.01,1,1,2,"")
> > > > Please report error to BOLDUC,[EMAIL PROTECTED]
> > >
> > > [KSB] Check the Admin and Ops manual for GVDATAFAIL - it says this is
> > > probably database damage. Did you shut down your PC with active
> > > processes? You will need to run mupip integ to check for database
> > > damage (which will probably need to be repaired manually). In the
> > > future, please either shut down cleanly, or run journaling (or both).
> > >
> > > ----------------------------------------
> >
> > This is the result of running "/usr/local/gtm/mupip integ -full -file
> > "/home/vista/OpenVistA/g/mumps.dat""
> >
> > ...
>
> [KSB] You have snipped the most important part of the integ report. In
> any case, you can read the Admin and Ops manual and repair the database.
>
> > Global variable ^YTX
> > Level Blocks Records % Used Adjacent
> > 1 1 6 2.514 0
> > 0 6 650 89.941 5
> >
> > Total error count from integ: 1.
> >
> > Type Blocks Records % Used Adjacent
> >
> > Directory 2 334 48.901 NA
> > Index 670 68949 45.255 1
> > Data 68612 13201429 98.068 66963
> > Free 716 NA NA NA
> > Total 70000 13270712 NA 66964
> > %GTM-E-INTEGERRS, Database integrity errors
> > [EMAIL PROTECTED] vista]$
> > [EMAIL PROTECTED] vista]$ /usr/local/OpenVistA/vista --run
> > /home/vista/OpenVistA
> > GTM>w %GTM-E-INTEGERRS
> > %GTM-E-UNDEF, Undefined local variable: %GTM
> >
> > Is there any way I can define this value?
>
> [KSB] This is an application question. Local variables don't touch the
> database. Somewhere in the VistA application logic will be code to set
> the value of the variable.
>
> At this point, I suggest you drop all other activity until you fix the
> database from a GT.M point of view.
>
> I don't know what tools VistA has to check the M global variables for
> consistency from an application point of view, but it may be worth
> running those, depending on which global variables were damaged.
>
>
> -------------------------------------------------------
> 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=6595&alloc_id=14396&op=click
> _______________________________________________
> Hardhats-members mailing list
> [email protected]
> 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=6595&alloc_id=14396&op=click
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
