Re: How to suppress Message in REXX App

[Tony Harminc]

On 1 June 2012 18:14, Skip Robinson  wrote:
> TSO PROFILE command controls messages issued via PUTLINE, which invokes
> TSO services and is therefore suppressible within TSO. TPUT is an SVC that
> cannot be intercepted by TSO and therefore cannot be suppressed by TSO.

Uh, not exactly. While TSO does not "intercept" TPUTs, PROFILE
NOINTERCOM most certainly controls ordinary TPUTs from another address
space. However there is a "high priority" (can't remember the keyword)
option on x-mem TPUT that overrides NOINTERCOM. It requires APF
authorization. So much the worse for the design if the program really
is using this option to force its messages on the poor user.

But I don't know the product in question, and so if the TPUT is coming
from another address space; if it's running in the TSO address space
it can't be suppressed by NOINTERCOM.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Away monday, public holiday, back tuesday

[John Stevenson]

I will be out of the office starting 01/06/2012 and will return on
05/06/2012.

For anything urgent contact the Mainframe Services support number, x79371
or 04 924 9371


CAUTION - This message may contain privileged and confidential information 
intended only for the use of the addressee named above. If you are not the 
intended recipient of this message you are hereby notified that any use, 
dissemination, distribution or reproduction of this message is prohibited. 
This email was sent by the Bank of New Zealand. You can contact us on 
0800 ASK BNZ (0800 275 269). Any views expressed in this message are those 
of the individual sender and may not necessarily reflect the views of Bank 
of New Zealand.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Allocation mystery

[Shmuel Metz (Seymour J.)]

In <4fc7e1b0.6070...@trainersfriend.com>, on 05/31/2012
   at 03:25 PM, Steve Comstock  said:

>I'm finding an unexpected allocation situation
>that maybe someone can explain.

Are all of your datasets supposed to be SMS managed? If so, there is
an ACS issue. If not, it has always worked that way.
 
-- 
 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: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Shmuel Metz (Seymour J.)]

In <026801cd4015$ba6e3cd0$2f4ab670$@mindspring.com>, on 06/01/2012
   at 09:43 AM, Lizette Koehler  said:

>Does anyone know if this message can be suppressed from a TSO
>session?  IF so, suggestions?

Run under Session Manager?
 
-- 
 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: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Skip Robinson]

TSO PROFILE command controls messages issued via PUTLINE, which invokes 
TSO services and is therefore suppressible within TSO. TPUT is an SVC that 
cannot be intercepted by TSO and therefore cannot be suppressed by TSO. 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Scott Ford 
To: IBM-MAIN@bama.ua.edu
Date:   06/01/2012 03:04 PM
Subject:Re: How to suppress Message in REXX App
Sent by:IBM Mainframe Discussion List 



Yes, system

Scott ford
www.identityforge.com

On Jun 1, 2012, at 5:59 PM, Walt Farrell  wrote:

> On Fri, 1 Jun 2012 16:37:51 -0400, Scott Ford  
wrote:
> 
>> TPut will go to sysprint or systsprt
> 
> She's concerned about a TSO session, and there it will go to the 
terminal.
> 
> -- 
> Walt



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Scott Ford]

Yes, system

Scott ford
www.identityforge.com

On Jun 1, 2012, at 5:59 PM, Walt Farrell  wrote:

> On Fri, 1 Jun 2012 16:37:51 -0400, Scott Ford  wrote:
> 
>> TPut will go to sysprint or systsprt
> 
> She's concerned about a TSO session, and there it will go to the terminal.
> 
> -- 
> Walt
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Walt Farrell]

On Fri, 1 Jun 2012 16:37:51 -0400, Scott Ford  wrote:

>TPut will go to sysprint or systsprt

She's concerned about a TSO session, and there it will go to the terminal.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Brain drain: Where Cobol systems go from here

[Kirk Talman]

IBM Mainframe Discussion List  wrote on 05/23/2012 
05:39:26 PM:

> From: "Roberts, John J" 

