Re: Performance Toolkit AND Monwrite???

[Alan Ackerman]

We were recently asked to collect raw monitor data for IBM, because they 

saw things in one of our z/VM 5.2.0 dumps that surprised them. It took ou
r 
current performance group a week to correctly collect the data. (I'm not 

in the performance group any more!) I think it is wise to know how to do 

this, and test it once in a while. As someone else pointed out, taking a 

sample before and after a big change could be really valuable if you have
 
a performance problem. Even for an abend, IBM may ask you for performance
 
data.

On Fri, 19 May 2006 11:23:39 -0500, Leland Lucius <[EMAIL PROTECTED]> 

wrote:

>Why does "z/VM: Getting Started with Linux on System z9 and zSeries" 
>instruct you to setup MONWRITE.  What benefit is there to have the raw 

>monitor records rather than Perftk's history?
>
>Thanks,
>
>Leland
>
=
===

Re: z/VM SVC's documented anywhere ?

[Alan Ackerman]

There is a list of SVCs at the HLASM site: 
. More about the topic in a 
thread in the lsit archives -- search for "HLASM.com announcement" 
starting 16 Nov 2004.

On Fri, 19 May 2006 13:25:39 -0500, C. Lawrence Perkins 
<[EMAIL PROTECTED]> wrote:

>Is there any documentation of the z/VM SVC's and what each does?  202 is
 
>the Star, of course, but are the others documented anywhere?  Our 
>applications are having problems with 109, 60, and 19 among others.
>
>Thanks.
>
=
===

Re: Performance Toolkit AND Monwrite???

[Bill Bitner]

>data in the CP MONITOR stream that Perftk can't deal with yet, and IBM wa=
>nts
>to make sure that it's available if needed.=20
>

None of the products available today report on 100% of what's in the raw
data. It would not be worth any vendors time to report all of the data as
much of it is really only meaningful to a couple dozen people in the
world. However, for those really specific design bugs that data can be
crucial. Likewise, the granularity that is kept in any of the products
might not be sufficient for problem determination. The purpose of
describing this in the Getting Started book is as Kurt described. We're
not saying that people should use it all the time. We just thought it
worth setting up so in a crisis or for the migration scenarios Kurt
outlined that the customer have a way to get this data. It was not
an attempt to sell more DASD or sell more maid services. :-)

Bill Bitner - VM Performance Evaluation - IBM Endicott - 607-429-3286

Re: z/VM SVC's documented anywhere ?

[Chris Langford]

The SVCs you mention are probably OS SVCs.

19 = OPEN
60= STAE
109= ESPIE


C. Lawrence Perkins wrote:
We're trying to develop a DB2/VM to DB2/UDB application on Linux system = 


using the DRDA protocol.  We're getting a lot of "unsupported SVC" messag=
es 
from our application code.


Is there any documentation of the z/VM SVC's and what each does?  202 is = 

the Star, of course, but are the others documented anywhere?  Our 
applications are having problems with 109, 60, and 19 among others.


Thanks.
..
For: [EMAIL PROTECTED]



  


--
Chris Langford,
Cestrian Software:
Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc. 


z/FM  - A toolbox for VM & MVS at http://zfm.cestrian.com
Deva Woodcrafting:
Furniture creation, House remodeling, Wagon restoration etc.

Re: z/VM SVC's documented anywhere ?

[Alan Altmark]

On Friday, 05/19/2006 at 01:25 EST, "C. Lawrence Perkins" 
<[EMAIL PROTECTED]> wrote:
> We're trying to develop a DB2/VM to DB2/UDB application on Linux system
> using the DRDA protocol.  We're getting a lot of "unsupported SVC" 
messages
> from our application code.
> 
> Is there any documentation of the z/VM SVC's and what each does?  202 is
> the Star, of course, but are the others documented anywhere?  Our
> applications are having problems with 109, 60, and 19 among others.

The CMS Application Development Guide for Assembler discusses SVC 202 and 
204 (CMSCALL) in Chapter 5.  The MVS SVCs are in Ch. 22.  The DOS SVCs are 
in Ch. 24.

SVC 203 still exists, but only for AMODE 24 programs.   SVC 201 is what 
you get when you issue the CMSRET macro.  Neither 201 nor 203 are 
explicitly discussed.

