<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Monitoring program usage</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/monitoring-program-usage/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/monitoring-program-usage/</link>
	<description></description>
	<lastBuildDate>Wed, 19 Jun 2013 19:19:38 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: waltz400</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/monitoring-program-usage/#comment-45640</link>
		<dc:creator>waltz400</dc:creator>
		<pubDate>Tue, 07 Mar 2006 12:52:17 +0000</pubDate>
		<guid isPermaLink="false">#comment-45640</guid>
		<description><![CDATA[Is your major problem not so much as who is using the command as much as who CAN use the command. The two commands you list are limited to programmers and QSECOFR on our system. 

All users arrive on our iSeries through defined menus and their user profiles have LMTCPB(*YES) so even if they can get to a command line all they can use is the DSPJOB and SIGNOFF commands. 

As far as finding out who might be using the commands, UPDDTA creates a temporary program named QDZTD00001 in QTEMP. If you have a file journalled this will show up as the program of record on any DB changes to the file. 

For STRSQL it is not so straight forward. The program it logs as the update program is the last program in the job stack. For instance a user has a startup program of INITPGM and executes an STRSQL from a command line after signing on. When they update a record the journal shows the update program as INITPGM. As long as you recognize this program as other than a normal application program that is doing legitimate updates then this might suffice.]]></description>
		<content:encoded><![CDATA[<p>Is your major problem not so much as who is using the command as much as who CAN use the command. The two commands you list are limited to programmers and QSECOFR on our system. </p>
<p>All users arrive on our iSeries through defined menus and their user profiles have LMTCPB(*YES) so even if they can get to a command line all they can use is the DSPJOB and SIGNOFF commands. </p>
<p>As far as finding out who might be using the commands, UPDDTA creates a temporary program named QDZTD00001 in QTEMP. If you have a file journalled this will show up as the program of record on any DB changes to the file. </p>
<p>For STRSQL it is not so straight forward. The program it logs as the update program is the last program in the job stack. For instance a user has a startup program of INITPGM and executes an STRSQL from a command line after signing on. When they update a record the journal shows the update program as INITPGM. As long as you recognize this program as other than a normal application program that is doing legitimate updates then this might suffice.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 6/9 queries in 0.012 seconds using memcached
Object Caching 265/268 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-06-19 21:52:24 -->