Re: Managing the CMS program stack from a multitasking CMS application

[Gillis, Mark]

This is what I'm trying to accomplish:

I was asked to look at providing an interface between one of our
products that runs in CMS to another of our products that runs in z/OS.
I already have a general-purpose REXX program in CMS that communicates
with the z/OS-based program via REXX sockets. It acts as an agent for
the z/OS program, in that it will issue commands on its behalf, return
results, as well as plug itself into the *MSG and *VMEVENT system
services (a bit like WAKEUP). At the heart of the REXX program is an
event handler that waits on socket events, console events, IUCV events
(converted to MT CMS events by a nucleus extension) and timer events.

The problem I have is that product that the CMS-based product appears to
only return information via the program stack. That prompted me to look
for a way to be told about data arriving on the program stack so that I
could read each line as it arrives from the stack and convert it to an
MT CMS event that my dispatcher loop could deal with.

You've answered my question, the answer being what I suspected (there
not being a way to be notified about data being queued to the stack).
  
It's sounding like I should talk to the people who own this CMS-based
product about having it modified to have the option to use something a
little more sophisticated than the program stack to return information.
That's the next step I'll take if this goes any further (which it
probably won't).

Thanks,
Mark Gillis.

-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Alan Altmark
Sent: Sunday, 1 May 2011 2:06 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Managing the CMS program stack from a multitasking CMS
application

On Thursday, 04/28/2011 at 05:17 EDT, "Gillis, Mark"
 
wrote:
> I have a multitasking CMS application that waits for a number of 
different 
> types of events and I would like to add a new event type that
represents 
data 
> from the CMS stack. I thought that the obvious way to do this would be

to start 
> a separate thread that would own the stack and issue an event to
contain 
each 
> line that arrives on the stack. My question is:
> 
> Is there a way to be notified when data is added to the CMS program 
stack? I 
> don?t want to poll, or do anything to cause a read to result to the 
virtual 
> console. I don?t see anything in the CMS Macros and Function
Reference, 
REXX/VM 
> Reference, CMS Callable Services Reference, or the CMS Application 
Multitasking 
> manuals that appear to fit the bill.

There is no built-in event monitor for CMS program stack events.  If you

tell us what you're trying to accomplish, perhaps we can provide some 
guidance.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

Managing the CMS program stack from a multitasking CMS application

[Gillis, Mark]

Hi,

I have a multitasking CMS application that waits for a number of
different types of events and I would like to add a new event type that
represents data from the CMS stack. I thought that the obvious way to do
this would be to start a separate thread that would own the stack and
issue an event to contain each line that arrives on the stack. My
question is:

Is there a way to be notified when data is added to the CMS program
stack? I don't want to poll, or do anything to cause a read to result to
the virtual console. I don't see anything in the CMS Macros and Function
Reference, REXX/VM Reference, CMS Callable Services Reference, or the
CMS Application Multitasking manuals that appear to fit the bill.

 

Any ideas?

 

Thanks in advance,

Mark Gillis

Re: Running REXX compiled in z/OS in CMS

[Gillis, Mark]

Great - now it all makes sense. We'll just pre-req the alternate library
for our product. Thanks.

 

From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Doug Breneman
Sent: Thursday, 14 April 2011 6:37 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Running REXX compiled in z/OS in CMS

 

Mark,
Many VM releases ago, VM Development wanted to have all customers
benefit from performance improvements for some of the items that were
written in REXX. You know about these parts like VMLINK, NOTE, SENDFILE,
FILELIST and many others. However, we could not assume that all
customers would install the REXX Alternate Library and customers would
want to use these parts even before they got around to installing the
REXX Alternate Library. So VM Development created a DMSRTPRC which is a
library which is sufficient for the compiled REXX parts that are shipped
with the VM product. It is not to be used by our customers for their own
use because it is not supported for general use. There is no guarantee
that your compiled part will run if you edit it to use DMSRTPRC. VM
Development will not service DMSRTPRC if it does not work with your
compiled part. We will service it if it fails with one of the parts that
are compiled and shipped as part of VM. 
pdb (Doug Breneman)
z/VM System Test IBM Endicott, NY

Inactive hide details for "Gillis, Mark" ---04/13/2011 04:26:40
PM---Thanks, Tracy. It sounds like we'll just need to require o"Gillis,
Mark" ---04/13/2011 04:26:40 PM---Thanks, Tracy. It sounds like we'll
just need to require our customers to install the alternate libr

From: "Gillis, Mark" 
To: IBMVM@LISTSERV.UARK.EDU
Date: 04/13/2011 04:26 PM
Subject: Re: Running REXX compiled in z/OS in CMS
Sent by: The IBM z/VM Operating System 






Thanks, Tracy. It sounds like we'll just need to require our customers
to install the alternate library as a pre-req to our product. I'm a bit
confused by all this though - IBM provide compiled REXX that has
DMSRTPRC in the header and this doesn't seem to require the alternate
library. If I edit a compiled REXX program and change EAGRTPRC to
DMSRTPRC it works fine. If either works, why do we have an alternate
library?

Mark Gillis. 

-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Tracy Dean
Sent: Wednesday, 13 April 2011 7:13 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Running REXX compiled in z/OS in CMS

On Wed, 13 Apr 2011 18:37:51 +1000, Gillis, Mark 
wro=
te:

>Hi,
>
>Here's a question that's half way between z/OS and CMS:
>
>I would like to compile some REXX in z/OS in such a way that it can be
>run in CMS by people who don't have the REXX compiler. From reading the
>manual, I thought that just specifying options of ALTLIB and SLINE
would=

>be sufficient, but this doesn't seem to be the case. I can make it work
>by XEDITing the compiled exec and changing the processor name in the
>header from EAGRTPRC to DMSRTPRC, but that surely isn't what IBM intend
>us to do. Does anyone know the legitimate way of doing this?
>
> 

Mark,
I can't comment on whether there are any other issues with taking REXX
co=
de
written and compiled on z/OS and running it on z/VM, but I can tell you
t=
hat
in order to run code in CMS that has EAGRTPRC in the header, you need to
install the free REXX Alternate Library on z/VM. You can get it here:
http://www.ibm.com/software/awdtools/rexx/rexxzseries/altlibrary.html

Just click on "Alternate Library for REXX on z/VM" in the 2nd paragraph.

Tracy Dean
IBM

Re: Running REXX compiled in z/OS in CMS

[Gillis, Mark]

Thanks, Tracy. It sounds like we'll just need to require our customers
to install the alternate library as a pre-req to our product. I'm a bit
confused by all this though - IBM provide compiled REXX that has
DMSRTPRC in the header and this doesn't seem to require the alternate
library. If I edit a compiled REXX program and change EAGRTPRC to
DMSRTPRC it works fine. If either works, why do we have an alternate
library?

Mark Gillis. 

-Original Message-
From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On
Behalf Of Tracy Dean
Sent: Wednesday, 13 April 2011 7:13 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Running REXX compiled in z/OS in CMS

On Wed, 13 Apr 2011 18:37:51 +1000, Gillis, Mark 
wro=
te:

>Hi,
>
>Here's a question that's half way between z/OS and CMS:
>
>I would like to compile some REXX in z/OS in such a way that it can be
>run in CMS by people who don't have the REXX compiler. From reading the
>manual, I thought that just specifying options of ALTLIB and SLINE
would=

>be sufficient, but this doesn't seem to be the case. I can make it work
>by XEDITing the compiled exec and changing the processor name in the
>header from EAGRTPRC to DMSRTPRC, but that surely isn't what IBM intend
>us to do. Does anyone know the legitimate way of doing this?
>
> 

Mark,
I can't comment on whether there are any other issues with taking REXX
co=
de
written and compiled on z/OS and running it on z/VM, but I can tell you
t=
hat
in order to run code in CMS that has EAGRTPRC in the header, you need to
install the free REXX Alternate Library on z/VM.  You can get it here:
http://www.ibm.com/software/awdtools/rexx/rexxzseries/altlibrary.html

Just click on "Alternate Library for REXX on z/VM" in the 2nd paragraph.

Tracy Dean
IBM

Running REXX compiled in z/OS in CMS

[Gillis, Mark]

Hi,

Here's a question that's half way between z/OS and CMS:

I would like to compile some REXX in z/OS in such a way that it can be
run in CMS by people who don't have the REXX compiler. From reading the
manual, I thought that just specifying options of ALTLIB and SLINE would
be sufficient, but this doesn't seem to be the case. I can make it work
by XEDITing the compiled exec and changing the processor name in the
header from EAGRTPRC to DMSRTPRC, but that surely isn't what IBM intend
us to do. Does anyone know the legitimate way of doing this?

 

Thanks,

Mark Gillis 
Principal Software Engineer 
Tel: +61 2 8898 2678 
Fax: +61 2 8898 2600 
mark.gil...@ca.com  

   

 

Re: simplest little pipe

[Gillis, Mark]

>From help pipe cp:

string

is a command passed to CP for execution. The string operand cannot
be 
specified if the secondary output stream of the CP stage is
connected; in 
that case, the CP stage issues only the commands that it reads from
its   
primary input stream.



Mark Gillis 

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Hughes, Jim
Sent: Thursday, 7 October 2010 7:33 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: simplest little pipe

Where are the clues indicating a secondary stream is not allowed if the
command is specified as part of the cp stage?

Be gentle.


Jim Hughes
603-271-5586
"It is fun to do the impossible."

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Frank M. Ramaekers
Sent: Wednesday, October 06, 2010 4:28 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: simplest little pipe

Was this more what you were looking for?

PIPE (ENDCHAR ?) LITERAL v dasd | a: CP | > b b a ? a: | SPEC /RC=/ 1
PAD 0 1-* NW.3  RIGHT| CONSOLE
RC= 001


 
Frank M. Ramaekers Jr.
 
 

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Hughes, Jim
Sent: Wednesday, October 06, 2010 3:18 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: simplest little pipe

When I add a secondary output to the CP stage, I get:

PIPCOM112E Excessive options "q v dasd".
PIPSCA003I ... Issued from stage 1 of pipeline 1.
PIPSCA001I ... Running "cp q v dasd".

Notice the pipeline is issuing "CP Q V DASD"

Would someone share their results when CP has a secondary output
defined?

Here is my pipeline:
/*  */
signal on novalue
"pipe ( endchar ? stagesep \ )  ",
   "? a:   cp q v dasd",
   "\ console   ",
   "?   a: \ specs /RC=/ 1 pad 0 1-* nw.3 ",
   "\ console"
 
 
return rc



Jim Hughes
603-271-5586
"It is fun to do the impossible."

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Dave Jones
Sent: Wednesday, October 06, 2010 3:52 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: simplest little pipe

Try this instead, Tom:

'PIPE (end ?)',
'| a: cp v dasd' ,  /* incorrect format for CP command, btw */
' > b b a',
'?',
'a:',
'| > c c a'

On 10/06/2010 02:47 PM, Tom Huegel wrote:
> This is so simple, but I am a little crossed eyed today.
> 
> Shouldn't I see the RC or error msg in 'C C A"?
> 
> pipe (endchar ?) cp  v dasd | a: > b b a  ? a: | > c c a
> 
> I don't get anything there.
> 

-- 
Dave Jones
V/Soft Software
www.vsoft-software.com
Houston, TX
281.578.7544

_

This message contains information which is privileged and confidential
and is solely for the use of the

intended recipient. If you are not the intended recipient, be aware that
any review, disclosure,

copying, distribution, or use of the contents of this message is
strictly prohibited. If you have

received this in error, please destroy it immediately and notify us at
privacy...@ailife.com.

Re: GCS GROUP command

[Gillis, Mark]

The instructions are listed in Appendix A.2 of the Group Control System
manual.

 

Mark.

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Gentry, Stephen
Sent: Monday, 13 July 2009 4:11 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: GCS GROUP command

 

I need to rebuild the GCS nuc.  I log on to maint and issue VMFSETUP ZVM
GCS.  That works.  I then type GROUP to bring up the config panels and
make my changes and save them. When I exit the GROUP exec, I was under
the assumption that an assemble deck and textlib deck are created.  They
aren't.  Did I leave out a step somewhere? Or if anyone has as list of
instructions on how to do this, I'd appreciate it.  This is on VM 5.4

Thanks,

Steve

Re: z/OS 1.9 ADCD

[Gillis, Mark]

SYS1?
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Neale Ferguson
Sent: Friday, 20 March 2009 5:44 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: z/OS 1.9 ADCD

Excuse the (slightly) off-topic subject but since we¹re running z/OS under
z/VM I am taking the liberty of posting.

I have forgotten the password of the TSO user IBMUSER. I don't believe I
changed it from when it was installed but I can't locate the ADCD
documentation that would tell me.

Neale

Re: VM Virtual CPUs and Threaded CMS Applications

[Gillis, Mark]

I haven't experienced this specific problem because IBM strongly advised
us to not allocate more than 1 virtual CPU to a mutitasking CMS
application. The reason they gave was that any CMS services called from
a thread running on a non-base CPU would need to be scheduled to run on
the base CPU, so that the overheads of this would outweigh the benefits
of the extra processors. If you're not invoking CMS services from
non-base threads then I guess that this won't be an issue for you.

Mark Gillis 
Principal Software Engineer 
Tel: +61 2 8898 2678 
Fax: +61 2 8898 2600 
[EMAIL PROTECTED] 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Gary M. Dennis
Sent: Sunday, 19 October 2008 10:24 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: VM Virtual CPUs and Threaded CMS Applications

 

If  you do not have experience with threaded CMS application
development, I suggest you read anything but the balance of of this
email.

I have an application that runs under CMS and consists of three distinct
layers.

1.  The top layer is some virtualized x86 OS. 
2.  The middle layer performs x86 to z translation 
3.  The base layer is everything else. That includes code fragment
storage, aging, retrieval, statistics collection/ push using IUCV, etc.


Layer two has been developed in such a way that, without layer three, it
simply translates a code fragments to z architecture code, executes that
code, then discards the translated fragment.  It detects the interface
stub for layer three and, if that is present, it takes advantage of the
capabilities including prior translation reuse.

Layer 3 is multithreaded and is the cause/source of the problem. Whether
layer 3 is run with layers 1 and 2 or in standalone test mode the
results are the same.

First the environment:

VM 4.3
Number of processors: 2
Virtual CPUs (from 2 to 6 .. See note below)

Now the application from 10,000 feet:

Layer three consists of a parent thread that creates 4 additional
threads.  Each thread is created in a dispatch class that is unique.

Routines are not shared between threads. Upon entry into each routine,
the preamble is destroyed and restored on exit to trap any potential
inadvertent share.   Critical fields shared between threads are
protected by a compare and swap spin lock.

Part of the testing consists of pushing 1WAY IUCV messages from each
connected client every 20 milliseconds.

The VM directory for each of 4 machines (one server and three clients)
defines the machine as  an XC mode machine with:

CPU 00 BASE
CPU 01


As each thread is created it requests either BASE or ANY CPU affinity.
BASE affinity is reserved for the parent and IUCV message handler
threads . ANY is used for all other threads . Each affinity request
receives a normal return code.

All this works beautifully for days and millions of messages UNTIL the
number of virtual CPUs defined exceed the number of real CPUs assigned
to the VM image.  When this takes place, everything comes unstuck. By
everything I mean everything in CMS.  Stack overflow (03FF abend), free
storage management failure, all of it.

The multitasking application dev guide states that to the extent
possible, dispatch classes are assigned to vCPUs and further states that
the max number of vCPUs that may be utilized is equal to the number of
dispatch classes. Whether the vCPUs are defined in the user directory
entry OR they are created dynamically using the CPU Create CMS
function, the results are the same.


My questions)