But I think that's a red herring, and that there's a problem in your 
process.  Are you trying to compile on Linux (using gcc?) and then run on 
CMS?  People who write programs in HLLs don't have to worry about SVCs. Or 
are you writing in assembler?

Alan Altmark
z/VM Development
IBM Endicott

Re: z/VM SVC's documented anywhere ?

[David Kreuter]

CMS uses SVCs 201-204. You can check the CMS Development Reference for 
Assembler and the CMS Macros and Functions Reference. The SVC #s you 
cite are note CMS SVCs - they may be simulated to one degree or another.

David Kreuter.
C. Lawrence Perkins wrote:

We're trying to develop a DB2/VM to DB2/UDB application on Linux system 


using the DRDA protocol.  We're getting a lot of "unsupported SVC" messag
es 
from our application code.


Is there any documentation of the z/VM SVC's and what each does?  202 is 

the Star, of course, but are the others documented anywhere?  Our 
applications are having problems with 109, 60, and 19 among others.


Thanks.



 

Re: Performance Toolkit AND Monwrite???

[Leland Lucius]

On Fri, 19 May 2006 12:16:20 -0500, Dave Jones <[EMAIL PROTECTED]> 

wrote:

>On Fri, 19 May 2006 11:23:39 -0500, Leland Lucius <[EMAIL PROTECTED]> 

wrote:
>
>>Why does "z/VM: Getting Started with Linux on System z9 and zSeries" 

>>instruct you to setup MONWRITE.  What benefit is there to have the raw 

>>monitor records rather than Perftk's history?
>>
>>Thanks,
>>
>>Leland
>
>None, really, other than helping fill up all of your DASD space
>The only reason I can think of is there might be Linux related performan
ce
>data in the CP MONITOR stream that Perftk can't deal with yet, and IBM 

wants
>to make sure that it's available if needed. 
>

That was kind of what I was thinking too...just one more thing to keep 

clean.  And I hate cleaning house.  :-)

But, Kurt does bring up some good points about being able to process it 

over on z/OS.  Our capacity planners here know that side of the fence and
 
could better "deal with foriegn" data rather than having to learn what to
 
do with Perftk.

So, I'll just have to clean an extra room in the house.  (I need a 
maid!!!  ;-D))

Leland

z/VM SVC's documented anywhere ?

[C. Lawrence Perkins]

We're trying to develop a DB2/VM to DB2/UDB application on Linux system 

using the DRDA protocol.  We're getting a lot of "unsupported SVC" messag
es 
from our application code.

Is there any documentation of the z/VM SVC's and what each does?  202 is 

the Star, of course, but are the others documented anywhere?  Our 
applications are having problems with 109, 60, and 19 among others.

Thanks.

Re: Performance Toolkit AND Monwrite???

[Kurt Acker]

The raw Monwrite data is a superset of the data available
from the Toolkit History files. While you could easily use the Toolkit,
or another product if you have one, we wanted to ensure that people knew
about this other method of collecting data. If you were to use this in
conjunction to Toolkit, you might not want to keep the raw files for a
long period of time (with a few possible exceptions of course). The value
add of having the MONWRITE id ready to collect monitor data includes: 
- you reduce it using PERFKIT BATCH mode for specialized
reports or variations
- you can feed it to other programs and products (e.g.
to send data to z/OS for capacity planning) 
- you also have data that can be compared to the history
file
- you have data that can be used for post report processing
by IBM when needed

We also highly recommend collecting the raw monitor
data and saving it before you make any major system change (new processor,
new DASD, product upgrades, etc.). You may never need the data, but for
scenarios where you cannot go back in time and collect it when problems
occur, it can be very helpful.

Kurt Acker  






Leland Lucius <[EMAIL PROTECTED]>

Sent by: The IBM z/VM Operating System

05/19/2006 12:23 PM



Please respond to
The IBM z/VM Operating System 





To
IBMVM@LISTSERV.UARK.EDU


cc



Subject
Performance Toolkit AND Monwrite???








Why does "z/VM: Getting Started with Linux on
System z9 and zSeries" 
instruct you to setup MONWRITE.  What benefit is there to have the
raw 
monitor records rather than Perftk's history?

Thanks,

Leland

