Thanks, Richard.  Been on vacation, logging onto Notes from home, and was 
simply too lazy to logon to MAINT and check the z/VM 510 SYSPROF EXEC (the 
previous VM we were running just barely over a year ago was VM/ESA 240). I 
did not check the SYSPROF EXEC when we upgraded from VM/ESA 240, but it 
looks like we can now yank a line from our PROFCMS EXEC!  ;-) 

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.






"Schuh, Richard" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
12/21/2006 03:27 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Huge LASTING GLOBALV file for DB/2 servers






Mike,
 
Your memory is good; your recent memory (or perhaps recent knowledge) is 
not. We used to have a GLOBALV INIT in our routine that acquires our Tools 
disk. I took it out some time ago when I was pleasantly surprised to see 
that IBM had fixed that flaw in SYSPROF.

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On 
Behalf Of Mike Walter
Sent: Thursday, December 21, 2006 12:23 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Huge LASTING GLOBALV file for DB/2 servers


Last I knew, "SYSPROF EXEC", which is by default executed during an IPL of 
CMS, does **not** issue a GLOBALV INIT.  That came as a surprise to me in 
the mid-1980's when a developer reported that their LASTING GLOBALV and 
even SESSION GLOBALVs were not being cleared. 

I solved that here by installing a local "PROFCMS EXEC", which is called 
from all our supported (i.e.: remove it an you are unsupported here) 
user's PROFILE EXECs.  That keep most of our local requirements out of 
SYSPROF EXEC, where changes at release boundaries have sometimes proved to 
be challenging. 

Mike Walter 
Hewitt Associates 
Any opinions expressed herein are mine alone and do not necessarily 
represent the opinions or policies of Hewitt Associates.

"Stracka, James (GTI)" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 
12/21/2006 01:45 PM 

ase respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU 
cc

Subject
Re: Huge LASTING GLOBALV file for DB/2 servers








Ed,

LASTING GLOBALV is normally cleared of duplicate entries at IPL CMS time. 
For them not to be cleared, could there be undisplayed characters making 
them unique?  An Explicit GLOBALV INIT should also clear the duplicates. 
Other than that, the duplicates could be being created by the SQL SVM 
itself in some sort of loop.

Jim

-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On 
Behalf Of Ed Zell
Sent: Thursday, December 21, 2006 2:02 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Huge LASTING GLOBALV file for DB/2 servers


We are running DB/2 for VM 7.4 on z/VM 4.4 at service level 0501.

Today I noticed that the LASTING GLOBALV file on all three of my servers 
is HUGE.  (SQLPROD's is 47,000+ lines and 276 blocks)  It is full of the 
same settings over and over again.  For example:

SQL/DS  "DBNAME"SQLPROD
SQL/DS  "RELEASE;7.4.0 
SQL/DS  "WORKUNIT"YES 
SQL/DS  "QRYBLKSIZE"8 
SQL/DS  "PROTOCOL"AUTO 


In the PROFILE EXEC of the machine, we do 

  SQLINIT DBNAME(SQLPROD) PROTOCOL(AUTO)

which I understand will set up these variable in LASTING GLOBALV. This 
particular virtual machine is shut down each night before 
2nd shift and logged off and then back on so the PROFILE and SQLINIT
do get executed at least once a day. 

In looking at the LASTING GLOBALV file, there are many lines with

 SQL/DS  "RELEASE;7.1.0  and   SQL/DS  "RELEASE;7.4.0 

so that tells me this has been going on a long time and I am just now 
noticing it.  We did convert from 7.1 to 7.4 in October of 2006 but it 
appears to have been growing like this since we installed z/VM 4.4 back in 
October of 2005 (although I can't be certain).

Has anyone else seen something similar to this by chance?  I am 
wondering if this is related to SQLINIT and is a DB/2 problem or if it is 
a problem with  GLOBALV ... SETP.

Any thoughts would be appreciated.  Thanks.

Ed Zell
Illinois Mutual Life Insurance
(309) 674-8255 x-107
.


CONFIDENTIAL NOTICE:  This communication, including any attachments, is 
intended only for the use of the individual or entity to which it is 
addressed and contains information which may be confidential.  If you are 
not the intended recipient, any distribution or copying of this 
communication is strictly prohibited.  If you have received this 
communication in error, notify the sender immediately, delete the 
communication and destroy all copies. Thank you for your compliance.
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the 
sender, delete it and do not read, act upon, print, disclose, copy, retain 
or redistribute it. Click here for important additional terms relating to 
this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------


The information contained in this e-mail and any accompanying documents 
may contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if 
this message has been addressed to you in error, please immediately alert 
the sender by reply e-mail and then delete this message, including any 
attachments. Any dissemination, distribution or other use of the contents 
of this message by anyone other than the intended recipient is strictly 
prohibited. 

 
The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient 
is strictly prohibited.


Reply via email to