1.  Has anyone had a similar experience? 
2.  Is this a known issue with 4.3? Or in more current releases? 
3.  Although this seems to be telling me no to go there, I've tried
but cannot find anything that says "You'll shoot your eye out , kid."
if you define more virtual CPUs than real processors. Anyone know of
such a restriction? 
4.  Is it possible that CMS kernel services don't tolerate a
situation where the number of virtual CPUs exceeds "real" processors?


Thanks in advance for any insight you might have on this behavior.

--.  .-  .-.  -.--

Gary Dennis
Mantissa Corporation

Re: CMS Multi-tasking - How is it different from z/OS task management

[Gillis, Mark]

This doesn't completely answer your question, but I was told that because the 
people writing Multitasking CMS were limited in how much of CMS they were 
allowed to change, that most traditional system calls are scheduled to the base 
CPU. Therefore, providing multiple CPUs can actually degrade performance.

Mark Gillis
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gary 
M. Dennis
Sent: Friday, 11 July 2008 8:14 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: CMS Multi-tasking - How is it different from z/OS task management

We are attempting to leverage z/VM CMS multi-tasking capabilities for
Windows® thread management.

We have substantial z/OS experience with regard to task management and
serialization so what we are experiencing in a CMS environment doesn¹t fit
what we had anticipated.