> >When the last Cobol programmers walk out the door, so may 50 years 
> of business processes within the software they created. Will you be 
> ready?

> 
> Ed, Interesting article and fairly accurate IMO.
> 
> This is what I can foresee happening:
> (1) Many companies will try to offshore their COBOL application 
> support.  But this won't work so well because it is hard enough to 
> understand these systems without facing the complications of 
> language and arcane terminology.  And the young ones back in 
> Bangalore will want to do Java, not COBOL.

Actually the language is not a problem.  We have people here from multiple 
nations, some whose English is lacking.  But they can doing the 
programming work - well.

The problem is the lack of application knowledge.  We just had a senior 
person retire to a ranch in FL.  He was senior person in his critical 
application.  He ran a series of weekly one hour technical seminars.  The 
problem was that he could answer any question off the top of his head. But 
an organized overview and drill down into each part of the system and the 
relationship of that system to multiple other systems was not there.

He was used to being a S(ubject)M(atter)E(xpert)/guru.  Ask him a question 
and he could answer it or tell you where to find the answer.

Without that kind of person, trying to port the application to anything 
else is risky as is training newbies.

> (2) Other companies will want to recruit overseas, either for CS 
> grads that they can train, or for those few that are willing to 
> invest in COBOL learning if that is what it takes to punch that H1B 
> ticket.  But even so, once here they are all going to be looking to 
> do something else, not COBOL.  So that company that recruits and 
> trains a COBOL resource is going to be looking for a replacement 
> within a couple years.

We have had over the years training programs to build new Cobol 
programmers.  They work fine.  But again, the application knowledge is not 
in books.  It was transmitted by SMEs.

> (3) Efforts to train new young COBOL resources are going to flop, as
> the article mentions.  Again, everyone expects COBOL to be a career 
> dead-end once beyond a 5 to 10 year transition period.

Since Cobol is now talking to distributed applications in various ways, 
Cobol people are getting exposure to distributed applications.  I recently 
had a project transferred from me which was going to have me build part of 
an environment that is both mainframe and distributed.  As long as the 
documentation is there, there is not a huge chasm to cross.

> (4) In the end, US companies are going to be forced to pay a premium
> just to hang on to their old-timers long enough to buy time to 
> implement that new ERP package or new custom application.  The ones 
> that will be successful doing this are going to be the ones that 
> accommodate their senior developer's desires: lots of time off, 
> telecommuting, job sharing, benefits, etc.

Right now at the moment there are enough Cobol programmers leaving other 
companies that is still a supply of new people, some of which have fine 
skill sets.  But as time goes on, there will be a cliff.

I just returned from Germany.  There was talk there that there is an 
"engineering" shortage in the market there.  Never bothered with the 
details.  Maybe the recession there will give them time to kick the can 
down the road more.  After all, it has been working so well for dealing 
with their financial problems.

> John


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Brain drain: Where Cobol systems go from here

[Kirk Talman]

I refuse to walk out.  They will have to carry out in a box or bag.  After 
4 decades of doing Cobol on mainframe, it is less obnoxious than any 
alternative I have right now - and they pay you to do it and give you 
insurance.

Besides now I am getting back into assembler.  This is too much fun to 
quit.

IBM Mainframe Discussion List  wrote on 05/23/2012 
04:31:39 PM:

> From: Ed Gould 

> Brain drain: Where Cobol systems go from here

> -When the last Cobol programmers walk out the door, so may 50 years 
> of business processes within the software they created. Will you be 
> ready?

> http://www.computerworld.com/s/article/9227263/The_Cobol_Brain_Drain?
> taxonomyId=154


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Scott Ford]

Lizette,

TPut will go to sysprint or systsprt

Scott ford
www.identityforge.com

On Jun 1, 2012, at 4:16 PM, Lizette Koehler  wrote:

> Scott 
> 
> Yes the output is going to a outdsn
> 
> HLIST DSN('"dsnvar"') MCDS ODS('"tmpdsn"')
> 
> 
> I have set  TSO PROF NOINTERCOM NOPAUSE NOMSGID NOMODE  NOWTPMSG NORECOVER
> 
> I have added the turning off of MSG prior to the HLIST and restore it after 
> HLIST.
> 
> I think the problem as pointed out is a TPUT.  Which means I may not be able 
> to suppress it from the user's session.
> 
> Lizette
> 
> 
> -Original Message-
>> From: Scott Ford 
>> Sent: Jun 1, 2012 1:03 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: How to suppress Message in REXX App
>> 
>> Lizette,
>> 
>> Are you trapping the messages ?
>> 
>> Scott ford
>> www.identityforge.com
>> 
>> On Jun 1, 2012, at 12:43 PM, Lizette Koehler  wrote:
>> 
>>> Cross Posting to IBM Main and TSO-REXX
>>> 
>>> 
>>> I have a Rexx process that issues the HLIST command.  I have been successful
>>> in trapping the output from the HLIST but have an issue when the message
>>> 
>>> ARC0138I is issued.
>>> 
>>> I have tried turning off all of the TSO PROF functions (MSGID, INTERCOM,
>>> etc)
>>> I have tried turning off message for that section of the code MSG('OFF')
>>> 
>>> Any yet it keeps getting produced so the user has to keep hitting enter
>>> until they are cleared.
>>> 
>>> This message can be overwhelming if my user requests 100's of datasets that
>>> do not have an MCDS entry.
>>> 
>>> Does anyone know if this message can be suppressed from a TSO session?  IF
>>> so, suggestions?
>>> 
>>> Thanks
>>> 
>>> Lizette Koehler
>>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Dennis Trojak]

Liz,
 Since you are doing this within a REXX why not issue a LISTC command on the 
DSN first with the VOL parameter and see if the VOLSER is MIGRAT before you 
issue the HLIST command? That way you know the dataset is truly migrated.
Dennis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Lizette Koehler
Sent: Friday, June 01, 2012 3:16 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: How to suppress Message in REXX App

Scott 

Yes the output is going to a outdsn

HLIST DSN('"dsnvar"') MCDS ODS('"tmpdsn"')


I have set  TSO PROF NOINTERCOM NOPAUSE NOMSGID NOMODE  NOWTPMSG NORECOVER

I have added the turning off of MSG prior to the HLIST and restore it after 
HLIST.

I think the problem as pointed out is a TPUT.  Which means I may not be able to 
suppress it from the user's session.

Lizette


-Original Message-
>From: Scott Ford 
>Sent: Jun 1, 2012 1:03 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: How to suppress Message in REXX App
>
>Lizette,
>
>Are you trapping the messages ?
>
>Scott ford
>www.identityforge.com
>
>On Jun 1, 2012, at 12:43 PM, Lizette Koehler  wrote:
>
>> Cross Posting to IBM Main and TSO-REXX
>> 
>> 
>> I have a Rexx process that issues the HLIST command.  I have been 
>> successful in trapping the output from the HLIST but have an issue 
>> when the message
>> 
>> ARC0138I is issued.
>> 
>> I have tried turning off all of the TSO PROF functions (MSGID, 
>> INTERCOM,
>> etc)
>> I have tried turning off message for that section of the code 
>> MSG('OFF')
>> 
>> Any yet it keeps getting produced so the user has to keep hitting 
>> enter until they are cleared.
>> 
>> This message can be overwhelming if my user requests 100's of 
>> datasets that do not have an MCDS entry.
>> 
>> Does anyone know if this message can be suppressed from a TSO 
>> session?  IF so, suggestions?
>> 
>> Thanks
>> 
>> Lizette Koehler
>>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Lizette Koehler]

Scott 

Yes the output is going to a outdsn

HLIST DSN('"dsnvar"') MCDS ODS('"tmpdsn"')


I have set  TSO PROF NOINTERCOM NOPAUSE NOMSGID NOMODE  NOWTPMSG NORECOVER

I have added the turning off of MSG prior to the HLIST and restore it after 
HLIST.

I think the problem as pointed out is a TPUT.  Which means I may not be able to 
suppress it from the user's session.

