Re: How to determine Alternate ID

[Alan Altmark]

On Thursday, 12/21/2006 at 04:34 PST, Don Russell 
<[EMAIL PROTECTED]> wrote:
> IBM VM BATCH uses Diag D4 to set an Alternate ID for task IDs, so in
> some ways the task machine is "masquerading" as a different userid.

> That is, how can I determine what my ORIGINID would be if I sent a spool
> file to another ID?
> 
> This is on z/VM 4.4

Issue an APPCVM CONNECT (CMALLC) to a private resource of your own 
creation.  The alternate ID is used as the source id in the connection. Of 
course, it's way easier to send a spool file to yourself and use diag 0xBC 
to look at the originid, and then discard it.

Your ESM may have a privileged query.  CP doesn't.

Alan Altmark
z/VM Development
IBM Endicott

Re: Huge LASTING GLOBALV file for DB/2 servers

[David Boyes]

>   Thanks so much for your quick response.  I just LOVE THIS LIST 
> 
>   Happy Holidays to everyone from us here in Peoria, Illinois, USA.

Guess that means we'll play in Peoria, hmm? Broadway, here we
come8-)

-- db

How to determine Alternate ID

[Don Russell]

IBM VM BATCH uses Diag D4 to set an Alternate ID for task IDs, so in 
some ways the task machine is "masquerading" as a different userid.


The BATCH SUBMIT command accepts an ALTID option which is used by that 
Diag D4, but the job owner is still the actual job submitter.


The DGROOLY EXEC runs on the task ID, and one of the parameters passed 
is the job owner. But I want to determine if there is an ALTID in effect.


Short of doing something gross like sending myself a spool file and 
checking the origin id, either of the spool file or looking at the IMSG, 
how can I determine the Alternate User ID of the ID I'm actually running on?


That is, how can I determine what my ORIGINID would be if I sent a spool 
file to another ID?


This is on z/VM 4.4

Thanks,
Don Russell

Re: Huge LASTING GLOBALV file for DB/2 servers

[Mike Walter]

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" 
12/21/2006 03:27 PM
Please respond to
"The IBM z/VM Operating System" 



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"  
12/21/2006 01:45 PM 

ase respond to
"The IBM z/VM Operating System" 



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. 

Re: Huge LASTING GLOBALV file for DB/2 servers

[Ed Zell]

> Do you by any chance run CA's VM:DB/Suite or IBM's Control
> Center with your DB2 databases?
>
> JR

Hi JR,

  No, everything is "roll yer own" here.  We have been running
  since the late 1980's (SQL/DS 2.1 if I remember correctly).  At
  that time there were no cool tools like the ones you mentioned.

  I wrote quite a few utilities for the VSE side and a menu system
  for the VM side to make it easy for Operations to do "SQL stuff".
  They weren't very elegant, but they did their job.  I am proud to
  say most of them still run today with little or no changes as the
  new releases come along.  The code is pretty scary to look at, but
  hey, I was wet behind the ears back then  :)