Our test was conducted on a virtual machine for which two CPU¹s are defined.
The test program contains CSECTS MAIN and THREAD1. The program is invoked
under CMS. 

CSECT MAIN process

1. Initialization 

2. Call VM thread create (referencing THREAD1 CSECT) from within MAIN CSECT
in order to create THREAD1 process in a different class (new-Class specified
on thread create call).

3. Issue WTO repeatedly

THREAD1 CSECT process

1. Initialization
2. Issue WTO repeatedly

What we expected:  Interspersed WTO's from both MAIN and THREAD1 threads

What we get: THREAD1 WTOs only. We thought MAIN, being in a separate class
(and therefore eligible to be assigned to different CPUs) would dispatch
(and both issue WTOs) but this did not happen.  In z/OS the fact that the
WTO was issued would provide sufficient dispatch latency for another task to
get a time slice.

Additional observations:

1. If line write is substituted for WTO in MAIN and THREAD1 there is no
observed difference.

2. The program works as expected IF yield is called within the WTO loops in
MAIN and THREAD1.

Why should yield have to be called?  Any thread wizards out there?


--.  .-  .-.  -.--

Gary Dennis
Mantissa Corporation

Re: XEDIT and non-printables

[Gillis, Mark]

If you need to edit data with non-printables, ensure that you have IMAGE
set to OFF - this will stop XEDIT from trying to treat occurrences of
x'05' as TAB characters and x'16' as backspace characters.
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Stephen Frazier
Sent: Wednesday, 21 May 2008 5:16 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: XEDIT and non-printables