Re: Performance Toolkit AND Monwrite???

[Thomas Kern]

Maybe the authors of that document could not get their management to pay 
for
the Performance ToolKit for a system that is meant to do nothing but host

Linux images.


After all, everything about Linux is supposed to be free.


/Tom Kern

On Fri, 19 May 2006 11:23:39 -0500, Leland Lucius <[EMAIL PROTECTED]> w
rote:
>Why does "z/VM: Getting Started with Linux on System z9 and zSeries" 
>instruct you to setup MONWRITE.  What benefit is there to have the raw 

>monitor records rather than Perftk's history?

Re: Performance Toolkit AND Monwrite???

[Dave Jones]

On Fri, 19 May 2006 11:23:39 -0500, Leland Lucius <[EMAIL PROTECTED]> w
rote:

>Why does "z/VM: Getting Started with Linux on System z9 and zSeries" 
>instruct you to setup MONWRITE.  What benefit is there to have the raw 

>monitor records rather than Perftk's history?
>
>Thanks,
>
>Leland

None, really, other than helping fill up all of your DASD space
The only reason I can think of is there might be Linux related performanc
e
data in the CP MONITOR stream that Perftk can't deal with yet, and IBM wa
nts
to make sure that it's available if needed. 

But the good news is that you can run very advanced 3rd party performance