Ed Zell
Illinois Mutual Life
(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.

Re: Huge LASTING GLOBALV file for DB/2 servers

[Imler, Steven J]

Do you by any chance run CA's VM:DB/Suite or IBM's Control Center with your DB2 
databases?

JR

JR (Steven) Imler
CA
Senior Software Engineer
Tel:  +1 703 708 3479
Fax:  +1 703 708 3267
[EMAIL PROTECTED]
 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed 
Zell
Sent: Thursday, December 21, 2006 02: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.

Re: Huge LASTING GLOBALV file for DB/2 servers

[Schuh, Richard]

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"  

12/21/2006 01:45 PM 
Please respond to
"The IBM z/VM Operating System" 



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

Re: Litotes?

[Schuh, Richard]

Or not complex (or easy or ...) 

That should have read "The opposite of trivial ..." - the "non-" did not
belong in the sentence.


Any time the proof is left for the reader, it will be non-trivial. The
professors or authors work all of the trivial ones for you.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of David Boyes
Sent: Thursday, December 21, 2006 12:08 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Litotes?

> Schuh, Richard wrote:
> > The opposite of non-trivial would be complex.
> Really?

No, it would be trivial. 

For completeness sake, the proof is left as an exercise for the reader.
Unfortunately, the margin of this email is too small to contain it. 

-- db

Re: Huge LASTING GLOBALV file for DB/2 servers

[Stracka, James (GTI)]

See line number 173 of SYSPROF EXEC:  

'GLOBALV INIT'

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
Sent: Thursday, December 21, 2006 3: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"  

12/21/2006 01:45 PM 
Please respond to
"The IBM z/VM Operating System" 



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 addre

Re: Huge LASTING GLOBALV file for DB/2 servers

[Ed Zell]

> Unless: the server would have its A-disk R/O when GLOBALV INIT is
done,
> or, the A-disk is changed after the GLOBALV INIT (I obtained a fix
> precisely for this problem in the the DGTSRVxx servers of DFSMS). 
>
> Kris,
> IBM Belgium, VM customer support

Kris,

  That's it.  The 191 disk for my DB/2 servers is a R/O disk that
  contains common EXEC's and startup parm files that are shared by
  all my servers.  One of the first things the PROFILE EXEC does is:

   'REL A' 
   'ACC 199 A'/* read/write work A disk for DB/2  */
   'ACC 191 B/A'

  but by then SYSPROF / GLOBALV INIT has already run and didn't do
  anything because of the read only disk.

  After looking at LASTING GLOBALV in more detail, there are 2600+
  copies of the variables  (18 lines each so 47,000+ total lines).
  That means this has been going on FOR YEARS !!

  I guess I either:

  1)  Remove  SQLINIT  from the startup EXEC or
  2)  Do a  GLOBALV INIT  after getting the 199 as a read/write A disk

  Thanks so much for your quick response.  I just LOVE THIS LIST 

  Happy Holidays to everyone from us here in Peoria, Illinois, USA.


Ed Zell
(309) 674-8255 x-107
[EMAIL PROTECTED]
.


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.

Re: Huge LASTING GLOBALV file for DB/2 servers

[Mike Walter]

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" 
12/21/2006 01:45 PM
Please respond to
"The IBM z/VM Operating System" 



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.

Re: Litotes?

[David Boyes]

> Schuh, Richard wrote:
> > The opposite of non-trivial would be complex.
> Really?

No, it would be trivial. 

For completeness sake, the proof is left as an exercise for the reader.
Unfortunately, the margin of this email is too small to contain it. 

-- db

Re: Huge LASTING GLOBALV file for DB/2 servers

[Kris Buelens]

I am surprized. but indeed, each time a GLOBALV SETP or PUTP is issued, it 
is written in LASTING GLOBALV, even if the value is the same as before. So 
yes indeed a careless use of SETP/PUTP can cause huge LASTING GLOBALV 
files.

But, GLOBALV INIT is supposed to cleanup the file, removing all but the 
last settting for each variable.  And as far as I know, a GLOBALV INIT is 
done by the SYSPROF EXEC, but also the very first time GLOBALV is used. 
And you say your server is restarted every day, so cleanup should be done.

Unless: the server would have its A-disk R/O when GLOBALV INIT is done, 
or, the A-disk is changed after the GLOBALV INIT (I obtained a fix 
precisely for this problem in the the DGTSRVxx servers of DFSMS).

Beware: don't place GLOBALV INIT commands everywhere: it not only 
reads/cleans the LASTING GLOBALV A file, but also wipes out all GLOBALV 
variables that are saved in storage only.

Kris,
IBM Belgium, VM customer support


The IBM z/VM Operating System  wrote on 
2006-12-21 20:01:34:

> 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.

Re: Huge LASTING GLOBALV file for DB/2 servers

[Stracka, James (GTI)]

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/

RES: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

[Carlos Bodra]

Remember that a lot of assgns are done in STDLABEL, STDLABUP and so on that
mades references to DOSRES and SYSWK1. Mainly are POWER and ICCF.

___
Carlos Bodra
zSeries System Programmer
São Paulo - SP - Brazil
 
-Mensagem original-
De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Em nome
de Rich Smrcina
Enviada em: quinta-feira, 21 de dezembro de 2006 00:08
Para: IBMVM@LISTSERV.UARK.EDU
Assunto: Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

Sure you can, but you may not like the results.  Why do you want to 
change them?

