Re: [Hardhats-members] DAT file keeps growing up
Then it should be straightforward to track this information with GT.M. Mupip journal -extract creates an extract from GT.M journal files. Some potentially useful qualifiers are: -g[lobal] to select globals of interest (or exclude globals not of interest) -u[ser] to select/exclude users -id to select/exclude process ids -t[ransaction] to select/exclude update types (Set/Kill) -be[fore] -af[ter] and -si[nce] to limit the extract in time. There is an entire chapter devoted to journaling in the Admin and Ops Guide, as well as technical bulletins on more recent information since the last edition was published. Note that we also recommend turning on process accounting / logging at the operating system level (and all GT.M processes are regular UNIX/Linux/VMS processes). -- Bhaskar On Thu, 2004-09-09 at 10:30, steven mcphelan wrote: > VistA does track this information sort of in Cache. If the journal file > does have the $J value associate with the record, then you can back track > that $J value via the Kernel Sign-on log. Between the date and time and $J, > you can determine which user was signed on for that transaction. *** This electronic mail transmission contains confidential and/or privileged information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. *** NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus et peut contenir de l'information privilegiee, confidentielle et/ou dispensee de divulgation aux termes des lois applicables. Si vous avez recu ce message par erreur, ou s'il ne vous est pas destine, veuillez le mentionner immediatement a l'expediteur et effacer ce courriel. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] DAT file keeps growing up
VistA does track this information sort of in Cache. If the journal file does have the $J value associate with the record, then you can back track that $J value via the Kernel Sign-on log. Between the date and time and $J, you can determine which user was signed on for that transaction. - Original Message - From: "K.S. Bhaskar" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 09, 2004 10:11 AM Subject: Re: [Hardhats-members] DAT file keeps growing up Greg -- By context, do you mean the application (e.g., registration, oncology, etc.)? That would have to be deduced from the global sets. Or do you want to create a journal record for each M entryref called (obviously a performance issue). Note that with GT.M transaction processing (not [yet!] used by VistA), you can specify a Transaction id that gets recorded in the journal file. -- Bhaskar On Thu, 2004-09-09 at 09:49, Greg Kreis wrote: > Thinking about it more, it would be useful to have the process in the > context. In other words, what program was running at the time of the > change. Thinking about it more, I'd want a way to name the context > and have that name applied to the journal entry. It could be a > nightmare to backtrack from a single node's change to the context that > started it. *** This electronic mail transmission contains confidential and/or privileged information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. *** NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus et peut contenir de l'information privilegiee, confidentielle et/ou dispensee de divulgation aux termes des lois applicables. Si vous avez recu ce message par erreur, ou s'il ne vous est pas destine, veuillez le mentionner immediatement a l'expediteur et effacer ce courriel. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=ick ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] DAT file keeps growing up
Greg -- By context, do you mean the application (e.g., registration, oncology, etc.)? That would have to be deduced from the global sets. Or do you want to create a journal record for each M entryref called (obviously a performance issue). Note that with GT.M transaction processing (not [yet!] used by VistA), you can specify a Transaction id that gets recorded in the journal file. -- Bhaskar On Thu, 2004-09-09 at 09:49, Greg Kreis wrote: > Thinking about it more, it would be useful to have the process in the > context. In other words, what program was running at the time of the > change. Thinking about it more, I'd want a way to name the context > and have that name applied to the journal entry. It could be a > nightmare to backtrack from a single node's change to the context that > started it. *** This electronic mail transmission contains confidential and/or privileged information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. *** NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus et peut contenir de l'information privilegiee, confidentielle et/ou dispensee de divulgation aux termes des lois applicables. Si vous avez recu ce message par erreur, ou s'il ne vous est pas destine, veuillez le mentionner immediatement a l'expediteur et effacer ce courriel. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=click ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] DAT file keeps growing up
Thinking about it more, it would be useful to have the process in the context. In other words, what program was running at the time of the change. Thinking about it more, I'd want a way to name the context and have that name applied to the journal entry. It could be a nightmare to backtrack from a single node's change to the context that started it. Koivulehto Heikki wrote: Caché's journal seems to have only the process IDs. hjk -- Lähettäjä: Greg Kreis[SMTP:[EMAIL PROTECTED]] Lähetetty: 9. syyskuuta 2004 1:46 Vastaanottaja: [EMAIL PROTECTED] Aihe: Re: [Hardhats-members] DAT file keeps growing up !"So, in theory, if you keep a table of user IDs and process IDs with date and time, you could trace back journal entries to a specific user on GT.M? Does anyone know if Cache's journals contain that much information? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&opclick ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] DAT file keeps growing up
That is too bad. VistA can track the user's identity, process ID, logon and logoff time. If the journal could ID the process and date.time, it could be tracked back to a user. Koivulehto Heikki wrote: Caché's journal seems to have only the process IDs. hjk -- Lähettäjä: Greg Kreis[SMTP:[EMAIL PROTECTED]] Lähetetty: 9. syyskuuta 2004 1:46 Vastaanottaja: [EMAIL PROTECTED] Aihe: Re: [Hardhats-members] DAT file keeps growing up !"So, in theory, if you keep a table of user IDs and process IDs with date and time, you could trace back journal entries to a specific user on GT.M? Does anyone know if Cache's journals contain that much information? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&opclick ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] DAT file keeps growing up
Caché's journal seems to have only the process IDs. hjk > -- > Lähettäjä:Greg Kreis[SMTP:[EMAIL PROTECTED] > Lähetetty:9. syyskuuta 2004 1:46 > Vastaanottaja:[EMAIL PROTECTED] > Aihe: Re: [Hardhats-members] DAT file keeps growing up > > !"So, in theory, if you keep a table of user IDs and process IDs with date > and time, you could trace back journal entries to a specific user on GT.M? > Does anyone know if Cache's journals contain that much information? > > --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=click ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] DAT file keeps growing up
Wake up Bhaskar! No more sleeping at the desk (or perhaps I was simply trying to multi-task across too many things at once)! Sorry, Alexis. I explained why a .jnl (journal) file can grow fast, but not why a .dat (database) file can grow fast. The only way for a database file to grow is if it has data put into it. A mupip integ -full will tell you how much space each global takes, and a mupip journal -extract will tell you which processes put them there. Apropos Greg's question, yes, with the GT.M journal file you can trace each update back to a specific user id, process and (approximate) time. And it's not just in theory - folklore has it (I don't know details, and it was before my time that it is supposed to have happened, so it is possible that this is an urban legend) that this information was used to identify a bank employee with his hand in the cookie jar. -- Bhaskar -Original Message- From: [EMAIL PROTECTED] on behalf of Greg Kreis Sent: Wed 9/8/2004 6:46 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [Hardhats-members] DAT file keeps growing up So, in theory, if you keep a table of user IDs and process IDs with date and time, you could trace back journal entries to a specific user on GT.M? Does anyone know if Cache's journals contain that much information? K.S. Bhaskar wrote: >Alexis -- > >Remember that the journal file contains information on all sets and >kills, as well as before images of modified blocks. [A quick read of >the chapter on journaling in the Administration and Operations manual as >well as Technical Bulletin 5-025 on the Mupip Set Journal command >(http://sourceforge.net/docman/display_doc.php?docid=11357&group_id=11026) may be in >order.] > >The mupip journal -extract command can be used to tell you exactly which >process made what updates. > >My guess is that the bulk of the information is before images - since >you are presumably not making updates at a fast rate, every time that a >block is modified during an epoch, GT.M will write a before image of >that block. For development purposes, you can use the epoch_interval >command of mupip set -journal to be something very large, such as 3600 >(once an hour) or even 86400 (once a day). > >Note that a large journal file is nothing to be concerned about. If you >want to get rid of it, backup the database using the mupip backup >command with the -newjnlfiles=noprevlink option. Once the backup >completes, you can delete the old generation journal file, since it will >no longer be needed for recovery from a system crash. > >-- Bhaskar > >On Wed, 2004-09-08 at 14:45, "Christian Alexis Diez Ocaña" wrote: > > >>Hi, >> >> >> >>I’m running SemiViva 0.4 over GT.M. >> >>Last week my mumps.dat file was 271M, today it is 769M ! >> >>I just added a few patients and a few new persons, and I can’t figure >>out the reason for such growth. >> >>Is there a way to identify what process is making the dat file larger? >>And/Or which files (within Vista) are growing up ? >> >> >> >>Thanks, >> >>Alexis *** This electronic mail transmission contains confidential and/or privileged information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. *** NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus et peut contenir de l'information privilegiee, confidentielle et/ou dispensee de divulgation aux termes des lois applicables. Si vous avez recu ce message par erreur, ou s'il ne vous est pas destine, veuillez le mentionner immediatement a l'expediteur et effacer ce courriel. <>
Re: [Hardhats-members] DAT file keeps growing up
So, in theory, if you keep a table of user IDs and process IDs with date and time, you could trace back journal entries to a specific user on GT.M? Does anyone know if Cache's journals contain that much information? K.S. Bhaskar wrote: Alexis -- Remember that the journal file contains information on all sets and kills, as well as before images of modified blocks. [A quick read of the chapter on journaling in the Administration and Operations manual as well as Technical Bulletin 5-025 on the Mupip Set Journal command (http://sourceforge.net/docman/display_doc.php?docid=11357&group_id=11026) may be in order.] The mupip journal -extract command can be used to tell you exactly which process made what updates. My guess is that the bulk of the information is before images - since you are presumably not making updates at a fast rate, every time that a block is modified during an epoch, GT.M will write a before image of that block. For development purposes, you can use the epoch_interval command of mupip set -journal to be something very large, such as 3600 (once an hour) or even 86400 (once a day). Note that a large journal file is nothing to be concerned about. If you want to get rid of it, backup the database using the mupip backup command with the -newjnlfiles=noprevlink option. Once the backup completes, you can delete the old generation journal file, since it will no longer be needed for recovery from a system crash. -- Bhaskar On Wed, 2004-09-08 at 14:45, "Christian Alexis Diez OcaÃa" wrote: Hi, Iâm running SemiViva 0.4 over GT.M. Last week my mumps.dat file was 271M, today it is 769M ! I just added a few patients and a few new persons, and I canât figure out the reason for such growth. Is there a way to identify what process is making the dat file larger? And/Or which files (within Vista) are growing up ? Thanks, Alexis *** This electronic mail transmission contains confidential and/or privileged information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. *** NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus et peut contenir de l'information privilegiee, confidentielle et/ou dispensee de divulgation aux termes des lois applicables. Si vous avez recu ce message par erreur, ou s'il ne vous est pas destine, veuillez le mentionner immediatement a l'expediteur et effacer ce courriel. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&opclick ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members -- Greg Kreis Pioneer Data Systems, Inc. http://www.PioneerDataSys.com - VistA Training and Consulting "Genius is childhood recaptured at will." (Charles Baudelaire)
Re: [Hardhats-members] DAT file keeps growing up
Alexis -- Remember that the journal file contains information on all sets and kills, as well as before images of modified blocks. [A quick read of the chapter on journaling in the Administration and Operations manual as well as Technical Bulletin 5-025 on the Mupip Set Journal command (http://sourceforge.net/docman/display_doc.php?docid=11357&group_id=11026) may be in order.] The mupip journal -extract command can be used to tell you exactly which process made what updates. My guess is that the bulk of the information is before images - since you are presumably not making updates at a fast rate, every time that a block is modified during an epoch, GT.M will write a before image of that block. For development purposes, you can use the epoch_interval command of mupip set -journal to be something very large, such as 3600 (once an hour) or even 86400 (once a day). Note that a large journal file is nothing to be concerned about. If you want to get rid of it, backup the database using the mupip backup command with the -newjnlfiles=noprevlink option. Once the backup completes, you can delete the old generation journal file, since it will no longer be needed for recovery from a system crash. -- Bhaskar On Wed, 2004-09-08 at 14:45, "Christian Alexis Diez OcaÃa" wrote: > Hi, > > > > Iâm running SemiViva 0.4 over GT.M. > > Last week my mumps.dat file was 271M, today it is 769M ! > > I just added a few patients and a few new persons, and I canât figure > out the reason for such growth. > > Is there a way to identify what process is making the dat file larger? > And/Or which files (within Vista) are growing up ? > > > > Thanks, > > Alexis *** This electronic mail transmission contains confidential and/or privileged information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. *** NOTE: Ce courriel est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus et peut contenir de l'information privilegiee, confidentielle et/ou dispensee de divulgation aux termes des lois applicables. Si vous avez recu ce message par erreur, ou s'il ne vous est pas destine, veuillez le mentionner immediatement a l'expediteur et effacer ce courriel. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=click ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] DAT file keeps growing up
You might want to check the error trap first. That is something that could certainly grow auto-magically. -Original Message-From: Christian Alexis Diez Ocaña [mailto:[EMAIL PROTECTED]Sent: Wednesday, September 08, 2004 1:46 PMTo: [EMAIL PROTECTED]Subject: [Hardhats-members] DAT file keeps growing up Hi, I'm running SemiViva 0.4 over GT.M. Last week my mumps.dat file was 271M, today it is 769M ! I just added a few patients and a few new persons, and I can't figure out the reason for such growth. Is there a way to identify what process is making the dat file larger? And/Or which files (within Vista) are growing up ? Thanks, Alexis
