Re: Rexx Detecting Value of MSG

[Paul Gilmartin]

On Wed, 20 Oct 2021 06:42:32 -0400, David Spiegel wrote:

>Hi Roops,
>Thank you for the suggestion.
>Unfortunately, I do not have UPDATE Access to the calling CLIST.
>If your assumption is correct, it looks like I will have to Front End my
>Rexx Exec with a CLIST that determines MSG/NOMSG and then calls Rexx
>with an argument for this.
>
Howeever, if that CLIST to which you lack UPDATE Access invokes your
Front End using EXEC, MSG will have reverted to default.


>On 2021-10-20 06:25, Rupert Reynolds wrote:
>> Reading that page, MSG seems to revert to default if you use EXEC to start
>> a new script.
>>
>> Pass it in as a parameter from CLIST and set it again?
>>>
>>> On 2021-10-19 22:24, Steve Horein wrote:
>>>> Maybe this?
>>>>
>>> [<https://www.ibm.com/docs/en/zos/2.4.0?topic=tef-msg>]

-- gil

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

Re: Rexx Detecting Value of MSG

[David Spiegel]

Hi Roops,
Thank you for the suggestion.
Unfortunately, I do not have UPDATE Access to the calling CLIST.
If your assumption is correct, it looks like I will have to Front End my 
Rexx Exec with a CLIST that determines MSG/NOMSG and then calls Rexx 
with an argument for this.


Regards,
David

On 2021-10-20 06:25, Rupert Reynolds wrote:

Reading that page, MSG seems to revert to default if you use EXEC to start
a new script.

Pass it in as a parameter from CLIST and set it again?

Roops

On Wed., Oct. 20, 2021, 03:45 David Spiegel, 
wrote:


Hi Steve.
I read that too, but, it does not seem to work in my case (Rexx Exec
called by CLIST).

Thanks and regards,
David

On 2021-10-19 22:24, Steve Horein wrote:

Maybe this?


https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.4.0%3Ftopic%3Dtef-msgdata=04%7C01%7C%7C589f8979d5194863e04d08d993b3fcc5%7C84df9e7fe9f640afb435%7C1%7C0%7C637703223569362818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JwaHnUOWLu8a3%2F%2BKk%2FaRs%2Bv0UqjJDSDQHiLGA7sCoOg%3Dreserved=0

On Tue, Oct 19, 2021 at 9:03 PM David Spiegel 
wrote:


Hi,
I am writing a Rexx Exec which is  invoked from a CLIST.
I would like the Rexx Exec to be able to obtain the value (set by the
calling CLIST) of CONTROL MSG/NOMSG .
Can someone suggest a method to do this (without resorting to

Assembler)?

Thank you in advance.
Regards,

David

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


-

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


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

Re: Rexx Detecting Value of MSG

[Rupert Reynolds]

Reading that page, MSG seems to revert to default if you use EXEC to start
a new script.

Pass it in as a parameter from CLIST and set it again?

Roops

On Wed., Oct. 20, 2021, 03:45 David Spiegel, 
wrote:

> Hi Steve.
> I read that too, but, it does not seem to work in my case (Rexx Exec
> called by CLIST).
>
> Thanks and regards,
> David
>
> On 2021-10-19 22:24, Steve Horein wrote:
> > Maybe this?
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.4.0%3Ftopic%3Dtef-msgdata=04%7C01%7C%7C1abc391437fb4a175dae08d99370bfce%7C84df9e7fe9f640afb435%7C1%7C0%7C637702934774024379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tB3Jw2X1Yaqg7vRn8BCz1H3AWbbCtsGK33LvgpUjwUM%3Dreserved=0
> >
> > On Tue, Oct 19, 2021 at 9:03 PM David Spiegel 
> > wrote:
> >
> >> Hi,
> >> I am writing a Rexx Exec which is  invoked from a CLIST.
> >> I would like the Rexx Exec to be able to obtain the value (set by the
> >> calling CLIST) of CONTROL MSG/NOMSG .
> >> Can someone suggest a method to do this (without resorting to
> Assembler)?
> >>
> >> Thank you in advance.
> >> Regards,
> >>
> >> David
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> > -
>

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

Re: Rexx Detecting Value of MSG

[David Spiegel]

Hi Steve.
I read that too, but, it does not seem to work in my case (Rexx Exec 
called by CLIST).


Thanks and regards,
David

On 2021-10-19 22:24, Steve Horein wrote:

Maybe this?
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.4.0%3Ftopic%3Dtef-msgdata=04%7C01%7C%7C1abc391437fb4a175dae08d99370bfce%7C84df9e7fe9f640afb435%7C1%7C0%7C637702934774024379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tB3Jw2X1Yaqg7vRn8BCz1H3AWbbCtsGK33LvgpUjwUM%3Dreserved=0

On Tue, Oct 19, 2021 at 9:03 PM David Spiegel 
wrote:


Hi,
I am writing a Rexx Exec which is  invoked from a CLIST.
I would like the Rexx Exec to be able to obtain the value (set by the
calling CLIST) of CONTROL MSG/NOMSG .
Can someone suggest a method to do this (without resorting to Assembler)?

Thank you in advance.
Regards,

David

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


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


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

Re: Rexx Detecting Value of MSG

[Steve Horein]

Maybe this?
https://www.ibm.com/docs/en/zos/2.4.0?topic=tef-msg

On Tue, Oct 19, 2021 at 9:03 PM David Spiegel 
wrote:

> Hi,
> I am writing a Rexx Exec which is  invoked from a CLIST.
> I would like the Rexx Exec to be able to obtain the value (set by the
> calling CLIST) of CONTROL MSG/NOMSG .
> Can someone suggest a method to do this (without resorting to Assembler)?
>
> Thank you in advance.
> Regards,
>
> David
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Rexx Detecting Value of MSG

[David Spiegel]

Hi,
I am writing a Rexx Exec which is  invoked from a CLIST.
I would like the Rexx Exec to be able to obtain the value (set by the 
calling CLIST) of CONTROL MSG/NOMSG .

Can someone suggest a method to do this (without resorting to Assembler)?

Thank you in advance.
Regards,

David

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

Re: MSG

[Seymour J Metz]

It would be helpful to include the message number in the subject.

As I recall, there is a discussion of SDSF security requirements in both the 
RACF and SDSF documentation. In addition to authorizing access to the SDSF 
address space, you will probably need to tailor authorization to commands. What 
are you currently doing for SDSF security?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Beaver [st...@stevebeaver.com]
Sent: Friday, March 19, 2021 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MSG

Has anyone seen this message before know how to fix the prblem

ISF458E Not authorized to connect to the SDSF server. Verify read
access to the ISF.CONNECT.system resource in the SDSF class.






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

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

Re: MSG

[Charles Mills]

Did you consider

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.e0zm100/SDSF_SDSFAUX_V2R3.htm 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steve Beaver
Sent: Friday, March 19, 2021 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MSG

Has anyone seen this message before know how to fix the prblem

ISF458E Not authorized to connect to the SDSF server. Verify read
access to the ISF.CONNECT.system resource in the SDSF class. 



 


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

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

Re: MSG

[Carmen Vitullo]

I forgot about the ISFPARM part, yes I set; 
  
   CONNECT AUXPROC(SDSFAUX),    AUXNAME(SDSFAUX),   
   AUXSAF(NOFAILRC4), 
   DEFAULT(YES) 
Carmen Vitullo 

   

-Original Message-

From: Todd <0316e668f7df-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN 
Date: Friday, 19 March 2021 10:32 AM CDT
Subject: Re: MSG

Try doing a SET SECTRACE in SDSF and then re-attempt the failing command. You 
should get a good amount of info in the SYSLOG to help resolve. 

We ran into some similar issues when going to 2.4. 

We also set this in SDSF to resolve when some things are not defined:

CONNECT DEFAULT(COND),/* Default server if not already assigned */ 
AUXSAF(NOFAILRC4), 

Thanks

Todd Burrell | Sr. IT Systems Engineer | Mainframe

todd.burr...@bcbsfl.com
M 404.723.2017



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Friday, March 19, 2021 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MSG

Has anyone seen this message before know how to fix the prblem

ISF458E Not authorized to connect to the SDSF server. Verify read access to the 
ISF.CONNECT.system resource in the SDSF class. 






--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
We comply with applicable Federal civil rights laws and do not discriminate.

You may access the Non-Discrimination and Accessibility Notice here 
<http://floridablue.com/ndnotice>.

Language Assistance Available:

Español, Kreyol Ayisien, Tiếng Việt, Português, 中文, français, Tagalog, русский, 
italiano, Deutsche, 한국어, Polskie, Gujarati, ไทย, العربية, 日本語, فارسی 
<http://floridablue.com/languageservices>

Florida Blue is a trade name of Blue Cross and Blue Shield of Florida, Inc. 
Blue Cross and Blue Shield of Florida, Inc., and its subsidiary and affiliate 
companies are not responsible for errors or omissions in this e-mail message. 
Any personal comments made in this e-mail do not reflect the views of Blue 
Cross and Blue Shield of Florida, Inc. The information contained in this 
document may be confidential and intended solely for the use of the individual 
or entity to whom it is addressed. This document may contain material that is 
privileged or protected from disclosure under applicable law. If you are not 
the intended recipient or the individual responsible for delivering to the 
intended recipient, please (1) be advised that any use, dissemination, 
forwarding, or copying of this document IS STRICTLY PROHIBITED; and (2) notify 
sender immediately by telephone and destroy the document. THANK YOU.


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

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

Re: MSG

[Carmen Vitullo]

It's been a long time since the SDSFAUX address space has been used for certain 
SDSF functions, When I first saw this message, I want to say back in z/OS 2.2 I 
used the migration guide + the SDSF operations and customization Guide to 
define all the new security resources I needed. once defined no more error 
messages   
   
Carmen Vitullo 

   

-Original Message-

From: Steve 
To: IBM-MAIN 
Date: Friday, 19 March 2021 10:27 AM CDT
Subject: MSG

Has anyone seen this message before know how to fix the prblem 

ISF458E Not authorized to connect to the SDSF server. Verify read 
access to the ISF.CONNECT.system resource in the SDSF class. 






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

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

Re: MSG

[Burrell, Todd]

Try doing a SET SECTRACE in SDSF and then re-attempt the failing command.  You 
should get a good amount of info in the SYSLOG to help resolve.  

We ran into some similar issues when going to 2.4. 

We also set this in SDSF to resolve when some things are not defined:

CONNECT DEFAULT(COND),/* Default server if not already assigned*/ 
  AUXSAF(NOFAILRC4),  

Thanks

Todd Burrell | Sr. IT Systems Engineer | Mainframe

todd.burr...@bcbsfl.com
M 404.723.2017



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Friday, March 19, 2021 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MSG

Has anyone seen this message before know how to fix the prblem

ISF458E Not authorized to connect to the SDSF server. Verify read access to the 
ISF.CONNECT.system resource in the SDSF class. 



 


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
We comply with applicable Federal civil rights laws and do not discriminate.

You may access the Non-Discrimination and Accessibility Notice here 
<http://floridablue.com/ndnotice>.

Language Assistance Available:

Español, Kreyol Ayisien, Tiếng Việt, Português, 中文, français, Tagalog, русский, 
italiano, Deutsche, 한국어, Polskie, Gujarati, ไทย, العربية, 日本語, فارسی 
<http://floridablue.com/languageservices>

Florida Blue is a trade name of Blue Cross and Blue Shield of Florida, Inc.  
Blue Cross and Blue Shield of Florida, Inc., and its subsidiary and affiliate 
companies are not responsible for errors or omissions in this e-mail message. 
Any personal comments made in this e-mail do not reflect the views of Blue 
Cross and Blue Shield of Florida, Inc.  The information contained in this 
document may be confidential and intended solely for the use of the individual 
or entity to whom it is addressed.  This document may contain material that is 
privileged or protected from disclosure under applicable law.  If you are not 
the intended recipient or the individual responsible for delivering to the 
intended recipient, please (1) be advised that any use, dissemination, 
forwarding, or copying of this document IS STRICTLY PROHIBITED; and (2) notify 
sender immediately by telephone and destroy the document. THANK YOU.


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

MSG

[Steve Beaver]

Has anyone seen this message before know how to fix the prblem

ISF458E Not authorized to connect to the SDSF server. Verify read
access to the ISF.CONNECT.system resource in the SDSF class. 



 


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

Re: BPXBATCH getting unexptected msg: INVALID LABEL

[Steve Lee]

you right! just oversight "4" IEFC662I INVALID LABEL, thank you too.

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

Re: BPXBATCH getting unexptected msg: INVALID LABEL

[Jon Perryman]

 In the future, you can easily help yourself by looking at the JCL expansion 
which has statement numbers and formatted output. The error message points you 
to the specific statement in error.

Jon.

On Saturday, October 5, 2019, 04:11:24 PM PDT, Rich Tabor 
 wrote:  
 
 //Val1  label has lower case letters

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Lee
Sent: Saturday, October 5, 2019 3:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] BPXBATCH getting unexptected msg: INVALID LABEL

Dear, 

when running a simple BPXBATCH with //STDPARM DD, get an error INVALID LABEL, 
which is nothing else that looks like a reference to a LABEL. 