Checking my "3270 Reference Summary" after blowing the dust off I see -
x'11' is 'Set Buffer 
Address' - the next two bytes are the address on the screen where
following characters are displayed.

Kris Buelens wrote:
> Xedit will never send X'11' to a 3270 when present in data, everything

> below X'40' is replaced by the non-disp character.
> 
> 3270 control characters do exist below x'40': Start field, Set Buffer 
> address, ..  But I don't know these by heart.
> 


-- 
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: Displaying data space storage in a VMDUMP

[Gillis, Mark]

Thanks, Bill - that all makes perfect sense. 
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Bill Holder
Sent: Thursday, 15 May 2008 6:00 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Displaying data space storage in a VMDUMP

I should have mentioned that although a single VMDUMP command can dump
multiple address spaces, doing so requires separate explicit
identificati=
on
of each each address space (primary or data space) to be dumped (via the
PRImary, SPACE, ASIT, ALET, or AREG options).  I had thought there was a
"dump them all" shorthand option, but I don't see it now, so I guess
that=

was wishful thinking / misremembering.  A VMDUMP command specifying
multi=
ple
spaces will generate one dump file per address space specified.  Also, I
should have used the term "primary" rather than "base" in my previous
pos=
t.  

- Bill Holder
  z/VM Development, IBM  

Re: Displaying data space storage in a VMDUMP

[Gillis, Mark]

Thanks, I wasn't aware of the existence of VMDUMPTL - I'll check it out.



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Neale Ferguson
Sent: Wednesday, 14 May 2008 7:09 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Displaying data space storage in a VMDUMP

 

Shouldn't you be using VMDUMPTL? It has a  command (VMDTSET) that allows
you to specify an ASCE when doing displays of storage. 



Does anyone know how to display data space storage in DUMPSCAN? The
DUMPSCAN DISPLAY command doesn't seem to know about ALETs.

Re: Displaying data space storage in a VMDUMP

[Gillis, Mark]

DUMP0001.

 

I don't see any operands on the display command, though, for specifying
an ALET, or anything else that would identify the data space.

 

Mark.



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of David Kreuter
Sent: Wednesday, 14 May 2008 6:57 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Displaying data space storage in a VMDUMP

 

the space needs to have been dumped - what is the filetype that DUMPLOAD
created?

David

 



From: The IBM z/VM Operating System on behalf of Gillis, Mark
Sent: Tue 5/13/2008 4:55 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] Displaying data space storage in a VMDUMP

Does anyone know how to display data space storage in DUMPSCAN? The
DUMPSCAN DISPLAY command doesn't seem to know about ALETs.

Thanks in advance,

Mark Gillis

Senior Software Engineer

Tel: +61 2 9429 2337

Fax: +61 2 9429 2394

[EMAIL PROTECTED]

Displaying data space storage in a VMDUMP

[Gillis, Mark]

Does anyone know how to display data space storage in DUMPSCAN? The
DUMPSCAN DISPLAY command doesn't seem to know about ALETs.

Thanks in advance,
Mark Gillis
Senior Software Engineer
Tel: +61 2 9429 2337
Fax: +61 2 9429 2394
[EMAIL PROTECTED]

Re: ETC HOSTS question

[Gillis, Mark]

Sorry - I should have said "ETC SAMPLE" instead of "ETC SAMPSERV"

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Gillis, Mark
Sent: Thursday, 20 March 2008 9:04 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ETC HOSTS question

Does this mean that for the ETC HOSTS file that you copy the ETC
SAMPSERV file on the 592 disk to ETC HOSTS on the same disk and then
modify it?

Mark Gillis
Senior Software Engineer
Tel: +61 2 9429 2337
Fax: +61 2 9429 2394
[EMAIL PROTECTED]

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Thursday, 20 March 2008 8:10 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ETC HOSTS question

On Wednesday, 03/19/2008 at 04:21 EDT, "Huegel, Thomas" 
<[EMAIL PROTECTED]> wrote:
> The DOC says 198.. 
> I am still missing something, I can't PING (by name) the new entry in 
ETC 
> HOSTS. 

The doc is wrong.  It was a bogus copy-n-paste of the [rather vague] 
information on HOSTS LOCAL, which you *do* copy to 198, customize, 
MAKESITE, then copy the resulting *INFO files to the 592.

(sigh)

Thanks for finding this.  All name resolution is done in the *user's* 
virtual machine, not in the stack.  So the user must have access to the 
file.

