LINK monitor status for OSA HMC

[Jake Anderson]

Hello

Cross posted

I apologize for my ignorance.

I was looking for the status of one of our OSA card under OSA advanced
facilities under HMC. For one of their PCHPID belonging to OSA shows the
port status as 'LINK MONITOR'

When I checked with my network team if their switch sees the MAC address of
my OSA port but they don't see it.

>From the physical cabling perspective what do I need to do?

Z14 zr1

Jake

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

Re: Blank page print after upgrade Zos2.5

[Brian Westerman]

I am assuming that you are printing with JES2 and not VPS or some other remote 
print product.

This can happen if you didn't re-assemble your separator exit.  Although it can 
happen with VPS as well if you forget to assemble it, but VPS is good about 
telling you if you forgot.  JES can mess up if the exit didn't assemble 
cleanly, or 

Do you notice that the data your exit is putting out is not being inserted into 
the separator?  Also, this can happen if your printer definitions have changed 
between the releases.  

Did you change your default lines per page for the printer.  IF your separator 
is larger than the page, it will cause an extra eject.

IBM says "Some printers do not reposition to "top of forms" after the trailer 
page. To avoid feeding blank pages through your printer, include a page eject 
statement in your exit routine following the trailer separator page."  If your 
problem is a blank page after the last separator, then this is likely to be the 
reason. 

Otherwise, I need more information to help you debug this.

Brian

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

Re: ARM

[David Spiegel]

Hi Steve,
The AB/S0878 might be a result of SMF Exits needing re-coding.
Also, if you supply the (subcode e.g. 0C) it would be helpful.

It might also be related to too many active channels in MQ.
Please see:
Why is the IBM MQ Channel Initiator abending with ABEND878? 



Regards,
David

On 2022-08-09 16:09, Steve Beaver wrote:

We are having a problem.  TcVision is a support product for ADABAS.

  


A couple times a week the Address Space gets an S878 and falls down.

And the users are getting upset.

  


Can anyone suggest a way to let the S878 die off and some how

set an ARM to allow ARM to case the TcVision to restart.

  

  


PS: I am oceans out of my depth with ARM


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: ARM

[Mike Schwab]

What is the 24 bit region size?  Some people move the TSO LPA modules to
private libraries to get more private memory.

z/OS S878 is the job requests more memory than what is available in THAT
address space.

I think IBM added some code to restart address spaces to prevent this abend.

On Tue, Aug 9, 2022, 15:10 Steve Beaver  wrote:

> We are having a problem.  TcVision is a support product for ADABAS.
>
>
>
> A couple times a week the Address Space gets an S878 and falls down.
>
> And the users are getting upset.
>
>
>
> Can anyone suggest a way to let the S878 die off and some how
>
> set an ARM to allow ARM to case the TcVision to restart.
>
>
>
>
>
> PS: I am oceans out of my depth with ARM
>
>
> --
> 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: ACF2, z/OS 2.5 and TCPIP

[Michael Brennan]

The IBM and Broadcom developers met about this issue and the result is the
issue we are having with TCPIP is back in IBMs hands.   The issue is we are
getting different abends in TCPIP such as
878-0C
653
4C5
To recover TCPIP we have to issue command
V TCPIP,,SYSPLEX,JOINGROUP
to get TCPIP to recover on the lpar where the abend occurrs.



On Mon, Aug 8, 2022 at 4:17 PM Hights, Charles 
wrote:

> What exactly is your problem? We have this setup on 5 LPAR's.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Paul Gilmartin
> Sent: Monday, August 8, 2022 2:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ACF2, z/OS 2.5 and TCPIP
>
> On Mon, 8 Aug 2022 15:42:05 -0500, Michael Brennan wrote:
>
> >Anyone having both z/OS 2.5 installed while also running ACF2 as your
> security system have any issues related to TCPIP after upgrading to z/OS
> 2.5?  We have issues opened with both IBM and Broadcom and they are both
> pointing at each other.
> >
> Ask each for the ticket number the other assigned to the issue.
> I'd be surprised if either is not a customer of the other.
>
> --
> gil
>
> --
> 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
>


-- 
Michael Brennan

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

Blank page print after upgrade Zos2.5

[Tommy Tsui]

We found most statements printing a blank page after separator exit. Anyone
hits the same problem after upgrade to zos2.5. We check all the jes2 spool
data are normal without error. Thanks

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

Re: ARM

[Pew, Curtis G]

On Aug 9, 2022, at 3:09 PM, Steve Beaver 
mailto:st...@stevebeaver.com>> wrote:

We are having a problem.  TcVision is a support product for ADABAS.



A couple times a week the Address Space gets an S878 and falls down.

And the users are getting upset.



Can anyone suggest a way to let the S878 die off and some how

set an ARM to allow ARM to case the TcVision to restart.

Have you reported the issue to Treehouse? It seems like the best solution is to 
fix the memory leak or whatever is causing the S878 abend.

(We have TcVision, but are at a very early stage of implementation. We aren’t 
seeing this problem.)


--
Curtis Pew
ITS Campus Solutions
curtis@austin.utexas.edu




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

Re: [EXTERNAL] ARM

[Pommier, Rex]

Steve,

Do you need to use ARM?  Do you have any kind of console automation that could 
"see" the abend and just do a restart of it?  

I'm hoping the vendor of TcVision is trying to get you a permanent fix.  Just 
restarting it when it falls over doesn't sound like a good long term solution.  
:-)

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Tuesday, August 9, 2022 3:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] ARM

We are having a problem.  TcVision is a support product for ADABAS.

 

A couple times a week the Address Space gets an S878 and falls down.

And the users are getting upset.

 

Can anyone suggest a way to let the S878 die off and some how 

set an ARM to allow ARM to case the TcVision to restart.

 

 

PS: I am oceans out of my depth with ARM


--
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

ARM

[Steve Beaver]

We are having a problem.  TcVision is a support product for ADABAS.

 

A couple times a week the Address Space gets an S878 and falls down.

And the users are getting upset.

 

Can anyone suggest a way to let the S878 die off and some how 

set an ARM to allow ARM to case the TcVision to restart.

 

 

PS: I am oceans out of my depth with ARM


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

SDSF's ISFUSER Conversion to RACF

[Michael Babcock]

I'm working on moving our ISFPRMxx member to RACF.  I have a question 
for the group (posted to IBM-MAIN and RACF-L).


How are people handling the "default SDSF user"?  The IDs that don't 
fall into any other group (in our case it's ISFUSER).  We do have 
TSOAUTH(JCL) in the ISFPRMxx for ISFUSER.    Are you creating a 
CLASS(SDSF) GROUP.ISFUSER.* profile and with UACC(READ) and NOT creating 
a ISFUSER group and COnnecting all other users to the ISFUSER group?  
This method seems to provide SDSF access to EVERY user (who doesn't fall 
into another group) even those without TSOAUTH(JCL).  This does have the 
advantage that security doesn't have to explicitly add new users to a 
ISFUSER group.


Or are people creating an ISFUSER group, creating a SDSF GROUP.ISFUSER.* 
profile with UACC(NONE), creating the ISFUSER group and COnnecting only 
those users with TSOAUTH(JCL) and permitting the ISFUSER group READ to 
the SDSF GROUP.ISFUSER.* profile?  This means that every new TSO user 
will need to be connected to the ISFUSER group or they won't get access 
to SDSF (another assumption on my part).


Or foregoing the creation of a SDSF GROUP.ISFUSER.* profile and the 
ISFUSER group altogether?  I'm assuming that anyone not connected to any 
other group will fall into the ISFRMxx's ISFUSER section even though 
they don't have TSOAUTH(JCL).


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

Re: TCB owner of 64 bit memory object

[Joseph Reichman]

No I was hoping to get something like what’s returned by VSMLIST for 64 bit 
storage 

> On Aug 9, 2022, at 10:37 AM, Joseph Reichman  wrote:
> 
> Thanks I know when I execute IARV64 in SRB 
> mode It requires a TCB token so the 31 bit concept of storage is owned by a 
> TCB is true for 64 bit storage as well 
> 
>> On Aug 9, 2022, at 9:48 AM, Harris Morgenstern  wrote:
>> 
>> IARV64 REQUEST=LIST does not return the TCB address.  There is also no 
>> "filter by owning TCB" parameter option associated with IARV64 REQUEST=LIST.
>> Both sound like reasonable requests for enhancement.
>> 
>> --
>> 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: TCB owner of 64 bit memory object

[Joseph Reichman]

Thanks I know when I execute IARV64 in SRB 
mode It requires a TCB token so the 31 bit concept of storage is owned by a TCB 
is true for 64 bit storage as well 

> On Aug 9, 2022, at 9:48 AM, Harris Morgenstern  wrote:
> 
> IARV64 REQUEST=LIST does not return the TCB address.  There is also no 
> "filter by owning TCB" parameter option associated with IARV64 REQUEST=LIST.
> Both sound like reasonable requests for enhancement.
> 
> --
> 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: TCB owner of 64 bit memory object

[Tom Harper]

If these memory objects were obtained by you, you could place the A(Owning TCB) 
in the USERTKN when they are obtained. 

Then, you can use the REQUEST=LIST to filter on that USERTKN and thus obtain 
the information you want. 

Tom Harper
Phoenix Software International 

Sent from my iPhone

> On Aug 9, 2022, at 9:47 AM, Harris Morgenstern  wrote:
> 
> IARV64 REQUEST=LIST does not return the TCB address.  There is also no 
> "filter by owning TCB" parameter option associated with IARV64 REQUEST=LIST.
> Both sound like reasonable requests for enhancement.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

TCB owner of 64 bit memory object

[Harris Morgenstern]

IARV64 REQUEST=LIST does not return the TCB address.  There is also no "filter 
by owning TCB" parameter option associated with IARV64 REQUEST=LIST.
Both sound like reasonable requests for enhancement.

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

Re: ACF2, z/OS 2.5 and TCPIP

[Steve Beaver]

Paul

Talk to Broadcom ACF2 support and ask them how to turn on a trace in ACF2.

That will answer a lot of questions

Best of Luck

Steve





This electronic mail (including any attachments) may contain information that 
is privileged, confidential, and/or otherwise protected from disclosure to 
anyone other than its intended recipient(s). Any dissemination or use of this 
electronic email or its contents (including any attachments) by persons other 
than the intended recipient(s) is strictly prohibited. If you have received 
this message in error, please notify us immediately by reply email so that we 
may correct our internal records. Please then delete the original message 
(including any attachments) in its entirety. Thank you

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hights, Charles
Sent: Monday, August 8, 2022 4:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ACF2, z/OS 2.5 and TCPIP

What exactly is your problem? We have this setup on 5 LPAR's.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Monday, August 8, 2022 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ACF2, z/OS 2.5 and TCPIP

On Mon, 8 Aug 2022 15:42:05 -0500, Michael Brennan wrote:

>Anyone having both z/OS 2.5 installed while also running ACF2 as your security 
>system have any issues related to TCPIP after upgrading to z/OS 2.5?  We have 
>issues opened with both IBM and Broadcom and they are both pointing at each 
>other.
>
Ask each for the ticket number the other assigned to the issue.
I'd be surprised if either is not a customer of the other.

--
gil

--
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