Daniel Allen wrote:
> Can you change DOSRES & SYSWK1 labels using ICKDSF under z/VM ? 
> 

-- 
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com

Catch the WAVV!  http://www.wavv.org
WAVV 2007 - Green Bay, WI - May 18-22, 2007

Re: Huge LASTING GLOBALV file for DB/2 servers

[Graves Nora E]

We've been running DB/2 for VM since Release 6.1.  We're currently on DB/2 7.3 
under z/VM 4.4.  Our current LASTING GLOBALV is 137 lines long for SQLPROD, and 
it doesn't have any duplicates in it. 

We do not have the SQLINIT step in our PROFILE EXEC for any of the databases.  
We also do not log the databases off very frequently.  However, they do get 
logged off enough that at least some duplicate entries should have occurred if 
that were the cause.

On my personal 191 disk, I don't have any duplicate entries, either.  I issue 
multiple SQLINIT commands each day, switching between various databases.  
However, I do not issue the command through my PROFILE EXEC.

I'm not a systems programmer, so we've about reached the limits of my 
knowledge. :-)


Nora Graves
[EMAIL PROTECTED]
Main IRS, Room 6513
(202) 622-6735 

-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.

Re: Litotes?

[Ray Mansell]

Schuh, Richard wrote:
The opposite of non-trivial would be complex. 

Really?

Re: Litotes?

[Schuh, Richard]

Be careful about what you read in Wikipedia. From what I have read, its
quality assurance is sometimes questionable. 

The opposite of non-trivial would be complex. In this case, saying
something is non-trivial is an understated way to stress its complexity;
hence, it is a litotes.

The Meriam Webster contains a definition for the word "nontrivial". As I
recall from 45 years ago, the word was hyphenated in math books and
papers. Since then, the hyphen appears to have been dropped, at least by
MWO. 

On the other side of the pond, the OED does not try to give a definition
for every non-banana. Instead, it defines "non" as a prefix that is used
similarly to "un", with  "un" being  the stronger of the two. It says,
"For example, unnatural implies that something is not natural in a bad
way, whereas non-natural is neutral." It seems to always include the
hyphen when using the non prefix.

As Shaw said, "England and America are two countries separated by a
common language." 

  

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Ackerman
Sent: Thursday, December 21, 2006 10:14 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Litotes?

OK, I give up. Why is "Warning: writing such code yourself is
non-trivial= !" a litotes?

I looked up "litotes" in Wikipedia at
. I can see how "not non-
trivial" would be a litotes, but why is "non-trivial"?

On Thu, 30 Nov 2006 20:51:07 -0500, Phil Smith III <[EMAIL PROTECTED]>
wrot=
e:

>"Wakser, David" <[EMAIL PROTECTED]> wrote:
>>I believe you meant: NOT trivial - not non-trivial!
>
>Um, no...if I'd meant "NOT trivial" I would have written that.  
>"Non-tri=
vial" is a litotes, and as such
makes the case more strongly.
>
>...phsiii
>=
==

===

Huge LASTING GLOBALV file for DB/2 servers

[Ed Zell]

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.

Re: Questions about encrypted telnet

[Alan Ackerman]

We are not using it yet, but we have a project to encrypt all TN3270 traf
fic (and eventually other 
traffic) to mainframes. As usual here, we are doing z/OS first, using wha
tever is built in to z/OS 
these days. (Target is 4Q2007.) z/VM would come next, so we have been tes
ting the VM SSL server 
in each release. (The 5.2.0 was the first one to support Red Hat, which w
e are required to use.)