Lizette


-Original Message-
>From: Scott Ford 
>Sent: Jun 1, 2012 1:03 PM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: How to suppress Message in REXX App
>
>Lizette,
>
>Are you trapping the messages ?
>
>Scott ford
>www.identityforge.com
>
>On Jun 1, 2012, at 12:43 PM, Lizette Koehler  wrote:
>
>> Cross Posting to IBM Main and TSO-REXX
>> 
>> 
>> I have a Rexx process that issues the HLIST command.  I have been successful
>> in trapping the output from the HLIST but have an issue when the message
>> 
>> ARC0138I is issued.
>> 
>> I have tried turning off all of the TSO PROF functions (MSGID, INTERCOM,
>> etc)
>> I have tried turning off message for that section of the code MSG('OFF')
>> 
>> Any yet it keeps getting produced so the user has to keep hitting enter
>> until they are cleared.
>> 
>> This message can be overwhelming if my user requests 100's of datasets that
>> do not have an MCDS entry.
>> 
>> Does anyone know if this message can be suppressed from a TSO session?  IF
>> so, suggestions?
>> 
>> Thanks
>> 
>> Lizette Koehler
>>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Scott Ford]

Lizette,

Are you trapping the messages ?

Scott ford
www.identityforge.com

On Jun 1, 2012, at 12:43 PM, Lizette Koehler  wrote:

> Cross Posting to IBM Main and TSO-REXX
> 
> 
> I have a Rexx process that issues the HLIST command.  I have been successful
> in trapping the output from the HLIST but have an issue when the message
> 
> ARC0138I is issued.
> 
> I have tried turning off all of the TSO PROF functions (MSGID, INTERCOM,
> etc)
> I have tried turning off message for that section of the code MSG('OFF')
> 
> Any yet it keeps getting produced so the user has to keep hitting enter
> until they are cleared.
> 
> This message can be overwhelming if my user requests 100's of datasets that
> do not have an MCDS entry.
> 
> Does anyone know if this message can be suppressed from a TSO session?  IF
> so, suggestions?
> 
> Thanks
> 
> Lizette Koehler
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

REXX USS directory list

[Roger Wasley]

Afternoon
I have been attempting to use SYSCALL READDIR and the fstat according to the 
manual but there seems to be no way to gath the DATE a USS file was accessed.

based on fstat st_type I knwo if it is a directory or file but not the date it 
was last accessed. I looked at the mtime field but either I misread it or it is 
no good

has anyone been able to do the READDIR or any other REXX SYSCALL and get the 
modfication date?

Many thanks

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Ed Gould]

Gil:

Maybe I am not understanding of your complaint.
The ARC message is sent to you as *YOU* requested some function from  
HSM.
HLIST for example is your request to DFHSM to list something (usually  
a DSN) and DFHSM is responding to your request.

So please explain why you are objecting to receiving the message?

Ed


On Jun 1, 2012, at 2:40 PM, Paul Gilmartin wrote:


On Fri, 1 Jun 2012 13:27:54 -0500, McKown, John wrote:

I don't know about that message in particular, but I know that the  
HSM started task often issues message via a directed TPUT having  
an option to deliver it to the userid which issued the HSM  
command. Similar to what the z/OS "SEND" commands does when sent  
by another TSO user or operator command. I don't know of any way  
to suppress it. Perhaps TSO PROFILE NOINTERCOM but I'm not in a  
position to try it. Makes me madder than you-know-where. Sometimes  
I'd like to strangle IBM developers.



Than behavior is _so_ 20th century.  The function needs to
be redesigned, at the very least to send the message to the
address space that requested the operation.  But IBM doesn't
care enough to do it right.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Paul Gilmartin]

On Fri, 1 Jun 2012 13:27:54 -0500, McKown, John wrote:

>I don't know about that message in particular, but I know that the HSM started 
>task often issues message via a directed TPUT having an option to deliver it 
>to the userid which issued the HSM command. Similar to what the z/OS "SEND" 
>commands does when sent by another TSO user or operator command. I don't know 
>of any way to suppress it. Perhaps TSO PROFILE NOINTERCOM but I'm not in a 
>position to try it. Makes me madder than you-know-where. Sometimes I'd like to 
>strangle IBM developers.
> 
Than behavior is _so_ 20th century.  The function needs to
be redesigned, at the very least to send the message to the
address space that requested the operation.  But IBM doesn't
care enough to do it right.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[Stocker, Herman]

Lizette,

MSGID only places the ID in the message.

In the TSO PROFILE have you tried NOWTPMSG
NOWTPMSG - SPECIFIES THE USER DOES NOT WISH TO RECEIVE WRITE TO
   PROGRAMMER MESSAGES AT HIS TERMINAL

I have not tested it but it may do what you want.

Regards,
Herman Stocker

It is impossible to make anything foolproof, because fools are so ingenious.
 -- Robert Heinlein


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Lizette Koehler
Sent: Friday, June 01, 2012 12:44 PM
To: IBM-MAIN@bama.ua.edu
Subject: How to suppress Message in REXX App

Cross Posting to IBM Main and TSO-REXX


I have a Rexx process that issues the HLIST command.  I have been successful in 
trapping the output from the HLIST but have an issue when the message

ARC0138I is issued.

I have tried turning off all of the TSO PROF functions (MSGID, INTERCOM,
etc)
I have tried turning off message for that section of the code MSG('OFF')

Any yet it keeps getting produced so the user has to keep hitting enter until 
they are cleared.

This message can be overwhelming if my user requests 100's of datasets that do 
not have an MCDS entry.

Does anyone know if this message can be suppressed from a TSO session?  IF so, 
suggestions?

Thanks

Lizette Koehler

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: INFO IBM-MAIN

 ---

The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during transmission. By reading the
message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. The sender's employer is not liable for any loss or damage
arising in any way from this message or its attachments.

 ---

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: How to suppress Message in REXX App

[McKown, John]

I don't know about that message in particular, but I know that the HSM started 
task often issues message via a directed TPUT having an option to deliver it to 
the userid which issued the HSM command. Similar to what the z/OS "SEND" 
commands does when sent by another TSO user or operator command. I don't know 
of any way to suppress it. Perhaps TSO PROFILE NOINTERCOM but I'm not in a 
position to try it. Makes me madder than you-know-where. Sometimes I'd like to 
strangle IBM developers.

-- 
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-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler
> Sent: Friday, June 01, 2012 11:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: How to suppress Message in REXX App
> 
> Cross Posting to IBM Main and TSO-REXX
> 
> 
> I have a Rexx process that issues the HLIST command.  I have 
> been successful
> in trapping the output from the HLIST but have an issue when 
> the message
> 
> ARC0138I is issued.
> 
> I have tried turning off all of the TSO PROF functions 
> (MSGID, INTERCOM,
> etc)
> I have tried turning off message for that section of the code 
> MSG('OFF')
> 
> Any yet it keeps getting produced so the user has to keep 
> hitting enter
> until they are cleared.
> 
> This message can be overwhelming if my user requests 100's of 
> datasets that
> do not have an MCDS entry.
> 
> Does anyone know if this message can be suppressed from a TSO 
> session?  IF
> so, suggestions?
> 
> Thanks
> 
> Lizette Koehler
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

How to suppress Message in REXX App

[Lizette Koehler]

Cross Posting to IBM Main and TSO-REXX


I have a Rexx process that issues the HLIST command.  I have been successful
in trapping the output from the HLIST but have an issue when the message

ARC0138I is issued.

I have tried turning off all of the TSO PROF functions (MSGID, INTERCOM,
etc)
I have tried turning off message for that section of the code MSG('OFF')

Any yet it keeps getting produced so the user has to keep hitting enter
until they are cleared.

This message can be overwhelming if my user requests 100's of datasets that
do not have an MCDS entry.

Does anyone know if this message can be suppressed from a TSO session?  IF
so, suggestions?

Thanks

Lizette Koehler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Allocation mystery