Alan Altmark
z/VM Development
IBM Endicott

Re: ETC HOSTS question

[Gillis, Mark]

Does this mean that for the ETC HOSTS file that you copy the ETC
SAMPSERV file on the 592 disk to ETC HOSTS on the same disk and then
modify it?

Mark Gillis
Senior Software Engineer
Tel: +61 2 9429 2337
Fax: +61 2 9429 2394
[EMAIL PROTECTED]

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Thursday, 20 March 2008 8:10 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ETC HOSTS question

On Wednesday, 03/19/2008 at 04:21 EDT, "Huegel, Thomas" 
<[EMAIL PROTECTED]> wrote:
> The DOC says 198.. 
> I am still missing something, I can't PING (by name) the new entry in 
ETC 
> HOSTS. 

The doc is wrong.  It was a bogus copy-n-paste of the [rather vague] 
information on HOSTS LOCAL, which you *do* copy to 198, customize, 
MAKESITE, then copy the resulting *INFO files to the 592.

(sigh)

Thanks for finding this.  All name resolution is done in the *user's* 
virtual machine, not in the stack.  So the user must have access to the 
file.

Alan Altmark
z/VM Development
IBM Endicott

Re: ETC HOSTS question

[Gillis, Mark]

Isn't ETC HOSTS supposed to live on the TCPMAINT's 198 disk, rather than
592 (even though the sample is provided on 592)?

Mark Gillis
Senior Software Engineer
Tel: +61 2 9429 2337
Fax: +61 2 9429 2394
[EMAIL PROTECTED]
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Thursday, 20 March 2008 5:04 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ETC HOSTS question

On Wednesday, 03/19/2008 at 01:28 EDT, Mark Vitale 
<[EMAIL PROTECTED]> wrote:
> Not sure about ETC HOSTS, but I can answer for HOSTS  LOCAL..
> You have to run MAKESITE to update HOSTS ADDRINFO and 
> HOSTS SITEINFO, since the clients only read the *INFO  files.

That hasn't been true for quite a while, Mark.  z/VM 5.1 introduced ETC 
HOSTS.  It does not require use of MAKESITE; the *INFO files are used
only 
if no ETC HOSTS is available.  ("Death to *INFO files!  Death, I say!")

Thomas said:
> I  recently had a change to ETC HOSTS but I can't find a way to get 
TCP/IP to 
> recognize my change.
> Is  there a way, other that recycling TCPIP, to get the stack to 
reprocess the 
> ETC  HOSTS file?

Recycling of the stack is not required.  Just put the updated ETC HOSTS
on 
the 592 disk and recycle the *application* server (to get it to
re-access 
the 592).  The file is read by the resolver, not the stack.

Alan Altmark
z/VM Development
IBM Endicott

Re: To define virtual processors or not

[Gillis, Mark]

Don't bother defining more than 1 to a machine that just runs a
Multitasking CMS application - it actually slows things down due to the
fact that most system calls switch back to the base processor.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Adam Thornton
Sent: Thursday, 14 February 2008 11:58 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: To define virtual processors or not

On Feb 13, 2008, at 6:54 PM, Paul Vincent wrote:

> Hello List,
>
> I'm new to z/VM and have a question.  Should I define virtual  
> processors to
> z/VM service ids/guests (TCPIP, Linux guests...) with the 'MACHINE  
> ESA ## &
> CPU #' control statements in the USER DIRECT file?  Is there a  
> performance
> benefit/cost, if I have more than 1 IFL, to define virtual  
> processors equal
> to the number of IFLs?  Or will a single virtual processor perform  
> just
> fine.

I like defining two (assuming that my real load is less than two full  
engines' worth) or as-many-as-I-expect-to-be-able-to-use-if-more-than- 
two.

Basically, this is to give my workload the best chance of parallel  
dispatch.  If I only have one virtual processor, I only have one thing  
*really* going on at a time in my Linux guest, even if the actual work  
is hopping around real processors.  I don't have any hard data that  
tells me this is really working, though.  Does anyone?

Adam

Re: Guest in 31 or 64 bit?

[Gillis, Mark]

And GCS because it runs DAT off, too. 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Ackerman
Sent: Saturday, 11 August 2007 3:07 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Guest in 31 or 64 bit?

On Fri, 10 Aug 2007 17:12:00 -0400, Neale Ferguson
<[EMAIL PROTECTED]>=
 wrote:

>No it program checks on an attempt to issue the SIGP to put the machine
>in 64-bit mode.
>
>On Fri, 2007-08-10 at 14:08 -0700, Schuh, Richard wrote:
>> Can an XC machine run 64-bit? Isn't XC a pseudo mode invented so that
>> CMS could access SFS DIRC directories that were in dataspaces?
>=
==
==
==

I don't think you can run any guest in XC mode besides CMS, but I don't
k=
now why. Maybe it has to  
do with turning DAT on? Nothing to do with 64-bit mode.

At least, that was my problem #1 when I installed the Marist Linux
distri=
bution back in early 2000. 
(The XC mode was hiding in a directory profile.) This was 31-bit Linux,
s=
ince 64-bit didn't exist 
yet (at least outside of IBM).

I wouldn't call it a pseudo-mode, though. It is as "real" as anything
els=
e in microcoded hardware 
is. It is special in that it is designed to allow use of dataspaces (and
=
access registers) with DAT off. 
It's just that the only operating system that I know of that runs DAT
off=
 is CMS.

Alan(dot)Ackerman(at)Bank of America(dot)com

Re: How to determine if running as a multitasking CMS app

[Gillis, Mark]

The problem is that I may eventually need to do a ThreadCreate (note
Multitasking CMS call, not POSIX pthread_create) or EventTrap call, but
not initially. It seemed pretty ugly to me to have to create a thread
just to decide if I was running as a true MT CMS app or not. Not
providing a call to determine this seems to have been an oversight
(along with having VMPROCESSEND events keyed on process name when
there's no way to retrieve a process ID from a process name - but I
digress). 

Thanks to everyone for the ideas provided - I think I'll stick to
running the chain of PSDs.

Mark Gillis
Senior Software Engineer
Tel: +61 2 9429 2337
Fax: +61 2 9429 2394
[EMAIL PROTECTED]
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Tuesday, 10 July 2007 11:02 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How to determine if running as a multitasking CMS app

On Monday, 07/09/2007 at 10:30 AST, Rick Troth <[EMAIL PROTECTED]> wrote:
> On Mon, 9 Jul 2007, Alan Altmark wrote:
> 
> > I have some assembler code that can run with C or Pascal (called
prior 
to
> > entering the "real" module).  I put in a WXTRN for CEESTART and 
VSPASCAL
> > in order to figure out whether it is running in an LE environment or

not.
> > Could you put in a WXTRN for VMSTART?   If the adcon is non-zero,
then
> > VMSTART was linked.
> 
> I've made a note of your recommendation.
> But this still only tells us that VMSTART is in the mix.
> Someone please convince me that this is sufficient.

Unfortunately I don't understand the underlying problem.  If I wanted to

know if pthread_create was going to work, I would issue it and remember 
the answer, so that I could fallback to Plan B.  But since that's the 
obvious answer, I figured that wasn't the problem.

Alan Altmark
z/VM Development
IBM Endicott

Re: How to determine if running as a multitasking CMS app

[Gillis, Mark]

DMSCALLER returned the name of the calling load module - not VMSTART.
Not to worry - running the chain of PSD's seems to work, I'll just keep
my fingers crossed that it stays that way.
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Don Russell
Sent: Tuesday, 10 July 2007 11:29 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How to determine if running as a multitasking CMS app

Not sure if this will work but...

Can you use DMSCALLER to "look back" to see who called you... do that 
repeatedly (looking further and further back) until you:
A - find the origin of the universe you currently know
or
B - find VMSTART

You would only need to do this one time when your program starts, then 
set your own flag for other parts to check as needed.

Or (untested), try calling an MT function (that actually requires 
MT) if it works, you're MT; if not, you're not. (Might need an ESPIE

or similar routine to "catch" an abend.)





Gillis, Mark wrote:
> Unfortunately, not applicable to what I'm doing - the module where I'm
> doing this is CMSCALL'd by a client application, so it's not linked
in,
> and I need to maintain backward compatibility, so it needs to stay
that
> way. 
>
> Good idea, though.
>
> Mark Gillis
> Senior Software Engineer
> Tel: +61 2 9429 2337
> Fax: +61 2 9429 2394
> [EMAIL PROTECTED]
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
On
> Behalf Of Alan Altmark
> Sent: Tuesday, 10 July 2007 10:59 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: How to determine if running as a multitasking CMS app
>
> On Tuesday, 07/10/2007 at 10:16ZE10, "Gillis, Mark"
<[EMAIL PROTECTED]>
>
> wrote:
>   
>> In case anyone?s interested, I raised this with IBM. Their response
>> 
> was 
> that 
>   
>> testing NUCMTDSP wouldn?t work, the only way possible being to run
the
>> 
>
> CMS 
>   
>> control blocks. Unfortunately, these control blocks have the
note?This
>> 
>
>   
>> information is NOT intended to be used as Programming Interfaces of 
>> 
> z/VM?
>   
>> ? which makes me a little uneasy about doing it this way. I guess
it?s
>> 
>
> all 
>   
>> there is, though.
>> 
>
> I have some assembler code that can run with C or Pascal (called prior
> to 
> entering the "real" module).  I put in a WXTRN for CEESTART and
VSPASCAL
>
> in order to figure out whether it is running in an LE environment or
> not. 
> Could you put in a WXTRN for VMSTART?   If the adcon is non-zero, then

> VMSTART was linked.
>
> Alan Altmark
> z/VM Development
> IBM Endicott
>   

Re: How to determine if running as a multitasking CMS app

[Gillis, Mark]

Unfortunately, not applicable to what I'm doing - the module where I'm
doing this is CMSCALL'd by a client application, so it's not linked in,
and I need to maintain backward compatibility, so it needs to stay that
way. 

Good idea, though.

Mark Gillis
Senior Software Engineer
Tel: +61 2 9429 2337
Fax: +61 2 9429 2394
[EMAIL PROTECTED]

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Tuesday, 10 July 2007 10:59 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How to determine if running as a multitasking CMS app

On Tuesday, 07/10/2007 at 10:16ZE10, "Gillis, Mark" <[EMAIL PROTECTED]>

wrote:
> In case anyone?s interested, I raised this with IBM. Their response
was 
that 
> testing NUCMTDSP wouldn?t work, the only way possible being to run the

CMS 
> control blocks. Unfortunately, these control blocks have the note?This

> information is NOT intended to be used as Programming Interfaces of 
z/VM?
> 
> ? which makes me a little uneasy about doing it this way. I guess it?s

all 
> there is, though.

I have some assembler code that can run with C or Pascal (called prior
to 
entering the "real" module).  I put in a WXTRN for CEESTART and VSPASCAL

in order to figure out whether it is running in an LE environment or
not. 
Could you put in a WXTRN for VMSTART?   If the adcon is non-zero, then 
VMSTART was linked.

Alan Altmark
z/VM Development
IBM Endicott

Re: How to determine if running as a multitasking CMS app

[Gillis, Mark]

In case anyone's interested, I raised this with IBM. Their response was
that testing NUCMTDSP wouldn't work, the only way possible being to run
the CMS control blocks. Unfortunately, these control blocks have the
note "This information is NOT intended to be used as Programming
Interfaces of z/VM"

... which makes me a little uneasy about doing it this way. I guess it's
all there is, though.



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Gillis, Mark
Sent: Friday, 29 June 2007 11:07 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: How to determine if running as a multitasking CMS app

 

I need to determine if my code is being called by a multitasking CMS
program (i.e., with entrypoint VMSTART) or not. It seems that it is
valid to issue almost any multitasking CMS call from a program that
hasn't been linked as a multitasking CMS application, except for
ThreadCreate and EventTrap, so at worst I could resort to issuing a
ThreadCreate and check the results, but this seems to be a pretty
expensive way to do it. I've noticed that the flag NUCMTDSP in the NUCON
seems to be set when a multitasking CMS app is active.

 

Does anyone know if there's a proper way to do this?

How to determine if running as a multitasking CMS app

[Gillis, Mark]

I need to determine if my code is being called by a multitasking CMS
program (i.e., with entrypoint VMSTART) or not. It seems that it is
valid to issue almost any multitasking CMS call from a program that
hasn't been linked as a multitasking CMS application, except for
ThreadCreate and EventTrap, so at worst I could resort to issuing a
ThreadCreate and check the results, but this seems to be a pretty
expensive way to do it. I've noticed that the flag NUCMTDSP in the NUCON
seems to be set when a multitasking CMS app is active.

 

Does anyone know if there's a proper way to do this?

Cleaning up pthreads in CMS

[Gillis, Mark]

I'm porting a z/OS application to CMS that uses multiple pthreads within
an LE enclave. It successfully uses the RESMGR macro to clean up after a
pthread ABENDs (on the basis that a pthread is a task).

 

RESMGR doesn't exist in CMS, so I was wondering if someone can tell me
if it's possible to do something similar in CMS, i.e., catch an ABEND
(e.g., program check) from a pthread, perform cleanup on its behalf and
allow the rest of the LE enclave to continue? I've looked at what's
available in the CMS Multitasking API (which I believe underlies CMS's
Open Extension pthreads), but I'm not sure if this is the best way to do
this in a pthread-compatible way.

Re: TCPNJE

[Gillis, Mark]

My RSCS definitions for our TCPNJE link (which works) are as follows:

LINKDEFINE linkname AST TYPE TCPNJE NODE nodename QUEUE SIZE
RETRY

PARM   linkname ITO=100 HOST=nnn.nnn.nnn.nnn

 

I can't provide our JES2 definition, since it was been made dynamically
by our z/OS people and won't be put into a parameter file until after
our DR test a few weeks from now.

Hope this helps.

 

Regards,

Mark Gillis.



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Wednesday, 23 May 2007 8:29 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: TCPNJE

 

Is there anyone who has an operating TCPNJE link between VM and z/OS? If
so, would you be willing to share your link definitions/parms (both
sides of the link would be nice) or otherwise disclose your secrets?  I
am at wit's end, getting socket errors (timeout variety) in the middle
of files. If they happen on stream 1, it freezes the link. My current
definition is:

LINKDEF MVS1   TYPE TCPNJE AST RETRY   

PARM MVS1 HOST=nn.nn.nn.nn KEEPALIV=NO STREAMS=4 BUFF=8192

This definition is the one that kept the link up the longest. It took a
socket error on stream 2 and kept on chugging until it subsequently had
the failure on stream 1. 

I suppose that the JES definition could be involved in this. Our JES
person tells me that he let everything default. I do not know what the
defaults for JES are, and he wasn't very forthcoming with information.

Regards,
Richard Schuh 

Re: z/VM usability

[Gillis, Mark]

Since IBM announced the demise of VSE/VSAM for VM I've been toying with
the idea of writing a VSAM substitute (at least one good enough for our
GCS-based products that rely on VSAM). I was thinking it would be based
around the *BLOCKIO IUCV service.

Unfortunately, the 1 piece of infrastructure that CMS has that is
missing in GCS is the SUBSYS operand on the FILEDEF command, to allow a
VSAM emulator to get control.

Given that IBM will never bring back VSE/VSAM for VM, what are the
chances of this being provided (allowing exits to get control at OPEN
time, etc) to at least allow vendors to do something else?

Mark Gillis
Senior Software Engineer
Tel: +61 2 9429 2337
Fax: +61 2 9429 2394
[EMAIL PROTECTED]
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Friday, 4 May 2007 2:31 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: z/VM usability

On Thursday, 05/03/2007 at 11:35 AST, "Edward M. Martin" 
<[EMAIL PROTECTED]> wrote:
> But the "If it ain't broke, don't fix it."  was caused by IBM not
> supporting a product that is supported by the other IBM Operating
> systems.
> 
> IBM is basically breaking a working system. (IMHO)
> 
> And I am working on away to get off the VM/VSAM part, and it looks
like
> it will be a NON-IBM solution.  But I am still looking.

By "business as usual", I mean that IBM continually withdraws products 
from the marketplace, even some that people are using.  There are still 
people using VM/ESA V2. 

It was nearly two years ago (June 2005) that we announced that you would

no longer be able to order VM/VSAM effective September 30, 2005.  In 
August of the same year we announced that VM/VSAM would end service 
February 28, 2007.  Standard meaning: "Don't deploy new applications
that 
depend on VM/VSAM and begin working on a migration or risk mitigation
plan 
for applications you already have."  It's true that if there is no 
replacement product from IBM, and no 3rd-party substitute, then, yes,
the 
application is eventually re-hosted or discontinued completely.  And 
sometimes on a non-IBM, non-Linux platform.  IBM makes the decisions it 
makes and has to live with the consequences.

I'm also sensitive to the fact that those decisions can also affect 
someone's livlihood (inside IBM and out).  I don't blame anyone for
being 
upset, if that's the case.

Don't get me wrong, I wish VM/VSAM was still around, but it isn't, so 
you're doing the right thing, triggering an application review.  If you 
choose that the risk of being unsupported is greater than the benefit
your 
company derives from the application, then it is time for a change.

Finally, to the best of my knowledge, we have done nothing to "break" a 
working system.  If you find a defect in CMS that causes VSAM to break, 
and you have a VM support contract, we will fix it.  If you find a
defect 
in VSAM itself, no such luck unless you have an extended VSAM support 
contract.

Alan Altmark
z/VM Development
IBM Endicott

Re: ISPF and ISPF/PDF

[Gillis, Mark]

'ISPF file tailoring' is used for JCL generation in MVS - a 'skeleton'
JCL file is read, variable substitution takes place and then written
out. This is obviously a gross simplification of what it's used for. 

Mark Gillis
Senior Software Engineer
Tel: +61 2 9429 2337
Fax: +61 2 9429 2394
[EMAIL PROTECTED]

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Rich Smrcina
Sent: Wednesday, 17 January 2007 12:53 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ISPF and ISPF/PDF

I've never used ISPF, so I'm not sure what 'ISPF file tailoring' is, but

if it's something like entering parameters or values of some sort, I 
expect it could be duplicated to a certain extent.

Ed Zell wrote:
>> Depending upon what those 'cool utilities' are they may be able to be

>> converted to REXX and Xedit (for full screen dialog support).  There
> are 
>> also some other full screen dialog packages available, there was a 
>> thread about that topic here some time ago.
> 
> I have done that with a few apps, but we generate a ton of VSE JCL
using
> ISPF file tailoring.  I've never really found a way to get away from
it
> that is as simple and easy as file tailoring.  Any thoughts there?
> 
> 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.
> 

-- 
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: RES: VSE/VSAM for VM

[Gillis, Mark]

I think the mechanism for redirecting VSAM requests to DB2 VM was the
SUBSYS operand on the FILEDEF command that allowed a VSAM emulator to be
provided. I was hoping that this might provide a mechanism for us to do
something for NetMaster in VM, but unfortunately the facility was never
provided for GCS.

Mark.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Tuesday, 20 June 2006 11:22 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RES: VSE/VSAM for VM

On Tuesday, 06/20/2006 at 11:02 CET, "Jones, Ian H"
<[EMAIL PROTECTED]> 
wrote:
> Thank you Mark. This is directed at IBM -
> 
> Auditors do not care tuppence whether a product is 'stable'. If a
> product is used to support a production workload they expect it to be
> *supported*. An auditor's reaction will vary from an 'observation'
that
> an unsupported product is being used, to a recommendation that use of
> the product be discontinued. In a business environment where auditors'
> reports can cause a company to lose a contract, no one can afford to
use
> unsupported software.

I'm not sure what you're directing to IBM, Ian.  In accordance with the 
terms of the license agreement, we've given the necessary notice about
end 
of service, as we promised.  We've even gone back and reevaluated the 
decision.

I would agree with you that you should should follow your company's 
policies with regard to the software you use.  (BTW, auditors determine 
whether you comply with the policy; they don't create policy unless
there 
is some area not covered by policy or the policy is too vague.)

That does yield some choices (not everyone can choose from all of
these):
- Reengineer the programs on Power or Intel architecture
- Move the programs to z/OS or z/VSE
- Reengineer the programs to not use VSAM
- Obtain an extended support contract (contact your IBM Business Partner

or IBM rep)
- Change the policy to allow unsupported "stable" software
- Obtain an approved deviation from policy based on cost/risk
- In the dim mists of eons past, there was a mechanism that allowed CMS 
VSAM requests to be redirected to DB2 for VM & VSE (added as an SPE to 
VM/SP 3, if memory still serves).  I have no idea if that option is
still 
available.

All good things must come to an end, and change is the inevitable
result. 
In the real world, change costs money.  So the question is: Which option

(a) costs least, and (b) meets your company's requirements?

Alan Altmark
z/VM Development
IBM Endicott

Re: RES: VSE/VSAM for VM

[Gillis, Mark]

I received the following reply from Gerhard Zierl from IBM in April:

"...The news is that after assessing the situation the product stays
withdrawn from market. Toady VM/VSAM is used in very stable environments
by customers who have the product already licensed and installed for a
long time, IBM hasn't seen new customers to this product for a long
time. Therefore we do not see any problem associated with the withdrawal
from market..  z/VM 5.2 customers can use their old VSAM distribution
tape which they have received with their current version of z/VM.

Same is true for end of service. The last APAR was 2001 (more than 5
years). Before that there was one (new function) APAR in 1999 and 2
defect APARs in 1996. VM/VSAM is a very stable product. In addion
VM/VSAM is used by customers in mature and stable environments, no new
applications, no major changes, etc... I would assume the same applies
to your product.  So the risk of encountering a severe problem is
extremely low.
In case customers decide they have a critical need to have service
beyond the EOS-date, then there is in general an option to ask IBM for a
charged service extension agreement."

Mark.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Shimon Lebowitz
Sent: Tuesday, 20 June 2006 6:48 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RES: VSE/VSAM for VM

> IBM MUST give an option. There are some products from IBM that uses
VSAM/VM
> and how we should handle this? Netview Access is one of them. Change
it
> means to re-think all our mainframe access. 

My list of current uses of VSAM also included Netview.
The response of the product owner was "Netview for
VM has already been discontinued, so that doesn't count".

I just looked at the VM LP Matrix for 5.2 (Dec. 16, 2005),
http://www.vm.ibm.com/techinfo/lpmigr/vml12165.html
and it says both apparently contradictory statements:

- Removed End of Service from Netview V2 for VM/ESA V2.3.0. This 
product is still supported. 
- Added Discontinuance of Service date for VSE/VSAM (5686-081), 
effective February 28, 2007.

In any case we have LOTS more using VSAM than Netview.

Shimon