I would be very interested in hearing other's experiences with the SSL se
rver, positive or negative. 
Unless our z/OS CS (that's the name of the mainframe network group here!)
 people decide to go 
with an outside appliance, it would be hard for us to use one. 

If you have problems with the SSL server, PLEASE report them to IBM. We n
eed for that server to 
work. 

As always, I would prefer people to answer questions posed here on this l
ist, and not offline, so 
that the rest of us can learn from the answers.

On Thu, 21 Dec 2006 10:09:57 -0500, Mrohs, Ray <[EMAIL PROTECTED]> wrot
e:

>How many sites are using SSL for end-to-end encryption of TN3270
>sessions? I am looking at SSLSERV as well as external appliances such as

>Visara's. We will provide this for about 800 concurrent CMS users at
>peak times.
>
>My main concerns are:
>1. reliability and proven load-handling capability
>2. user impact, so we want to minimize changes at the desktop
>3. system overhead  
>4. compatibility with other initiatives such as 2-factor authentication 

>
>I am interested in hearing about any real-life test or production
>implementations. If its too sensitive to discuss in the open, please
>email or call me. Thanks.
>
>Ray Mrohs
>U.S. Department of Justice
>202-307-6896
> 
>
=
==
=

Re: z/VM 5.2 ESAMON vs IBM PTK regarding SYTSHS_RSASHARE monitor record

[Gregg Reed]

I concur and indeed I left info w/support how I believed a CPC with
dedicated and shared resources should be displayed. my rational, so be it.
I don't think its universally accepted and I'm not about making it so.  I
coded my own macro to represent what I think PR/SM and Redbooks describe,
across CPCs  w/ active and de-act'd LPs and my TPF fellows are
beginning to see it too.  I agree, 100%, CHOOSE, track, measure or
sacrifice chickens when the moon is full no, i  don't think so. There
is no such nonsense on the autobahn, on the other hand, i;ve never driven
there but I'd like to,  I'd like to measure it...
Gregg
"No plan survives execution"


   
 Alan Altmark  
 <[EMAIL PROTECTED] 
 ibm.com>   To 
 Sent by: The IBM  IBMVM@LISTSERV.UARK.EDU 
 z/VM Operating cc 
 System
 <[EMAIL PROTECTED] Subject 
 ARK.EDU>  Re: z/VM 5.2 ESAMON vs IBM PTK  
   regarding SYTSHS_RSASHARE monitor   
   record  
 12/21/2006 09:55  
 AM
   
   
 Please respond to 
   The IBM z/VM
 Operating System  
 <[EMAIL PROTECTED] 
 ARK.EDU>  
   
   




On Thursday, 12/21/2006 at 06:35 EST, Gregg Reed
<[EMAIL PROTECTED]> wrote:
> I'd second that. The PTK is great at what it does and while I was doing
an
> extensive comparison a year ago, it's where I'd point operators and RTM
> familiar folk to, it is a huge upgrade to RTM, but it takes an FMR/not
> working as designed to do anything about.

If you believe or even suspect that Performance Toolkit is giving you
useless or incorrect information, please contact the Support Center. While
measuring tape speed in "furlongs per fortnight" might be accurate, it's
not exactly useful in most situations.  It may be there's a good reason
for changing the metric.  As my world-famous colleague says, "It depends."

But as Barton said, make your decision about performance products (e.g.
ESAMON, OMEGAMON, PTK, homegrown) based on your company's goals and needs,
not on the values of any particular field on any particular report.

But, whatever you choose, CHOOSE!  If all you want to do is kick the
tires, a speedometer, tachometer, odometer, fuel gauge, oil pressure
gauge, and thermometer aren't really important.  However, if you're going
to take her out on the Autobahn and redline it, you gotta have 'em.
(Otherwise how would you know you're redlining it?  Remember, the CPU
doesn't make noise as you rev it up.)

Alan Altmark
z/VM Development
IBM Endicottt
ere
a
d

Litotes?

[Alan Ackerman]

OK, I give up. Why is "Warning: writing such code yourself is non-trivial
!" a litotes?

I looked up "litotes" in Wikipedia at . I can see how "not non-
trivial" would be a litotes, but why is "non-trivial"?

On Thu, 30 Nov 2006 20:51:07 -0500, Phil Smith III <[EMAIL PROTECTED]> wrot
e:

>"Wakser, David" <[EMAIL PROTECTED]> wrote:
>>I believe you meant: NOT trivial - not non-trivial!
>
>Um, no...if I'd meant "NOT trivial" I would have written that.  "Non-tri
vial" is a litotes, and as such 
makes the case more strongly.
>
>...phsiii
>
=

===

Re: IPL Help for old 9672 with VM/ESA 2.4

[Hans Rempel]

Hi Larry. It is possible that the 2.4 vm system ddr does not support it. It 
does work on z/VM 3.1 and later DDR. 

For testing in your VM userid you must use LOADPARM and not PARM. I kept my 
tape volid so I had to IPL twice to get past the volid. The rest of the tape 
should then hold the DDR program followed by ddr data. No tape mark in between 
the DDR program and data. 

Hans 

Although we have IPLed our VM/ESA 2.4 on our 9672 using the HMC, I also need to 
know how to run a DDR restore.

With a DDR tape that I had built with DDR at the front, followed by a full-pack 
dump after it, I could not get it to work under VM.  With a tape at 181 and the 
disk pack attached at 521, both I 181 PARM AUTO0521 and I 181 LOADPARM AUTO0521 
came back to my console asking for input.
Perhaps it would work if run on the bare iron.

Or, perhaps, I did not understand Hans Rempel when he wrote:

  You will need to IPL the standalone DDR tape and add the following 8
  character value AUTODDDA to the PARM field. DDDA is the address of the disk
  drive to receive the output from the DDR restore.

  This IPL provides no messages and will load the DDR program and restore tape
  data to disk drive DDDA. Upon successful completion a disable PSW state will
  be loaded "PSW 000A ".
 





Sent via the WebMail system at hmrconsultants.com


 
   

Re: Questions about encrypted telnet

[Fran Hensler]

Slippery Rock University is using SSL TN3270.  We use the Hummingbird
HostExplorer emulator on the desktop and an SSL appliance called iCYA
(Internet Control Your Access) from Illustro:  http://www.illustro.com/icya.htm
 
The iCYA offloads the encryption from the mainframe.  Secure data
coming into the iCYA on port 992 is sent to the mainframe in clear
text on port 23 and when the response is received by the iCYA it is
encrypted and sent out on port 992.
 
We did not do a mass conversion of desktops to SSL TN3270.  Users who
are not converted yet come into the iCYA on port 23.
 
So the iCYA handles both the SSL users and the unsecured users.
Eventually we will close port 23 and then all users will be required
to use the SSL version of HostExplorer.
 
/Fran Hensler at Slippery Rock University of Pennsylvania USA for 43 years
 [EMAIL PROTECTED] +1.724.738.2153
"Yes, Virginia, there is a Slippery Rock"
 
On Thu, 21 Dec 2006 10:09:57 -0500 Mrohs, Ray said:
>How many sites are using SSL for end-to-end encryption of TN3270
>sessions? I am looking at SSLSERV as well as external appliances such as
>Visara's. We will provide this for about 800 concurrent CMS users at
>peak times.
>
>My main concerns are:
>1. reliability and proven load-handling capability
>2. user impact, so we want to minimize changes at the desktop
>3. system overhead
>4. compatibility with other initiatives such as 2-factor authentication
>
>I am interested in hearing about any real-life test or production
>implementations. If its too sensitive to discuss in the open, please
>email or call me. Thanks.
>
>Ray Mrohs
>U.S. Department of Justice
>202-307-6896
>

Re: z/VM 5.2 ESAMON vs IBM PTK regarding SYTSHS_RSASHARE monitor record

[David Boyes]

> However, if you're going
> to take her out on the Autobahn and redline it, you gotta have 'em.
> (Otherwise how would you know you're redlining it?  Remember, the CPU
> doesn't make noise as you rev it up.)

Requirement! Requirement!

(Find some of those Sequent guys you bought up. *They* do blinkenlights
right. )

Re: Questions about encrypted telnet

[Alan Altmark]

On Thursday, 12/21/2006 at 10:09 EST, "Mrohs, Ray" <[EMAIL PROTECTED]> 
wrote:
> How many sites are using SSL for end-to-end encryption of TN3270
> sessions? I am looking at SSLSERV as well as external appliances such as
> Visara's. We will provide this for about 800 concurrent CMS users at
> peak times.
> 
> My main concerns are:
> 1. reliability and proven load-handling capability
> 2. user impact, so we want to minimize changes at the desktop
> 3. system overhead
> 4. compatibility with other initiatives such as 2-factor authentication
> 
> I am interested in hearing about any real-life test or production
> implementations. If its too sensitive to discuss in the open, please
> email or call me. Thanks.

If you do respond to Ray privately and want me to be aware of your 
issues/concerns, please e-mail or call me as well.  If you're having 
*problems* with SSLSERV, please include the PMR number.  (A problem 
without a PMR isn't really a problem, now is it?)

Alan Altmark
z/VM Development
IBM Endicott

Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

[August Carideo]

If your under vm why change then, just have them come up off line
or do not have then accessed in that userid
are they dedicated or mini disk
anyway you can change them with ditto also,  DID command



   
 Daniel Allen  
 <[EMAIL PROTECTED] 
 m> To 
 Sent by: The IBM  IBMVM@LISTSERV.UARK.EDU 
 z/VM Operating cc 
 System
 <[EMAIL PROTECTED] Subject 
 ARK.EDU>  Re: Changing DOSRES & SYSWK1 labels 
   using ICKDSF under z/VM ?   
   
 12/21/2006 10:22  
 AM
   
   
 Please respond to 
   The IBM z/VM
 Operating System  
 <[EMAIL PROTECTED] 
 ARK.EDU>  
   
   




I am installing a new version of z/VSE and we want to keep the volumes
around.



-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Rich Smrcina
Sent: Wednesday, December 20, 2006 6:08 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

Sure you can, but you may not like the results.  Why do you want to
change them?

Daniel Allen wrote:
> Can you change DOSRES & SYSWK1 labels using ICKDSF under z/VM ?
>

--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com

Catch the WAVV!  http://www.wavv.org
WAVV 2007 - Green Bay, WI - May 18-22, 2007


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

[Daniel Allen]

I am installing a new version of z/VSE and we want to keep the volumes
around. 



-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Rich Smrcina
Sent: Wednesday, December 20, 2006 6:08 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

Sure you can, but you may not like the results.  Why do you want to
change them?

Daniel Allen wrote:
> Can you change DOSRES & SYSWK1 labels using ICKDSF under z/VM ? 
> 

--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com

Catch the WAVV!  http://www.wavv.org
WAVV 2007 - Green Bay, WI - May 18-22, 2007


**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply e-mail and destroy all copies of the original message.

Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

[Daniel Allen]

Thanks for the advice, Tom. 



-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Tom Cluster
Sent: Wednesday, December 20, 2006 7:16 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

I have always used DITTO in CMS to do this.

ICKDSF CPVOL has a clip function - I'm not sure if you can do it outside
of CPVOL.  Maybe you could use CPVOL's LABEL function even though it's
not a VM volume, but I've never tried it.

If you have DITTO in CMS, use it.  It works nicely.

  - Tom.

At 06:03 PM 12/20/2006, you wrote:
>Can you change DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

Tom Cluster
County of Sonoma
Santa Rosa, CA
(707) 565-3384 (Tuesdays and Wednesdays only) 

**
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. Any 
unauthorized review, use, disclosure or distribution is prohibited. If you are 
not the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message.

Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM

[Stephen Frazier]

Yes, but your VSE guest might not like it. :)
If you know what you are doing (on the VSE side) and have several VSE guests then there are some 
benefits from having each guest use different labels fort their disks.


[EMAIL PROTECTED] wrote:

Can you change DOSRES & SYSWK1 labels using ICKDSF under z/VM ?
 
 



--
Stephen Frazier
Information Technology Unit
Oklahoma Department of Corrections
3400 Martin Luther King
Oklahoma City, Ok, 73111-4298
Tel.: (405) 425-2549
Fax: (405) 425-2554
Pager: (405) 690-1828
email:  stevef%doc.state.ok.us

Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?

[Rich Smrcina]

If you DEDICATE the volumes to the VSE machines or use the MDISK DEVNO
option, you won't have to worry about duplicate volume labels.

Rich Smrcina
VM Assist, Inc.
Main: (866)569-7378
Cell: (414)491-6001

Catch the WAVV!  http://www.wavv.org
WAVV 2007 - Green Bay, WI

- Original Message -
From: Daniel Allen <[EMAIL PROTECTED]>
Date: Thursday, December 21, 2006 9:24 am
Subject: Re: Changing DOSRES & SYSWK1 labels using ICKDSF under z/VM ?
To: IBMVM@LISTSERV.UARK.EDU

> I am installing a new version of z/VSE and we want to keep the volumes
> around. 
> 
> 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Rich Smrcina
> Sent: Wednesday, December 20, 2006 6:08 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Changing DOSRES & SYSWK1 labels using ICKDSF under 
> z/VM ?
> 
> Sure you can, but you may not like the results.  Why do you want to
> change them?
> 
> Daniel Allen wrote:
> > Can you change DOSRES & SYSWK1 labels using ICKDSF under z/VM ? 
> > 
> 
> --
> Rich Smrcina
> VM Assist, Inc.
> Phone: 414-491-6001
> Ans Service:  360-715-2467
> rich.smrcina at vmassist.com
> 
> Catch the WAVV!  http://www.wavv.org
> WAVV 2007 - Green Bay, WI - May 18-22, 2007
> 
> 
> **
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you are not the intended recipient, 
> please contact the sender by reply e-mail and destroy all copies of 
> the original message.
> 

Questions about encrypted telnet

[Mrohs, Ray]

How many sites are using SSL for end-to-end encryption of TN3270
sessions? I am looking at SSLSERV as well as external appliances such as
Visara's. We will provide this for about 800 concurrent CMS users at
peak times.

My main concerns are:
1. reliability and proven load-handling capability
2. user impact, so we want to minimize changes at the desktop
3. system overhead  
4. compatibility with other initiatives such as 2-factor authentication 

I am interested in hearing about any real-life test or production
implementations. If its too sensitive to discuss in the open, please
email or call me. Thanks.

Ray Mrohs
U.S. Department of Justice
202-307-6896
 

Re: z/VM 5.2 ESAMON vs IBM PTK regarding SYTSHS_RSASHARE monitor record

[Alan Altmark]

On Thursday, 12/21/2006 at 06:35 EST, Gregg Reed 
<[EMAIL PROTECTED]> wrote:
> I'd second that. The PTK is great at what it does and while I was doing 
an
> extensive comparison a year ago, it's where I'd point operators and RTM
> familiar folk to, it is a huge upgrade to RTM, but it takes an FMR/not
> working as designed to do anything about.

If you believe or even suspect that Performance Toolkit is giving you 
useless or incorrect information, please contact the Support Center. While 
measuring tape speed in "furlongs per fortnight" might be accurate, it's 
not exactly useful in most situations.  It may be there's a good reason 
for changing the metric.  As my world-famous colleague says, "It depends."

But as Barton said, make your decision about performance products (e.g. 
ESAMON, OMEGAMON, PTK, homegrown) based on your company's goals and needs, 
not on the values of any particular field on any particular report.

But, whatever you choose, CHOOSE!  If all you want to do is kick the 
tires, a speedometer, tachometer, odometer, fuel gauge, oil pressure 
gauge, and thermometer aren't really important.  However, if you're going 
to take her out on the Autobahn and redline it, you gotta have 'em. 
(Otherwise how would you know you're redlining it?  Remember, the CPU 
doesn't make noise as you rev it up.)

Alan Altmark
z/VM Development
IBM Endicott

Re: IPL Help for old 9672 with VM/ESA 2.4

[Pohlen (Mailinglist)]

I don't know the method with AUTODDDA. Therefore I will tell you how I do it
if necessary (hopefully not too often).

The standalone method if you have no VM working:

1. Mount the tape containing the DDR IPL on a drive
2. on HMC IPL on the tape drive with LOADPARM  where  is the 4-digit
device address of the 3270 console terminal where you want to enter the
restore parms. This terminal must be switched on before starting the ipl.
3. After IPL there should appear a message similar to this
z/VM DASD DUMP/RESTORE PROGRAM
ENTER CARD READER ADDRESS OR CONTROL STATEMENTS
ENTER:
4. now enter the following on the screen
SYSPRINT CONS
If there is MORE THAN ONE DDR DUMP on the tape:   IN tapeaddress
TAPE (LEAVE
else
IN tapeaddress TAPE
OUT dasdaddr DASD
RESTORE ALL

After the restore you can enter a new OUT dasdaddr DASD and RESTORE ALL.
Notice: Do not enter a blank command line to the DDR program because it
thinks then it's finished and you have to reipl from the standalone tape.

A DDR standalone tape can be created as follows from a CMS user with an
attached tape drive as 181:

FILEDEF INMOVE DISK IPL DDRXA S
FILEDEF OUTMOVE TAP1 (BLOCK 80
MOVEFILE

I know there is also a UTILTAPE command, but I find this more handy. I can
put these commands into an exec and put a DDRIPL automatically in front of a
DDR dump.

Please don't understand me wrong. I don't say that Hans' method does not
work but I only know this method for restoring a standalone DDR dump.

Hope this helps

Franz Josef

- Original Message - 
From: "Larry Israel" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, December 21, 2006 7:29 AM
Subject: Re: [IBMVM] IPL Help for old 9672 with VM/ESA 2.4


> Although we have IPLed our VM/ESA 2.4 on our 9672 using the HMC, I also
> need to know how to run a DDR restore.
>
> With a DDR tape that I had built with DDR at the front, followed by a
> full-pack dump after it, I could not get it to work under VM.  With a
> tape at 181 and the disk pack attached at 521, both I 181 PARM AUTO0521
> and I 181 LOADPARM AUTO0521 came back to my console asking for input.
> Perhaps it would work if run on the bare iron.
>
> Or, perhaps, I did not understand Hans Rempel when he wrote:
>
>   You will need to IPL the standalone DDR tape and add the following 8
>   character value AUTODDDA to the PARM field. DDDA is the address of the
disk
>   drive to receive the output from the DDR restore.
>
>   This IPL provides no messages and will load the DDR program and restore
tape
>   data to disk drive DDDA. Upon successful completion a disable PSW state
will
>   be loaded "PSW 000A ".

Re: z/VM 5.2 ESAMON vs IBM PTK regarding SYTSHS_RSASHARE monitor record

[Gregg Reed]

I'd second that. The PTK is great at what it does and while I was doing an
extensive comparison a year ago, it's where I'd point operators and RTM
familiar folk to, it is a huge upgrade to RTM, but it takes an FMR/not
working as designed to do anything about.  I would, rather tend to believe
ESAMON and when an issue arises, I can explore raw data/change the
panel/report to meet my expectations, ask and receive sound advice about my
perceptions.  All that's bits and bytes, and we are all about the
details... however, if the specific number is important to you, track it,
correlate it to, report it to management as an indicator of.. . as long as
the underlining interpretation remains the same, it's a metric; if it adds,
subtracts, multiplies, divides, it's OK otherwise, move on.
Gregg
"No plan survives execution"


   
 Dave Jones
 <[EMAIL PROTECTED] 
 ARE.COM>   To 
 Sent by: The IBM  IBMVM@LISTSERV.UARK.EDU 
 z/VM Operating cc 
 System
 <[EMAIL PROTECTED] Subject 
 ARK.EDU>  Re: z/VM 5.2 ESAMON vs IBM PTK  
   regarding SYTSHS_RSASHARE monitor   
   record  
 12/20/2006 07:06  
 PM
   
   
 Please respond to 
   The IBM z/VM
 Operating System  
 <[EMAIL PROTECTED] 
 ARK.EDU>  
   
   




Craig,

I believe, based on some evidence I've seen at some client sites, that th
e
ESAMON numbers are correct while the PTK ones are not. I believe the caus
e
of ths is the fact that some of the numbers reported by the underlying CP

MONITOR data stream are not quite what they should be, and the folks at
Velocity have made an attempt to correct that problem.

Hope this helps.

DJ

On Wed, 20 Dec 2006 14:40:33 -0800, Craig Sutton <[EMAIL PROTECTED]>
 wrote:

>Hello,
>I've been comparing the Velocity ESAMON and IBM Performance Toolkit
>products on z/VM 5.2, and have noticed that they disagree on the value o
f
>the SYTSHS_RSASHARE monitor record. According to the IBM doc, the
>SYTSHS_RSASHARE monitor record represents "Cardinal count of resident sh
ared
>frames". When I extract the MRSYTSHS monitor record from ESAMON, I get:
>
>SYTSHS_RSACTSHR=6300.0
>SYTSHS_RSASHARE=9400.0
>
>When I extract the MRSYTSHS monitor record through PTK, I get:
>
>SYTSHS_RSACTSHR=6300
>SYTSHS_RSASHARE=2409384
>
>which corresponds to the 'Shared storage' value reported in PTK STORAGE.

>Does anyone know which one's correct?
>
>Thanks, Craig
>