[Paul Gilmartin]

On Thu, 31 May 2012 19:31:04 -0600, Steve Comstock wrote:
>
>> Something has to specify the UNIT.  Does "LIKE" establish the
>> UNIT but not the VOL?  Strange.
>
>LIKE establishes neither; UNIT comes from the system default
>unit, usually SYSALLDA; VOL is chosen from available storage
>volumes.
> 
Humph!  I tried your DD statement on 1.12, without "LIKE":

 3 //STEP EXEC  PGM=IEFBR14 
 
 4 //NEWMASTDD  DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA  
   
 IEF210I JOBCARD STEP NEWMAST - UNIT FIELD SPECIFIES INCORRECT DEVICE NAME  
 IEF272I JOBCARD STEP - STEP WAS NOT EXECUTED.  
 
... so our system default is either not specified or misspecified.

M&C says:

#2.121 "z/OS V1R12.0 MVS System Messages, Vol 8 (IEF-IGD)" IBM Libra.. (p1 of 
3) 
   Library View Topics Framed Contents Revised Topics Previous Topic Next   
 
   Topic Search Search Results Previous Topic Match Next Topic Match Notes  
 
   List Notes Print Download Download PDF Handheld Disconnected Handheld
 
   Connected Help   
 
 ___
 

 
2.121 IEF210I   


 
   Explanation: In a DD statement, the unit name subparameter in the UNIT   
 
   parameter was incorrect: 
 

 
 * The unit is not defined to the current system configuration, or a
 
   demand request for a unit being added to the configuration occurred  
 
   prior to the dynamic configuration change completing.
 
 * If the DD statement specified a cataloged data set, the unit field   
 
   in the catalog entry is incorrect.   
 
 * The DD statement did not contain a UNIT parameter for a  
 
   non-cataloged, non-passed data set.  
 
 * The DD statement did not contain a DISP parameter, indicating a new  
 
   data set, and did not contain a UNIT parameter, indicating an old
 
   data set. 

It would be helpful if the message identified the incorrect unit name
and its provenance, and distinguished among the 4 cases (5, actually:
the first represents 2) in the bullets.  But that would be a step toward
self-explanatory messages, and I know the modal view on this forum
is that messages should _not_ be self-explanatory.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SMF log stream access

[John Eells]

Miklos Szigetvari wrote:

Hi

Any fast way to access the SMF log stream ?
Intend to collect, in the SMF log stream, the performance records
(30,14,15) for the actual day.

Have an assembler program to browse the log stream from the required
date/time, but it is still very slow

Tried with dump(IFASMFDL) and with SUBSYS=(LOGR) JCL , but seems to me,
it is not a very fast method.




Are you already collecting them in a separate log stream?  (You can send 
the same records to more than one log stream.)


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

BMC CMF

[Paul Peplinski]

We are looking at using CMF instead of RMF and would be interested in current 
user experience as far as compatibility (MXG, SCRT, reporting), reliability, 
and CPU consumption (including zIIP). Also if there are any benefits gained in 
Mainview by doing so.

Paul

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: SMF log stream access

[Charles Mills]

System exits IEFU83, IEFU84, and IEFU85.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Miklos Szigetvari
Sent: Friday, June 01, 2012 5:48 AM
To: IBM-MAIN@bama.ua.edu
Subject: SMF log stream access

Hi

Any fast way to access the SMF log stream ?
Intend to collect,  in the SMF log stream,  the performance records
(30,14,15) for the actual day.

Have an assembler program to browse the log stream from the required
date/time, but it is still very slow

Tried with dump(IFASMFDL)  and with SUBSYS=(LOGR) JCL , but seems to me, it
is not a very fast method.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

SMF log stream access

[Miklos Szigetvari]

Hi

Any fast way to access the SMF log stream ?
Intend to collect,  in the SMF log stream,  the performance records (30,14,15) 
for the actual day.

Have an assembler program to browse the log stream from the required date/time, 
but it is still very slow

Tried with dump(IFASMFDL)  and with SUBSYS=(LOGR) JCL , but seems to me, it is 
not a very fast method.


