Re: How Many OMEGAMON ICATs Can Run At The Same Time?.

[Stephen Hall]

___

Note: This e-mail is subject to the disclaimer contained at the bottom of this 
message.
___


>Date:Fri, 19 Nov 2010 08:59:39 +0100
>From:"Vernooij, CP - SPLXM" 
>Subject: Re: How Many OMEGAMON ICATs Can Run At The Same Time?.
>
>"George Henke"  wrote in message
>news:...
>> Is anyone able to run more than one ICAT (formerly CICAT) at the same
>>time,
>> eg ICAT for CICS, ICAT for DB2, etc.
>>
>> --
> George Henke
>
>You mean: several users configuring Omegamon components simultaneously?
>I think they will collide regularly, because they are configuring the same RTE.
>The only way should be to separate them right from the beginning to their own 
>RTEs and datasets.
>
>Kees.

Yes, that would be the only way to do it, but not what I would recommend, as it 
would lead to a lot of duplication, 
as well as increased overhead in applying maintenance etc.

My suggestion would be to nominate an ICAT / Omegamon Installation owner who 
manages the installation and
configuration on behalf of all teams. Depending on the number of LPARS / RTES 
you have I would also recommend
looking at the batch ICAT Process, or even the new PARMLIB installation 
process. I have 9 LPARS configured
with most Omegamon components and use the batch process, I can regenerate a new 
RTE in about 30 minutes depending
on the number of DB2 and IMS regions in the RTE.


Thanks & Regards,
–
Stephen Hall
Mainframe Platform Manager
INSURANCE AUSTRALIA GROUP (IAG)
___

The information transmitted in this message and its attachments (if any) is 
intended 
only for the person or entity to which it is addressed.
The message may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of, or taking of any action in 
reliance 
upon this information, by persons or entities other than the intended recipient 
is 
prohibited.

If you have received this in error, please contact the sender and delete this 
e-mail 
and associated material from any computer.

The intended recipient of this e-mail may only use, reproduce, disclose or 
distribute 
the information contained in this e-mail and any attached files, with the 
permission 
of the sender.

This message has been scanned for viruses.
___

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS messages.. totally true... almost totally useless

[Edward Jaffe]

On 11/19/2010 7:47 PM, W. Kevin Kelley wrote:

If you've given up, I can't help.


Yeah. I wish I was that powerful. ;-)


Over the years, I have helped a number of customers get changes made to
messages (primarily for automation purposes). This was done by the customer
opening a formal complaint.


According to the SHARE requirements data base, this requirement was submitted 
nearly 18 years ago in March 1993. See what you can do...


Requirement#:SSSHARE012091
Status:Waiting for Response
Priority:3.4
Vote Distribution:+5=7 +4=5 +3=9 +2=5 +1=1 abstain=1 Priority=3.4
Vote History:1993-03-01 (3.0) N/A
Submitted:1993-03-01
Revised:2010-11-17 11:08
Title:TSO/E: Message IKJ705 Too Vague
Description:The TSO/E message IKJ705 states that there is an invalid 
command in
SYS1.PARMLIB(IKJTSOxx). TSO/E should tell the systems programmer which command
is invalid.
Benefit:I cannot tell which command in my IKJTSOxx is invalid: all commands 
seem
correct to me. Today, the only way to resolve this problem, is by eliminating
commands one-by-one and re-starting TSO to discover which command is invalid.
Time Limit:N/A
Solution:Left to the developers.
Classification:T
Product
Name:TSO/E
Product
Code:5665-285
Author
Name:REDACTED
Company:REDACTED
Address 1:REDACTED
Source:SHARE
Div.:S
Program:MVS
Project:MVSE
Sub
Project:TSO
UG-Status:A
CATEGORY:zSeries Software
SUBCAT:z/OS
Entity:TSO
IBM Rep:REDACTED
Domain:IBMUS

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS messages.. totally true... almost totally useless

[Robert A. Rosenberg]

At 02:07 + on 11/20/2010, Ted MacNEIL wrote about Re: zOS 
messages.. totally true... almost totally useless:



 >May I suggest that you open a formal problem with IBM for each of these?

With all due respect.
That's akin to cleaning the Agean Stables.
-
Ted MacNEIL
eamacn...@yahoo.ca


Hercules did it - He just needed to divert a river to do it. Luckily 
he did not need to first file an Environmental Impact Statement or 
deal with the deal with the Department of the Environment (or end up 
getting fined for pollution).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Don Williams]

I learned Wylbur first. I still miss it.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Eric Bielefeld
> Sent: Friday, November 19, 2010 10:01 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: REXX "address" environments
> 
> I've always liked ISPF edit much more than XEDIT.  You said PDF edit -
> I'm
> not sure if you mean something different than ISPF edit.
> 
> My theory is that what you learn to use first is usually what you like
> best.
> I first learned SPF edit back around 1979.  I was the VM systems
> programmer
> for 5 or 6 years, but I never liked XEDIT as well.  I remember several
> of
> the programmers and analysts who used XEDIT long before we installed
> MVS
> liked XEDIT much better than ISPF.
> 
> Eric Bielefeld
> Sr. Systems Programmer
> IBM Global Services Division
> Dubuque, Iowa
> 
> - Original Message - >
> > Don't I need XEDIT first? Is there an XEDIT for z/OS? XEDIT beats the
> > stuffing out of PDF edit as far as I'm concerned. Although I would be
> > mollified if PDF edit would enhance the FIND, RFIND, CHANGE, and
> RCHANGE
> > to include POSIX regular expressions.
> >
> >>
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS messages.. totally true... almost totally useless

[W. Kevin Kelley]

On Fri, 19 Nov 2010 18:29:26 -0800, Edward Jaffe 
 wrote:

>
>LOL! This has been going on so long that there is even a SHARE requirement 
from
>the 1980s against a similar message produced by this very same "brain dead"
>IKJTSOxx parser.
>
>We came across this a few months ago during a meeting of the SHARE MVS 
Core
>Technologies Project Requirements Committee. We were all pretty astonished.
>
>I guess IBM refused to take an APAR so the customer was forced to use the
>requirements process. A lot of good it did him...
>
>--

Ed,

If you've given up, I can't help.

Over the years, I have helped a number of customers get changes made to 
messages (primarily for automation purposes). This was done by the customer 
opening a formal complaint. 

Saying a message is useless is a non-starter; stating that it lacks sufficient 
information to identify the problem it is reporting and that it causes a great 
deal of manual effort to be expended by precious system programming 
resource is a much better way to describe the problem that the message 
causes. Fixing a problem like this is going to be a business decision; you need 
to describe the problem the message is causing in terms of the business 
impact that it has on a customer. Lost productivity, lost time, etc.

W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: reusing a TCB?

[Sam Siegel]

On Fri, Nov 19, 2010 at 7:03 PM, Ken Moore  wrote:

> I must be reading the wrong books or something.  I'm trying to find a way
> to
> ATTACH a TCB and then reuse that TCB several times (to run the same
> program) and then detach it when I'm done with it.  I need to keep it
> around
> because I'm doing CICS EXCI calls under the attached TCB but I lose the
> EXCI
> pipe and user environment if I can't reuse the TCB.  I'm feeling a bit
> retarded
> at this point.  There has to be a way, as CICS uses pooled TCBs all the
> time.
>
>
Ken ... you may want to consider an alternative way to accomplish what I
think you are looking for.  Consider using some type of synchronization
mechanism (ECB, etc.) and a control flag passes as one of the parms to your
attached program.

When the attached program completes the work, it WAITs on the ECB. Your main
program POSTs the ECB to run the attached program again.  This can be
repeated as often as needed by your main program.

Just after the WAIT in the attached program, place a small amount of code to
check the control flag.  The control flags (set by the main program) tells
the attached program to: 1) perform 'business' function again and WAIT on
the ECB; 2) exit.

You can of course add more control functions as needed to meet your
requirements.  For example, the attached program can be a shell of a driver
that LINKs other sub-programs based on the function code, etc.

With logic similar to this, you can keep the attached program and the
related EXCI pipe, etc. around as long as required.

Cheers,
Sam


> Ken Moore
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

IBM messages

[john gilmore]

I do not myself believe that IBM messages are almost totally useless, and I 
doubt that many people do.  They vary in quality from component to component; 
some of them are misleading to some readers; and some of them are 'radically' 
uninformative.
 
Those that are egregiously incorrect are usually corrected when their 
deficiencies are brought to IBM's attention, but thery are not common.
 
There are real problems, but wholesale condemnation is unlikely to be helpful 
in getting these problems addressed.  It is to easy to shrug off as uninformed.
 
To whom at what level of experience are they directed?  Are they now viewed as 
free-standing?   Or are they still viewed as vehicles for directing attention 
to a manual where fuller information is provided?  What are the informal 
constraints on, expectations about, their lengths within IBM?  (The IBM HLASM 
now permits macro MNOTEs to be as much as 1024 bytes in length, but those 
generated by IBM macros continue to be much too cryptic: they make almost no 
use of text that is more than two or three lines in length.)
 
About Agean stables I will limit myself to noting that the 5th labo[u]r of 
Hercules/Herakles was the cleaning of the enormous [cattle] stables of King 
Augeas,. hence the Augean stables in a single day.  Herakles succeeded in doing 
so by diverting two streams through them.  
 
Apposite classical allusions have their uses, mais le bon Dieu est dans le 
détail.

John Gilmore Ashland, MA 01721-1817 USA


  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

reusing a TCB?

[Ken Moore]

I must be reading the wrong books or something.  I'm trying to find a way to 
ATTACH a TCB and then reuse that TCB several times (to run the same 
program) and then detach it when I'm done with it.  I need to keep it around 
because I'm doing CICS EXCI calls under the attached TCB but I lose the EXCI 
pipe and user environment if I can't reuse the TCB.  I'm feeling a bit retarded 
at this point.  There has to be a way, as CICS uses pooled TCBs all the time. 

Ken Moore

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Eric Bielefeld]

I've always liked ISPF edit much more than XEDIT.  You said PDF edit - I'm 
not sure if you mean something different than ISPF edit.


My theory is that what you learn to use first is usually what you like best. 
I first learned SPF edit back around 1979.  I was the VM systems programmer 
for 5 or 6 years, but I never liked XEDIT as well.  I remember several of 
the programmers and analysts who used XEDIT long before we installed MVS 
liked XEDIT much better than ISPF.


Eric Bielefeld
Sr. Systems Programmer
IBM Global Services Division
Dubuque, Iowa

- Original Message - >

Don't I need XEDIT first? Is there an XEDIT for z/OS? XEDIT beats the
stuffing out of PDF edit as far as I'm concerned. Although I would be
mollified if PDF edit would enhance the FIND, RFIND, CHANGE, and RCHANGE
to include POSIX regular expressions.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS messages.. totally true... almost totally useless

[Edward Jaffe]

On 11/19/2010 5:14 PM, W. Kevin Kelley wrote:

On Fri, 19 Nov 2010 16:19:00 -0800, John Mattson
  wrote:


Continuing to voice my annoyance with zOS messages.

May I suggest that you open a formal problem with IBM for each of these?


LOL! This has been going on so long that there is even a SHARE requirement from 
the 1980s against a similar message produced by this very same "brain dead" 
IKJTSOxx parser.


IKJ705I A COMMAND FOUND IN TSO PARMLIB MEMBER IKJTSOxx IS NOT VALID.

Which command? Where?

We came across this a few months ago during a meeting of the SHARE MVS Core 
Technologies Project Requirements Committee. We were all pretty astonished.


I guess IBM refused to take an APAR so the customer was forced to use the 
requirements process. A lot of good it did him...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS messages.. totally true... almost totally useless

[Ted MacNEIL]

>May I suggest that you open a formal problem with IBM for each of these? 

With all due respect.
That's akin to cleaning the Agean Stables.
-
Ted MacNEIL
eamacn...@yahoo.ca

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Edward Jaffe]

On 11/19/2010 10:57 AM, McKown, John wrote:

I know that I'm missing something, but that seems to be addressed here:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/14.14


These are instructions for updating IBM's TSO/E REXX environment parameters 
modules. The difficulty in going down this road is identifying every IRXINIT 
issuer under which your HCE might execute and then updating each and every 
associated EPM to include an entry for your HCE. If the EPMs are not delivered 
in source form, you will need to work with the developers.


It's pretty easy for ISPEXEC and ISREDIT to be in ISPF's EPM since they are 
delivered by a single component. And, if your HCE is tied to ISPF, you can do 
the same thing.


But, IRXINIT can be issued by *any* program. For example, our multi-user Phoenix 
TP Monitor Environment does this and it has its own EPM. I suspect Netview has 
its own, various IBM and ISV automation products have their own, and so forth. 
Basically, *any* environment in which REXX EXECs might run will likely need to 
be inspected and possibly customized.


I was envisioning something a bit more automatic and global in scope...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS messages.. totally true... almost totally useless

[W. Kevin Kelley]

On Fri, 19 Nov 2010 16:19:00 -0800, John Mattson 
 wrote:

>Continuing to voice my annoyance with zOS messages.  

May I suggest that you open a formal problem with IBM for each of these? 

W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: zOS messages.. totally true... almost totally useless

[zMan]

Indeed. This is almost as bad in z/OS as in UNIX.

Try z/VM, it has REAL error messages...

On Fri, Nov 19, 2010 at 7:19 PM, John Mattson  wrote:
> Case #1
>        Continuing to voice my annoyance with zOS messages.  This popped
> up, apparantly has been that way for some time. Big help, there are 166
> lines in my IKJTSO00. If it can identify duplicate, it can tell me what it
> is.
> IKJ710I DUPLICATE PARAMETER FOUND IN MEMBER IKJTSO00 OF DATASET
> SYS1.PARMLIB.V108
>        So I actually manage to find the duplicate parm by sorting a copy
> of the parmlib, try a fix and I get this again probably true, but
> could they tell me which one?
> IKJ703I TSO PARMLIB MEMBER IKJTSO0$ CONTAINS AN INCORRECT KEYWORD.
>
> Case#2
>  LOGINDY(              +
>  (TS0312,SYSALLDA)     +
>  (MTEST1,SYSALLDA)     +
>  (TS0313,SYSALLDA)     +
>  (TS0312,SYSALLDA)     +
>  (MPROD1,SYSALLDA)     +
>  (TS0312,SYSALLDA)     +
>  (TS0311,SYSALLDA)     +
>  )                     +
> Doing DFDSS ADRDSSU.  What message does this give?
> ADR026E (001)-SETUP(01), TS0312 IS INVALID AS OBJECT DDNAME
> Horse-feathers. Nothing invalid about TS0312, it is a DUPLICATE.  So
> what???  At least properly identify the problem
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Paul Gilmartin]

On Fri, 19 Nov 2010 16:18:58 -0800, Edward Jaffe wrote:
>
>Sadly, it appears that SYSCALLS initializes some important REXX variables. If
>you don't call it, they never get initialized. :-(
>
Even worse, if one relies on PROCEDURE EXPOSE to isolate
variable scopes, one must put SYSCALLS('ON') in many subroutines
or EXPOSE necessary symbols at each level in the hierarchy.

(Wasn't it you who, several years ago, argued for balancing
each SYSCALLS('ON') with a matching SYSCALLS('OFF')?  Doesn't
quite work.  You'd need SYSCALLS(PUSH) and SYSCALLS(POP).
Or have SYSCALLS respect procedure scopes as ADDRESS, NUMERIC,
et. al do.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

zOS messages.. totally true... almost totally useless

[John Mattson]

Case #1 
Continuing to voice my annoyance with zOS messages.  This popped 
up, apparantly has been that way for some time. Big help, there are 166 
lines in my IKJTSO00. If it can identify duplicate, it can tell me what it 
is. 
IKJ710I DUPLICATE PARAMETER FOUND IN MEMBER IKJTSO00 OF DATASET 
SYS1.PARMLIB.V108 
So I actually manage to find the duplicate parm by sorting a copy 
of the parmlib, try a fix and I get this again probably true, but 
could they tell me which one? 
IKJ703I TSO PARMLIB MEMBER IKJTSO0$ CONTAINS AN INCORRECT KEYWORD.  

Case#2 
  LOGINDY(  + 
  (TS0312,SYSALLDA) + 
  (MTEST1,SYSALLDA) + 
  (TS0313,SYSALLDA) + 
  (TS0312,SYSALLDA) + 
  (MPROD1,SYSALLDA) + 
  (TS0312,SYSALLDA) + 
  (TS0311,SYSALLDA) + 
  ) + 
Doing DFDSS ADRDSSU.  What message does this give? 
ADR026E (001)-SETUP(01), TS0312 IS INVALID AS OBJECT DDNAME 
Horse-feathers. Nothing invalid about TS0312, it is a DUPLICATE.  So 
what???  At least properly identify the problem 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Edward Jaffe]

On 11/19/2010 3:41 PM, Mark Zelden wrote:

Based on a quick test of SLEEP from TSO without  rc=syscalls('ON'), it looks
like it isn't required.   Maybe since z/OS 1.8.


Sadly, it appears that SYSCALLS initializes some important REXX variables. If 
you don't call it, they never get initialized. :-(


For example (first one works, second one fails):

 3 *-* message = 'Hello World!'
>L>   "Hello World!"
 4 *-* rc = syscalls('ON')
>L>   "ON"
>F>   "0"
 5 *-* address SYSCALL 'open /dev/console' O_WRONLY 666
>L>   "open /dev/console"
>V>   "1"
>O>   "open /dev/console 1"
>L>   "666"
>O>   "open /dev/console 1 666"
 6 *-* consolefd = RETVAL
>V>   "1"
 7 *-* address SYSCALL 'write' consolefd 'message'
>L>   "write"
>V>   "1"
>O>   "write 1"
>L>   "message"
>O>   "write 1 message"
***

 3 *-* message = 'Hello World!'
>L>   "Hello World!"
 4 *-* /* rc = syscalls('ON') */
 5 *-* address SYSCALL 'open /dev/console' O_WRONLY 666
>L>   "open /dev/console"
>L>   "O_WRONLY"
>O>   "open /dev/console O_WRONLY"
>L>   "666"
>O>   "open /dev/console O_WRONLY 666"
   +++ RC(-22) +++
 6 *-* consolefd = RETVAL
>L>   "RETVAL"
 7 *-* address SYSCALL 'write' consolefd 'message'
>L>   "write"
>V>   "RETVAL"
>O>   "write RETVAL"
>L>   "message"
>O>   "write RETVAL message"
   +++ RC(-21) +++
***

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Mark Zelden]

On Fri, 19 Nov 2010 17:52:18 -0600, Paul Gilmartin  wrote:

>On Fri, 19 Nov 2010 17:41:49 -0600, Mark Zelden wrote:
>>
>>Based on a quick test of SLEEP from TSO without  rc=syscalls('ON'), it looks
>>like it isn't required.   Maybe since z/OS 1.8.
>>
>I assume you mean "sleep 0".  Fortunately that doesn't mean
>"sleep forever", as some languages quirkily treat null constructs.
>

I ran this test.  I've always included rc=syscalls('on') in the past.

/* REXX */ 
arg sleep_time 
if sleep_time = '' then sleep_time = 10
say 'Sleeping for' sleep_time 'seconds.'   
address syscall "sleep" sleep_time 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Paul Gilmartin]

On Fri, 19 Nov 2010 17:41:49 -0600, Mark Zelden wrote:
>
>Based on a quick test of SLEEP from TSO without  rc=syscalls('ON'), it looks
>like it isn't required.   Maybe since z/OS 1.8.
>
I assume you mean "sleep 0".  Fortunately that doesn't mean
"sleep forever", as some languages quirkily treat null constructs.

Every language needs a couple things:

o A no-op (IEFBR14, /bin/true, whatever)

o A lexical convention for comments.

> --   ---  --
>$P1  MG06358  HTE7730 050930   WSY1:  Added the SYSCALL
>   host environment to the SUBCOM table in support
>   of USS REXX. Added the EZAFTPKR function package
>   to the system package tables in support of the
>   FTPAPI function.
>
Yaaay!.  But only half; see my previous ply.  Now what we
need is "address SH".  I'd gladly accept the return of
SYSCALLS('ON') (I never even missed it) if it enabled SH.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Ted MacNEIL]

>The bottom line is that you pay for MSUs both in hardware and software
costs. 
>That's pretty meaningful!

Yes, it is, but it's over feet of clay. As I said in a previous post, it's 
scary 
that many millions are spent on meaningless numbers.
the issue is ther fact that the numbers mean next to nothing, but we still pay 
for abritary ratings.


 Ted MacNEIL
eamacn...@yahoo.ca


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Mark Zelden]

On Fri, 19 Nov 2010 15:17:00 -0800, Edward Jaffe
 wrote:

>On 11/19/2010 10:57 AM, McKown, John wrote:
>> I know that I'm missing something, but that seems to be addressed here:
>>
>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/14.14
>
>Based on the following table entry, I'm not sure why rc=syscalls('ON') is
required:
>
>SUBCOMT11_ENTRY EQU */* Set up 11th SUBCOMTB entry
>  @P1A*/
>SUBCOMT11_NAME DC CL8'SYSCALL '  /* Subcom env name  @P1A*/
>SUBCOMT11_ROUTINE DC CL8'BPXWREXX'   /* routine handling the @P1A*/
>*/* subcommand env. is   @P1A*/
>*/* BPXWREXX @P1A*/
>SUBCOMT11_TOKEN DC CL16'' /* Blank Subcom Token  @P1A*/
>
>--
>Edward E Jaffe


Based on a quick test of SLEEP from TSO without  rc=syscalls('ON'), it looks
like it isn't required.   Maybe since z/OS 1.8.

 --   ---  --   
$P1  MG06358  HTE7730 050930   WSY1:  Added the SYSCALL 
   host environment to the SUBCOM table in support  
   of USS REXX. Added the EZAFTPKR function package 
   to the system package tables in support of the   
   FTPAPI function. 


--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Paul Gilmartin]

On Fri, 19 Nov 2010 15:17:00 -0800, Edward Jaffe wrote:
>
>Based on the following table entry, I'm not sure why rc=syscalls('ON') is 
>required:
>
>SUBCOMT11_ENTRY EQU */* Set up 11th SUBCOMTB entry
>  @P1A*/
>SUBCOMT11_NAME DC CL8'SYSCALL '  /* Subcom env name  @P1A*/
>SUBCOMT11_ROUTINE DC CL8'BPXWREXX'   /* routine handling the @P1A*/
>*/* subcommand env. is   @P1A*/
>*/* BPXWREXX @P1A*/
>SUBCOMT11_TOKEN DC CL16'' /* Blank Subcom Token  @P1A*/
>
Ummm...  Example:

  1 *-*  say O_RDONLY address()
>>>"O_RDONLY TSO"
 O_RDONLY TSO
*-*  address syscall close 9
>>>"CLOSE 9"
*-*  say O_RDONLY
>>>"O_RDONLY"
 O_RDONLY
*-*  RC=syscalls('ON')
>>>"0"
*-*  say O_RDONLY
>>>"2"
 2
 ***

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Edward Jaffe]

On 11/19/2010 10:57 AM, McKown, John wrote:

I know that I'm missing something, but that seems to be addressed here:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/14.14


Based on the following table entry, I'm not sure why rc=syscalls('ON') is 
required:

SUBCOMT11_ENTRY EQU */* Set up 11th SUBCOMTB entry
 @P1A*/
SUBCOMT11_NAME DC CL8'SYSCALL '  /* Subcom env name  @P1A*/
SUBCOMT11_ROUTINE DC CL8'BPXWREXX'   /* routine handling the @P1A*/
*/* subcommand env. is   @P1A*/
*/* BPXWREXX @P1A*/
SUBCOMT11_TOKEN DC CL16'' /* Blank Subcom Token  @P1A*/

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[John McKown]

On Fri, 2010-11-19 at 16:01 -0500, Shmuel Metz (Seymour J.) wrote:
> In ,
> on 11/18/2010
>at 07:43 AM, "McKown, John"  said:
> 
> >There are a number of environments for REXX which are accessed via
> >the "ADDRESS" command. Eg: ADDRESS TSO ; ADDRESS SDSF; ADDRESS
> >SYSCALL; ADDRESS ISPEXEC; ADDRESS ISREDIT. So, I my mind was
> >wandering around without a keeper the other day and started thinking
> >about what other environments might be nice to have available.
> 
> address XEDIT

Don't I need XEDIT first? Is there an XEDIT for z/OS? XEDIT beats the
stuffing out of PDF edit as far as I'm concerned. Although I would be
mollified if PDF edit would enhance the FIND, RFIND, CHANGE, and RCHANGE
to include POSIX regular expressions.

> 
> >The first one was one I can really get into: ADDRESS FTP.
> 
> Yes!
>  

If people here think that the REXX ftpapi mentioned by Gil is
insufficient, then maybe I will look at this. It's more like BPXWUNIX
calls than ADDRESS TSO, but it looked fairly nice to me. What I really
need is for the normal FTP client to do scripting. Something akin to:

put somefile
if ftprc <> 250 then do; transfer failed
   exit 16
done /* or od or fi or ??? */


-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Ward, Mike S]

Maybe not if the 200 MSU machine is four processors at 50 msu's each.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Edward Jaffe
Sent: Friday, November 19, 2010 4:33 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SI and MI MIPS

On 11/19/2010 1:24 PM, Tom Marchant wrote:
> On Fri, 19 Nov 2010 20:38:12 +, Ted MacNEIL wrote:
>> The evaluation, as I said in another post, is at best a guess.
> In other words, there is no meaningful indicator of processor speed.
>
> In that case, to single out MIPS as meaningless is, in itself, a
> meaningless statement.

LOL! So true! :-D

I think it should be obvious that if a 100 MSU machine meets all SLAs,
then a 
200 MSU machine will exceed them. The "meaningless" part comes in only
when you 
try to split hairs--something performance gurus routinely do to try to
squeeze 
every ounce of performance out of a slightly undersized box.

The bottom line is that you pay for MSUs both in hardware and software
costs. 
That's pretty meaningful!

-- 
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to which they are addressed. If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your system. 
If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this
information is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Logging software alternatives

[Kirk Wolf]

I suspect that this log printer is similar to what IMS used to require,
which was considered important for purposes of operation and recovery.  (As
I recall it, IMS wouldn't even shut down properly unless it could write (and
get an ACK) that its final shutdown/checkpoint message was written to this
printer).

If this is the case, your current setup seems inadequate to me.  I don't
know ALCS (at all), but if this logging information is critical to its
operation, then I would see if there is a way (an exit?) that would allow
you to route to a z/OS logstream.


On Fri, Nov 19, 2010 at 3:23 PM, Dana Mitchell  wrote:

> On Fri, 19 Nov 2010 15:56:23 -0500, Tony Harminc 
> wrote:
>
> >Wow! How 1980s.
>
> Unfortunately yes...
>
> >Is it a requirement that the data end up on this PC?
>
> Yes, a network directory.  we could send the files there via other means
> but
> some users need to look at the current file real-time.
>
> >Now, um, this ALCS... Is this the "TPF under MVS" thing?
>
> Yes exactly
>
> >Does it not have its own printer exits and such where you could capture
> print
> >data and redirect it?
>
> We are looking into that also
>
>
> thanks
> Dana
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Paul Gilmartin]

On Fri, 19 Nov 2010 22:25:36 +, Schumacher, Otto wrote:

>I was not saying that IEFBR14 changed but that when run file allocation would 
>do an HDELETE.

I remain skeptical.  I believe it's neither IEFBR14 nor allocation,
but the initiator or reader/converter/interpreter which issues
HDELETE and never invokes allocation.  But I haven't inspected
allocation messages to verify.

>I also know that HSS does dataset migrations.

ITYM HSM.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Eric Bielefeld]

That's interesting, because I entered that off of a 1.9 system, which came out 
3 years ago.
--
Eric Bielefeld
Systems Programmer


 Mike Schwab  wrote: 
> >
> > 1BFF 07FE  
> >
> > 1B is Subtract register - FF is subtracting R15 from itself, giving 0 - the 
> > return code.  07 is Branch on Condition to the address in R14.
> >
> > --
> > Eric Bielefeld
> > Systems Programmer
> >
> 
> http://en.wikipedia.org/wiki/IEFBR14
> 
> They went back to that version last year.
> -- 
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FTP Named Pipes

[Kirk Wolf]

On Fri, Nov 19, 2010 at 4:26 PM, Paul Gilmartin wrote:

> (Will dovetail CO:z fromdsn/todsn move load modules/program
> objects?)
>
> Not currently.  We use the C library for dataset I/O, and load mods /
program objects require the binder's involvement.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Edward Jaffe]

On 11/19/2010 1:24 PM, Tom Marchant wrote:

On Fri, 19 Nov 2010 20:38:12 +, Ted MacNEIL wrote:

The evaluation, as I said in another post, is at best a guess.

In other words, there is no meaningful indicator of processor speed.

In that case, to single out MIPS as meaningless is, in itself, a
meaningless statement.


LOL! So true! :-D

I think it should be obvious that if a 100 MSU machine meets all SLAs, then a 
200 MSU machine will exceed them. The "meaningless" part comes in only when you 
try to split hairs--something performance gurus routinely do to try to squeeze 
every ounce of performance out of a slightly undersized box.


The bottom line is that you pay for MSUs both in hardware and software costs. 
That's pretty meaningful!


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Schumacher, Otto]

I was not saying that IEFBR14 changed but that when run file allocation would 
do an HDELETE. I also know that HSS does dataset migrations. I was just telling 
the person that allocation may be causing the issue and/or his region 
specification maybe to small. As I remember there was a problem related to 
invoking IEFBR14 with a region of 1k.  

Regards
Otto Schumacher
 
HP Enterprise Services
Infrastructure Specialist
Ahold Account
CICS & Capacity Technical Support
P.O. Box 6462
2000 Wade Hampton Blvd.
LC1-302
Greenville,  South Carolina, 29606
Cell: 864 569--5338
Tel: 864 987-1417
Fax: 864 987-4500
E-mail: otto.schumac...@hp.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

FTP Named Pipes

[Paul Gilmartin]

z/OS 1.12 introduces the ability of FTP to operate on named pipes.
Fairly unusual; most FTP implementations deal only with regular
files (but legacy data sets are hardly regular; consider all the
SITE and LOCSITE commands introduced to support them.)

So, in principle, one could initiate on host A a GET from host
X to a named pipe, and a PUT from that named pipe to host Y.

Can this be done concurrently, so the data need never occupy disk
space on host A?  Probably, with two z/OS Unix sessions; less
likely with TSO except by using two IDs to run two sessions at the
same time.

And, then, can one working only on host A stream a load module/
program object from host X to host Y in this fashion?

(Will dovetail CO:z fromdsn/todsn move load modules/program
objects?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Paul Gilmartin]

On Fri, 19 Nov 2010 16:14:32 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>As a nonstandard extension to
>>Rexx, it would also be nice to terminate a host interface,
>
>That wouldn't make a lot of sense, because it's the host that call
>REXX in the first place. What would it mean to cancel, e.g., address
>ISREDIT in the middle of an edit macro?
>
Is that much different from "address ISREDIT END" or "address
ISREDIT CANCEL", which I've seen (mis-)used in edit macros.
The effect is to return the session to the Edit member menu.

Or "address XEDIT COMMAND QUIT", for which the macro continues
executing but subsequent "address XEDIT" instructions get RC=6.

Or "address TSO LOGOFF" in an EXEC started under a Unix shell.
But in that case, TSO isn't the host; it's really more of a
coprocessor.  "address FTP" would need to be similar, as would
"address SFTP".  Each would need to initiate a connection to
be terminated by the QUIT command.

Note the dire warnings about issuing SYSCALLS('OFF') in an
EXEC running under the Unix shell.

>>Note that the z/OS Rexx implementation is somewhat non-standard as
>>is.
>
>Is the CMS version any closer to the ANSI standard than the TSO/E
>version?
>
Yes.  The CMS version implements the stream I/O instructions.
(I know those are MFC; are they actually ANSI?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Tom Marchant]

On Fri, 19 Nov 2010 20:38:12 +, Ted MacNEIL wrote:
>
>The evaluation, as I said in another post, is at best a guess.

In other words, there is no meaningful indicator of processor speed.

In that case, to single out MIPS as meaningless is, in itself, a 
meaningless statement.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Logging software alternatives

[Dana Mitchell]

On Fri, 19 Nov 2010 15:56:23 -0500, Tony Harminc  
wrote:

>Wow! How 1980s.

Unfortunately yes...

>Is it a requirement that the data end up on this PC?

Yes, a network directory.  we could send the files there via other means but 
some users need to look at the current file real-time.

>Now, um, this ALCS... Is this the "TPF under MVS" thing? 

Yes exactly

>Does it not have its own printer exits and such where you could capture print 
>data and redirect it?

We are looking into that also


thanks
Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Shmuel Metz (Seymour J.)]

In ,
on 11/18/2010
   at 07:43 AM, "McKown, John"  said:

>There are a number of environments for REXX which are accessed via
>the "ADDRESS" command. Eg: ADDRESS TSO ; ADDRESS SDSF; ADDRESS
>SYSCALL; ADDRESS ISPEXEC; ADDRESS ISREDIT. So, I my mind was
>wandering around without a keeper the other day and started thinking
>about what other environments might be nice to have available.

address XEDIT

>The first one was one I can really get into: ADDRESS FTP.

Yes!
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Shmuel Metz (Seymour J.)]

In , on 11/19/2010
   at 09:29 AM, Robert Birdsall  said:

>Personally, I think address MVS ought to cover basic OS functions
>like catalog, 

Not if that name is already taken.

>while 'hosts' should be able to be provided for other functions,
>e.g. address 

They've been able to do that for decades; the problem is convincing
them to actually do so.

>z/OS Rexx allows for the addition of function packages.  Does it
>allow for the addition of (non-IBM) hosts?

It provides the interface; the host has to initialize it and provide
supporting code.

>As a nonstandard extension to 
>Rexx, it would also be nice to terminate a host interface, 

That wouldn't make a lot of sense, because it's the host that call
REXX in the first place. What would it mean to cancel, e.g., address
ISREDIT in the middle of an edit macro?

>Note that the z/OS Rexx implementation is somewhat non-standard as
>is.

Is the CMS version any closer to the ANSI standard than the TSO/E
version?

>Hmm.. should this discussion move to a Rexx list?

I'd say that IBM-MAIN is more appropriate than TSO-REXX when you're
talking about more than just TSO.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Shmuel Metz (Seymour J.)]

In
,
on 11/19/2010
   at 07:01 PM, "Schumacher, Otto"  said:

>The IEFBR14 program using allocation actually does an hdelete on a
>dataset that has been migrated with SMS rather than requiring that
>the dataset be recalled so that the file can be deleted.

No; it's not IEFBR14 that changed.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Ted MacNEIL]

>The Revenue forecaster for Washington has likened "forecasting" as "driving 
>forward while looking in the rearview mirror".

Forecasting is more than that (trite) expression.

It's also (for example) such things as the number of transactions per ABM (and 
how many new ones are installed), how many RSPs, accounts (plus growth), 
business projections (by non-IT, so there's a CYA involved), or, in wholesale, 
how many orders, in stock clearing how many trades, in insurance how many 
policies/claims, in medical how many beds, in x how much y?

>If you've never been where you are going, it's hard to navigate the rocks and 
>shoals.

But, if you don't attempt the voyage you shall not make it to the destination.


-
Ted MacNEIL
eamacn...@yahoo.ca

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Logging software alternatives

[Tony Harminc]

On 19 November 2010 12:12, Dana Mitchell  wrote:
> We are using this current setup:   Application (ALCS)  writes log data to a 
> non-
> sna printer LU in a real 3174.  This port is plugged into an IrmaPrint box 
> (yes
> really!)  that converts the stream to serial RS232.  That in turn is plugged 
> into
> a PC running 'Advanced Serial Data Logger' software from AGGsoft.com.  This
> software captures the serial data and writes to a PC file and spins a new one
> at midinght etc.

Wow! How 1980s.

> We are looking to get rid of the 3174's and we currently use OSAs for
> consoles.  What I am looking for is a way using the OSAs as the printer LUs
> and route the data ultimately to the PC log file.   Does anyone have any ideas
> about how to do this?

Is it a requirement that the data end up on this PC?

Unless I much misunderstand the problem, I would look at a z/OS
application program that looks like a 328x printer on one end, and
talks to   on the other. The something could be a dataset
(regular or GDG), a SYSOUT stream, a UNIX log stream, a TCP pipe, etc.
etc.

Writing such a program is not trivial, but neither is it impossibly
complex, particularly if it has to handle only a single writer. I
believe there are public domain implementations that do the SNA stuff
(yes, I know you said non-SNA, but a VTAM application program can look
like a non-SNA printer, as long as the driving program is using VTAM
for its printing). IBM's old JES328x provides almost the opposite of
what you want, but it is conceptually similar.

Now, um, this ALCS... Is this the "TPF under MVS" thing? Does it not
have its own printer exits and such where you could capture print data
and redirect it?

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Mike Schwab]

On Fri, Nov 19, 2010 at 2:28 PM, Eric Bielefeld  wrote:
> Just out of curiousity, I browsed SYS1.LINKLIB(IEFBR14).  It looks the same 
> as it did probably about 25 years ago when I last looked at it.  The code is 
> basically 8 bytes:
>
> 1BFF 07FE  
>
> 1B is Subtract register - FF is subtracting R15 from itself, giving 0 - the 
> return code.  07 is Branch on Condition to the address in R14.
>
> --
> Eric Bielefeld
> Systems Programmer
>

http://en.wikipedia.org/wiki/IEFBR14

They went back to that version last year.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Potential heresy regarding E and L macros etc. (Was: WTO ABEND D23 help)

[Chris Craddock]

On Fri, Nov 19, 2010 at 10:40 AM, Chris Mason wrote:

> Charles
>
> It was because of your earlier posts on automation topics that I
> bothered to
> poke my nose in here and it was only when I saw what might be a bit of
> irritation with the static nature of macro coding, even the "E" and "L" -
> or
> perhaps especially because of the "E" and "L" form - that I feel prompted
> to
> suggest a step further than the course proposed by Chris Craddock.
>
> This step is, having studied the "E" and "L" forms of the macro, ditch the
> pesky things and just code what is necessary in raw - but superbly
> documented as always, of course - instructions - with perhaps a comment box
> surrounding something like the macro text that you would have coded had it
> been dynamic enough.[1]
>


I think you have missed the point I was making about the WTO interface. I do
NOT advocate ditching formal interfaces in general. In fact, the exact
opposite is true. I generally advocate for using the official macro
interfaces for calling system services. Doing it "by hand" is error prone
and certainly not worth the effort if you have to do it more than
once. However there are a few egregious cases where the official interface
is (a) so old and crufty that it is unreasonably difficult to use for the
general case - the WTO interface we were discussing is a classic example, or
(b) is so complicated that it is essentially unusable by mere mortals - many
of the XES and LOGR interfaces would fall into that category. I would
probably concede your point about the xxxCB macros too, although I've seen
the VSAM versions used extensively in products I've been associated with and
once you get the gist of them they aren't that onerous.

In those "too hard for mere mortals" cases I provide additional macro
infrastructure or kinder-gentler callable service interfaces so that other
developers don't have to wrestle with the ugly use cases. But even in those
cases I generally use the official macro interface under the covers unless
there is a compelling reason not to.


-- 
This email might be from the
artist formerly known as CC
(or not) You be the judge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Ted MacNEIL
> Sent: Friday, November 19, 2010 9:14 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: SI and MI MIPS
> 
> >So if management asks for a recommendation about migrating to a new
> mainframe to handle current workload, what numbers do mean something?
> 
> I don't know how to compress almost 30 years of experience in
> Capacity/Configuration/Performance Management into a single reply.
> 
> But, it is a basic understanding of what your workload is, how the
> various components interact, seasonality, tracking, constant revision
> of forecasts, analysis of announcements, LSPR, zPCR, understanding of
> the relationships between existing models within and without the same
> processor family, along with experience and gut instinct, among other
> things.
> 
> Also, you should have the answer ready before the question is asked.

Continuing Friday discussion.

The Revenue forecaster for Washington has likened "forecasting" as
"driving forward while looking in the rearview mirror".
If you've never been where you are going, it's hard to navigate the
rocks and shoals.

Dave Gibney
Information Technology Services
Washington State University

> 
> 
> -
> Ted MacNEIL
> eamacn...@yahoo.ca
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Tony Harminc]

On 19 November 2010 13:57, McKown, John  wrote:
> I know that I'm missing something, but that seems to be addressed here:
>
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/14.14

[Statically adding Host Command Environments]

Yes, you can do this without having to run code ahead of time. But
there are some problems with the whole REXX environment, including
HCEs. Most of them have to do with the "integrated into TSO/E" vs "not
integrated into TSO/E" split. I believe most of this strange design is
fallout from the time when invoking APF authorized programs first
became usable under TSO/E.

An HCE such as the proposed FTP one might well want to add its own
routines to handle I/O or message processing, but those services are
unavailable if the REXX environment is integrated into TSO/E. There is
always the choice of initializing an environment that is not
integrated (even when running unser TSO/E), but then the TSO/E
services are not available. One has the choice of these or those
useful features, but not both.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Ted MacNEIL]

>That's not what I meant.  >Once the analysis, the understanding, and the gut 
>instinct have all been factored in, what numbers from IBM are meaningful to 
>use to specify to management which CPU will work and which one won't?  >Given 
>that MIPS ratings are meaningless, how does one talk to management about how a 
>new CPU will handle the workload differently?
>What's the basis for discussion?

I'm sorry for being unclear.
As I said, I can't compress 30 years into a message, or two.

The direct answer is it's not easy, and what I said is what you get.

The evaluation, as I said in another post, is at best a guess.
This has been an issue for over 30 years, and acknowleged for about 20.

Even LSPR/zPCR has issues.

There is no 'you can get there from here'.
There is just experience (and sacrifices on the eve of the new moon).

I'm not trying to duck, or make it sound like magic, but the bottom line is you 
do the best you can with the information you can gather.

I've had many experiences, in 30 years, where we were wrong in estimating the 
capacity required.
One, where we thought an R25 would be enought for a year, and we upgraded to an 
R35 within a week, and were at an R65 9 months later.
Another, under COD, we did a 'temporary' upgrade and neve downgraded it.

I could show you my scars (and my performance appraisals).

When we agreed on the proposal, it was management and staff together, as a team.

When it wasn't adequate, it was staff who had made the reco, and we were the 
ones who had fouled up.

Mind you, fouled wasn't the word my VP used.

-
Ted MacNEIL
eamacn...@yahoo.ca

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Eric Bielefeld]

Just out of curiousity, I browsed SYS1.LINKLIB(IEFBR14).  It looks the same as 
it did probably about 25 years ago when I last looked at it.  The code is 
basically 8 bytes:

1BFF 07FE  

1B is Subtract register - FF is subtracting R15 from itself, giving 0 - the 
return code.  07 is Branch on Condition to the address in R14.

--
Eric Bielefeld
Systems Programmer


 "Kelman wrote: 
> Yes, it sounds interesting.  Did CA7 install its own version of IEFBR14?
> As Gerhard said in another post, IEFBR14 as supplied doesn't have any
> instructions requiring addressability, so it can't get an S0C4.
> 
> Tom Kelman
> Capacity Planning
> Commerce Bank, Kansas City

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: - SMTP :- ERROR: inet_addr failed, cannot convert address 'LOCALHOST'

[Shmuel Metz (Seymour J.)]

In , on 11/18/2010
   at 03:31 AM, Ravi Kumar  said:

>Forgot to add it does work with IEBGENER ..Thanks

Apples and oranges. IEBGENER is not an MTA and doesn't need any mail
parameters. Assuming that SYSUT2 is a SYSOUT file processed by the
SMTP external writer, then it's the SMTP JCL and parameters that
matter.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Ted MacNEIL]

>The IEFBR14 program using allocation actually does an hdelete on a dataset 
>that has been migrated with SMS rather than requiring that the dataset be 
>recalled so that the file can be deleted.

1. I thought this was optional, and the default behavior was to not do the 
HDELete.

2. SMS does not migrate.


>This feature was introduced with zOS 1.11.
>This new feature saves a lot of time and I/O to delete files that have been 
>migrated.

But, it's a kludge.

-
Ted MacNEIL
eamacn...@yahoo.ca

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Paul Gilmartin]

On Fri, 19 Nov 2010 13:18:22 -0600, Tom Marchant wrote:

>On Fri, 19 Nov 2010 19:01:44 +, Schumacher, Otto wrote:
>
>>The IEFBR14 program using allocation actually does an hdelete
>>on a dataset that has been migrated with SMS rather than requiring
>>that the dataset be recalled so that the file can be deleted.
>
>Actually, no, IEFBR14 doesn't do that.  Allocation was modified to
>recognize that case and it is Allocation that issued the HDELETE.
>
That strikes me as highly plausible; the code is OCO.

It is rumored that IEFBR14 has the highest ratio of APARs to
bytes of code of any MVS program supplied by IBM.

I don't know how to substantiate that.  I'd be more confident
that IEFBR14 has the highest ratio of lines of Friday LISTSERV
discussion to lines of executable code.

Just doing my part,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Greg Shirey]

That's not what I meant.  Once the analysis, the understanding, and the gut 
instinct have all been factored in, what numbers from IBM are meaningful to use 
to specify to management which CPU will work and which one won't?  Given that 
MIPS ratings are meaningless, how does one talk to management about how a new 
CPU will handle the workload differently?  What's the basis for discussion?

Thanks,
Greg 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ted MacNEIL
Sent: Friday, November 19, 2010 11:14 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SI and MI MIPS

But, it is a basic understanding of what your workload is, how the various 
components interact, seasonality, tracking, constant revision of forecasts, 
analysis of announcements, LSPR, zPCR, understanding of the relationships 
between existing models within and without the same processor family, along 
with experience and gut instinct, among other things.

Also, you should have the answer ready before the question is asked.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Tom Marchant]

On Fri, 19 Nov 2010 19:01:44 +, Schumacher, Otto wrote:

>The IEFBR14 program using allocation actually does an hdelete 
>on a dataset that has been migrated with SMS rather than requiring 
>that the dataset be recalled so that the file can be deleted.

Actually, no, IEFBR14 doesn't do that.  Allocation was modified to 
recognize that case and it is Allocation that issued the HDELETE.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Schumacher, Otto]

The IEFBR14 program using allocation actually does an hdelete on a dataset that 
has been migrated with SMS rather than requiring that the dataset be recalled 
so that the file can be deleted. This feature was introduced with zOS 1.11. 
This new feature saves a lot of time and I/O to delete files that have been 
migrated. There was a problem with the region having to be increased that was 
discussed on this list.  We did not experience the problem because our default 
region is set to 8m in the iefusi exit.

Regards
Otto Schumacher
 
HP Enterprise Services
Infrastructure Specialist
Ahold Account
CICS & Capacity Technical Support
P.O. Box 6462
2000 Wade Hampton Blvd.
LC1-302
Greenville,  South Carolina, 29606
Cell: 864 569--5338
Tel: 864 987-1417
Fax: 864 987-4500
E-mail: otto.schumac...@hp.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Gerhard Adam
Sent: Friday, November 19, 2010 1:35 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14

IEFBR14 can't get a S0C4 from the instructions coded in it, since none of
them require addressability.  Therefore, you're looking a modified version
of it that obviously has code added.

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Richard L Peurifoy]

On 11/19/2010 12:50 PM, Kelman, Tom wrote:

Yes, it sounds interesting.  Did CA7 install its own version of IEFBR14?
As Gerhard said in another post, IEFBR14 as supplied doesn't have any
instructions requiring addressability, so it can't get an S0C4.


My guess would be that the abend wasn't actually in IEFBR14,
but rather in some CA7 exit such as IEFUSI or IEFACTRT.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[McKown, John]

I know that I'm missing something, but that seems to be addressed here:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4a370/14.14

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe
> Sent: Friday, November 19, 2010 12:25 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: REXX "address" environments
> 
> On 11/19/2010 7:29 AM, Robert Birdsall wrote:
> > It also would be nice if address initialized the host 
> interface on first call, so
> > SysCalls('ON'), etc. would not be necessary.
> 
> I think this would be a nice enhancement.
> 
> I believe the problem here is that there is no mapping from 
> the host command 
> environment (HCE) name to the module name that 
> supports/creates it. For example, 
> rc=ejesrexx(...) initializes the 'ejes' HCE. After that, you 
> can 'address ejes' 
> in your REXX. If someone tried to use 'address ejes' prior to 
> HCE creation, how 
> would REXX know that module EJESREXX should be invoked to create it?
> 
> Perhaps a parmlib member (part of IKJTSOxx?) could contain 
> this mapping? Another 
> thought would be some sort of registration service that 
> programs could use at 
> IPL time to establish this association.
> 
> -- 
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> 310-338-0400 x318
> edja...@phoenixsoftware.com
> http://www.phoenixsoftware.com/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Kelman, Tom]

Yes, it sounds interesting.  Did CA7 install its own version of IEFBR14?
As Gerhard said in another post, IEFBR14 as supplied doesn't have any
instructions requiring addressability, so it can't get an S0C4.

Tom Kelman
Capacity Planning
Commerce Bank, Kansas City


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Gerhard Adam
Sent: Friday, November 19, 2010 12:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IEFBR14

>just to let everyone know...ca7 problem..

What does that mean?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[Mike Schwab]

You can requre that a successful SMS backup before it allows the
dataset to be migrated.

On Fri, Nov 19, 2010 at 8:00 AM, willie bunter  wrote:

> When the batch job is executed all the dsns (these are all VSAM dsns) are 
> migrated ML2 - including those that were created this morning before the 
> migrate was done.  According to the Migration Attributes shouldn't those dsns 
> which were created today & yesterday not be migrated?
> Could someone help me understand where else I should look.
>
> Thanks in advance for your help.

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Gerhard Adam]

>just to let everyone know...ca7 problem..

What does that mean?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Gerhard Adam]

IEFBR14 can't get a S0C4 from the instructions coded in it, since none of
them require addressability.  Therefore, you're looking a modified version
of it that obviously has code added.

Adam

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[Joel C. Ewing]

HMIG default for explicit command migration is ML1.  If you explicitly 
say ML2 then you are saying migrate to ML2 and that's what it does.  As 
previously mentioned, Migration Attributes for primary and level 1 only 
apply to auto migration.  Manual migration assumes you want what you ask 
for.


As others have already stated, you really need to assign system datasets 
that should not be subject to auto migration to a distinct  management 
class that doesn't allow it.  That's how management classes are intended 
to be used.  If they will never be re-allocated, you can simply use 
ALTER (TSO or batch IDCAMS) to alter the management class of existing 
datasets.  If they will be reallocated, modify your ACS routines or use 
RACF profile attributes to influence the ACS routines to change the 
MGMTCLAS when system datasets are allocated.  Long-term it might be 
better to use a distinct naming convention to make it easier to separate 
the system datasets that should get different treatment.

  Joel C. Ewing

On 11/19/2010 09:44 AM, willie bunter wrote:

Ron&  Ted,

Believe you me I have addressed this situation in the past but the mind set 
being stuck in the 20th century I have had no success.

Last question given the present set up:

  Migration Attributes
   Primary Days Non-usage  . : 3
   Level 1 Days Date/Days  . : 2
   Command or Auto Migrate . : BOTH

How can I just migrate to ML1?  For a test I issued the command but the dsn was 
migrated to ML2 even thought the Level 1 days has a value of 2?


--- On Fri, 11/19/10, Ron Hawkins  wrote:


From: Ron Hawkins
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Friday, November 19, 2010, 7:11 AM


Willie,

But that's why we have Migration Classes. The idea behind SMS is to allow
your policies to operate at the dataset level.

Why not put the system files in a migration class with no auto migration,
and let DFHSM manage the other stuff?

Ron


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On

Behalf Of

willie bunter
Sent: Friday, November 19, 2010 6:51 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] DFHSM MIGRATE MYSTERY

Stan,

Thanks for the clarification that Command migrate will supersede the SMS
attributes.  The reason why this particular Storage group is exempted from
Space Management is because there are several system files which reside in
this storage group.  Exempting them from migration could open the door for
other unforseen problems.

Thanks.

--- On Fri, 11/19/10, Stan Weyman  wrote:


From: Stan Weyman
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Friday, November 19, 2010, 6:43 AM


Command migration is going to do what you tell it to do regardless of

the

SMS attributes.  Why not let SMS manage these datasets?

Stan Weyman
Senior Software Engineer
stan.wey...@emc.com
EMC²  (508)249-3966
where information lives
It is wise to keep in mind that neither
success nor failure is ever final...

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On

Behalf Of

willie bunter
Sent: Friday, November 19, 2010 9:01 AM
To: IBM-MAIN@bama.ua.edu
Subject: DFHSM MIGRATE MYSTERY

Hallo To All,

I came across a problem where dsns are not being migrated from a given

Storage

Group.  The STORAGE GROUP is SMS managed but it is exempt from Auto

Migrate.

A batch job is executed weekly to manually migrate the dsns - below is the
command :
HMIG 'SYS2.B*.HISTORY.D*.T*' ML2

Below is the construct of this particular Management Class

Expiration Attributes

   Expire after Days Non-usage  . : 55
   Expire after Date/Days . . . . : 55
   Retention Limit  . . . . . . . : NOLIMIT

Migration Attributes
   Primary Days Non-usage  . : 3
   Level 1 Days Date/Days  . : 0
   Command or Auto Migrate . : BOTH

When the batch job is executed all the dsns (these are all VSAM dsns) are
migrated ML2 - including those that were created this morning before the
migrate was done.  According to the Migration Attributes shouldn't those

dsns

which were created today&  yesterday not be migrated?
Could someone help me understand where else I should look.

Thanks in advance for your help.





--
Joel C. Ewing, Fort Smith, ARjcew...@acm.org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Edward Jaffe]

On 11/19/2010 7:29 AM, Robert Birdsall wrote:

It also would be nice if address initialized the host interface on first call, 
so
SysCalls('ON'), etc. would not be necessary.


I think this would be a nice enhancement.

I believe the problem here is that there is no mapping from the host command 
environment (HCE) name to the module name that supports/creates it. For example, 
rc=ejesrexx(...) initializes the 'ejes' HCE. After that, you can 'address ejes' 
in your REXX. If someone tried to use 'address ejes' prior to HCE creation, how 
would REXX know that module EJESREXX should be invoked to create it?


Perhaps a parmlib member (part of IKJTSOxx?) could contain this mapping? Another 
thought would be some sort of registration service that programs could use at 
IPL time to establish this association.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Scott Rowe]

IEFBR14 doesn't save either half of the registers.

On Fri, Nov 19, 2010 at 1:13 PM, Mike Schwab wrote:

> On Fri, Nov 19, 2010 at 12:00 PM, Tony Harminc  wrote:
> > On 19 November 2010 11:56, Ron Wells  wrote:
> >
> >>> Just happened and seeing if anyone else has run across this
> >>> runninf z/os 1.11  ran IEFBR14 and recieved 0C4-4 on one LPAR..runs on
> >>> other LPAR
> >>> put in STEPLIB on failing LPAR and works??
> >
> >> just to let everyone know...ca7 problem..
> >
> > That's pretty impressive. I've caused my fair share of S0C4s over my
> > programming lifetime, but I've never managed to make IEFBR14 do it.
> >
> > Tony H.
> I guess you could run a 32 bit IEFBR14 program on a 64 bit z/OS system
> and not save the upper half of the registers.
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee.
If you are not the intended recipient, please be advised that you have
received this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited.
If you have received this material in error, please (i) do not read it,
(ii) reply to the sender that you received the message in error, and
(iii) erase or destroy the material. Emails are not secure and can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Mike Schwab]

On Fri, Nov 19, 2010 at 12:00 PM, Tony Harminc  wrote:
> On 19 November 2010 11:56, Ron Wells  wrote:
>
>>> Just happened and seeing if anyone else has run across this
>>> runninf z/os 1.11  ran IEFBR14 and recieved 0C4-4 on one LPAR..runs on
>>> other LPAR
>>> put in STEPLIB on failing LPAR and works??
>
>> just to let everyone know...ca7 problem..
>
> That's pretty impressive. I've caused my fair share of S0C4s over my
> programming lifetime, but I've never managed to make IEFBR14 do it.
>
> Tony H.
I guess you could run a 32 bit IEFBR14 program on a 64 bit z/OS system
and not save the upper half of the registers.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Tony Harminc]

On 19 November 2010 11:56, Ron Wells  wrote:

>> Just happened and seeing if anyone else has run across this
>> runninf z/os 1.11  ran IEFBR14 and recieved 0C4-4 on one LPAR..runs on
>> other LPAR
>> put in STEPLIB on failing LPAR and works??

> just to let everyone know...ca7 problem..

That's pretty impressive. I've caused my fair share of S0C4s over my
programming lifetime, but I've never managed to make IEFBR14 do it.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Ted MacNEIL]

>zPCR modelling? 

That's akin to saying a Sysprog only needs SMP/E skills.

zPCR is only as good as its input, and LSPR does not try every possible 
configuration, including some they have figures for.
What is missing is extrapolated, usually linearly, which is not how the MP 
effect works.

Capacity Analysts have been aware, for almost 20 years since I first started 
seeing press about it, that relative capacity comparisons are, at best, an 
estimate.

And, with more powerful processors, the variance in capacity has taken even 
larger swings.

Unfortunately, even MSU ratings are suspect (with/without the 'technology 
dividend').
And, the scariest part is the fact that Senior Management is committing 
millions to these guesses.

-
Ted MacNEIL
eamacn...@yahoo.ca

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Ted MacNEIL]

>So if management asks for a recommendation about migrating to a new mainframe 
>to handle current workload, what numbers do mean something?

I don't know how to compress almost 30 years of experience in 
Capacity/Configuration/Performance Management into a single reply.

But, it is a basic understanding of what your workload is, how the various 
components interact, seasonality, tracking, constant revision of forecasts, 
analysis of announcements, LSPR, zPCR, understanding of the relationships 
between existing models within and without the same processor family, along 
with experience and gut instinct, among other things.

Also, you should have the answer ready before the question is asked.


-
Ted MacNEIL
eamacn...@yahoo.ca

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Logging software alternatives

[Dana Mitchell]

We are using this current setup:   Application (ALCS)  writes log data to a non-
sna printer LU in a real 3174.  This port is plugged into an IrmaPrint box (yes 
really!)  that converts the stream to serial RS232.  That in turn is plugged 
into 
a PC running 'Advanced Serial Data Logger' software from AGGsoft.com.  This 
software captures the serial data and writes to a PC file and spins a new one 
at midinght etc. 

We are looking to get rid of the 3174's and we currently use OSAs for 
consoles.  What I am looking for is a way using the OSAs as the printer LUs 
and route the data ultimately to the PC log file.   Does anyone have any ideas 
about how to do this?

thanks
Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Ken Porowski]

zPCR modelling? 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Greg Shirey
Sent: Friday, November 19, 2010 11:58 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] SI and MI MIPS

So if management asks for a recommendation about migrating to a new
mainframe to handle current workload, what numbers do mean something?


Thanks,
Greg 


-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
Sent: Thursday, November 18, 2010 5:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SI and MI MIPS

>In fairness, it -is- a number that a high manager can use to reasonbly
quantify things. 

I disagree.
The number means nothing.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Ron Wells]

just to let everyone know...ca7 problem..




From:   "Kelman, Tom" 
To: IBM-MAIN@bama.ua.edu
Date:   11/19/2010 09:57 AM
Subject:Re: IEFBR14
Sent by:IBM Mainframe Discussion List 



Ron,

Are the libraries listed in the linklist on the two LPARs different?  It
sounds to me as if you have a bogus IEFBR14 in the one linklist.  I'd
check the libraries in the linklist on the LPAR where it is failing,
starting with the first library in the list, to verify that.

Tom Kelman
Capacity Planning
Commerce Bank, Kansas City


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ron Wells
Sent: Friday, November 19, 2010 9:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: IEFBR14

Just happened and seeing if anyone else has run across this
runninf z/os 1.11  ran IEFBR14 and recieved 0C4-4 on one LPAR..runs on 
other LPAR
put in STEPLIB on failing LPAR and works??

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the
sender, which  may be legally privileged information.  This information
is intended only  for  the use of the individual or entity addressed
above.  If you are not  the  intended  recipient, or  an  employee  or
agent responsible for delivering it to the intended recipient, you are
hereby notified that any disclosure,  copying, distribution, or the
taking of any action in reliance on the contents of the E-mail or
attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Greg Shirey]

So if management asks for a recommendation about migrating to a new mainframe 
to handle current workload, what numbers do mean something?

Thanks,
Greg 


-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
Sent: Thursday, November 18, 2010 5:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SI and MI MIPS

>In fairness, it -is- a number that a high manager can use to reasonbly 
>quantify things. 

I disagree.
The number means nothing.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Potential heresy regarding E and L macros etc. (Was: WTO ABEND D23 help)

[Chris Mason]

Charles

Sorry - a rather late response.

As you may know I normally restrict myself to questions relating to the two 
Communications Server components but I have messed about with trivial 
assembler programs which were completely my own and with no expectation 
that anyone will ever need to maintain them except myself - but possibly at 
some indefinite time in the future.

So having got that caveat out of the way, I am about to pronounce what to 
some might be heresy. So any reading this who are of a nervous or excitable 
disposition should be sitting down and keeping clear of sharp objects and may 
care to have a sedative handy preferably in a soft plastic beaker.

It was because of your earlier posts on automation topics that I bothered to 
poke my nose in here and it was only when I saw what might be a bit of 
irritation with the static nature of macro coding, even the "E" and "L" - or 
perhaps especially because of the "E" and "L" form - that I feel prompted to 
suggest a step further than the course proposed by Chris Craddock.

This step is, having studied the "E" and "L" forms of the macro, ditch the 
pesky things and just code what is necessary in raw - but superbly 
documented as always, of course - instructions - with perhaps a comment box 
surrounding something like the macro text that you would have coded had it 
been dynamic enough.[1]

I came to this conclusion a long time ago as soon as the obvious point came 
home that the logic the "other side", as it were, of the SVC call which was 
going to be using the register values and any "control block" associated with 
the SVC call wouldn't have the first clue regarding whether macros had loaded 
the register values and created the "control block" or rawly coded instructions 
had.

The only remaining matter is "maintainability". That is why I suggest you 
redouble your undoubtedly normal sterling efforts to provide superb 
commenting around the instructions surrounding the SVC call.

Actually I first came to these conclusions not so much with SVC calls but with 
the BALR 14,15 calls associated with the VTAM API and it was all about 
flexibility. I used to code up my trivial VTAM programs with a timorous mix of 
macro instructions and operands where I could and raw instructions dipping 
into the "control blocks" where I absolutely couldn't.

Then on one famous occasion - for me anyhow! - I tried to use the interface 
which was actually supposed to get around this little difficulty, the xxxCB 
macros[2]. Getting on for some 10 years before when I had attended a VTAM 
class at a time when there was so little to VTAM systems programming that 
the course also included application programming, I learned just a little about 
these xxxCB macros and how they were supposed to work and also that, since 
the similarly named and abbreviated VTAM and VSAM were developed at about 
the same time and there was a fond hope that the similarity in structure 
provided a synergy which could assist programmers in moving data from the 
VTAM API to the VSAM API and back again.[3] These xxxCB calls also happen
(ed) to be part of both the VTAM and the VSAM API.

My attempt to use the VTAM xxxCB macros in place or raw instructions 
peeking into and zapping fields in "control blocks" failed miserably. Both (a) 
they didn't seem to have kept up with all the changes to the "control block" 
fields and (b) once you got to see how they worked it was evident you were 
just adding yet another "control block", the one used by the xxxCB macro to 
the "control block" with which you really wanted to work. What a mess! It 
began to look as if these xxxCB macros were the result of an instruction from 
a "suit" of whom the poor developer was too afraid to be able to point out 
that the whole idea was nonsense.

By pure chance I happen to be in contact just this week concerning another 
technical exchange - a Techdoc or two no less - with a then colleague who is 
a vital part of this story. Having discovered that the VTAM xxxCB macros were 
deficient in their capabilities, I mentioned this to him and what I was trying 
to 
do. He "took me aside", as it were, and confided that, actually the xxxCB 
macros had been abandoned a few releases - maybe an odd version - before! 
This was sometime in the early '80s.[4]

The moral of this story is that there is no substitute for using raw 
instructions 
in order to take a look inside "control blocks" and fit them up for the purpose 
you have in mind. You can use "L" form of macros if you like or you can just 
build the "control block" "by hand". You can use "E" form of macros if you like 
or you can just load the registers and issue the SVC or whatever is currently 
the most popular flavour of the archetypical BALR 14,15, whichever call the 
macro is "disguising".

After all, when it comes to trying to work out if the call or SVC did what it 
was supposed to do, you tend to be using raw instructions - although I tried 
for a while using table-driven c

Re: SI and MI MIPS

[Ted MacNEIL]

>I actually took Hal's comment the other way, that the "not very far from the 
>actuality" was referring back to the meaningless indicator.  >In that case, it 
>really is pretty accurate.
>IOW, MIPS is meaningless.

Because of:

>>In fairness, it -is- a number that a high manager can use to reasonbly 
>>quantify things.

I took it the other way.
The poster appeared to believe it was a meaningful measurement.

-
Ted MacNEIL
eamacn...@yahoo.ca

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Pommier, Rex R.]

Hey Ted,

I actually took Hal's comment the other way, that the "not very far from the 
actuality" was referring back to the meaningless indicator.  In that case, it 
really is pretty accurate.  IOW, MIPS is meaningless.

Dont'cha just love English?

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Ted MacNEIL
Sent: Thursday, November 18, 2010 5:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SI and MI MIPS

>I share your distaste for the term. I like: "Meaninless Indication of 
>Processor Speed'.


>What's cool is that is not very far from the actuality

Actually, it is.

>In fairness, it -is- a number that a high manager can use to reasonbly 
>quantify things.

I disagree.
The number means nothing.
And, when IBM first went to MSUs, it meant less.
Especially with the so-called 'technology dividend'.
LSPR, which they use to set MSU values, does not test/check everything.

A statistic based on invalid assumptions is just so much air.

November 2004:
Don't be Misled by MIPS

http://tinyurl.com/yqa4yy
http://preview.tinyurl.com/yqa4yy


The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited. If you received this e-mail in error, please reply to 
sender and destroy or delete the message and any attachments. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IEFBR14

[Kelman, Tom]

Ron,

Are the libraries listed in the linklist on the two LPARs different?  It
sounds to me as if you have a bogus IEFBR14 in the one linklist.  I'd
check the libraries in the linklist on the LPAR where it is failing,
starting with the first library in the list, to verify that.

Tom Kelman
Capacity Planning
Commerce Bank, Kansas City


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ron Wells
Sent: Friday, November 19, 2010 9:38 AM
To: IBM-MAIN@bama.ua.edu
Subject: IEFBR14

Just happened and seeing if anyone else has run across this
runninf z/os 1.11  ran IEFBR14 and recieved 0C4-4 on one LPAR..runs on 
other LPAR
put in STEPLIB on failing LPAR and works??

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the
sender, which  may be legally privileged information.  This information
is intended only  for  the use of the individual or entity addressed
above.  If you are not  the  intended  recipient, or  an  employee  or
agent responsible for delivering it to the intended recipient, you are
hereby notified that any disclosure,  copying, distribution, or the
taking of any action in reliance on the contents of the E-mail or
attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Question of the Day - CPU Utilization on a Soft Capped Machine

[Kelman, Tom]

RMF/SMF records timings, not percentages, so whatever analysis program
you are using is calculating the percentages.  Typically that is a
percentage of the total machine/LPAR/engine, not based on the cap.  That
is the percentage figure you'd see in the RMF reports.  Of course, once
the LPAR use hits the cap, then WLM will act as if the system is at 100%
utilization and not allow it to go above the cap.

Tom Kelman
Capacity Planning
Commerce Bank, Kansas City


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Chase, John
Sent: Friday, November 19, 2010 8:35 AM
To: IBM-MAIN@bama.ua.edu
Subject: Question of the Day - CPU Utilization on a Soft Capped Machine

Posted on behalf of a colleague:

"When we measure CPU utilization [%] on an LPAR that is soft capped, are
the results based on the soft capped available capacity or the defined
capacity?  Inquiring minds want to know."

Assumption:  Measurement is via SDSF (DA), RMF or TMON/MVS.

TIA,

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[willie bunter]

Ron & Ted,
 
Believe you me I have addressed this situation in the past but the mind set 
being stuck in the 20th century I have had no success.
 
Last question given the present set up: 
 
 Migration Attributes   
  Primary Days Non-usage  . : 3    
  Level 1 Days Date/Days  . : 2    
  Command or Auto Migrate . : BOTH 
    
How can I just migrate to ML1?  For a test I issued the command but the dsn was 
migrated to ML2 even thought the Level 1 days has a value of 2?
 

--- On Fri, 11/19/10, Ron Hawkins  wrote:


From: Ron Hawkins 
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Friday, November 19, 2010, 7:11 AM


Willie,

But that's why we have Migration Classes. The idea behind SMS is to allow
your policies to operate at the dataset level.

Why not put the system files in a migration class with no auto migration,
and let DFHSM manage the other stuff?

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> willie bunter
> Sent: Friday, November 19, 2010 6:51 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] DFHSM MIGRATE MYSTERY
> 
> Stan,
> 
> Thanks for the clarification that Command migrate will supersede the SMS
> attributes.  The reason why this particular Storage group is exempted from
> Space Management is because there are several system files which reside in
> this storage group.  Exempting them from migration could open the door for
> other unforseen problems.
> 
> Thanks.
> 
> --- On Fri, 11/19/10, Stan Weyman  wrote:
> 
> 
> From: Stan Weyman 
> Subject: Re: DFHSM MIGRATE MYSTERY
> To: IBM-MAIN@bama.ua.edu
> Received: Friday, November 19, 2010, 6:43 AM
> 
> 
>    Command migration is going to do what you tell it to do regardless of
the
> SMS attributes.  Why not let SMS manage these datasets?
> 
> Stan Weyman
> Senior Software Engineer
> stan.wey...@emc.com
> EMC²  (508)249-3966
> where information lives
> It is wise to keep in mind that neither
> success nor failure is ever final...
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> willie bunter
> Sent: Friday, November 19, 2010 9:01 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: DFHSM MIGRATE MYSTERY
> 
> Hallo To All,
> 
> I came across a problem where dsns are not being migrated from a given
Storage
> Group.  The STORAGE GROUP is SMS managed but it is exempt from Auto
Migrate.
> A batch job is executed weekly to manually migrate the dsns - below is the
> command :
> HMIG 'SYS2.B*.HISTORY.D*.T*' ML2
> 
> Below is the construct of this particular Management Class
> 
> Expiration Attributes
> 
>   Expire after Days Non-usage  . : 55
>   Expire after Date/Days . . . . : 55
>   Retention Limit  . . . . . . . : NOLIMIT
> 
> Migration Attributes
>   Primary Days Non-usage  . : 3
>   Level 1 Days Date/Days  . : 0
>   Command or Auto Migrate . : BOTH
> 
> When the batch job is executed all the dsns (these are all VSAM dsns) are
> migrated ML2 - including those that were created this morning before the
> migrate was done.  According to the Migration Attributes shouldn't those
dsns
> which were created today & yesterday not be migrated?
> Could someone help me understand where else I should look.
> 
> Thanks in advance for your help.
> 
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

IEFBR14

[Ron Wells]

Just happened and seeing if anyone else has run across this
runninf z/os 1.11  ran IEFBR14 and recieved 0C4-4 on one LPAR..runs on 
other LPAR
put in STEPLIB on failing LPAR and works??

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX "address" environments

[Robert Birdsall]

This sounds similar to the use of 'address' in the Amiga version of Rexx.
It seemed to work well there.

Personally, I think address MVS ought to cover basic OS functions like catalog, 
while 'hosts' should be able to be provided for other functions, e.g. address 
CA7, address CICS, address HomeGrownAutomation ...

z/OS Rexx allows for the addition of function packages.  Does it allow for the 
addition of (non-IBM) hosts?

It also would be nice if address initialized the host interface on first call, 
so 
SysCalls('ON'), etc. would not be necessary.  As a nonstandard extension to 
Rexx, it would also be nice to terminate a host interface, like 'address CICS 
remove' or 'address -CICS' or some such.
Note that the z/OS Rexx implementation is somewhat non-standard as is.

Hmm.. should this discussion move to a Rexx list?
I don't participate in any, but then, who needs my comments anyway?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[Ted MacNEIL]

>Sorry the last sentence should read "including them in Auto Migrate could open 
>the door for other unforseen problems".  Sorry for the typo. 

If they are truly System Data Sets, then you could protect them from auto 
migrate by either:
1. Different Management Class.
2. (Preferred option) Put them somewhere else.

-
Ted MacNEIL
eamacn...@yahoo.ca

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[Ron Hawkins]

Willie,

But that's why we have Migration Classes. The idea behind SMS is to allow
your policies to operate at the dataset level.

Why not put the system files in a migration class with no auto migration,
and let DFHSM manage the other stuff?

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> willie bunter
> Sent: Friday, November 19, 2010 6:51 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] DFHSM MIGRATE MYSTERY
> 
> Stan,
> 
> Thanks for the clarification that Command migrate will supersede the SMS
> attributes.  The reason why this particular Storage group is exempted from
> Space Management is because there are several system files which reside in
> this storage group.  Exempting them from migration could open the door for
> other unforseen problems.
> 
> Thanks.
> 
> --- On Fri, 11/19/10, Stan Weyman  wrote:
> 
> 
> From: Stan Weyman 
> Subject: Re: DFHSM MIGRATE MYSTERY
> To: IBM-MAIN@bama.ua.edu
> Received: Friday, November 19, 2010, 6:43 AM
> 
> 
>    Command migration is going to do what you tell it to do regardless of
the
> SMS attributes.  Why not let SMS manage these datasets?
> 
> Stan Weyman
> Senior Software Engineer
> stan.wey...@emc.com
> EMC²  (508)249-3966
> where information lives
> It is wise to keep in mind that neither
> success nor failure is ever final...
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> willie bunter
> Sent: Friday, November 19, 2010 9:01 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: DFHSM MIGRATE MYSTERY
> 
> Hallo To All,
> 
> I came across a problem where dsns are not being migrated from a given
Storage
> Group.  The STORAGE GROUP is SMS managed but it is exempt from Auto
Migrate.
> A batch job is executed weekly to manually migrate the dsns - below is the
> command :
> HMIG 'SYS2.B*.HISTORY.D*.T*' ML2
> 
> Below is the construct of this particular Management Class
> 
> Expiration Attributes
> 
>   Expire after Days Non-usage  . : 55
>   Expire after Date/Days . . . . : 55
>   Retention Limit  . . . . . . . : NOLIMIT
> 
> Migration Attributes
>   Primary Days Non-usage  . : 3
>   Level 1 Days Date/Days  . : 0
>   Command or Auto Migrate . : BOTH
> 
> When the batch job is executed all the dsns (these are all VSAM dsns) are
> migrated ML2 - including those that were created this morning before the
> migrate was done.  According to the Migration Attributes shouldn't those
dsns
> which were created today & yesterday not be migrated?
> Could someone help me understand where else I should look.
> 
> Thanks in advance for your help.
> 
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[willie bunter]

Sorry the last sentence should read "including them in Auto Migrate could open 
the door for other unforseen problems".  Sorry for the typo. 

--- On Fri, 11/19/10, willie bunter  wrote:


From: willie bunter 
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Friday, November 19, 2010, 6:51 AM


Stan,
 
Thanks for the clarification that Command migrate will supersede the SMS 
attributes.  The reason why this particular Storage group is exempted from 
Space Management is because there are several system files which reside in this 
storage group.  Exempting them from migration could open the door for other 
unforseen problems.
 
Thanks.

--- On Fri, 11/19/10, Stan Weyman  wrote:


From: Stan Weyman 
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Friday, November 19, 2010, 6:43 AM


   Command migration is going to do what you tell it to do regardless of the 
SMS attributes.  Why not let SMS manage these datasets?

Stan Weyman 
Senior Software Engineer
stan.wey...@emc.com
EMC²  (508)249-3966
where information lives
It is wise to keep in mind that neither
success nor failure is ever final...

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Friday, November 19, 2010 9:01 AM
To: IBM-MAIN@bama.ua.edu
Subject: DFHSM MIGRATE MYSTERY

Hallo To All,
 
I came across a problem where dsns are not being migrated from a given Storage 
Group.  The STORAGE GROUP is SMS managed but it is exempt from Auto Migrate.  A 
batch job is executed weekly to manually migrate the dsns - below is the 
command :
HMIG 'SYS2.B*.HISTORY.D*.T*' ML2
 
Below is the construct of this particular Management Class
 
Expiration Attributes  
   
  Expire after Days Non-usage  . : 55  
  Expire after Date/Days . . . . : 55  
  Retention Limit  . . . . . . . : NOLIMIT 

Migration Attributes    
  Primary Days Non-usage  . : 3 
  Level 1 Days Date/Days  . : 0 
  Command or Auto Migrate . : BOTH  

When the batch job is executed all the dsns (these are all VSAM dsns) are 
migrated ML2 - including those that were created this morning before the 
migrate was done.  According to the Migration Attributes shouldn't those dsns 
which were created today & yesterday not be migrated?
Could someone help me understand where else I should look.
 
Thanks in advance for your help.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[willie bunter]

Stan,
 
Thanks for the clarification that Command migrate will supersede the SMS 
attributes.  The reason why this particular Storage group is exempted from 
Space Management is because there are several system files which reside in this 
storage group.  Exempting them from migration could open the door for other 
unforseen problems.
 
Thanks.

--- On Fri, 11/19/10, Stan Weyman  wrote:


From: Stan Weyman 
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Friday, November 19, 2010, 6:43 AM


   Command migration is going to do what you tell it to do regardless of the 
SMS attributes.  Why not let SMS manage these datasets?

Stan Weyman 
Senior Software Engineer
stan.wey...@emc.com
EMC²  (508)249-3966
where information lives
It is wise to keep in mind that neither
success nor failure is ever final...

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Friday, November 19, 2010 9:01 AM
To: IBM-MAIN@bama.ua.edu
Subject: DFHSM MIGRATE MYSTERY

Hallo To All,
 
I came across a problem where dsns are not being migrated from a given Storage 
Group.  The STORAGE GROUP is SMS managed but it is exempt from Auto Migrate.  A 
batch job is executed weekly to manually migrate the dsns - below is the 
command :
HMIG 'SYS2.B*.HISTORY.D*.T*' ML2
 
Below is the construct of this particular Management Class
 
Expiration Attributes  
   
  Expire after Days Non-usage  . : 55  
  Expire after Date/Days . . . . : 55  
  Retention Limit  . . . . . . . : NOLIMIT 

Migration Attributes    
  Primary Days Non-usage  . : 3 
  Level 1 Days Date/Days  . : 0 
  Command or Auto Migrate . : BOTH  

When the batch job is executed all the dsns (these are all VSAM dsns) are 
migrated ML2 - including those that were created this morning before the 
migrate was done.  According to the Migration Attributes shouldn't those dsns 
which were created today & yesterday not be migrated?
Could someone help me understand where else I should look.
 
Thanks in advance for your help.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[Mark Jacobs]

Can't you set the storage pool migration thresholds to both high and low 
levels such that daily auto-migration activities will bring the pool 
down to a level to support the next days expected allocations?


Mark Jacobs

On 11/19/10 09:45, willie bunter wrote:

Lizette,
  
The reason why we do a manual migrate of these dsns is because the STORAGE pool gets filled up, hence space abends.  If I understand what you say correctly, if a manual migrate command is issued, the dsns are migrated regardless of the Migration attributes?


--- On Fri, 11/19/10, Lizette Koehler  wrote:


From: Lizette Koehler
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Friday, November 19, 2010, 6:10 AM


   

willie bunter Wrote:
When the batch job is executed all the dsns (these are all VSAM
dsns) are migrated ML2 - including those that were created this morning
before the migrate was done.  According to the Migration Attributes
shouldn't those dsns which were created today&  yesterday not be
migrated?
Could someone help me understand where else I should look.

 


Willie,

When you issue a manual migrate - I think it will just go whether or not it
meets the requirements.

I guess the question of why you want to do manual migrates is going to pop
up.

Either SMS migrates for you or it does not.  So if you issue the migrate
command the datasets will go. 


So, the question in my mind is - what are the dataset requirements for
migration?  And why are the SMS rules not sufficient to handle them?  In my
shop we have an SMS pool where datasets are not migrated for a very long
time.  And because of that, when it fills up, we manually migrate datasets
based on our decision.  SMS does not prevent up from migrating those
datasets created minutes ago.

Lizette

--

   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[willie bunter]

Lizette,
 
The reason why we do a manual migrate of these dsns is because the STORAGE pool 
gets filled up, hence space abends.  If I understand what you say correctly, if 
a manual migrate command is issued, the dsns are migrated regardless of the 
Migration attributes?

--- On Fri, 11/19/10, Lizette Koehler  wrote:


From: Lizette Koehler 
Subject: Re: DFHSM MIGRATE MYSTERY
To: IBM-MAIN@bama.ua.edu
Received: Friday, November 19, 2010, 6:10 AM


> willie bunter Wrote:
> When the batch job is executed all the dsns (these are all VSAM
> dsns) are migrated ML2 - including those that were created this morning
> before the migrate was done.  According to the Migration Attributes
> shouldn't those dsns which were created today & yesterday not be
> migrated?
> Could someone help me understand where else I should look.
> 


Willie,

When you issue a manual migrate - I think it will just go whether or not it
meets the requirements.

I guess the question of why you want to do manual migrates is going to pop
up.

Either SMS migrates for you or it does not.  So if you issue the migrate
command the datasets will go.  

So, the question in my mind is - what are the dataset requirements for
migration?  And why are the SMS rules not sufficient to handle them?  In my
shop we have an SMS pool where datasets are not migrated for a very long
time.  And because of that, when it fills up, we manually migrate datasets
based on our decision.  SMS does not prevent up from migrating those
datasets created minutes ago.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[Stan Weyman]

   Command migration is going to do what you tell it to do regardless of the 
SMS attributes.  Why not let SMS manage these datasets?

Stan Weyman 
Senior Software Engineer
stan.wey...@emc.com
EMC²  (508)249-3966
where information lives
It is wise to keep in mind that neither
success nor failure is ever final...

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Friday, November 19, 2010 9:01 AM
To: IBM-MAIN@bama.ua.edu
Subject: DFHSM MIGRATE MYSTERY

Hallo To All,
 
I came across a problem where dsns are not being migrated from a given Storage 
Group.  The STORAGE GROUP is SMS managed but it is exempt from Auto Migrate.  A 
batch job is executed weekly to manually migrate the dsns - below is the 
command :
HMIG 'SYS2.B*.HISTORY.D*.T*' ML2
 
Below is the construct of this particular Management Class
 
Expiration Attributes  
   
  Expire after Days Non-usage  . : 55  
  Expire after Date/Days . . . . : 55  
  Retention Limit  . . . . . . . : NOLIMIT 

Migration Attributes    
  Primary Days Non-usage  . : 3 
  Level 1 Days Date/Days  . : 0 
  Command or Auto Migrate . : BOTH  

When the batch job is executed all the dsns (these are all VSAM dsns) are 
migrated ML2 - including those that were created this morning before the 
migrate was done.  According to the Migration Attributes shouldn't those dsns 
which were created today & yesterday not be migrated?
Could someone help me understand where else I should look.
 
Thanks in advance for your help.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Question of the Day - CPU Utilization on a Soft Capped Machine

[Chase, John]

Posted on behalf of a colleague:

"When we measure CPU utilization [%] on an LPAR that is soft capped, are
the results based on the soft capped available capacity or the defined
capacity?  Inquiring minds want to know."

Assumption:  Measurement is via SDSF (DA), RMF or TMON/MVS.

TIA,

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ICSF Question: Are dynamic calls permitted?

[Paul Gilmartin]

On Fri, 19 Nov 2010 07:30:08 -0600, Staller, Allan wrote:

>IIRC static linking is *NOT* required. Just make the ICSF loadlib avail
>via LNKLST or steplib
>
>
>So, my question is whether static linking is required, or if (for
>instance) a standard Enterprise COBOL dynamic call ("CALL dataname")
>will also work.
>
>
Rexx can do this.  See the Rexx example in (IIRC) SYS1.SAMPLIB(CSFTEST).

One concern I'd have is the LOAD/DELETE overhead of making the
repeated dynamic calls to ICSF.  This could be alleviated by keeping
ICSF in LPA or by performing an initial LOAD; repeated calls to
dynamic ICSF; and a final DELETE.  Alas, I believe Rexx lacks the
LOAD/DELETE facility.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[Lizette Koehler]

> willie bunter Wrote:
> When the batch job is executed all the dsns (these are all VSAM
> dsns) are migrated ML2 - including those that were created this morning
> before the migrate was done.  According to the Migration Attributes
> shouldn't those dsns which were created today & yesterday not be
> migrated?
> Could someone help me understand where else I should look.
> 


Willie,

When you issue a manual migrate - I think it will just go whether or not it
meets the requirements.

I guess the question of why you want to do manual migrates is going to pop
up.

Either SMS migrates for you or it does not.  So if you issue the migrate
command the datasets will go.  

So, the question in my mind is - what are the dataset requirements for
migration?  And why are the SMS rules not sufficient to handle them?  In my
shop we have an SMS pool where datasets are not migrated for a very long
time.  And because of that, when it fills up, we manually migrate datasets
based on our decision.  SMS does not prevent up from migrating those
datasets created minutes ago.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: DFHSM MIGRATE MYSTERY

[Richards, Robert B.]

H, it has been awhile, but I believe when you issue HMIGRATE that is 
considered "command" migration and it ignores those attributes and does what 
you told it to do. :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Friday, November 19, 2010 9:01 AM
To: IBM-MAIN@bama.ua.edu
Subject: DFHSM MIGRATE MYSTERY

Hallo To All,

I came across a problem where dsns are not being migrated from a given Storage 
Group.  The STORAGE GROUP is SMS managed but it is exempt from Auto Migrate.  A 
batch job is executed weekly to manually migrate the dsns - below is the 
command :
HMIG 'SYS2.B*.HISTORY.D*.T*' ML2

Below is the construct of this particular Management Class

Expiration Attributes

  Expire after Days Non-usage  . : 55
  Expire after Date/Days . . . . : 55
  Retention Limit  . . . . . . . : NOLIMIT

Migration Attributes
  Primary Days Non-usage  . : 3
  Level 1 Days Date/Days  . : 0
  Command or Auto Migrate . : BOTH

When the batch job is executed all the dsns (these are all VSAM dsns) are 
migrated ML2 - including those that were created this morning before the 
migrate was done.  According to the Migration Attributes shouldn't those dsns 
which were created today & yesterday not be migrated?
Could someone help me understand where else I should look.

Thanks in advance for your help.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

DFHSM MIGRATE MYSTERY

[willie bunter]

Hallo To All,
 
I came across a problem where dsns are not being migrated from a given Storage 
Group.  The STORAGE GROUP is SMS managed but it is exempt from Auto Migrate.  A 
batch job is executed weekly to manually migrate the dsns - below is the 
command :
HMIG 'SYS2.B*.HISTORY.D*.T*' ML2
 
Below is the construct of this particular Management Class
 
Expiration Attributes  
   
  Expire after Days Non-usage  . : 55  
  Expire after Date/Days . . . . : 55  
  Retention Limit  . . . . . . . : NOLIMIT 

Migration Attributes    
  Primary Days Non-usage  . : 3 
  Level 1 Days Date/Days  . : 0 
  Command or Auto Migrate . : BOTH  

When the batch job is executed all the dsns (these are all VSAM dsns) are 
migrated ML2 - including those that were created this morning before the 
migrate was done.  According to the Migration Attributes shouldn't those dsns 
which were created today & yesterday not be migrated?
Could someone help me understand where else I should look.
 
Thanks in advance for your help.





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ICSF Question: Are dynamic calls permitted?

[Staller, Allan]

IIRC static linking is *NOT* required. Just make the ICSF loadlib avail
via LNKLST or steplib

HTH,


So, my question is whether static linking is required, or if (for
instance) a standard Enterprise COBOL dynamic call ("CALL dataname")
will also work.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SI and MI MIPS

[Tom Marchant]

On Thu, 18 Nov 2010 22:58:39 +, Ted MacNEIL wrote:
>
>I've been involved in performance/capacity since 1981, and 
>I've never seen an MI/SI distinction, before.

LSPR has listed separate data for a single instance of z/OS 
and multiple instances for years

>>I'd go on to say that MIP ratings are an approximation at best.
>
>I agree.
>But, there is no such thing as a MIP.

I agree about that.  Pet peeve of mine too. 
Maybe he also has a potted cactu.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Look at PSA for multiple processors. Possible?

[Veilleux, Jon L]

Just an FYI. 
In IPCS browse using ACTIVE I cannot list all three of our CPs. I get storage 
not available for two of them. In an SVC dump they are all available. Must be a 
limitation.


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Dave Day
Sent: Thursday, November 18, 2010 5:11 PM
To: IBM-MAIN@bama.ua.edu
Subject: Look at PSA for multiple processors. Possible?

I would like to pick up a value from the PSA for each active processor.  
The CVT points to the PCCAVT which has one pointer for each processor.  The 
PCCA has a field PCCAPSAV.

(18)ADDRESS  4PCCAPSAV - VIRTUAL ADDRESS OF
PSA

On my Dallas RDP system, this points to a field in extended SQA.  However, 
the contents of this virtual PSA do not correlate at all to the contents of the 
actual PSA, using XDC to interrogate and display.  However, in looking at an 
SVC dump from a day or so ago for this same system, it appears the fields are 
valid.  I then looked at an SVC dump from a customer, where there were 6 
engines active, and each virtual PSA looked valid.  So, SVC dump must know how 
to do this.  If anyone knows how to accomplish this programmatically, I would 
appreciate them sharing this with me.  Thanks.

--Dave Day   

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: TSM Problem

[Peter Vander Woude]

Dave,

In TSM, when changing the device type for a storage pool, I would recommend,
creating a new device class, for pointing to the new esoteric.  Then create
a new stgpool, using that new device class.  Update the stgpool hierarchy to
refer to the new stgpool (or if writing direct to it, update the management
class to point to it).

Once that's done, you'd update the old tape stgpool to have the new pool as
the next level.  Then force a migration of the data from the 9840d's to the vsm.

If that is not possible, try going through and updating any of the tapes,
that are on the 9840d's, and change their status from readwrite to readonly.
 This effectively does the same type of thing as the markfull of hsm.

Peter

On Mon, 15 Nov 2010 11:49:42 -0500, O'Brien, David W. (NIH/CIT) [C]
 wrote:

>Some time ago I changed the device type for Devclass Cartridge from an
esoteric for 9840Ds to an esoteric for our VSM unit.
>
>I neglected to see that I had a 9840D cart with a status of 'filling'.
>Since the devclass now points to VSM, I'm getting the following msg.
>
>ANR5373I Cannot allocate tape drive of unit type ETAPE for tape Q3.
Reply C(cancel), R (retry), or W(wait).
>
>I browsed the Admin Reference manual but did not see a command which would
allow me to change the status of this tape to FULL.
>
>Any suggestions welcomed.
>
>I could change the devclass back to the former esoteric but then I'd get
error msgs. on the 2 open virtual tapes.
>
>
>Thank You,
>Dave O'Brien
>NIH Contractor
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Strange ADRDSSU behavior (ADR485E)

[R.S.]

The following scenario:
z/OS 1.11
DSS job
COPY DS(INC(**) EXC(SYS1.VVDS.**)) -
 LOGINDDNAME(IND) -
 CANCELERROR TOLERATE(ENQF) -
 OUTDD(OTD) ALLDATA(*) ALLEXCP -
 RECATALOG(CAT.MAST.NEWCAT) -
 RENAMEU(ZFS.OLDSYS.**,ZFS.NEWSYS.**)

The job succesfully copies all ZFS (VSAM LDS) datasets, *except* the 
following one: ZFS.OLDSYS.SHPUROOT


DSS end with RC=8 and te following message.
ADR485E (001)-AMOVE(01), CATALOG CAT.MAST.NEWCAT IS NOT IN 
STEPCAT/JOBCAT/MASTERCAT STRUCTURE. DATA SET ZFS.OLDSYS.SHPUROOT WILL BE 
PROCESSED.


Manual says: he NONSMS cluster named in the message required DFSMSdss to 
use IDCAMS or VSAM I/O to perform the COPY or RESTORE. This
requires that both the source and target cluster (allocated by DFSMSdss) 
be accessible via the catalog structure.


I have no idea why this dataset requires IDCAMS, while other datasets 
were succesfully processed.


Any clue???


BTW: I googled for ADR485E - first hit says about empty cluster - this 
cluster is NOT empty.

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 16.07.2010 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.248.328 złotych. 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ReSizing the SMF Man Files

[Elardus Engelbrecht]

Ted MacNEIL wrote:

>>However... in regards to this discussion (and remember, I'm an IEFU29 
user), if you are already paying for and using console automation, be it home 
grown, vanilla Netview, SAA, AFOPER, BMC,  etc., how much extra does it 
cost to write and activate a rule to dump MANx data sets when the message 
comes out that triggers the dump?

>This comes down to an "it depends".
>Neither is right or wrong.

Yup. Here I agree 100% with Ted. 

The reason I ask is to see what arguments are there for IEFU29. All of them 
are very good. I'm the last one to argue againts exit lovers. ;-D

But, Assembler skills are declining, I'm one of the handfull here who can 
conjure something up. Not in Gandalf the Grey's way, but I'm nearly there I'll 
admit... ;-D

Here we are using exits only if there are NO alternatives exist at all.

I'm using an Automation Tool to do all my SMF processing including 
intercepting any WTOs related to SMF switch, full, buffer, lost data, etc. The 
Automation Tool also sends alerts to our cell phones.

Also please see my post on 2010/11/03 in thread: 'How long for SMF to switch'

>It's more important to realise that there is no point in converting from one 
method to the other. It ain't broke!

Yes, Ted! If it is working and your business goals are reached, why try 
breaking it? 

I think it is time we return to poor Lizette (The OP of this thread) and 
resolve 
the original issue. ;-D

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How Many OMEGAMON ICATs Can Run At The Same Time?

[Vernooij, CP - SPLXM]

"George Henke"  wrote in message
news:...
> Is anyone able to run more than one ICAT (formerly CICAT) at the same
time,
> eg ICAT for CICS, ICAT for DB2, etc.
> 
> -- 
> George Henke

You mean: several users configuring Omegamon components simultaneaously?
I think they will collide regularly, because they are configuring the
same RTE.
The only way should be to separate them right from the beginning to
their own RTEs and datasets.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html