tools (e.g., Velocity's ESAMON) in addition to or as a replacement for Pe
rftk.

Hope this helps.

DJ

Performance Toolkit AND Monwrite???

[Leland Lucius]

Why does "z/VM: Getting Started with Linux on System z9 and zSeries" 
instruct you to setup MONWRITE.  What benefit is there to have the raw 

monitor records rather than Perftk's history?

Thanks,

Leland

Re: vm alternat userid support

[Alan Altmark]

On Friday, 05/19/2006 at 09:33 AST, John Hall <[EMAIL PROTECTED]> 
wrote:

> If your worker and/or server is "trusted", you can use the CSL API to
> create workunits that specify the altuser and then use that workunit
> on CSL calls for work for that altuser. 

You mentioned 'trust'.  The following is a public service announcement:


It's worth noting that the altuser support on DMSGETWU does not depend on 
diagnose 0xD4, but uses the ALTID parameter on APPCVM CONNECT.  I mention 
this because diagnose 0xD4 is class B (by default) and can be problematic 
in a multi-threaded environment, requiring serialization of CONNECTs. 
(Imagine a virtual machine with two CPUs with Diag D4 race conditions.) It 
also grants more capability than is strictly needed, esp. if you just give 
class B instead of moving it to its own privclass.  DMSGETWU (with userid) 
only requires OPTION COMSRV in a class G user.

The only other effect of OPTION COMSRV is that the user can choose to 
accept APPC connections in a way the stops CP from verifying any 
security-related information.  This is how TSAF does what it does, but it 
requires extra programming to exploit it.


Alan Altmark
z/VM Development
IBM Endicott

Re: vm alternat userid support

[John Hall]

On 5/19/06, Westlund, Mats (Mainframe servers) <[EMAIL PROTECTED]> wrote:


SFS do not check the alternate user so the suggested method to
create a lock for a file to see what altuser is running do not
work if the worker it selves use any sfs files.

When the worker first access a filepool the appc connection is
assigned the userid/altuserid that the worker has in that moment
and that userid is kept in the sfs filepool as long as the appc
connection exists so even if the worker is assigned a new altuser
the connection to sfs still uses the old (firs) userid.

To get the "right" userid the worker has to reset the appc connection
to the filepool before accessing files for the new user.

This is a problem when developing worker applications using sfs,
the worker it selves can't use files in sfs and the order of setting
up appc connections to sfs is very important.


This is correct.  Often a brute force method is employed when setting
up a worker for a transaction set via DMSPURWU.  In fact, if the
worker is not "trusted", you are forced to do this during worker
setup, to ensure that there are no lingering authorizations available
from a previous transaction.

If your worker and/or server is "trusted", you can use the CSL API to
create workunits that specify the altuser and then use that workunit
on CSL calls for work for that altuser.  If your application is single
threaded, you can also change the "default workunit" which will affect
all subsequent interactions with SFS.

A single-threaded application (that may or may not be multi-client,
but serves clients in a serial fashion) can simply obtain a workunit
(DMSGETWU), make it the default (DMSPUSWU), perform whatever work it
requires, return to the previous work unit (DMSPOPWU), and discard the
workunit (DMSRETWU).

A multi-threaded application that wishes to use the altuser facility
with SFS must limit itself to the CSL set, specifying a workunit as
applicable.  This allows a worker/server to perform work on behalf of
one or more users (via altuser) at the same time.  Additionally, one
might serialize access to certain CMS functions, so that you can use
the "default workunit" (DMSPUSWU/DMSPOPWU) so as to issue traditional
CMS commands.  For example, you might create a critical section
(serial access by all threads) to the ERASE command that issues the
series DMSPUSWU, ERASE, DMSPOPWU so that the ERASE runs with the
authority and auditing of the altuser associated with the given
workunit (poor example, b/c you could just use DMSERASE, but the
example holds true).

John

--
John Hall   (+1) 727-397-6373  Safe Software, Inc.
JohnHall (at) SafeSoftware.Com  http://www.SafeSoftware.Com
JohnBeachFL (at) gmail.com

Re: vm alternat userid support

[Alan Altmark]

On Friday, 05/19/2006 at 08:35 ZE2, "Westlund, Mats (Mainframe servers)" 
<[EMAIL PROTECTED]> wrote:
> SFS do not check the alternate user so the suggested method to 
> create a lock for a file to see what altuser is running do not 
> work if the worker it selves use any sfs files. 

SFS doesn't have a choice.  It sees the userid CP puts there.

But you're right that diag D4 only affects APPC connections made after 
that point, having no affect on existing connections.  So an application 
that tries to exploit this would have to issue DMSPURWU CSL routine to 
sever the APPC connection before using Diag D4.

Alan Altmark
z/VM Development
IBM Endicott

Re: vm alternat userid support

[Westlund, Mats (Mainframe servers)]

Title: Re: vm alternat userid support






>Another would be to create a lock on an SFS access directory, and then

>query the lock



SFS do not check the alternate user so the suggested method to 

create a lock for a file to see what altuser is running do not 

work if the worker it selves use any sfs files.


When the worker first access a filepool the appc connection is 

assigned the userid/altuserid that the worker has in that moment 

and that userid is kept in the sfs filepool as long as the appc 

connection exists so even if the worker is assigned a new altuser 

the connection to sfs still uses the old (firs) userid.


To get the “right” userid the worker has to reset the appc connection 

to the filepool before accessing files for the new user. 


This is a problem when developing worker applications using sfs, 

the worker it selves can’t use files in sfs and the order of setting 

up appc connections to sfs is very important.


Regards 

Mats Westlund

Re: Emulated tape/ECKD disk

[Jeff Gribbin, EDS]

"This really needs to be core VM function" ...

David,
Let me reiterate that comment as I understand it, because I think it's 

possible to interpret the scope of what you mean by, "Core VM function" i
n 
different ways - and it's a definition that we need to agree upon if we'r
e 
to have a fruitful discussion.

In my view, the, "Core VM Function" that IBM has to buy into is the 
provision of an API in CP that allows the creation of an RDEV of any kind
 
("take, "any" with a pinch of salt - hopefully it could be architeched to
 
do, "any" in principle but maybe limited for practical/business reasons t
o 
(say) tape and DASD on its first outing) together with the supporting API
 
that allows communication between the created RDEV and a Service Virtual 

Machine. Again, I cite *CCS as the conceptual model.

Personally, I DO NOT see (and, if I read you correctly, neither do you) 

the provision of the server code that drives this API as part of the "Cor
e 
VM Function" that IBM needs to buy into. While I can see that IBM might 

well wish to take advantage of the API and deliver function that is based
 
on the API I am also certain that there are entrepreneurs across the whol
e 
spectrum from Open-Sourcers to Proprietary OCOers who would gladly grab 

the opportunity to provide all kinds of arcane and esoteric device suppor
t 
base upon the aforesaid, "Core VM Function".

As I said earlier, I believe that this is just a re-statement and 
clarification of the scope that you already subscribe to but - if not the
n 
at least, with your reply, we're likely all to be definitely talking abou
t 
the same thing.

Pardon my pedantry.

Regards
Jeff