the Step releasing is below: 
//Val1 EXEC PGM=BPXBATCH,REGION=0M,TIME=NOLIMIT
//*COND=(0,LT)
//*
//STDPARM DD *
sh cd /var/CareFirst/CAMSM/R60/msm/;
ls -RE
/*
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
// 

**    

IEFC452I AAD3382Z - JOB NOT RUN - JCL ERROR    279
STMT NO. MESSAGE
4 IEFC662I INVALID LABEL


Any input would greatly be appreciated. 
Steve 

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

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

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

Re: BPXBATCH getting unexptected msg: INVALID LABEL

[Steve Lee]

Oops thanks!!!

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

Re: BPXBATCH getting unexptected msg: INVALID LABEL

[Rich Tabor]

//Val1  label has lower case letters

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Lee
Sent: Saturday, October 5, 2019 3:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] BPXBATCH getting unexptected msg: INVALID LABEL

Dear, 

when running a simple BPXBATCH with //STDPARM DD, get an error INVALID LABEL, 
which is nothing else that looks like a reference to a LABEL. 


the Step releasing is below: 
//Val1 EXEC PGM=BPXBATCH,REGION=0M,TIME=NOLIMIT
//*COND=(0,LT)
//*
//STDPARM DD *
sh cd /var/CareFirst/CAMSM/R60/msm/;
ls -RE
/*
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
// 

** 

IEFC452I AAD3382Z - JOB NOT RUN - JCL ERROR 279
STMT NO. MESSAGE
4 IEFC662I INVALID LABEL


Any input would greatly be appreciated. 
Steve 

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

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

BPXBATCH getting unexptected msg: INVALID LABEL

[Steve Lee]

Dear, 

when running a simple BPXBATCH with //STDPARM DD, get an error INVALID LABEL, 
which is nothing else that looks like a reference to a LABEL. 


the Step releasing is below: 
//Val1 EXEC PGM=BPXBATCH,REGION=0M,TIME=NOLIMIT
//*COND=(0,LT)
//*
//STDPARM DD *
sh cd /var/CareFirst/CAMSM/R60/msm/;
ls -RE
/*
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
// 

** 

IEFC452I AAD3382Z - JOB NOT RUN - JCL ERROR 279
STMT NO. MESSAGE
4 IEFC662I INVALID LABEL


Any input would greatly be appreciated. 
Steve 

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

Re: ISMF msg

[Mark Pace]

I did not.  Wish I had thought to do that.

Thanks for the reminder though.

On Fri, Mar 8, 2019 at 2:28 PM Mark Pace  wrote:

> This is a test system where no one is allowed except me.
>
> On Fri, Mar 8, 2019 at 12:53 PM Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
>> Mark Pace wrote:
>>
>> >I checked in RACF and I had no rules protecting the SYS3 datasets, so I
>> don't think that was the issue.
>>
>> No 'rules'? This is not looking good, but then, it should probably not
>> affect your issue, AFAIK.
>>
>> Do you have any profiles defined at all or have something in the Global
>> Access Table?
>>
>> What is your PROTECTALL status in RACF?
>>
>> Groete / Greetings
>> Elardus Engelbrecht
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
>
>
>

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: ISMF msg

[Mark Pace]

This is a test system where no one is allowed except me.

On Fri, Mar 8, 2019 at 12:53 PM Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Mark Pace wrote:
>
> >I checked in RACF and I had no rules protecting the SYS3 datasets, so I
> don't think that was the issue.
>
> No 'rules'? This is not looking good, but then, it should probably not
> affect your issue, AFAIK.
>
> Do you have any profiles defined at all or have something in the Global
> Access Table?
>
> What is your PROTECTALL status in RACF?
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: ISMF msg

[Chuck Kreiter]

Did you press F1 after getting RC=08 in ISMF.  Sometimes you can get a better 
explanation that way.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Friday, March 8, 2019 12:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISMF msg

I fixed it, but not sure why/how it wasn't working.
At some point I remember my SYS1.DFSMS.SCDS was missing the correct 
configuration.  The ACDS was correct, but I wasn't sure how to get it retrieve 
in to an SCDS. I finally remembered that I could save the ACDS into a new SCDS. 
 That became SYS3.DFSMS.SCDS.  I made SYS3.DFSMS.SCDS the current SCDS and it 
was that one I was trying to update.  So I tried to SAVESCDS to the old 
SYS1.DFSMS.SCDS.  That worked and I can now update SYS1.DFSMS.SCDS with the new 
volume and activate it.

I checked in RACF and I had no rules protecting the SYS3 datasets, so I don't 
think that was the issue.

On Fri, Mar 8, 2019 at 11:55 AM Carmen Vitullo  wrote:

> YW! WOW that's a lot of 'stuff'
> hope you get it figured out, let us know
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Mark Pace" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, March 8, 2019 10:49:57 AM
> Subject: Re: ISMF msg
>
> Thanks for the pointer. Now to figure out what it is telling me.
>
> 11:47 Start of ISPF Log - - - - Session # 1580
> ---
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG);
> FUNCTION(VOLUME)
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS
>
> 11:48 - DGTUV035 RETURN CODE(0008); REASON
> CODE(6131)
> 11:48 - DGTUV027 MODULE(IGDCSU10); PROCEDURE()
>
> 11:48 - DGTUV028 MESSAGE ID( - ); LAST
> PANEL(DGTDCSG7)
> 11:48 - DGTUV029 SERVICE(SMS/CS);
> FEEDBACK(SUBRET: 0 SUBRSN: 0)
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG);
> FUNCTION(VOLUME)
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS
>
> 11:48 - DGTUV035 RETURN CODE(0012); REASON
> CODE(3117)
> 11:48 - DGTUV027 MODULE(DGTFCFAC);
> PROCEDURE(DGTFCFAC)
> 11:48 - DGTUV028 MESSAGE ID(DGTUC051 - DGTUC051); LAST PANEL(DGTDCSG7)
> 11:48 - DGTUV029 SERVICE(SMS/CS);
> FEEDBACK(ACCESS, CSI ACCESS MODE = W)
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG);
> FUNCTION(VOLUME)
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS
>
> 11:48 - DGTUV035 RETURN CODE(0012); REASON
> CODE(3117)
> 11:48 - DGTUV027 MODULE(DGTFSGP3);
> PROCEDURE(ACCESS)
> 11:48 - DGTUV028 MESSAGE ID( - ); LAST
> PANEL(DGTDCSG7)
> 11:48 - DGTUV029 SERVICE(DGTECFAC);
> FEEDBACK(CALLMOD:DGTFSGSV CALLPROC:PROCOP2P)
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG);
> FUNCTION(VOLUME)
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS
>
> 11:48 - DGTUV035 RETURN CODE(0012); REASON
> CODE(3221)
> 11:48 - DGTUV027 MODULE(DGTFSGVR);
> PROCEDURE(VOSEL)
> 11:48 - DGTUV028 MESSAGE ID( - ); LAST
> PANEL(DGTDCSG7)
> 11:48 - DGTUV029 SERVICE(NONE);
> FEEDBACK(ELEMENT NAME: TMPSG1)
>
> On Fri, Mar 8, 2019 at 11:40 AM Carmen Vitullo 
> wrote:
>
> > some if the ISMF messages may have just gone to the ISPF log, you 
> > may
> wnat
> > to check 7.5 to see if the log is active and if any messages are 
> > there , just a thought
> >
> >
> > Carmen Vitullo
> >
> > - Original Message -
> >
> > From: "Mark Pace" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Sent: Friday, March 8, 2019 10:38:05 AM
> > Subject: Re: ISMF msg
> >
> > I'm NOT running HSM.
> >
> > On Fri, Mar 8, 2019 at 11:37 AM Mark Pace 
> wrote:
> >
> > > I'm running HSM, no started task to look at.
> > >
> > > I'll check on my TSO profile.
> > >
> > > On Fri, Mar 8, 2019 at 11:22 AM Lizette Koehler <
> stars...@mindspring.com>
> >
> > > wrote:
> > >
> > >> Sometime the messages come back to the tso session when using ISMF.
> > >>
> > >> Check your TSO PROFILE and make sure you are not suppressing them
> > >>
> > >> You could also check the DFHSM STC Task for the messages, they 
> > >> could
> be
> > >> there as well.
> > >>
> > >>
> > >> Lizette
> > >>
> > >>
> > >> > -Original Message-
> > >> > From: IBM Mainframe Discussion List  
> > >> > On
> > >> Behalf Of
> > >> > Mark Pace
> > >> > Sent: Friday, March 08, 2019 9:16 AM
> > >> > To: IBM-MAIN@LISTSERV.UA.EDU
> > >> > Subject: ISMF msg
> > >> >

Re: ISMF msg

[Carmen Vitullo]

great! the SYS3 dataset still may have caused the issue if you're in a protect 
all configuration. 
I still have the notes from z/os 1.3 on how to recreate a SCDS from an ACDS. 
good stuff and good that it's still a valid fix ! 



Carmen Vitullo 

- Original Message -

From: "Mark Pace"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 8, 2019 11:23:43 AM 
Subject: Re: ISMF msg 

I fixed it, but not sure why/how it wasn't working. 
At some point I remember my SYS1.DFSMS.SCDS was missing the correct 
configuration. The ACDS was correct, but I wasn't sure how to get it 
retrieve in to an SCDS. I finally remembered that I could save the ACDS 
into a new SCDS. That became SYS3.DFSMS.SCDS. I made SYS3.DFSMS.SCDS the 
current SCDS and it was that one I was trying to update. So I tried to 
SAVESCDS to the old SYS1.DFSMS.SCDS. That worked and I can now update 
SYS1.DFSMS.SCDS with the new volume and activate it. 

I checked in RACF and I had no rules protecting the SYS3 datasets, so I 
don't think that was the issue. 

On Fri, Mar 8, 2019 at 11:55 AM Carmen Vitullo  wrote: 

> YW! WOW that's a lot of 'stuff' 
> hope you get it figured out, let us know 
> 
> 
> 
> Carmen Vitullo 
> 
> - Original Message - 
> 
> From: "Mark Pace"  
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Sent: Friday, March 8, 2019 10:49:57 AM 
> Subject: Re: ISMF msg 
> 
> Thanks for the pointer. Now to figure out what it is telling me. 
> 
> 11:47 Start of ISPF Log - - - - Session # 1580 
> --- 
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG); 
> FUNCTION(VOLUME) 
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS 
> 
> 11:48 - DGTUV035 RETURN CODE(0008); REASON 
> CODE(6131) 
> 11:48 - DGTUV027 MODULE(IGDCSU10); PROCEDURE() 
> 
> 11:48 - DGTUV028 MESSAGE ID( - ); LAST 
> PANEL(DGTDCSG7) 
> 11:48 - DGTUV029 SERVICE(SMS/CS); 
> FEEDBACK(SUBRET: 0 SUBRSN: 0) 
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG); 
> FUNCTION(VOLUME) 
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS 
> 
> 11:48 - DGTUV035 RETURN CODE(0012); REASON 
> CODE(3117) 
> 11:48 - DGTUV027 MODULE(DGTFCFAC); 
> PROCEDURE(DGTFCFAC) 
> 11:48 - DGTUV028 MESSAGE ID(DGTUC051 - 
> DGTUC051); LAST PANEL(DGTDCSG7) 
> 11:48 - DGTUV029 SERVICE(SMS/CS); 
> FEEDBACK(ACCESS, CSI ACCESS MODE = W) 
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG); 
> FUNCTION(VOLUME) 
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS 
> 
> 11:48 - DGTUV035 RETURN CODE(0012); REASON 
> CODE(3117) 
> 11:48 - DGTUV027 MODULE(DGTFSGP3); 
> PROCEDURE(ACCESS) 
> 11:48 - DGTUV028 MESSAGE ID( - ); LAST 
> PANEL(DGTDCSG7) 
> 11:48 - DGTUV029 SERVICE(DGTECFAC); 
> FEEDBACK(CALLMOD:DGTFSGSV CALLPROC:PROCOP2P) 
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG); 
> FUNCTION(VOLUME) 
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS 
> 
> 11:48 - DGTUV035 RETURN CODE(0012); REASON 
> CODE(3221) 
> 11:48 - DGTUV027 MODULE(DGTFSGVR); 
> PROCEDURE(VOSEL) 
> 11:48 - DGTUV028 MESSAGE ID( - ); LAST 
> PANEL(DGTDCSG7) 
> 11:48 - DGTUV029 SERVICE(NONE); 
> FEEDBACK(ELEMENT NAME: TMPSG1) 
> 
> On Fri, Mar 8, 2019 at 11:40 AM Carmen Vitullo  
> wrote: 
> 
> > some if the ISMF messages may have just gone to the ISPF log, you may 
> wnat 
> > to check 7.5 to see if the log is active and if any messages are there , 
> > just a thought 
> > 
> > 
> > Carmen Vitullo 
> > 
> > - Original Message - 
> > 
> > From: "Mark Pace"  
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Sent: Friday, March 8, 2019 10:38:05 AM 
> > Subject: Re: ISMF msg 
> > 
> > I'm NOT running HSM. 
> > 
> > On Fri, Mar 8, 2019 at 11:37 AM Mark Pace  
> wrote: 
> > 
> > > I'm running HSM, no started task to look at. 
> > > 
> > > I'll check on my TSO profile. 
> > > 
> > > On Fri, Mar 8, 2019 at 11:22 AM Lizette Koehler < 
> stars...@mindspring.com> 
> > 
> > > wrote: 
> > > 
> > >> Sometime the messages come back to the tso session when using ISMF. 
> > >> 
> > >> Check your TSO PROFILE and make sure you are not suppressing them 
> > >> 
> > >> You could also check the DFHSM STC Task for the messages, they could 
> be 
> > >> there as well. 
> > >> 
> > >> 
> > >> Lizette 
> > >> 
> > >> 
> > >> > -Original Message- 
> > >> > From: IBM Mainframe Discussion List  On 
> > >> Behalf Of 
> > >> > Mark Pace 
> > >> > Sent: Friday, March 08, 2019 9:16 AM 
> > &g

Re: ISMF msg

[Elardus Engelbrecht]

Mark Pace wrote:

>I checked in RACF and I had no rules protecting the SYS3 datasets, so I don't 
>think that was the issue.

No 'rules'? This is not looking good, but then, it should probably not affect 
your issue, AFAIK. 

Do you have any profiles defined at all or have something in the Global Access 
Table?

What is your PROTECTALL status in RACF?

Groete / Greetings
Elardus Engelbrecht

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

Re: ISMF msg

[Mark Pace]

I fixed it, but not sure why/how it wasn't working.
At some point I remember my SYS1.DFSMS.SCDS was missing the correct
configuration.  The ACDS was correct, but I wasn't sure how to get it
retrieve in to an SCDS. I finally remembered that I could save the ACDS
into a new SCDS.  That became SYS3.DFSMS.SCDS.  I made SYS3.DFSMS.SCDS the
current SCDS and it was that one I was trying to update.  So I tried to
SAVESCDS to the old SYS1.DFSMS.SCDS.  That worked and I can now update
SYS1.DFSMS.SCDS with the new volume and activate it.

I checked in RACF and I had no rules protecting the SYS3 datasets, so I
don't think that was the issue.

On Fri, Mar 8, 2019 at 11:55 AM Carmen Vitullo  wrote:

> YW! WOW that's a lot of 'stuff'
> hope you get it figured out, let us know
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Mark Pace" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, March 8, 2019 10:49:57 AM
> Subject: Re: ISMF msg
>
> Thanks for the pointer. Now to figure out what it is telling me.
>
> 11:47 Start of ISPF Log - - - - Session # 1580
> ---
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG);
> FUNCTION(VOLUME)
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS
>
> 11:48 - DGTUV035 RETURN CODE(0008); REASON
> CODE(6131)
> 11:48 - DGTUV027 MODULE(IGDCSU10); PROCEDURE()
>
> 11:48 - DGTUV028 MESSAGE ID( - ); LAST
> PANEL(DGTDCSG7)
> 11:48 - DGTUV029 SERVICE(SMS/CS);
> FEEDBACK(SUBRET: 0 SUBRSN: 0)
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG);
> FUNCTION(VOLUME)
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS
>
> 11:48 - DGTUV035 RETURN CODE(0012); REASON
> CODE(3117)
> 11:48 - DGTUV027 MODULE(DGTFCFAC);
> PROCEDURE(DGTFCFAC)
> 11:48 - DGTUV028 MESSAGE ID(DGTUC051 -
> DGTUC051); LAST PANEL(DGTDCSG7)
> 11:48 - DGTUV029 SERVICE(SMS/CS);
> FEEDBACK(ACCESS, CSI ACCESS MODE = W)
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG);
> FUNCTION(VOLUME)
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS
>
> 11:48 - DGTUV035 RETURN CODE(0012); REASON
> CODE(3117)
> 11:48 - DGTUV027 MODULE(DGTFSGP3);
> PROCEDURE(ACCESS)
> 11:48 - DGTUV028 MESSAGE ID( - ); LAST
> PANEL(DGTDCSG7)
> 11:48 - DGTUV029 SERVICE(DGTECFAC);
> FEEDBACK(CALLMOD:DGTFSGSV CALLPROC:PROCOP2P)
> 11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG);
> FUNCTION(VOLUME)
> 11:48 - DGTUV039 SYS3.DFSMS.SCDS
>
> 11:48 - DGTUV035 RETURN CODE(0012); REASON
> CODE(3221)
> 11:48 - DGTUV027 MODULE(DGTFSGVR);
> PROCEDURE(VOSEL)
> 11:48 - DGTUV028 MESSAGE ID( - ); LAST
> PANEL(DGTDCSG7)
> 11:48 - DGTUV029 SERVICE(NONE);
> FEEDBACK(ELEMENT NAME: TMPSG1)
>
> On Fri, Mar 8, 2019 at 11:40 AM Carmen Vitullo 
> wrote:
>
> > some if the ISMF messages may have just gone to the ISPF log, you may
> wnat
> > to check 7.5 to see if the log is active and if any messages are there ,
> > just a thought
> >
> >
> > Carmen Vitullo
> >
> > - Original Message -
> >
> > From: "Mark Pace" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Sent: Friday, March 8, 2019 10:38:05 AM
> > Subject: Re: ISMF msg
> >
> > I'm NOT running HSM.
> >
> > On Fri, Mar 8, 2019 at 11:37 AM Mark Pace 
> wrote:
> >
> > > I'm running HSM, no started task to look at.
> > >
> > > I'll check on my TSO profile.
> > >
> > > On Fri, Mar 8, 2019 at 11:22 AM Lizette Koehler <
> stars...@mindspring.com>
> >
> > > wrote:
> > >
> > >> Sometime the messages come back to the tso session when using ISMF.
> > >>
> > >> Check your TSO PROFILE and make sure you are not suppressing them
> > >>
> > >> You could also check the DFHSM STC Task for the messages, they could
> be
> > >> there as well.
> > >>
> > >>
> > >> Lizette
> > >>
> > >>
> > >> > -Original Message-
> > >> > From: IBM Mainframe Discussion List  On
> > >> Behalf Of
> > >> > Mark Pace
> > >> > Sent: Friday, March 08, 2019 9:16 AM
> > >> > To: IBM-MAIN@LISTSERV.UA.EDU
> > >> > Subject: ISMF msg
> > >> >
> > >> > I'm trying to add a new volume to a storage pool.
> > >> >
> > >> > When I try to add I get this message on the Panel - SMS RETCODE:
> > >> 8
> > >> >
> > >> > Searching google it points to ARC0940I - which tells me to look are
> > >> preceding
> > >> > ARCxxx messages. I am not seeing any ARC messa

Re: ISMF msg

[Carmen Vitullo]

YW! WOW that's a lot of 'stuff' 
hope you get it figured out, let us know 



Carmen Vitullo 

- Original Message -

From: "Mark Pace"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 8, 2019 10:49:57 AM 
Subject: Re: ISMF msg 

Thanks for the pointer. Now to figure out what it is telling me. 

11:47 Start of ISPF Log - - - - Session # 1580 
--- 
11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG); 
FUNCTION(VOLUME) 
11:48 - DGTUV039 SYS3.DFSMS.SCDS 

11:48 - DGTUV035 RETURN CODE(0008); REASON 
CODE(6131) 
11:48 - DGTUV027 MODULE(IGDCSU10); PROCEDURE() 

11:48 - DGTUV028 MESSAGE ID( - ); LAST 
PANEL(DGTDCSG7) 
11:48 - DGTUV029 SERVICE(SMS/CS); 
FEEDBACK(SUBRET: 0 SUBRSN: 0) 
11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG); 
FUNCTION(VOLUME) 
11:48 - DGTUV039 SYS3.DFSMS.SCDS 

11:48 - DGTUV035 RETURN CODE(0012); REASON 
CODE(3117) 
11:48 - DGTUV027 MODULE(DGTFCFAC); 
PROCEDURE(DGTFCFAC) 
11:48 - DGTUV028 MESSAGE ID(DGTUC051 - 
DGTUC051); LAST PANEL(DGTDCSG7) 
11:48 - DGTUV029 SERVICE(SMS/CS); 
FEEDBACK(ACCESS, CSI ACCESS MODE = W) 
11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG); 
FUNCTION(VOLUME) 
11:48 - DGTUV039 SYS3.DFSMS.SCDS 

11:48 - DGTUV035 RETURN CODE(0012); REASON 
CODE(3117) 
11:48 - DGTUV027 MODULE(DGTFSGP3); 
PROCEDURE(ACCESS) 
11:48 - DGTUV028 MESSAGE ID( - ); LAST 
PANEL(DGTDCSG7) 
11:48 - DGTUV029 SERVICE(DGTECFAC); 
FEEDBACK(CALLMOD:DGTFSGSV CALLPROC:PROCOP2P) 
11:48 * ISMF ERROR * - DGTUV034 APPLICATION(DGT6 - SG); 
FUNCTION(VOLUME) 
11:48 - DGTUV039 SYS3.DFSMS.SCDS 

11:48 - DGTUV035 RETURN CODE(0012); REASON 
CODE(3221) 
11:48 - DGTUV027 MODULE(DGTFSGVR); 
PROCEDURE(VOSEL) 
11:48 - DGTUV028 MESSAGE ID( - ); LAST 
PANEL(DGTDCSG7) 
11:48 - DGTUV029 SERVICE(NONE); 
FEEDBACK(ELEMENT NAME: TMPSG1) 

On Fri, Mar 8, 2019 at 11:40 AM Carmen Vitullo  wrote: 

> some if the ISMF messages may have just gone to the ISPF log, you may wnat 
> to check 7.5 to see if the log is active and if any messages are there , 
> just a thought 
> 
> 
> Carmen Vitullo 
> 
> - Original Message - 
> 
> From: "Mark Pace"  
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Sent: Friday, March 8, 2019 10:38:05 AM 
> Subject: Re: ISMF msg 
> 
> I'm NOT running HSM. 
> 
> On Fri, Mar 8, 2019 at 11:37 AM Mark Pace  wrote: 
> 
> > I'm running HSM, no started task to look at. 
> > 
> > I'll check on my TSO profile. 
> > 
> > On Fri, Mar 8, 2019 at 11:22 AM Lizette Koehler  
> 
> > wrote: 
> > 
> >> Sometime the messages come back to the tso session when using ISMF. 
> >> 
> >> Check your TSO PROFILE and make sure you are not suppressing them 
> >> 
> >> You could also check the DFHSM STC Task for the messages, they could be 
> >> there as well. 
> >> 
> >> 
> >> Lizette 
> >> 
> >> 
> >> > -Original Message- 
> >> > From: IBM Mainframe Discussion List  On 
> >> Behalf Of 
> >> > Mark Pace 
> >> > Sent: Friday, March 08, 2019 9:16 AM 
> >> > To: IBM-MAIN@LISTSERV.UA.EDU 
> >> > Subject: ISMF msg 
> >> > 
> >> > I'm trying to add a new volume to a storage pool. 
> >> > 
> >> > When I try to add I get this message on the Panel - SMS RETCODE: 
> >> 8 
> >> > 
> >> > Searching google it points to ARC0940I - which tells me to look are 
> >> preceding 
> >> > ARCxxx messages. I am not seeing any ARC messages on the console or 
> >> system 
> >> > log. I thought ARC messages came out of HSM, but I am not running 
> HSM. 
> >> > 
> >> > -- 
> >> > The postings on this site are my own and don’t necessarily represent 
> >> > Mainline’s positions or opinions 
> >> > 
> >> > Mark D Pace 
> >> > Senior Systems Engineer 
> >> > Mainline Information Systems 
> >> > 
> >> > 
> -- 
> >> > For IBM-MAIN subscribe / signoff / archive access instructions, send 
> >> email to 
> >> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> >> 
> >> -- 
> >> For IBM-MAIN subscribe / signoff / archive access instructions, 
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> >> 
> > 
> > 
> > -- 
> > The postings on this site are my own and don’t necessarily represent 
> > Mainline’s positions or opinions 
> > 
> >

Re: ISMF msg

[Mark Pace]

Thanks for the pointer.  Now to figure out what it is telling me.

11:47   Start of ISPF Log - - -  - Session # 1580
---
11:48   *  ISMF ERROR  * - DGTUV034  APPLICATION(DGT6 - SG);
FUNCTION(VOLUME)
11:48- DGTUV039  SYS3.DFSMS.SCDS

11:48- DGTUV035  RETURN CODE(0008); REASON
CODE(6131)
11:48- DGTUV027  MODULE(IGDCSU10); PROCEDURE()

11:48- DGTUV028  MESSAGE ID( - ); LAST
PANEL(DGTDCSG7)
11:48- DGTUV029  SERVICE(SMS/CS);
FEEDBACK(SUBRET: 0 SUBRSN: 0)
11:48   *  ISMF ERROR  * - DGTUV034  APPLICATION(DGT6 - SG);
FUNCTION(VOLUME)
11:48- DGTUV039  SYS3.DFSMS.SCDS

11:48- DGTUV035  RETURN CODE(0012); REASON
CODE(3117)
11:48- DGTUV027  MODULE(DGTFCFAC);
PROCEDURE(DGTFCFAC)
11:48- DGTUV028  MESSAGE ID(DGTUC051 -
DGTUC051); LAST PANEL(DGTDCSG7)
11:48- DGTUV029  SERVICE(SMS/CS);
FEEDBACK(ACCESS, CSI ACCESS MODE = W)
11:48   *  ISMF ERROR  * - DGTUV034  APPLICATION(DGT6 - SG);
FUNCTION(VOLUME)
11:48- DGTUV039  SYS3.DFSMS.SCDS

11:48- DGTUV035  RETURN CODE(0012); REASON
CODE(3117)
11:48- DGTUV027  MODULE(DGTFSGP3);
PROCEDURE(ACCESS)
11:48- DGTUV028  MESSAGE ID( - ); LAST
PANEL(DGTDCSG7)
11:48- DGTUV029  SERVICE(DGTECFAC);
FEEDBACK(CALLMOD:DGTFSGSV  CALLPROC:PROCOP2P)
11:48   *  ISMF ERROR  * - DGTUV034  APPLICATION(DGT6 - SG);
FUNCTION(VOLUME)
11:48- DGTUV039  SYS3.DFSMS.SCDS

11:48- DGTUV035  RETURN CODE(0012); REASON
CODE(3221)
11:48- DGTUV027  MODULE(DGTFSGVR);
PROCEDURE(VOSEL)
11:48- DGTUV028  MESSAGE ID( - ); LAST
PANEL(DGTDCSG7)
11:48- DGTUV029  SERVICE(NONE);
FEEDBACK(ELEMENT NAME: TMPSG1)

On Fri, Mar 8, 2019 at 11:40 AM Carmen Vitullo  wrote:

> some if the ISMF messages may have just gone to the ISPF log, you may wnat
> to check 7.5 to see if the log is active and if any messages are there ,
> just a thought
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Mark Pace" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, March 8, 2019 10:38:05 AM
> Subject: Re: ISMF msg
>
> I'm NOT running HSM.
>
> On Fri, Mar 8, 2019 at 11:37 AM Mark Pace  wrote:
>
> > I'm running HSM, no started task to look at.
> >
> > I'll check on my TSO profile.
> >
> > On Fri, Mar 8, 2019 at 11:22 AM Lizette Koehler 
>
> > wrote:
> >
> >> Sometime the messages come back to the tso session when using ISMF.
> >>
> >> Check your TSO PROFILE and make sure you are not suppressing them
> >>
> >> You could also check the DFHSM STC Task for the messages, they could be
> >> there as well.
> >>
> >>
> >> Lizette
> >>
> >>
> >> > -Original Message-
> >> > From: IBM Mainframe Discussion List  On
> >> Behalf Of
> >> > Mark Pace
> >> > Sent: Friday, March 08, 2019 9:16 AM
> >> > To: IBM-MAIN@LISTSERV.UA.EDU
> >> > Subject: ISMF msg
> >> >
> >> > I'm trying to add a new volume to a storage pool.
> >> >
> >> > When I try to add I get this message on the Panel - SMS RETCODE:
> >> 8
> >> >
> >> > Searching google it points to ARC0940I - which tells me to look are
> >> preceding
> >> > ARCxxx messages. I am not seeing any ARC messages on the console or
> >> system
> >> > log. I thought ARC messages came out of HSM, but I am not running
> HSM.
> >> >
> >> > --
> >> > The postings on this site are my own and don’t necessarily represent
> >> > Mainline’s positions or opinions
> >> >
> >> > Mark D Pace
> >> > Senior Systems Engineer
> >> > Mainline Information Systems
> >> >
> >> >
> --
> >> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> >> email to
> >> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu 

Re: ISMF msg

[Carmen Vitullo]

some if the ISMF messages may have just gone to the ISPF log, you may wnat to 
check 7.5 to see if the log is active and if any messages are there , just a 
thought 


Carmen Vitullo 

- Original Message -

From: "Mark Pace"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 8, 2019 10:38:05 AM 
Subject: Re: ISMF msg 

I'm NOT running HSM. 

On Fri, Mar 8, 2019 at 11:37 AM Mark Pace  wrote: 

> I'm running HSM, no started task to look at. 
> 
> I'll check on my TSO profile. 
> 
> On Fri, Mar 8, 2019 at 11:22 AM Lizette Koehler  
> wrote: 
> 
>> Sometime the messages come back to the tso session when using ISMF. 
>> 
>> Check your TSO PROFILE and make sure you are not suppressing them 
>> 
>> You could also check the DFHSM STC Task for the messages, they could be 
>> there as well. 
>> 
>> 
>> Lizette 
>> 
>> 
>> > -Original Message- 
>> > From: IBM Mainframe Discussion List  On 
>> Behalf Of 
>> > Mark Pace 
>> > Sent: Friday, March 08, 2019 9:16 AM 
>> > To: IBM-MAIN@LISTSERV.UA.EDU 
>> > Subject: ISMF msg 
>> > 
>> > I'm trying to add a new volume to a storage pool. 
>> > 
>> > When I try to add I get this message on the Panel - SMS RETCODE: 
>> 8 
>> > 
>> > Searching google it points to ARC0940I - which tells me to look are 
>> preceding 
>> > ARCxxx messages. I am not seeing any ARC messages on the console or 
>> system 
>> > log. I thought ARC messages came out of HSM, but I am not running HSM. 
>> > 
>> > -- 
>> > The postings on this site are my own and don’t necessarily represent 
>> > Mainline’s positions or opinions 
>> > 
>> > Mark D Pace 
>> > Senior Systems Engineer 
>> > Mainline Information Systems 
>> > 
>> > -- 
>> > For IBM-MAIN subscribe / signoff / archive access instructions, send 
>> email to 
>> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>> 
>> -- 
>> For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>> 
> 
> 
> -- 
> The postings on this site are my own and don’t necessarily represent 
> Mainline’s positions or opinions 
> 
> Mark D Pace 
> Senior Systems Engineer 
> Mainline Information Systems 
> 
> 
> 
> 

-- 
The postings on this site are my own and don’t necessarily represent 
Mainline’s positions or opinions 

Mark D Pace 
Senior Systems Engineer 
Mainline Information Systems 

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


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

Re: ISMF msg

[Mark Pace]

I'm NOT running HSM.

On Fri, Mar 8, 2019 at 11:37 AM Mark Pace  wrote:

> I'm running HSM, no started task to look at.
>
> I'll check on my TSO profile.
>
> On Fri, Mar 8, 2019 at 11:22 AM Lizette Koehler 
> wrote:
>
>> Sometime the messages come back to the tso session when using ISMF.
>>
>> Check your TSO PROFILE and make sure you are not suppressing them
>>
>> You could also check the DFHSM STC Task for the messages, they could be
>> there as well.
>>
>>
>> Lizette
>>
>>
>> > -Original Message-
>> > From: IBM Mainframe Discussion List  On
>> Behalf Of
>> > Mark Pace
>> > Sent: Friday, March 08, 2019 9:16 AM
>> > To: IBM-MAIN@LISTSERV.UA.EDU
>> > Subject: ISMF msg
>> >
>> > I'm trying to add a new volume to a storage pool.
>> >
>> > When I try to add I get this message on the Panel - SMS RETCODE:
>>  8
>> >
>> > Searching google it points to ARC0940I - which tells me to look are
>> preceding
>> > ARCxxx messages.  I am not seeing any ARC messages on the console or
>> system
>> > log.  I thought ARC messages came out of HSM, but I am not running HSM.
>> >
>> > --
>> > The postings on this site are my own and don’t necessarily represent
>> > Mainline’s positions or opinions
>> >
>> > Mark D Pace
>> > Senior Systems Engineer
>> > Mainline Information Systems
>> >
>> > --
>> > For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to
>> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
>
>
>

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: ISMF msg

[Mark Pace]

I'm running HSM, no started task to look at.

I'll check on my TSO profile.

On Fri, Mar 8, 2019 at 11:22 AM Lizette Koehler 
wrote:

> Sometime the messages come back to the tso session when using ISMF.
>
> Check your TSO PROFILE and make sure you are not suppressing them
>
> You could also check the DFHSM STC Task for the messages, they could be
> there as well.
>
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> Behalf Of
> > Mark Pace
> > Sent: Friday, March 08, 2019 9:16 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: ISMF msg
> >
> > I'm trying to add a new volume to a storage pool.
> >
> > When I try to add I get this message on the Panel - SMS RETCODE:
>  8
> >
> > Searching google it points to ARC0940I - which tells me to look are
> preceding
> > ARCxxx messages.  I am not seeing any ARC messages on the console or
> system
> > log.  I thought ARC messages came out of HSM, but I am not running HSM.
> >
> > --
> > The postings on this site are my own and don’t necessarily represent
> > Mainline’s positions or opinions
> >
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to
> > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: ISMF msg

[Mark Pace]

Yes, it was initialized as SMS and it's online.

 INIT UNIT(B052) VOLID(TTMP02) -
  NOVFY DEVTYPE(3390) PRG STGR VTOC(0,1,104) INDEX(7,0,45)

UNIT TYPE STATUSVOLSER VOLSTATE  SS
B052 3390 O TTMP02 PRIV/RSDNT 0

On Fri, Mar 8, 2019 at 11:19 AM Carmen Vitullo  wrote:

> is the volume online to the system you are trying to add?
> was init INIT'd as SMS ?
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Mark Pace" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Friday, March 8, 2019 10:15:41 AM
> Subject: ISMF msg
>
> I'm trying to add a new volume to a storage pool.
>
> When I try to add I get this message on the Panel - SMS RETCODE: 8
>
> Searching google it points to ARC0940I - which tells me to look are
> preceding ARCxxx messages. I am not seeing any ARC messages on the console
> or system log. I thought ARC messages came out of HSM, but I am not
> running HSM.
>
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: ISMF msg

[Lizette Koehler]

Sometime the messages come back to the tso session when using ISMF.

Check your TSO PROFILE and make sure you are not suppressing them

You could also check the DFHSM STC Task for the messages, they could be there 
as well.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Mark Pace
> Sent: Friday, March 08, 2019 9:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ISMF msg
> 
> I'm trying to add a new volume to a storage pool.
> 
> When I try to add I get this message on the Panel - SMS RETCODE: 8
> 
> Searching google it points to ARC0940I - which tells me to look are preceding
> ARCxxx messages.  I am not seeing any ARC messages on the console or system
> log.  I thought ARC messages came out of HSM, but I am not running HSM.
> 
> --
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
> 
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: ISMF msg

[Carmen Vitullo]

is the volume online to the system you are trying to add? 
was init INIT'd as SMS ? 



Carmen Vitullo 

- Original Message -

From: "Mark Pace"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, March 8, 2019 10:15:41 AM 
Subject: ISMF msg 

I'm trying to add a new volume to a storage pool. 

When I try to add I get this message on the Panel - SMS RETCODE: 8 

Searching google it points to ARC0940I - which tells me to look are 
preceding ARCxxx messages. I am not seeing any ARC messages on the console 
or system log. I thought ARC messages came out of HSM, but I am not 
running HSM. 

-- 
The postings on this site are my own and don’t necessarily represent 
Mainline’s positions or opinions 

Mark D Pace 
Senior Systems Engineer 
Mainline Information Systems 

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


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

ISMF msg

[Mark Pace]

I'm trying to add a new volume to a storage pool.

When I try to add I get this message on the Panel - SMS RETCODE: 8

Searching google it points to ARC0940I - which tells me to look are
preceding ARCxxx messages.  I am not seeing any ARC messages on the console
or system log.  I thought ARC messages came out of HSM, but I am not
running HSM.

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: IEF196I msg in JESMSGLG

[Jim Beck]

Mark,
When we phased out an in-house developed automation system to a commercially 
available one, we had several message rules that needed the same capability.  I 
wrote an MPF exit program that used the OICTXTERF3,CTXTESJL statement, then 
in MFPLSTxx had MSGID SUP(YES),USEREXIT(exitname).  MVS Initialization and 
Tuning reference and MVS Installation Exits has more info.

Jim


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

IEF196I msg in JESMSGLG

[Steely.Mark]

When I execute a batch job which uses a JES2 init I get the following  job 
messages:

   J E S 2  J O B  L O G  --  S Y S T E M  X X X X  --  N O 
D E  X X X X

09.00.18 JOB12252  FRIDAY,09 NOV 2018 
09.00.18 JOB12252  TSS7000I XX0042 Last-Used 09 Nov 18 00:01 System=SYSA 
Facility=
09.00.18 JOB12252  $HASP373 XX004215 STARTED - INIT S- CLASS S- SYS 

09.00.18 JOB12252  XX004215  JS010(IEFBR14 )  
09.00.19 JOB12252  XX004215  JS020(IEFBR14 )  
09.00.19 JOB12252  XX004215  JS030(IEFBR14 )  
09.00.19 JOB12252  XX004215  JS040(IEFBR14 )  
09.00.19 JOB12252  XX004215  JS050(IEFBR14 )  
09.00.19 JOB12252  XX004215  JS060(IEFBR14 )  
09.00.19 JOB12252  XX004215  JS070(IEFBR14 )  
09.00.19 JOB12252  $HASP395 XX004215 ENDED - RC=

The job step messages are produced by the IEFACTRT exit.

When I execute the same batch job - but it uses a WLM init I get job messages:

   J E S 2  J O B  L O G  --  S Y S T E M  X X X X  --  N O 
D E  X X X X

08.49.06 JOB11630  FRIDAY,09 NOV 2018 
08.49.06 JOB11630  TSS7000I XX0042 Last-Used 09 Nov 18 00:01 System=SYSA 
Facility=
08.49.06 JOB11630  $HASP373 XX004215 STARTED - WLM INIT  - SRVCLASS BATWLMB  - 
SYS 
08.49.06 JOB11630  XX004215  JS010(IEFBR14 )  
08.49.06 JOB11630  IEF196I XX004215  JS010(IEFBR14 )  
08.49.06 JOB11630  XX004215  JS020(IEFBR14 )  
08.49.06 JOB11630  IEF196I XX004215  JS020(IEFBR14 )  
08.49.06 JOB11630  XX004215  JS030(IEFBR14 )  
08.49.06 JOB11630  IEF196I XX004215  JS030(IEFBR14 )  
08.49.06 JOB11630  XX004215  JS040(IEFBR14 )  
08.49.06 JOB11630  IEF196I XX004215  JS040(IEFBR14 )  
08.49.06 JOB11630  XX004215  JS050(IEFBR14 )  
08.49.06 JOB11630  IEF196I XX004215  JS050(IEFBR14 )  
08.49.06 JOB11630  XX004215  JS060(IEFBR14 )  
08.49.06 JOB11630  IEF196I XX004215  JS060(IEFBR14 )  
08.49.06 JOB11630  XX004215  JS070(IEFBR14 )  
08.49.06 JOB11630  IEF196I XX004215  JS070(IEFBR14 )  
08.49.06 JOB11630  $HASP395 XX004215 ENDED - RC=

This execution also gets the IEF196I messages.

I tried using an OPS/MVS rule to suppress the MSG but that only removed the 
message from the console.

Is there any way to get rid of the IEF196I messages from the JESMSGLG.

Thank You


*** Disclaimer ***
This communication (including all attachments) is solely for the use of the 
person to whom it is addressed and is a confidential AAA communication. If you 
are not the intended recipient, any use, distribution, printing, or copying is 
prohibited. If you received this email in error, please immediately delete it 
and notify the sender.

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

Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB

[Larre Shiller]

Ding!  I asked IBM about this message earlier this year and here was the 
response:

"After examining this issue, we do agree the documentation in the V2R3 z/OS MVS 
System   
Messages, Vol 8 (IEF-IGD) for Message IEFA111I is incomplete. We spoke  
with development and they already created a RCF, Reader's Comment Form, 
for this issue.  The documentation will be updated in the next book 
release.

In regard to SWA, all started tasks/jobs submitted under JES3, will 
default to JES3's settings. However, if a started task were to run under
SUB=MSTR, then the IEFA111I Message will always output SWA=BELOW.   
Currently, all started tasks submitted under MSTR will be ran with  
SWA=BELOW.  Please Note: Any task(s) started before JES will also run   
under MSTR as well."

Larre

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

Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB

[Giliad Wilf]

On Fri, 10 Aug 2018 14:04:16 +, Pew, Curtis G 
 wrote:

>On Aug 10, 2018, at 8:35 AM, Giliad Wilf 
><00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> I can't believe $T JOBCLASS commands will affect STCs started before JES2 
>> was up, or started by subsystems other than JES2.
>
>I can’t either. But does the master subsystem support SWA=ABOVE?
>
>
>-- 
>Pew, Curtis G
>curtis@austin.utexas.edu
>ITS Systems/Core/Administrative Services
>

Your idea can be tested.
I only need to write a simple IEFUJV that sets SWA=ABOVE and see what does MSG 
IEFA111I say for all those STCs that showed SWA=BELOW earlier. 
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB

[Carmen Vitullo]

it's a NEW informational message, I can'gt find anywhere in the Init and Tuning 
where you can set SWA in the ALLOxx member, but this is what I found, as posted 
previously 


looks like a new message for 2.3 and new values , parms added to the ALLOC 
member 



Explanation: This message describes selected settings that will be used for the 
job. These settings may come from 
several different sources, such as the JOB statement, the job class attributes, 
ALLOCxx settings, or system defaults. 



Carmen Vitullo 

- Original Message -

From: "Curtis G Pew"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, August 10, 2018 9:04:16 AM 
Subject: Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB 

On Aug 10, 2018, at 8:35 AM, Giliad Wilf 
<00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote: 
> 
> I can't believe $T JOBCLASS commands will affect STCs started before JES2 was 
> up, or started by subsystems other than JES2. 

I can’t either. But does the master subsystem support SWA=ABOVE? 


-- 
Pew, Curtis G 
curtis@austin.utexas.edu 
ITS Systems/Core/Administrative Services 


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


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

Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB

[Pew, Curtis G]

On Aug 10, 2018, at 8:35 AM, Giliad Wilf 
<00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:
> 
> I can't believe $T JOBCLASS commands will affect STCs started before JES2 was 
> up, or started by subsystems other than JES2.

I can’t either. But does the master subsystem support SWA=ABOVE?


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB

[Giliad Wilf]

On Fri, 10 Aug 2018 13:26:00 +, Allan Staller  wrote:

>Nope. This can only be changed by command. JES2 will remember prior settings 
>until changed via command.
>
>$TJOBCLASS(*),SWA=ABOVE
>$TJOBCLASS(STC),SWA=ABOVE  <-
>$TJOBCLASS(TSU),SWA=ABOVE
>
>It sounds (to me) like someone issue the command previously and reality and 
>JESPARM have gotten out of sync.
>

I can't believe $T JOBCLASS commands will affect STCs started before JES2 was 
up, or started by subsystems other than JES2.

>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Giliad Wilf
>Sent: Friday, August 10, 2018 8:19 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB
>
>Hi All, Observing a z/OS 2.3 start-up of a new system, I can see a lot of 
>these messages,all of which state "SWA=BELOW".
>All our JES2 jobclasses specify "SWA=ABOVE, but these messages are issued 
>forSTCs invoked before JES2 start-up, or for STCs managed by subsystems other 
>thanJES2.
> AFAIK, SWA location can be set by IEFUJV, which is roughly SR 15,15 plus BR 
> 14 on our vanilla system. Is there a way to control SWA location for such 
> STCs without writing a site IEFUJV? Maybe a PARMLIB member, such as ALLOCxx? 
> Regards,
>

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

Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB

[Carmen Vitullo]

looks like a new message for 2.3 and new values , parms added to the ALLOC 
member 



Explanation: This message describes selected settings that will be used for the 
job. These settings may come from 
several different sources, such as the JOB statement, the job class attributes, 
ALLOCxx settings, or system defaults. 





Carmen Vitullo 

- Original Message -

From: "Giliad Wilf" <00d50942efa9-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, August 10, 2018 8:19:00 AM 
Subject: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB 

Hi All, Observing a z/OS 2.3 start-up of a new system, I can see a lot of these 
messages,all of which state "SWA=BELOW". 
All our JES2 jobclasses specify "SWA=ABOVE, but these messages are issued 
forSTCs invoked before JES2 start-up, or for STCs managed by subsystems other 
thanJES2. 
AFAIK, SWA location can be set by IEFUJV, which is roughly SR 15,15 plus BR 14 
on our vanilla system. Is there a way to control SWA location for such STCs 
without writing a site IEFUJV? Maybe a PARMLIB member, such as ALLOCxx? 
Regards, 

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


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

Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB

[Allan Staller]

Nope. This can only be changed by command. JES2 will remember prior settings 
until changed via command.

$TJOBCLASS(*),SWA=ABOVE
$TJOBCLASS(STC),SWA=ABOVE  <-
$TJOBCLASS(TSU),SWA=ABOVE

It sounds (to me) like someone issue the command previously and reality and 
JESPARM have gotten out of sync.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Giliad Wilf
Sent: Friday, August 10, 2018 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB

Hi All, Observing a z/OS 2.3 start-up of a new system, I can see a lot of these 
messages,all of which state "SWA=BELOW".
All our JES2 jobclasses specify "SWA=ABOVE, but these messages are issued 
forSTCs invoked before JES2 start-up, or for STCs managed by subsystems other 
thanJES2.
 AFAIK, SWA location can be set by IEFUJV, which is roughly SR 15,15 plus BR 14 
on our vanilla system. Is there a way to control SWA location for such STCs 
without writing a site IEFUJV? Maybe a PARMLIB member, such as ALLOCxx? Regards,

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB

[Giliad Wilf]

Hi All, Observing a z/OS 2.3 start-up of a new system, I can see a lot of these 
messages,all of which state "SWA=BELOW".
All our JES2 jobclasses specify "SWA=ABOVE, but these messages are issued 
forSTCs invoked before JES2 start-up, or for STCs managed by subsystems other 
thanJES2.
 AFAIK, SWA location can be set by IEFUJV, which is roughly SR 15,15 plus BR 14 
on our vanilla system. Is there a way to control SWA location for such STCs 
without writing a site IEFUJV? Maybe a PARMLIB member, such as ALLOCxx? 
Regards, 

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

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Farley, Peter x23353]

By experimentation, V5.2 cannot perform INITCHECK at any OPT level even with 
REGION=1536M (the largest  region I am allowed to use here) for very large 
programs (30K+ lines actual code).  It does succeed at OPT(1) and OPT(2) for 
more reasonably-sized programs (less than 6K lines) with REGION=350M.

I will check out those videos, thanks.

As for IBM's "thinking" on this subject, maybe PFCSK syndrome?  Insufficient 
real-world experience?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Friday, January 27, 2017 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL V5.2 question: INITCHECK option incompatible with 
OPTIMIZE(0)? (Msg IGYOS4021-W)

"Actually, Tom Ross in his migration presentation recommends this procedure:..."


Yes, unfortunately that was May 2016, and INITCHECK appeared in September 2016.

The reference I was making was to the V6.1 Migration Guide. The advice seems 
not to be in the MG for V5.2, although INITCHECK is there.

With V6.1, the compiler "back end" uses 64-bit addressing, allowing larger 
programs (which are generally "generated" programs) to be optimised than with 
V5.2. The only reason it is V6, not V5.3, is because of this change.

Have a look at Youtube for Enterprise COBOL V6.1. There's an Introduction, 
which is only two weeks old, and a two-month old "Migration Assistant" video. 
I've not seen either yet...

If it were easy to use INITCHECK with OPT(0), but the compile would take 
longer, why didn't they just do it? It's a migration and perhaps "initial 
compile" thing? If it takes longer, it is then your choice to use it or not.

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Bill Woodger]

"Actually, Tom Ross in his migration presentation recommends this procedure:..."


Yes, unfortunately that was May 2016, and INITCHECK appeared in September 2016.

The reference I was making was to the V6.1 Migration Guide. The advice seems 
not to be in the MG for V5.2, although INITCHECK is there.

With V6.1, the compiler "back end" uses 64-bit addressing, allowing larger 
programs (which are generally "generated" programs) to be optimised than with 
V5.2. The only reason it is V6, not V5.3, is because of this change.

Have a look at Youtube for Enterprise COBOL V6.1. There's an Introduction, 
which is only two weeks old, and a two-month old "Migration Assistant" video. 
I've not seen either yet...

If it were easy to use INITCHECK with OPT(0), but the compile would take 
longer, why didn't they just do it? It's a migration and perhaps "initial 
compile" thing? If it takes longer, it is then your choice to use it or not.

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

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Farley, Peter x23353]

Thanks Jeffrey.  I will pass that on here.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Holst, Jeffrey A
Sent: Friday, January 27, 2017 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL V5.2 question: INITCHECK option incompatible with 
OPTIMIZE(0)? (Msg IGYOS4021-W)

I encountered this same issue while installing COBOL V6.1. Seeing no 
documentation about this, I opened a PMR. 

I think that part of the resolution was to document this.

The explanation that I got was that while there was no technical reason for the 
incompatibility,  the point of OPTIMIZE(0) is to obtain a fast compile at the 
expense of performance when the program is executed. Apparently INITCHECK 
causes the compiler to run much longer, defeating the purpose of OPTIMIZE(0). 
Thus IBM's decision to make these options incompatible.

Jeffrey Holst
Systems Administator Senior
Technology and Operations, Shared Services Whitehall Service Center 2
(614) 856-5443

--

Date:Thu, 26 Jan 2017 15:25:00 -0500
From:"Farley, Peter x23353" <peter.far...@broadridge.com>
Subject: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? 
(Msg IGYOS4021-W)

We are beginning the transition to COBOL V5.2 from V4.2 and exploring the new 
options available for debugging.

We just discovered that the INITCHECK option is incompatible with OPTIMIZE(0).  
Using both options generates this warning-level message:

IGYOS4021-W   The "INITCHECK" option was discarded due to option conflict 
resolution.  The "OPTIMIZE(0)" option took precedence. 

There is no restriction documented for INITCHECK in the V5.2 Programmer's Guide 
and no mention of this incompatibility in the section on incompatible compiler 
options either.

Is this a maintenance issue?  Are we missing a PTF or was there a PTF applied 
that introduced the restriction without updating the documentation?  If the 
latter, a pointer to the PTF documentation would be appreciated.

Peter
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Farley, Peter x23353]

Actually, Tom Ross in his migration presentation recommends this procedure:

Best Practices for COBOL V5/V6 Migration
To find out if users have invalid data, IBM has recommendations for
migrating to COBOL V5/V6:
1. Compile with SSRANGE, ZONECHECK and OPT(0) for initial code
changes and unit test
– To find table misuse and invalid data
– OPT(0) programs are easiest to debug
2. Recompile with NOSSRANGE, NOZONECHECK and OPT(2) for
quality assurance test and production
– NOSSRANGE and NOZONECHECK are required for good
performance
– OPT(2) is preferred for good performance in production

 Note: You may have to change to a 2-compile development process if
you are not using one already

No mention of INITCHECK there at all.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Friday, January 27, 2017 4:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL V5.2 question: INITCHECK option incompatible with 
OPTIMIZE(0)? (Msg IGYOS4021-W)

On Thu, 26 Jan 2017 20:56:27 -0600, Mike Schwab <mike.a.sch...@gmail.com> wrote:

>Initially, the numeric / zero checks would not work like before.  I 
>know there is an parm to make it work like before in 6.1.  Not sure if 
>they applied it to 5.2.
>
>IBM Cobol Documentation page.  Click on Version (6.1) then download 
>Migration guide.  Compare to 5.2 guide.
>http://www-01.ibm.com/support/docview.wss?uid=swg27036733 & download PDF.

INITCHECK is new, so can't really have a different behaviour to before.

I think what you are referring to is the general problem that using "bad data", 
which then gives "undefined results" (perhaps rather "not the expected defined 
results") can change between compilers (up to V4.2 vs V5+).

IBM's recommendation is to compile with SSRANGE, ZONECHECK and INITCHECK and 
run regression-tests (acutually, since INITCHECK is a compile-time-only thing, 
check the compile listing before running anything for that...). Even where 
suggesting that there should be a mention of OPT greater than zero if required 
for INITCHECK.

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Holst, Jeffrey A]

I encountered this same issue while installing COBOL V6.1. Seeing no 
documentation about this, I opened a PMR. 

I think that part of the resolution was to document this.

The explanation that I got was that while there was no technical reason for the 
incompatibility,  the point of OPTIMIZE(0) is to obtain a fast compile at the 
expense of performance when the program is executed. Apparently INITCHECK 
causes the compiler to run much longer, defeating the purpose of OPTIMIZE(0). 
Thus IBM's decision to make these options incompatible.

Jeffrey Holst
Systems Administator Senior
Technology and Operations, Shared Services
Whitehall Service Center 2
(614) 856-5443

--

Date:Thu, 26 Jan 2017 15:25:00 -0500
From:"Farley, Peter x23353" <peter.far...@broadridge.com>
Subject: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? 
(Msg IGYOS4021-W)

We are beginning the transition to COBOL V5.2 from V4.2 and exploring the new 
options available for debugging.

We just discovered that the INITCHECK option is incompatible with OPTIMIZE(0).  
Using both options generates this warning-level message:

IGYOS4021-W   The "INITCHECK" option was discarded due to option conflict 
resolution.  The "OPTIMIZE(0)" option took precedence. 

There is no restriction documented for INITCHECK in the V5.2 Programmer's Guide 
and no mention of this incompatibility in the section on incompatible compiler 
options either.

Is this a maintenance issue?  Are we missing a PTF or was there a PTF applied 
that introduced the restriction without updating the documentation?  If the 
latter, a pointer to the PTF documentation would be appreciated.

Peter
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

***



The contents of this email are the property of PNC. If it was not addressed to 
you, you have no legal right to read it. If you think you received it in error, 
please notify the sender. Do not forward or copy without permission of the 
sender. This message may be considered a commercial electronic message under 
Canadian law or this message may contain an advertisement of a product or 
service and thus may constitute a commercial electronic mail message under US 
law. You may unsubscribe at any time from receiving commercial electronic 
messages from PNC at http://pages.e.pnc.com/globalunsub/
PNC, 249 Fifth Avenue, Pittsburgh, PA 15222; pnc.com




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

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Bill Woodger]

On Thu, 26 Jan 2017 20:56:27 -0600, Mike Schwab  wrote:

>Initially, the numeric / zero checks would not work like before.  I
>know there is an parm to make it work like before in 6.1.  Not sure if
>they applied it to 5.2.
>
>IBM Cobol Documentation page.  Click on Version (6.1) then download
>Migration guide.  Compare to 5.2 guide.
>http://www-01.ibm.com/support/docview.wss?uid=swg27036733 & download PDF.
>
>
>

INITCHECK is new, so can't really have a different behaviour to before.

I think what you are referring to is the general problem that using "bad data", 
which then gives "undefined results" (perhaps rather "not the expected defined 
results") can change between compilers (up to V4.2 vs V5+).

IBM's recommendation is to compile with SSRANGE, ZONECHECK and INITCHECK and 
run regression-tests (acutually, since INITCHECK is a compile-time-only thing, 
check the compile listing before running anything for that...). Even where 
suggesting that there should be a mention of OPT greater than zero if required 
for INITCHECK.

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

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Bill Woodger]

Although I can't see it documented, I suspect that INITCHECK can only be 
offered as a side-effect of the complex analysis which is already done for the 
higher levels of optimisation, and which is not done at the lowest level of 
optimisation (OPT(0)). The message is probably correct, but the relationship 
should be documented in the Programming Guide.

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

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Mike Schwab]

Initially, the numeric / zero checks would not work like before.  I
know there is an parm to make it work like before in 6.1.  Not sure if
they applied it to 5.2.

IBM Cobol Documentation page.  Click on Version (6.1) then download
Migration guide.  Compare to 5.2 guide.
http://www-01.ibm.com/support/docview.wss?uid=swg27036733 & download PDF.



On Thu, Jan 26, 2017 at 8:37 PM, Farley, Peter x23353
<peter.far...@broadridge.com> wrote:
> Not my call, unfortunately.  Mgmt decision already made more than several 
> levels above me.
>
> If there are any docs out there (preferably slide-type presentations suitable 
> for mgmt) with technical justification(s) that could help change the 
> decision, I'd appreciate pointers.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Mike Schwab
> Sent: Thursday, January 26, 2017 9:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL V5.2 question: INITCHECK option incompatible with 
> OPTIMIZE(0)? (Msg IGYOS4021-W)
>
> I would suggest getting 6.1 then converting.  IBM made some changes that 
> eliminate some situations that need coding changes.  Should be the same 
> license cost, just cost you install time.  Be sure to convert to Country 
> Multiplex / MSU licensing so you don't have a limited time before having to 
> pay for 4.2 AND 5.2/6.1.
>
> On Thu, Jan 26, 2017 at 2:25 PM, Farley, Peter x23353 
> <peter.far...@broadridge.com> wrote:
>> We are beginning the transition to COBOL V5.2 from V4.2 and exploring the 
>> new options available for debugging.
>>
>> We just discovered that the INITCHECK option is incompatible with 
>> OPTIMIZE(0).  Using both options generates this warning-level message:
>>
>> IGYOS4021-W   The "INITCHECK" option was discarded due to option conflict 
>> resolution.  The "OPTIMIZE(0)" option took precedence.
>>
>> There is no restriction documented for INITCHECK in the V5.2 Programmer's 
>> Guide and no mention of this incompatibility in the section on incompatible 
>> compiler options either.
>>
>> Is this a maintenance issue?  Are we missing a PTF or was there a PTF 
>> applied that introduced the restriction without updating the documentation?  
>> If the latter, a pointer to the PTF documentation would be appreciated.
>>
>> Peter
> --
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Farley, Peter x23353]

Not my call, unfortunately.  Mgmt decision already made more than several 
levels above me.

If there are any docs out there (preferably slide-type presentations suitable 
for mgmt) with technical justification(s) that could help change the decision, 
I'd appreciate pointers.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Thursday, January 26, 2017 9:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL V5.2 question: INITCHECK option incompatible with 
OPTIMIZE(0)? (Msg IGYOS4021-W)

I would suggest getting 6.1 then converting.  IBM made some changes that 
eliminate some situations that need coding changes.  Should be the same license 
cost, just cost you install time.  Be sure to convert to Country Multiplex / 
MSU licensing so you don't have a limited time before having to pay for 4.2 AND 
5.2/6.1.

On Thu, Jan 26, 2017 at 2:25 PM, Farley, Peter x23353 
<peter.far...@broadridge.com> wrote:
> We are beginning the transition to COBOL V5.2 from V4.2 and exploring the new 
> options available for debugging.
>
> We just discovered that the INITCHECK option is incompatible with 
> OPTIMIZE(0).  Using both options generates this warning-level message:
>
> IGYOS4021-W   The "INITCHECK" option was discarded due to option conflict 
> resolution.  The "OPTIMIZE(0)" option took precedence.
>
> There is no restriction documented for INITCHECK in the V5.2 Programmer's 
> Guide and no mention of this incompatibility in the section on incompatible 
> compiler options either.
>
> Is this a maintenance issue?  Are we missing a PTF or was there a PTF applied 
> that introduced the restriction without updating the documentation?  If the 
> latter, a pointer to the PTF documentation would be appreciated.
>
> Peter
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Mike Schwab]

I would suggest getting 6.1 then converting.  IBM made some changes
that eliminate some situations that need coding changes.  Should be
the same license cost, just cost you install time.  Be sure to convert
to Country Multiplex / MSU licensing so you don't have a limited time
before having to pay for 4.2 AND 5.2/6.1.

On Thu, Jan 26, 2017 at 2:25 PM, Farley, Peter x23353
 wrote:
> We are beginning the transition to COBOL V5.2 from V4.2 and exploring the new 
> options available for debugging.
>
> We just discovered that the INITCHECK option is incompatible with 
> OPTIMIZE(0).  Using both options generates this warning-level message:
>
> IGYOS4021-W   The "INITCHECK" option was discarded due to option conflict 
> resolution.  The "OPTIMIZE(0)" option took precedence.
>
> There is no restriction documented for INITCHECK in the V5.2 Programmer's 
> Guide and no mention of this incompatibility in the section on incompatible 
> compiler options either.
>
> Is this a maintenance issue?  Are we missing a PTF or was there a PTF applied 
> that introduced the restriction without updating the documentation?  If the 
> latter, a pointer to the PTF documentation would be appreciated.
>
> Peter
> --
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
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...@listserv.ua.edu with the message: INFO IBM-MAIN

COBOL V5.2 question: INITCHECK option incompatible with OPTIMIZE(0)? (Msg IGYOS4021-W)

[Farley, Peter x23353]

We are beginning the transition to COBOL V5.2 from V4.2 and exploring the new 
options available for debugging.

We just discovered that the INITCHECK option is incompatible with OPTIMIZE(0).  
Using both options generates this warning-level message:

IGYOS4021-W   The "INITCHECK" option was discarded due to option conflict 
resolution.  The "OPTIMIZE(0)" option took precedence. 

There is no restriction documented for INITCHECK in the V5.2 Programmer's Guide 
and no mention of this incompatibility in the section on incompatible compiler 
options either.

Is this a maintenance issue?  Are we missing a PTF or was there a PTF applied 
that introduced the restriction without updating the documentation?  If the 
latter, a pointer to the PTF documentation would be appreciated.

Peter
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Diagnosing a Catalog Enqueue Problem - What does Msg IEC347I tell me?

[Peter Hunkeler]

We've had a delay which seems to be caused by a problem with catalog 
processing. Automation regularly issues some MODIFY CATALOG and D GRS commands.

Below is an extract from the response to F CATALOG,LIST (IEC347I)
 IEC347I LIST CATALOG TASK(S) 
CASFLAGS -  
TASK ADDRESS - JOBNAME  / STEPNAME - ELAPSED TIME - ID  *-W-E-- 0079C130
 P0ANYJOB / DB2RUN   00.01.44 01  *   WAITING FOR BCS ENQ Shr Sys   
 FROM 23136534 FOR 00.01.44  *... long list of wainting task follows here
I tried to find out what the last line above, specifically the 8 digit number 
behind "FROM" are telling me? All of the waiters show the identical 8 digit 
number. Could not find it, neither in "Managing Catalogs", nor in "System 
Messages -> IEC347I" nor did GIYF help.
Is this useful information at all when trying to find the causer of the delay?
GRS tells the catalog that probably is causing the delay: S=SYSTEMS SYSIGGV2 
SYS1.CATALOG.PLEX.P0.UCAT10SYSNAMEJOBNAME ASID TCBADDR   
EXC/SHRSTATUSSYSA  CATALOG0033   009AC258   SHARE  
OWNSYSC  CATALOG0033   00989BC8 EXCLUSIVEWAIT long 
list of waiters follows here...


--
Peter Hunkeler


--
Peter Hunkeler

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

Re: Diagnosing a Catalog Enqueue Problem - What does Msg IEC347I tell me?

[Lizette Koehler]

So the number 23136534 is a latch number.  I would think additional D GRS
commands could help.   

D GRS,ANALYZE,LATCH,DEPENDENCY,DETAIL
Would be helpful in this case.

Did you have any jobs running that were backing up the catalog(s)?
Who was the owner of the Enqueue (D GRS,C)
What latch was in play (D GRS,ANALYZE,LATCH,DEPENDENCY,DETAIL)

There are a few other D GRS commands that might be helpful with these conditions
D GRS,ANALYZE,BLOCKER
D GRS,ANALYZE,WAITER
D GRS,ANALYSE,LATCH,BLOCKER  <--  the commands book may be wrong,  Might
be ANAYLZE.


I always start with the OWNER in a D GRS,C command then see how long it is held.
And work down from there.


Lizette




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: Thursday, December 10, 2015 2:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Diagnosing a Catalog Enqueue Problem - What does Msg IEC347I tell me?
> 
> We've had a delay which seems to be caused by a problem with catalog
processing.
> Automation regularly issues some MODIFY CATALOG and D GRS commands.
> 
> Below is an extract from the response to F CATALOG,LIST (IEC347I)
>  IEC347I LIST CATALOG TASK(S)
> CASF
> LAGS -  TASK ADDRESS - JOBNAME  / STEPNAME - ELAPSED TIME - ID  *-W-E--
> 0079C130 P0ANYJOB / DB2RUN   00.01.44 01  *   WAITING FOR BCS ENQ
Shr
> SysFROM 23136534 FOR 00.01.44  *... long list of wainting task follows
here
> I tried to find out what the last line above, specifically the 8 digit number
behind
> "FROM" are telling me? All of the waiters show the identical 8 digit number.
Could
> not find it, neither in "Managing Catalogs", nor in "System Messages ->
IEC347I" nor
> did GIYF help.
> Is this useful information at all when trying to find the causer of the delay?
> GRS tells the catalog that probably is causing the delay: S=SYSTEMS SYSIGGV2
> SYS1.CATALOG.PLEX.P0.UCAT10SYSNAMEJOBNAME ASID TCBADDR
> EXC/SHRSTATUSSYSA  CATALOG0033   009AC258   SHARE
OWNSYSC
> CATALOG0033   00989BC8 EXCLUSIVEWAIT long list of
waiters follows
> here...
> 
> 
> --
> Peter Hunkeler
> 

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

Re: Diagnosing a Catalog Enqueue Problem - What does Msg IEC347I tell me?

[Lizette Koehler]

There are some share presentations on Latches

Understanding GRS ENQ and Latch Usage and Contention

In this session, the speaker discusses GRS resource consumption and the various
IBM tools related to monitoring ENQ and GRS latch contention. Contention is a
good indication that something is hung, things changed, or that it's probably
not a good idea to scheduled two contentious jobs at the time. Tools include GRS
display commands, the GRS EQDQ monitor, and RMF related reporting. Understanding
how GRS works with regard to system resources demands such as real storage, XCF
and XES is also covered.
 
Another is
The Basics of GRS - An Overview of GRS ENQ Processing

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Thursday, December 10, 2015 4:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Diagnosing a Catalog Enqueue Problem - What does Msg IEC347I tell
> me?
> 
> So the number 23136534 is a latch number.  I would think additional D GRS
> commands could help.
> 
> D GRS,ANALYZE,LATCH,DEPENDENCY,DETAIL
> Would be helpful in this case.
> 
> Did you have any jobs running that were backing up the catalog(s)?
> Who was the owner of the Enqueue (D GRS,C) What latch was in play (D
> GRS,ANALYZE,LATCH,DEPENDENCY,DETAIL)
> 
> There are a few other D GRS commands that might be helpful with these
conditions
> D GRS,ANALYZE,BLOCKER D GRS,ANALYZE,WAITER
> D GRS,ANALYSE,LATCH,BLOCKER  <--  the commands book may be wrong,
> Might
> be ANAYLZE.
> 
> 
> I always start with the OWNER in a D GRS,C command then see how long it is
held.
> And work down from there.
> 
> 
> Lizette
> 
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Peter Hunkeler
> > Sent: Thursday, December 10, 2015 2:36 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Diagnosing a Catalog Enqueue Problem - What does Msg IEC347I tell
me?
> >
> > We've had a delay which seems to be caused by a problem with catalog
> processing.
> > Automation regularly issues some MODIFY CATALOG and D GRS commands.
> >
> > Below is an extract from the response to F CATALOG,LIST (IEC347I)
> > IEC347I LIST CATALOG TASK(S)
> >
> CASF
> > LAGS -  TASK ADDRESS - JOBNAME  / STEPNAME - ELAPSED TIME - ID  *-W-E--
> > 0079C130 P0ANYJOB / DB2RUN   00.01.44 01  *   WAITING FOR BCS
ENQ
> Shr
> > SysFROM 23136534 FOR 00.01.44  *... long list of wainting task
follows
> here
> > I tried to find out what the last line above, specifically the 8 digit
> > number
> behind
> > "FROM" are telling me? All of the waiters show the identical 8 digit number.
> Could
> > not find it, neither in "Managing Catalogs", nor in "System Messages
> > ->
> IEC347I" nor
> > did GIYF help.
> > Is this useful information at all when trying to find the causer of the
delay?
> > GRS tells the catalog that probably is causing the delay: S=SYSTEMS SYSIGGV2
> > SYS1.CATALOG.PLEX.P0.UCAT10SYSNAMEJOBNAME ASID TCBADDR
> > EXC/SHRSTATUSSYSA  CATALOG0033   009AC258   SHARE
> OWNSYSC
> > CATALOG0033   00989BC8 EXCLUSIVEWAIT long list of
> waiters follows
> > here...
> >
> >
> > --
> > Peter Hunkeler

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

AW: Re: Diagnosing a Catalog Enqueue Problem - What does Msg IEC347I tell me?

[Peter Hunkeler]

Thanks, Lizette for all the information. Will carefully study.


I saw the text talking about some latch information in System Messages. I can't 
tell why but I was inclinded to believe the text in my case would be something 
else. Wrong five minutes, I guess.


I didn't mention, but there is also a D GRS,C issued together with the other 
commands. It showed "no latch contention exists", and no other contentention 
that might have been related to the catalog problem.


The owner of the contention in the SYSIGGV2 catalog resource is CATALOG (and 
not additional jobname). It was clear from the MODIFY CATALOG,LIST that catalog 
is having contention. It is not yet clear whart caused it. Still 
investigating


--
Peter Hunkeler



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

AW: Re: Diagnosing a Catalog Enqueue Problem - What does Msg IEC347I tell me?

[Peter Hunkeler]

> Long running LISTCAT and/or EXPORT on catalog (for backup)?


You mean when someone does an ISPF 3.4 specifying a DSN level which will match 
a large number of data sets? Good hint.


Question becomes, how to find out now? I guess there is no track left.


--
Peter Hunkeler



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

Re: Diagnosing a Catalog Enqueue Problem - What does Msg IEC347I tell me?

[Staller, Allan]

Long running LISTCAT and/or EXPORT on catalog (for backup)?


... deleted
The owner of the contention in the SYSIGGV2 catalog resource is CATALOG (and 
not additional jobname). It was clear from the MODIFY CATALOG,LIST that catalog 
is having contention. It is not yet clear whart caused it. Still 
investigating


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

Re: MPF message processing not started for msg

[J O Skip Robinson]

When you get 'terminated at end of memory', all bets are off. This generally 
happens when the address space has run out of storage to the point that 
recovery routines cannot run. No recovery, no message processing, no 
preservation of sysout, etc. Your MPF entries indicate user exit processing. 
Probably not going to happen.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brad Wissink
Sent: Friday, September 18, 2015 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MPF message processing not started for msg

I have a batch job that abended with the following messages .

N C00 H50A 2015260 17:03:16.08 J0684125   $HASP310 U0051299 
TERMINATED AT END OF MEMORY
M 400 H50A 2015260 17:03:16.25    IEF402I U0051299 
FAILED IN ADDRESS SPACE 0058 892   
E   892   SYSTEM ABEND 
S04F - REASON CODE F30901  

I have two MPF message exits defined for one for each message.   

/*$HASP310 - JOBNAME TERMINATED AT END OF MEMORY  */
$HASP310,SUP(NO),USEREXIT(SY159)
/*IEF402I - JOBNAME FAILED IN ADDRESS SPACE SYSTEM ABEND SXXX */
IEF402I,SUP(NO),USEREXIT(SY147) 

I did a 'D MPF' to make sure the exits were defined and active.

Does anyone have an idea on why the exits were not called?


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

MPF message processing not started for msg

[Brad Wissink]

I have a batch job that abended with the following messages .

N C00 H50A 2015260 17:03:16.08 J0684125   $HASP310 U0051299 
TERMINATED AT END OF MEMORY
M 400 H50A 2015260 17:03:16.25    IEF402I U0051299 
FAILED IN ADDRESS SPACE 0058 892   
E   892   SYSTEM ABEND 
S04F - REASON CODE F30901  

I have two MPF message exits defined for one for each message.   

/*$HASP310 - JOBNAME TERMINATED AT END OF MEMORY  */
$HASP310,SUP(NO),USEREXIT(SY159)
/*IEF402I - JOBNAME FAILED IN ADDRESS SPACE SYSTEM ABEND SXXX */
IEF402I,SUP(NO),USEREXIT(SY147) 

I did a 'D MPF' to make sure the exits were defined and active.

Does anyone have an idea on why the exits were not called?

  

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

Re: msg BPXF024I with EZYFS60I

[Elardus Engelbrecht]

Kirk Wolf  wrote:

Wouldn't it be great if you didn't have to configure default system 
environment variables like TZ for each and every job?

It would be great, but if your system is using LE, then whatever the default is 
setup in LE (CEE parmlib member or CEE option module depending on LE library 
used), is used, unles you set up your own TZ for EACH application. [1] 


Headline: Provide option for dubbed processes to inherit environment from 
init process

Question: add another requirement - that dubbed proc can either accept 
inheretance or not. If not, use its own defaults if not setup (own TZ).


Paul Gilmartin wrote:

Many years ago, I submitted a PMR to the effect that when TZ is unset the time 
zone should default not to UTC but to system time, as on many other UNIX 
systems.  It was rejected on the ground that such behavior would be 
incompatible with AIX.

Good PMR, but why, oh why was it ultimately rejected? Whoever rejected that PMR 
are either bored or too lazy.


Where's /etc/localtime when you need it?

I also don't see or missed it after searching my z toys. Do you need to create 
it manually? But *will* it be used at all?

Groete / Greetings
Elardus Engelbrecht

[1] - I had to show my SMTP (actually CSSMTP) team how to setup a member 
containing TZ=GMT-2 statement. They could do it on other LPARs where needed.

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

Re: msg BPXF024I with EZYFS60I

[John McKown]

On Mon, Nov 3, 2014 at 6:25 AM, Elardus Engelbrecht 
elardus.engelbre...@sita.co.za wrote:

 Kirk Wolf  wrote:

 Wouldn't it be great if you didn't have to configure default system
 environment variables like TZ for each and every job?

 It would be great, but if your system is using LE, then whatever the
 default is setup in LE (CEE parmlib member or CEE option module depending
 on LE library used), is used, unles you set up your own TZ for EACH
 application. [1]


​This is what I have done.​ I am lucky in that my company is little and
does not span time zones. But it does make me wonder what a multinational
company would do for a default TZ which is not GMT. TZ of the home
office, or of the physical location of the data center, or the CEO's
wife's favorite second cousin? grin/



 Headline: Provide option for dubbed processes to inherit environment
 from init process

 Question: add another requirement - that dubbed proc can either accept
 inheretance or not. If not, use its own defaults if not setup (own TZ).


​I'm not understanding this. If the inheritance were done​, the application
could still have its own defaults set. Perhaps via LE parameters in the
PARM=. Hum, and if a dubbed process inherits its environment variables,
and is in an LE run unit, does it inherit from init or from the ENVAR
parameter, if any, set via the PARM? I.e. who takes precedence when an LE
run unit is dubbed. I vote for LE. And, other that in code, how are the
application specific environment variables set? Via the SYSENV DD
statement? Of course, if a request is made from IBM, that is _their_ design
decision. I've often been told that IBM prefers to be told what you want
the end results to be, not how you want them accomplished.




 Paul Gilmartin wrote:

 Many years ago, I submitted a PMR to the effect that when TZ is unset the
 time zone should default not to UTC but to system time, as on many other
 UNIX systems.  It was rejected on the ground that such behavior would be
 incompatible with AIX.

 Good PMR, but why, oh why was it ultimately rejected? Whoever rejected
 that PMR are either bored or too lazy.


 Where's /etc/localtime when you need it?

 I also don't see or missed it after searching my z toys. Do you need to
 create it manually? But *will* it be used at all?



​No it won't be used, that's what Gil was getting at. Personally, I don't
see the need. ​IMO, all z/OS systems should have the hardware TOD clock set
to GMT/UTC (yes, I know they are not exactly the same thing). I don't
really see the plus of /etc/localtime vs. just setting the z/OS TIMEZONE
offset. They are both global to the z/OS image. I would hope that the
UNIX default would be the same as the z/OS batch default. But that's just
my personal take on it.




 Groete / Greetings
 Elardus Engelbrecht

 [1] - I had to show my SMTP (actually CSSMTP) team how to setup a member
 containing TZ=GMT-2 statement. They could do it on other LPARs where needed.

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




-- 
The temperature of the aqueous content of an unremittingly ogled
culinary vessel will not achieve 100 degrees on the Celsius scale.

Maranatha! 
John McKown

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

Re: msg BPXF024I with EZYFS60I

[Kirk Wolf]

I don't disagree that the TZ default for z/OS Unix should be derived from
the z/OS TIMEZONE offset.

But the RFE that I submitted is about more than setting TZ - it is about
having dubbed processes inherit their environment variables from the init
process.   Also, read the RFE and you will see that the suggestion is that
there be a system and user OMVS segment level option to control whether
blind dubbed processes should inherit their environment or not.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Mon, Nov 3, 2014 at 6:49 AM, John McKown john.archie.mck...@gmail.com
wrote:

 On Mon, Nov 3, 2014 at 6:25 AM, Elardus Engelbrecht 
 elardus.engelbre...@sita.co.za wrote:

  Kirk Wolf  wrote:
 
  Wouldn't it be great if you didn't have to configure default system
  environment variables like TZ for each and every job?
 
  It would be great, but if your system is using LE, then whatever the
  default is setup in LE (CEE parmlib member or CEE option module depending
  on LE library used), is used, unles you set up your own TZ for EACH
  application. [1]
 

 ​This is what I have done.​ I am lucky in that my company is little and
 does not span time zones. But it does make me wonder what a multinational
 company would do for a default TZ which is not GMT. TZ of the home
 office, or of the physical location of the data center, or the CEO's
 wife's favorite second cousin? grin/


 
  Headline: Provide option for dubbed processes to inherit environment
  from init process
 
  Question: add another requirement - that dubbed proc can either accept
  inheretance or not. If not, use its own defaults if not setup (own TZ).
 
 
 ​I'm not understanding this. If the inheritance were done​, the application
 could still have its own defaults set. Perhaps via LE parameters in the
 PARM=. Hum, and if a dubbed process inherits its environment variables,
 and is in an LE run unit, does it inherit from init or from the ENVAR
 parameter, if any, set via the PARM? I.e. who takes precedence when an LE
 run unit is dubbed. I vote for LE. And, other that in code, how are the
 application specific environment variables set? Via the SYSENV DD
 statement? Of course, if a request is made from IBM, that is _their_ design
 decision. I've often been told that IBM prefers to be told what you want
 the end results to be, not how you want them accomplished.



 
  Paul Gilmartin wrote:
 
  Many years ago, I submitted a PMR to the effect that when TZ is unset
 the
  time zone should default not to UTC but to system time, as on many other
  UNIX systems.  It was rejected on the ground that such behavior would be
  incompatible with AIX.
 
  Good PMR, but why, oh why was it ultimately rejected? Whoever rejected
  that PMR are either bored or too lazy.
 
 
  Where's /etc/localtime when you need it?
 
  I also don't see or missed it after searching my z toys. Do you need to
  create it manually? But *will* it be used at all?
 


 ​No it won't be used, that's what Gil was getting at. Personally, I don't
 see the need. ​IMO, all z/OS systems should have the hardware TOD clock set
 to GMT/UTC (yes, I know they are not exactly the same thing). I don't
 really see the plus of /etc/localtime vs. just setting the z/OS TIMEZONE
 offset. They are both global to the z/OS image. I would hope that the
 UNIX default would be the same as the z/OS batch default. But that's just
 my personal take on it.



 
  Groete / Greetings
  Elardus Engelbrecht
 
  [1] - I had to show my SMTP (actually CSSMTP) team how to setup a member
  containing TZ=GMT-2 statement. They could do it on other LPARs where
 needed.
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions,
  send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 



 --
 The temperature of the aqueous content of an unremittingly ogled
 culinary vessel will not achieve 100 degrees on the Celsius scale.

 Maranatha! 
 John McKown

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


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

Re: msg BPXF024I with EZYFS60I

[John McKown]

On Mon, Nov 3, 2014 at 8:18 AM, Kirk Wolf k...@dovetail.com wrote:

 I don't disagree that the TZ default for z/OS Unix should be derived from
 the z/OS TIMEZONE offset.

 But the RFE that I submitted is about more than setting TZ - it is about
 having dubbed processes inherit their environment variables from the init
 process.   Also, read the RFE and you will see that the suggestion is that
 there be a system and user OMVS segment level option to control whether
 blind dubbed processes should inherit their environment or not.

 Kirk Wolf
 Dovetailed Technologies
 http://dovetail.com


​OK, I _finally_ actually read the RFE and voted for it. I am still
wondering will be the overriding source of UNIX environment variables: the
/etc/init.options​ file or the ENVAR set in LE. And, just to be contrary
grin: Should blind dubbed processes inherit the environment variables
from the running BPXOINIT or by reading  interpreting /etc/init.options.
Well, I guess that is an implementation detail for IBM to determine.

-- 
The temperature of the aqueous content of an unremittingly ogled
culinary vessel will not achieve 100 degrees on the Celsius scale.

Maranatha! 
John McKown

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

Re: msg BPXF024I with EZYFS60I

[Paul Gilmartin]

On Mon, 3 Nov 2014 08:18:03 -0600, Kirk Wolf wrote:

I don't disagree that the TZ default for z/OS Unix should be derived from
the z/OS TIMEZONE offset.

But the RFE that I submitted is about more than setting TZ - it is about
having dubbed processes inherit their environment variables from the init
process.   Also, read the RFE and you will see that the suggestion is that
there be a system and user OMVS segment level option to control whether
blind dubbed processes should inherit their environment or not.
 
Oh, heck!  I'll go further.  Beyond that, the default TZ should be a setting
in the user's OMVS segment, just like HOME and SHELL (umask, too.)
FTP server should use this in formatting file timestamps for the LS command.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Mon, Nov 3, 2014 at 6:49 AM, John McKown john.archie.mck...@gmail.com
wrote:

 On Mon, Nov 3, 2014 at 6:25 AM, Elardus Engelbrecht 
 elardus.engelbre...@sita.co.za wrote:

  Kirk Wolf  wrote:
 
  Wouldn't it be great if you didn't have to configure default system
  environment variables like TZ for each and every job?
 
  ... if your system is using LE, ...
 
What does system is using mean?  LE is enabled for the LPAR?  Any
active job is using LE?  Other?

(JMcK:)
 ​This is what I have done.​ I am lucky in that my company is little and
 does not span time zones. But it does make me wonder what a multinational
 company would do for a default TZ which is not GMT. TZ of the home
 office, or of the physical location of the data center, or the CEO's
 wife's favorite second cousin? grin/
 
A good argument for a RACF segment setting.


  Headline: Provide option for dubbed processes to inherit environment
  from init process
 
  Question: add another requirement - that dubbed proc can either accept
  inheretance or not. If not, use its own defaults if not setup (own TZ).
 
 
 ​I'm not understanding this. If the inheritance were done​, the application
 could still have its own defaults set. Perhaps via LE parameters in the
 PARM=. Hum, and if a dubbed process inherits its environment variables,
 and is in an LE run unit, does it inherit from init or from the ENVAR
 parameter, if any, set via the PARM? I.e. who takes precedence when an LE
 run unit is dubbed. I vote for LE. And, other that in code, how are the
 application specific environment variables set? Via the SYSENV DD
 statement? Of course, if a request is made from IBM, that is _their_ design
 decision. I've often been told that IBM prefers to be told what you want
 the end results to be, not how you want them accomplished.
.
 ​... I don't
 really see the plus of /etc/localtime vs. just setting the z/OS TIMEZONE
 offset. They are both global to the z/OS image. I would hope that the
 UNIX default would be the same as the z/OS batch default. But that's just
 my personal take on it.
 
Correct display of file timestamps from the other side of the Daylight Time
boundary.  (Today AZ and CO are the same; last week they were an hour
apart.)  Actually, the z/OS TIMEZONE should follow POSIX conventions in
order to be DST aware.

-- gil

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

Re: msg BPXF024I with EZYFS60I

[John McKown]

On Mon, Nov 3, 2014 at 9:52 AM, Paul Gilmartin 
000433f07816-dmarc-requ...@listserv.ua.edu wrote:

 On Mon, 3 Nov 2014 08:18:03 -0600, Kirk Wolf wrote:

 I don't disagree that the TZ default for z/OS Unix should be derived from
 the z/OS TIMEZONE offset.
 
 But the RFE that I submitted is about more than setting TZ - it is about
 having dubbed processes inherit their environment variables from the init
 process.   Also, read the RFE and you will see that the suggestion is that
 there be a system and user OMVS segment level option to control whether
 blind dubbed processes should inherit their environment or not.
 
 Oh, heck!  I'll go further.  Beyond that, the default TZ should be a
 setting
 in the user's OMVS segment, just like HOME and SHELL (umask, too.)
 FTP server should use this in formatting file timestamps for the LS
 command.


​I __like__ it!. However, going even further, ​create a new OMVS segment
field, perhaps ENVAR (to mirror LE), in which you can set _any_ number of
environment variables similar to how the ENVAR in LE is specified.
Ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea31c0/1.2.19

There is still the question about the hierarchy of inheritance. Personally,
I would go: /etc/init.options overridden by OMVS ENVAR, overridden by PARM=
ENVAR.

-- 
The temperature of the aqueous content of an unremittingly ogled
culinary vessel will not achieve 100 degrees on the Celsius scale.

Maranatha! 
John McKown

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

msg BPXF024I with EZYFS60I

[Tim Brown]

These messages are not  showing the local Z/OS time  which is this case was 
09:18

Is there a parameter that controls this

09:18:17.75 STC09130 0090  BPXF024I (EMS) Nov  2 14:18:17 ftps 16777562 : E
781
  781 0090  CONN   ends   Input=223 bytes Output=0 bytes

Tim

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

Re: msg BPXF024I with EZYFS60I

[John McKown]

It depends on how you start the FTP server. But, basically, you need to set
the TZ environment variable to the proper value. For me, in the U.S.
Central Time Zone, I have TZ=CST6CDT . I set it in a couple of places. One
is in the LE parameters. As shown below:

=== SYS1.PARMLIB(CEEPRM00) ===
/* NONCICS LE PARMS */
CEEDOPT(
  ALL31(OFF),
  STACK(,,BELOW)
  CBLQDA(OFF),
  COUNTRY(US),
  DEBUG,
  DYNDUMP(*USERID,DYNAMIC,NOTDUMP),
  ENVAR('TZ=CST6CDT'),
  LIBSTACK(8K,4K,FREE),
  STORAGE(NONE,NONE,NONE,8K)
 )
/* CICS LE PARMS */
CEECOPT(
  ALL31(OFF),
  STACK(,,BELOW),
  STORAGE(00,NONE,NONE,0K)
 )
/* 64 BIT GROUP */
CELQDOPT(
 )

===

But, in this particular case, I have customized the FTPD started task JCL.
Example:

//FTPD   PROC MODULE='FTPD',PARMS=''
//FTPD   EXEC PGM=MODULE,REGION=4096K,TIME=NOLIMIT,
//PARM=('POSIX(ON) ALL31(ON) TZ=CST6CDT ',
//   'ENVAR(RESOLVER_CONFIG=/etc/resolv.conf,TZ=CST6CDT)/PARMS')
//*

You'll likely notice I have the TZ=CST6CDT in two places. That was due to
confusion on my part as to where it actually goes. I _think_ it only needs
to be within the ENVAR(...) portion. But it doesn't seem to hurt being in
both. So I cowardly left it alone once I had it doing what I wanted.


On Sun, Nov 2, 2014 at 8:23 AM, Tim Brown tbr...@cenhud.com wrote:

 These messages are not  showing the local Z/OS time  which is this case
 was 09:18

 Is there a parameter that controls this

 09:18:17.75 STC09130 0090  BPXF024I (EMS) Nov  2 14:18:17 ftps
 16777562 : E
 781
   781 0090  CONN   ends   Input=223 bytes Output=0
 bytes

 Tim

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




-- 
The temperature of the aqueous content of an unremittingly ogled
culinary vessel will not achieve 100 degrees on the Celsius scale.

Maranatha! 
John McKown

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

Re: msg BPXF024I with EZYFS60I

[Tim Brown]

John

 Thanks!!

Tim

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Sunday, 02 November, 2014 10:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: msg BPXF024I with EZYFS60I

It depends on how you start the FTP server. But, basically, you need to set the 
TZ environment variable to the proper value. For me, in the U.S.
Central Time Zone, I have TZ=CST6CDT . I set it in a couple of places. One is 
in the LE parameters. As shown below:

=== SYS1.PARMLIB(CEEPRM00) ===
/* NONCICS LE PARMS */
CEEDOPT(
  ALL31(OFF),
  STACK(,,BELOW)
  CBLQDA(OFF),
  COUNTRY(US),
  DEBUG,
  DYNDUMP(*USERID,DYNAMIC,NOTDUMP),
  ENVAR('TZ=CST6CDT'),
  LIBSTACK(8K,4K,FREE),
  STORAGE(NONE,NONE,NONE,8K)
 )
/* CICS LE PARMS */
CEECOPT(
  ALL31(OFF),
  STACK(,,BELOW),
  STORAGE(00,NONE,NONE,0K)
 )
/* 64 BIT GROUP */
CELQDOPT(
 )

===

But, in this particular case, I have customized the FTPD started task JCL.
Example:

//FTPD   PROC MODULE='FTPD',PARMS=''
//FTPD   EXEC PGM=MODULE,REGION=4096K,TIME=NOLIMIT,
//PARM=('POSIX(ON) ALL31(ON) TZ=CST6CDT ',
//   'ENVAR(RESOLVER_CONFIG=/etc/resolv.conf,TZ=CST6CDT)/PARMS')
//*

You'll likely notice I have the TZ=CST6CDT in two places. That was due to 
confusion on my part as to where it actually goes. I _think_ it only needs to 
be within the ENVAR(...) portion. But it doesn't seem to hurt being in both. So 
I cowardly left it alone once I had it doing what I wanted.


On Sun, Nov 2, 2014 at 8:23 AM, Tim Brown tbr...@cenhud.com wrote:

 These messages are not  showing the local Z/OS time  which is this 
 case was 09:18

 Is there a parameter that controls this

 09:18:17.75 STC09130 0090  BPXF024I (EMS) Nov  2 14:18:17 ftps
 16777562 : E
 781
   781 0090  CONN   ends   Input=223 bytes Output=0
 bytes

 Tim

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




--
The temperature of the aqueous content of an unremittingly ogled culinary 
vessel will not achieve 100 degrees on the Celsius scale.

Maranatha! 
John McKown

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

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

Re: msg BPXF024I with EZYFS60I

[Kirk Wolf]

Wouldn't it be great if you didn't have to configure default system
environment variables like TZ for each and every job?

If you agree, please vote for this RFE:


--
Notification generated at: 25 Sep 2014, 09:25 AM Eastern Time (ET)

ID:59716
Headline:  Provide option for dubbed processes to inherit
environment from init process
Submitted on:  25 Sep 2014, 09:25 AM Eastern Time (ET)
Brand: Servers and Systems Software
Product:   z/OS

Link:  http://www.ibm.com/developerworks/rfe
/execute?use_case=viewRfeCR_ID=59716

--

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Sun, Nov 2, 2014 at 12:51 PM, Tim Brown tbr...@cenhud.com wrote:

 John

  Thanks!!

 Tim

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of John McKown
 Sent: Sunday, 02 November, 2014 10:26 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: msg BPXF024I with EZYFS60I

 It depends on how you start the FTP server. But, basically, you need to
 set the TZ environment variable to the proper value. For me, in the U.S.
 Central Time Zone, I have TZ=CST6CDT . I set it in a couple of places. One
 is in the LE parameters. As shown below:

 === SYS1.PARMLIB(CEEPRM00) ===
 /* NONCICS LE PARMS */
 CEEDOPT(
   ALL31(OFF),
   STACK(,,BELOW)
   CBLQDA(OFF),
   COUNTRY(US),
   DEBUG,
   DYNDUMP(*USERID,DYNAMIC,NOTDUMP),
   ENVAR('TZ=CST6CDT'),
   LIBSTACK(8K,4K,FREE),
   STORAGE(NONE,NONE,NONE,8K)
  )
 /* CICS LE PARMS */
 CEECOPT(
   ALL31(OFF),
   STACK(,,BELOW),
   STORAGE(00,NONE,NONE,0K)
  )
 /* 64 BIT GROUP */
 CELQDOPT(
  )

 ===

 But, in this particular case, I have customized the FTPD started task JCL.
 Example:

 //FTPD   PROC MODULE='FTPD',PARMS=''
 //FTPD   EXEC PGM=MODULE,REGION=4096K,TIME=NOLIMIT,
 //PARM=('POSIX(ON) ALL31(ON) TZ=CST6CDT ',
 //   'ENVAR(RESOLVER_CONFIG=/etc/resolv.conf,TZ=CST6CDT)/PARMS')
 //*

 You'll likely notice I have the TZ=CST6CDT in two places. That was due to
 confusion on my part as to where it actually goes. I _think_ it only needs
 to be within the ENVAR(...) portion. But it doesn't seem to hurt being in
 both. So I cowardly left it alone once I had it doing what I wanted.


 On Sun, Nov 2, 2014 at 8:23 AM, Tim Brown tbr...@cenhud.com wrote:

  These messages are not  showing the local Z/OS time  which is this
  case was 09:18
 
  Is there a parameter that controls this
 
  09:18:17.75 STC09130 0090  BPXF024I (EMS) Nov  2 14:18:17 ftps
  16777562 : E
  781
781 0090  CONN   ends   Input=223 bytes Output=0
  bytes
 
  Tim
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions, send
  email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
 



 --
 The temperature of the aqueous content of an unremittingly ogled culinary
 vessel will not achieve 100 degrees on the Celsius scale.

 Maranatha! 
 John McKown

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

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


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

Re: msg BPXF024I with EZYFS60I

[Paul Gilmartin]

On Sun, 2 Nov 2014 16:20:08 -0600, Kirk Wolf  wrote:

Wouldn't it be great if you didn't have to configure default system
environment variables like TZ for each and every job?

If you agree, please vote for this RFE:


--
Notification generated at: 25 Sep 2014, 09:25 AM Eastern Time (ET)

ID:59716
Headline:  Provide option for dubbed processes to inherit
environment from init process
Submitted on:  25 Sep 2014, 09:25 AM Eastern Time (ET)
Brand: Servers and Systems Software
Product:   z/OS

Link:  http://www.ibm.com/developerworks/rfe
/execute?use_case=viewRfeCR_ID=59716

--
 
Many years ago, I submitted a PMR to the effect that when TZ is unset
the time zone should default not to UTC but to system time, as on
many other UNIX systems.  It was rejected on the ground that such
behavior would be incompatible with AIX.

Where's /etc/localtime when you need it?

-- gil

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

Re: MSG IKJ56961E LISTBC TERMINATED

[John Norgauer]

Problem solved. Some time ago, on my test LPAR I decided to use a Broadcast 
data set name other than SYS1.BRODCAST. 
Apparently, when using a name other than SYS1.BRODCAST, the IKJTSOXX member 
needs to have LOGNAME(*) specified.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Tuesday, September 16, 2014 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

LISTBC may be getting run by your logon proc or some such, which makes getting 
additional info difficult. Once you're logged on, try typing LISTBC yourself. ? 
should work then. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Norgauer jcnorga...@ucdavis.edu
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/16/2014 10:09 AM
Subject:Re: MSG IKJ56961E LISTBC TERMINATED
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



For some reason, there was no dynalloc return / reason code displayed.

This is the text of the message:

THE MESSAGE LOG COULD NOT BE ALLOCATED.+

The + sign indicates that there is additional info available, but I can 
not get that info.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Anthony Thompson
Sent: Monday, September 15, 2014 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

The full IKJ56961E message should have supplied dynalloc return / reason 
codes, which the OP didn't supply but would have helped.

Skip may have it right with regards to SYS1.BRODCAST, but the OP should 
check his IKJTSO member is see if TSO/E userlogs are being used instead 
(SEND statement, USERLOG parameter).

Given that 'many volumes were eliminated',  it may be that his private 
TSO/E userlog was trashed, and the SMS ACS routines crippled to the point 
a new one can't be allocated (check the form of the TSO/E USERLOG 
filename, if used, and throw it through a SMS ACS test case).


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Skip Robinson
Sent: Tuesday, 16 September 2014 5:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

My first inclination was to say that SYS1.BRODCAST had resided on a volume 
that was removed. Then I remembered this line in MSTJCLxx: 

//SYSLBC   DD DISP=SHR,DSN=SYS1.BRODCAST 

which would make IPL pretty dicey. Then it occurred to me that as long as 
the data set it cataloged, maybe the system doesn't really look for it 
until LISTBC needs to do I/O. So do LISTCAT on SYS1.BRODCAST  .
If the volume is missing, that's the problem. Otherwise, check for a 
personal 'userlog' data set cataloged to a missing volume. 

. 
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Norgauer jcnorga...@ucdavis.edu
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/15/2014 11:03 AM
Subject:MSG IKJ56961E LISTBC TERMINATED
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Getting this at TSO logon time. This is on a test LPAR which had many 
volumes eliminated(because of clean-up).

Any thoughts as to identifying the volume?


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

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

Re: MSG IKJ56961E LISTBC TERMINATED

[John Norgauer]

For some reason, there was no dynalloc return / reason code displayed.

This is the text of the message:

THE MESSAGE LOG COULD NOT BE ALLOCATED.+

The + sign indicates that there is additional info available, but I can not get 
that info.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Monday, September 15, 2014 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

The full IKJ56961E message should have supplied dynalloc return / reason codes, 
which the OP didn't supply but would have helped.

Skip may have it right with regards to SYS1.BRODCAST, but the OP should check 
his IKJTSO member is see if TSO/E userlogs are being used instead (SEND 
statement, USERLOG parameter).

Given that 'many volumes were eliminated',  it may be that his private TSO/E 
userlog was trashed, and the SMS ACS routines crippled to the point a new one 
can't be allocated (check the form of the TSO/E USERLOG filename, if used, and 
throw it through a SMS ACS test case).


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Tuesday, 16 September 2014 5:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

My first inclination was to say that SYS1.BRODCAST had resided on a volume that 
was removed. Then I remembered this line in MSTJCLxx: 

//SYSLBC   DD DISP=SHR,DSN=SYS1.BRODCAST 

which would make IPL pretty dicey. Then it occurred to me that as long as the 
data set it cataloged, maybe the system doesn't really look for it until LISTBC 
needs to do I/O. So do LISTCAT on SYS1.BRODCAST  .
If the volume is missing, that's the problem. Otherwise, check for a personal 
'userlog' data set cataloged to a missing volume. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Norgauer jcnorga...@ucdavis.edu
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/15/2014 11:03 AM
Subject:MSG IKJ56961E LISTBC TERMINATED
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Getting this at TSO logon time. This is on a test LPAR which had many volumes 
eliminated(because of clean-up).

Any thoughts as to identifying the volume?


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

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

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

Re: MSG IKJ56961E LISTBC TERMINATED

[Skip Robinson]

LISTBC may be getting run by your logon proc or some such, which makes 
getting additional info difficult. Once you're logged on, try typing 
LISTBC yourself. ? should work then. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Norgauer jcnorga...@ucdavis.edu
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/16/2014 10:09 AM
Subject:Re: MSG IKJ56961E LISTBC TERMINATED
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



For some reason, there was no dynalloc return / reason code displayed.

This is the text of the message:

THE MESSAGE LOG COULD NOT BE ALLOCATED.+

The + sign indicates that there is additional info available, but I can 
not get that info.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Anthony Thompson
Sent: Monday, September 15, 2014 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

The full IKJ56961E message should have supplied dynalloc return / reason 
codes, which the OP didn't supply but would have helped.

Skip may have it right with regards to SYS1.BRODCAST, but the OP should 
check his IKJTSO member is see if TSO/E userlogs are being used instead 
(SEND statement, USERLOG parameter).

Given that 'many volumes were eliminated',  it may be that his private 
TSO/E userlog was trashed, and the SMS ACS routines crippled to the point 
a new one can't be allocated (check the form of the TSO/E USERLOG 
filename, if used, and throw it through a SMS ACS test case).


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Skip Robinson
Sent: Tuesday, 16 September 2014 5:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

My first inclination was to say that SYS1.BRODCAST had resided on a volume 
that was removed. Then I remembered this line in MSTJCLxx: 

//SYSLBC   DD DISP=SHR,DSN=SYS1.BRODCAST 

which would make IPL pretty dicey. Then it occurred to me that as long as 
the data set it cataloged, maybe the system doesn't really look for it 
until LISTBC needs to do I/O. So do LISTCAT on SYS1.BRODCAST  .
If the volume is missing, that's the problem. Otherwise, check for a 
personal 'userlog' data set cataloged to a missing volume. 

. 
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Norgauer jcnorga...@ucdavis.edu
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/15/2014 11:03 AM
Subject:MSG IKJ56961E LISTBC TERMINATED
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Getting this at TSO logon time. This is on a test LPAR which had many 
volumes eliminated(because of clean-up).

Any thoughts as to identifying the volume?


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

MSG IKJ56961E LISTBC TERMINATED

[John Norgauer]

Getting this at TSO logon time. This is on a test LPAR which had many volumes 
eliminated(because of clean-up).

Any thoughts as to identifying the volume?

Thanks.

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

Re: MSG IKJ56961E LISTBC TERMINATED

[Skip Robinson]

My first inclination was to say that SYS1.BRODCAST had resided on a volume 
that was removed. Then I remembered this line in MSTJCLxx: 

//SYSLBC   DD DISP=SHR,DSN=SYS1.BRODCAST 

which would make IPL pretty dicey. Then it occurred to me that as long as 
the data set it cataloged, maybe the system doesn't really look for it 
until LISTBC needs to do I/O. So do LISTCAT on SYS1.BRODCAST  .
If the volume is missing, that's the problem. Otherwise, check for a 
personal 'userlog' data set cataloged to a missing volume. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Norgauer jcnorga...@ucdavis.edu
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/15/2014 11:03 AM
Subject:MSG IKJ56961E LISTBC TERMINATED
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Getting this at TSO logon time. This is on a test LPAR which had many 
volumes eliminated(because of clean-up).

Any thoughts as to identifying the volume?


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

Re: MSG IKJ56961E LISTBC TERMINATED

[Anthony Thompson]

The full IKJ56961E message should have supplied dynalloc return / reason codes, 
which the OP didn't supply but would have helped.

Skip may have it right with regards to SYS1.BRODCAST, but the OP should check 
his IKJTSO member is see if TSO/E userlogs are being used instead (SEND 
statement, USERLOG parameter).

Given that 'many volumes were eliminated',  it may be that his private TSO/E 
userlog was trashed, and the SMS ACS routines crippled to the point a new one 
can't be allocated (check the form of the TSO/E USERLOG filename, if used, and 
throw it through a SMS ACS test case).


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Tuesday, 16 September 2014 5:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

My first inclination was to say that SYS1.BRODCAST had resided on a volume that 
was removed. Then I remembered this line in MSTJCLxx: 

//SYSLBC   DD DISP=SHR,DSN=SYS1.BRODCAST 

which would make IPL pretty dicey. Then it occurred to me that as long as the 
data set it cataloged, maybe the system doesn't really look for it until LISTBC 
needs to do I/O. So do LISTCAT on SYS1.BRODCAST  .
If the volume is missing, that's the problem. Otherwise, check for a personal 
'userlog' data set cataloged to a missing volume. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Norgauer jcnorga...@ucdavis.edu
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/15/2014 11:03 AM
Subject:MSG IKJ56961E LISTBC TERMINATED
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Getting this at TSO logon time. This is on a test LPAR which had many 
volumes eliminated(because of clean-up).

Any thoughts as to identifying the volume?


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

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

Re: MSG IKJ56961E LISTBC TERMINATED

[Anthony Thompson]

Oh, another possibility... When volumes were removed from your test LPAR, were 
the catalogues cleaned up to remove entries that referred to files on those 
removed volumes? It may be that you have dead catalogue entries that refer to 
datasets that no longer exist ( general SYS1.BRODCAST or private TSO/E 
userlogs), which would cause allocation failures.

Note also the IKJTSO member can specify an alternate name for SYS1.BRODCAST, as 
well as a specific volser for it.


Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Tuesday, 16 September 2014 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

The full IKJ56961E message should have supplied dynalloc return / reason codes, 
which the OP didn't supply but would have helped.

Skip may have it right with regards to SYS1.BRODCAST, but the OP should check 
his IKJTSO member is see if TSO/E userlogs are being used instead (SEND 
statement, USERLOG parameter).

Given that 'many volumes were eliminated',  it may be that his private TSO/E 
userlog was trashed, and the SMS ACS routines crippled to the point a new one 
can't be allocated (check the form of the TSO/E USERLOG filename, if used, and 
throw it through a SMS ACS test case).


Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Tuesday, 16 September 2014 5:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MSG IKJ56961E LISTBC TERMINATED

My first inclination was to say that SYS1.BRODCAST had resided on a volume that 
was removed. Then I remembered this line in MSTJCLxx: 

//SYSLBC   DD DISP=SHR,DSN=SYS1.BRODCAST 

which would make IPL pretty dicey. Then it occurred to me that as long as the 
data set it cataloged, maybe the system doesn't really look for it until LISTBC 
needs to do I/O. So do LISTCAT on SYS1.BRODCAST  .
If the volume is missing, that's the problem. Otherwise, check for a personal 
'userlog' data set cataloged to a missing volume. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Norgauer jcnorga...@ucdavis.edu
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/15/2014 11:03 AM
Subject:MSG IKJ56961E LISTBC TERMINATED
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



Getting this at TSO logon time. This is on a test LPAR which had many volumes 
eliminated(because of clean-up).

Any thoughts as to identifying the volume?


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

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

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

DFHSM QUESTION - UNABLE TO FIX MSG 909 - AUDIT

[willie bunter]

Good Day All,

AUDIT MEDIACONTROLS VOLUMES(MVSZ04) NOFIX.  I received the following message :

/* MSG 909 - ERROR IN OPENING DSN(DFHSM.HMIG.T182120.A4PROD.XPD2.A4226) 
VOLUME(MVSZ04) */ 
/* MSG 998 - AUDIT CONTINUING, COMMAND ACTIVITY LOG MAY CONTAIN ADDITIONAL 
INFORMATION */

I ran a FIXCDS A DFHSM.HMIG.T182120.A4PROD.XPD2.A4226 DISPLAY but HSM says that 
the file does not exist :
ARC0195I TYPE A, KEY DFHSM.HMIG.T182120.A4PROD.XPD2.A4226, FIXCDS DISPLAY, ERROR
 I checked the error message in the manual DFSMShsm Storage Management 
SC35-0421-14 to perform the cleanup. According to IBM Speak all it says the 
following :

MSG 908 ERROR CLOSING DSN(dsname) [VOLUME(volser) | SDSP FOR VOLUME(volser)].
Explanation:
An error has been encountered during the closing of the data set dsname. The 
data set is on the volume volser.

If my understanding of IBM Speak is correct the dsn shold be on the volume.  
However, I checked the volume via ISPF 3.4 but it is not there.  Also, this 
volume is a NOSDSP contrary to the IBM explanation

Could someone suggest what I should do to correct the error or it will 
mysteriously go away?

Thanks.

 

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

Re: DFHSM QUESTION - UNABLE TO FIX MSG 909 - AUDIT

[Staller, Allan]

ISTR, that if SDSP is used, all ML1 volumes should have a SDSP dataset.
This may have changed. Check the fine manuals,

HTH,
snip
AUDIT MEDIACONTROLS VOLUMES(MVSZ04) NOFIX.  I received the following message :

/* MSG 909 - ERROR IN OPENING DSN(DFHSM.HMIG.T182120.A4PROD.XPD2.A4226) 
VOLUME(MVSZ04) */ 
/* MSG 998 - AUDIT CONTINUING, COMMAND ACTIVITY LOG MAY CONTAIN ADDITIONAL 
INFORMATION */

I ran a FIXCDS A DFHSM.HMIG.T182120.A4PROD.XPD2.A4226 DISPLAY but HSM says that 
the file does not exist :
ARC0195I TYPE A, KEY DFHSM.HMIG.T182120.A4PROD.XPD2.A4226, FIXCDS DISPLAY, 
ERROR  I checked the error message in the manual DFSMShsm Storage Management 
SC35-0421-14 to perform the cleanup. According to IBM Speak all it says the 
following :

MSG 908 ERROR CLOSING DSN(dsname) [VOLUME(volser) | SDSP FOR VOLUME(volser)].
Explanation:
An error has been encountered during the closing of the data set dsname. The 
data set is on the volume volser.

If my understanding of IBM Speak is correct the dsn shold be on the volume.  
However, I checked the volume via ISPF 3.4 but it is not there.  Also, this 
volume is a NOSDSP contrary to the IBM explanation
/snip

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

Re: DFHSM QUESTION - UNABLE TO FIX MSG 909 - AUDIT

[Pommier, Rex]

Willie,

While I can't comment on what you need to do to actually fix the problem, I can 
comment on your confusion about the SDSP.  The description in the storage mgmt 
manual (I have a slightly older revision of the book) for message 909 (you 
documented 908) says:


MSG 909 ERROR OPENING [DSN(datasetname) | SDSP FOR VOLUME(volser)]  An error 
has been encountered during the OPENING of the data set indicated. The data set 
is on either the SDSP VOLUME indicated or the VOLUME indicated.


So since your actual error is stating error in opening DSN..., it is having 
trouble opening the dataset.  No SDSP is involved.  If the SDSP were there and 
involved, the error would state it was having trouble with the SDSP for 
volume  Since you can't find the actual dataset, I would interpret the MSG 
909 as DFHSM tried to open the DSN on this volume, but something is wrong so 
HSM threw an open error.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of willie bunter
Sent: Friday, August 15, 2014 8:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFHSM QUESTION - UNABLE TO FIX MSG 909 - AUDIT

Good Day All,

AUDIT MEDIACONTROLS VOLUMES(MVSZ04) NOFIX.  I received the following message :

/* MSG 909 - ERROR IN OPENING DSN(DFHSM.HMIG.T182120.A4PROD.XPD2.A4226) 
VOLUME(MVSZ04) */ 
/* MSG 998 - AUDIT CONTINUING, COMMAND ACTIVITY LOG MAY CONTAIN ADDITIONAL 
INFORMATION */

I ran a FIXCDS A DFHSM.HMIG.T182120.A4PROD.XPD2.A4226 DISPLAY but HSM says that 
the file does not exist :
ARC0195I TYPE A, KEY DFHSM.HMIG.T182120.A4PROD.XPD2.A4226, FIXCDS DISPLAY, ERROR
 I checked the error message in the manual DFSMShsm Storage Management 
SC35-0421-14 to perform the cleanup. According to IBM Speak all it says the 
following :

MSG 908 ERROR CLOSING DSN(dsname) [VOLUME(volser) | SDSP FOR VOLUME(volser)].
Explanation:
An error has been encountered during the closing of the data set dsname. The 
data set is on the volume volser.

If my understanding of IBM Speak is correct the dsn shold be on the volume.  
However, I checked the volume via ISPF 3.4 but it is not there.  Also, this 
volume is a NOSDSP contrary to the IBM explanation

Could someone suggest what I should do to correct the error or it will 
mysteriously go away?

Thanks.

 

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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: DFHSM QUESTION - UNABLE TO FIX MSG 909 - AUDIT

[Willie Bunter]

Rex,

Thanks for taking the time to clear up my misunderstanding about the error 
message.  Hopefully somebody can provide a solution. so that I can resolve the 
problem.

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

Re: DFHSM QUESTION - UNABLE TO FIX MSG 909 - AUDIT

[retired mainframer]

Did you look at the volume in question?  Is the dataset there?  Is the DSCB 
correct?  Can you browse the dataset (or print it with IDCAMS or dump it with 
ADRDSSU)?

The dataset is a migration one.  Is it on ML1 or ML2?  If ML1, then there might 
also be a backup copy.  If ML2, do you duplex your ML2 volumes?  If the dataset 
is truly unusable and unrecoverable, the simplest thing may be to delete it and 
the various HSM records and pretend it never existed. 

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Willie Bunter
 Sent: Friday, August 15, 2014 8:08 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: DFHSM QUESTION - UNABLE TO FIX MSG 909 - AUDIT
 
 Rex,
 
 Thanks for taking the time to clear up my misunderstanding about the error
 message.  Hopefully somebody can provide a solution. so that I can resolve
 the problem.
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

dark operation - msg IOS003A, intervention required, what to do?

[John McKown]

We run dark on the weekends and part of the nights. We are having a
problem right now with our 3584 tape library, the physical 3590 drive
side, not the VTS. The first looks like:

IOS000I 0809,08,IOE,01,0600,,**,101332,POPH302D  790
 100410C060127050  0091 4204E8205E112011
 EQUIPMENT CHECK

Now, this usually causes an abend. But we have a _nice_ product,
TapeCopy from Rocket, which traps the resultant S714-0C abend, report
it, and then continues. In our case, this is a _problem_ because the
next message out of these jobs is:

*IOS003A 0809,INTERVENTION REQUIRED, READY THE DEVICE

At this point, the job hangs. I'm not sure why it does not S522,
except that I _think_ it is in OPEN? In any case, there is no one
around to see this message. I happened to notice it because I logged
in about 8 p.m. and noticed the job wasn't running. And then noticed
that message in the JOBLOG. From 6:23 a.m. that morning. Over 12 hours
lost.

Well, I now have a CA-OPS/MVS rule to trap the ISO003A message which
causes, eventually, an SMS text message to be sent to the ON CALL
tech services person.

But the only thing I have found to do at this point is to VARY
,OFFLINE,FORCE which causes the job to abend. The SWAP command
give an error of some sort.  Is there something better that I could
do?

In addition to the above, I have seen:

CBR3776I Volume 101855 inaccessible in library $ATL0002.

Which I think means that the robot did not take the tape from the
drive having a problem. Which definitely means somebody needs to go in
to pause the library, retrieve the tape, unpause the library, put the
tape in the input drawer. Which leads to its own problems because we
shared the idiot machine with a Windows server with __IDIOT__ software
which aborts if the library is paused when it decides to mount a tape.
This rather than waiting a bit and retrying a few times.

Any words of wisdom, or commiseration, are welcome.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! 
John McKown

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

SMPE msg GIM24801S

[John Norgauer]

I am trying to clean-up my SMPE.SMPPTS. Am getting message:

GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE ACCEPT 
COMMAND

Here's my SMPE command:

ACCEPT
SOURCEID(ZOSV1R13) CHECK

The sourceid has lots of PTF's that are in APPLY status.

Shouldn't this work?



John Norgauer
Senior Systems Programmer
Mainframe Technical Support Services
University of California Davis Medical Center
2315 Stockton Blvd
ASB 1300
Sacramento, Ca 95817
916-734-0536

 SYSTEMS PROGRAMMING..  Guilty, until proven innocent !! JN  2004

Hardware eventually breaks - Software eventually works  anon


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

Re: SMPE msg GIM24801S

[Lizette Koehler]

Are you sure you have any PTFs to accept?  Try listing PTFs you think are 
applied but not accepted.

Then run an accept check against those PTFs (one or more should be sufficient)

If you do not get the error, then you know your current control cards are 
probably not doing what you want.

When was the last time you successfully used these control cards to accept 
check maint?


Sometimes when I am stuck, I will use the SMPE Panels OPT 4 or Opt 2 and have 
the panels generate the commands I need.

Lizette



-Original Message-
From: John Norgauer john.norga...@ucdmc.ucdavis.edu
Sent: Dec 20, 2012 4:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE msg GIM24801S

I am trying to clean-up my SMPE.SMPPTS. Am getting message:

GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE ACCEPT 
COMMAND

Here's my SMPE command:

ACCEPT
SOURCEID(ZOSV1R13) CHECK

The sourceid has lots of PTF's that are in APPLY status.

Shouldn't this work?



John Norgauer

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

Re: SMPE msg GIM24801S

[John Norgauer]

Oops I only checked the Sourceid with a SMPE list command against the 
target.

My bad... looks like they are accepted. Thanks for the suggestion.



John Norgauer
Senior Systems Programmer
Mainframe Technical Support Services
University of California Davis Medical Center
2315 Stockton Blvd
ASB 1300
Sacramento, Ca 95817
916-734-0536

 SYSTEMS PROGRAMMING..  Guilty, until proven innocent !! JN  2004

Hardware eventually breaks - Software eventually works  anon


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

Re: MQ msg

[Neubert, Kevin]

Yes.  STAT is active for all classes.  ACCTG is active for class 01.  If STAT 
were inactive, DISPLAY TRACE(STAT) would indicate CSQW137I...SPECIFIED TRACE 
NOT ACTIVE.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Wells
Sent: Friday, October 05, 2012 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MQ msg

anyone...the manual not clear ..
this display mean MQ trace active ??

RESPONSE=AGFP
 CSQW127I -MQP1 CURRENT TRACE ACTIVITY IS - 
 TNO TYPE   CLASSDEST USERID   RMID 
 01  STAT   *SMF  ** 
 02  ACCTG  01   SMF  ** 
 END OF TRACE REPORT 

needing to collect MQ perf stats..

--
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...@listserv.ua.edu with the message: INFO IBM-MAIN

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

MQ msg

[Ron Wells]

anyone...the manual not clear ..
this display mean MQ trace active ??

RESPONSE=AGFP 
 CSQW127I -MQP1 CURRENT TRACE ACTIVITY IS - 
 TNO TYPE   CLASSDEST USERID   RMID 
 01  STAT   *SMF  ** 
 02  ACCTG  01   SMF  ** 
 END OF TRACE REPORT 

needing to collect MQ perf stats..

--
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...@listserv.ua.edu with the message: INFO IBM-MAIN