(I have already asked this in 2010 , maybe something new here)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: RMM DELETE VOLUME

[Gonzalo Cengotita]

Enrique,

It looks like you should use NOEJECT parm, since EJECT (which is the
default if using FORCE, REPLACE or REMOVE parms) try to access the
SMS-managed library.

This is from the manual "zOS V1R11.0 DFSMSrmm Guide and Reference"

   Task: Delete a volume if the SMS-managed library is no longer available.
   Command:
   RMM DELELETEVOLUME volser NOEJECT FORCE

   Chapter 9. Using RMM TSO subcommand

Let me know if it worked
Regards,

Gonzalo Cengotita


2012/6/1 ENRIQUE ELOI MONTERO ROMERO <
enriqueeloi.montero.contrac...@bbva.com>

> Hi team,
>
> This time the question is related to RMM DELETEVOLUME.
>
> We have several volumes as scratch, but they do not exist because the
> tape loader was turned off and is not connected.
> Just to clean the RMM, we want to delete such volumes from RMM. So we
> tried :
>
> > rmm dv VOL005
> Result : EDG3248I THE VOLUME IS ALREADY A SCRATCH VOLUME SO CANNOT BE
> RELEASED
>
> That is logical, in RMM it is an scratch volume, so we tried with :
>
>
> > rmm dv VOL005 force
> EDG3334I LIBRARY TYPE CANNOT BE DETERMINED
>
> > rmm dv VOL005 release
> EDG3248I THE VOLUME IS ALREADY A SCRATCH VOLUME SO CANNOT BE RELEASED
>
> > rmm dv VOL005 remove
> EDG3334I LIBRARY TYPE CANNOT BE DETERMINED
>
> I have no more ideas to remove those volumes.
>
> Some hints to remove it?
>
> Best regards, and happy week end.
>
> Enrique
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>



-- 
*
*
*Gonzalo Cengotita*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

RMM DELETE VOLUME

[ENRIQUE ELOI MONTERO ROMERO]

Hi team,

This time the question is related to RMM DELETEVOLUME.

We have several volumes as scratch, but they do not exist because the
tape loader was turned off and is not connected.
Just to clean the RMM, we want to delete such volumes from RMM. So we tried :

> rmm dv VOL005
Result : EDG3248I THE VOLUME IS ALREADY A SCRATCH VOLUME SO CANNOT BE RELEASED

That is logical, in RMM it is an scratch volume, so we tried with :


> rmm dv VOL005 force
EDG3334I LIBRARY TYPE CANNOT BE DETERMINED

> rmm dv VOL005 release
EDG3248I THE VOLUME IS ALREADY A SCRATCH VOLUME SO CANNOT BE RELEASED

> rmm dv VOL005 remove
EDG3334I LIBRARY TYPE CANNOT BE DETERMINED

I have no more ideas to remove those volumes.

Some hints to remove it?

Best regards, and happy week end.

Enrique

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: What is a PC Call?

[R.S.]

W dniu 2012-06-01 00:43, Mike Schwab pisze:

Just because they added something to the hardware, does not mean they
are ready to add it to the operating system.

When z/VM 6 came out, it required a z10 to run on, because they
changed the software to use hardware introduced with that processort.
Which means they need to support z/VM 5 on older processors until they
upgrade or exceed the reasonable hardware lifetime.

When z/OS 2.1 comes out, it will drop support for z/900 and z/990
processors so they can use hardware feature only available on newer
hardware.  You can still run z/OS 1.13 on older processor but not take
advantage of the newer hardware.


(my €0.02)
It is also possible to use new hardware features OPTIONALLY.
So, if HW >= z10 then exploit_new_features else use_legacy_code.

Good example of such approach was z/OS 1.1 - 1.5
It could run on 64-bit machine as well as on 31-bit machines.
IMHO the difference between 9672 G5 and z/900 was significantly bigger 
than difference between z/990 and z9 (z/OS V2) or z9 and z10 (z/VM V6).




--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN