Re: What determines the effective terminal size?

[Christian Svensson]

Thanks all, this cleared up some things indeed!

I have now read and experimented, and for my ICC terminal size issue it
seem that with the combined tips above I managed to craft "LOGON
APPLID=TSO,LOGMODE=D4B32784" which makes me able to use a 80x43 terminal in
ISPF at least (and D4B32785 for a 27x132) when autodetection fails.
That is very much appreciated progress. Ideally I would like to
use D4B32XX3 to make use of the dynamic sizing, which I see that my TCPIP
connections use (D NET,SESSIONS,SID=xxx) (or rather, the remote version
D4C32XX3), but if I try to force that LOGMODE I get the earlier mentioned
error IKT00405I "Screen erase caused by error recovery procedure".

That issue however seems to be "working as intended":
SSMVSE11008 Allow OSA-ICC Consoles to have larger than Mod 5 Screen Size
Consoles connected via an OSA-ICC must use 3270 screen sizes 2 (24X80), 3
(32X80), 4 (43X80), or 5 (27X132) while SMCS consoles can use screen sizes
up to 60X132. The OSA-ICC support needs to be updated to allow for larger
screen sizes.
Rejected: OSA-ICC is a stabilized function and is not being enhanced.

It does seem that this was later re-opened and fixed for z13 and newer, so
I guess my poor zBC12 will have to live with this limitation.

Either way, now I understand more!

Regards,

On Mon, Dec 6, 2021 at 6:08 PM Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> If your installation has not disabled or deleted them, IBM standard
> VTAMLST defines a flexible log mode (D4C32XX3) that you can specify in the
> LOGON to VTAM.  I use this in a PCOMM script that I use to login to my
> employer's systems:
>
> logon applid=,logmode=D4C32XX3
>
> Where "" is my employer's system name.   This allows me to use a
> custom screen size (50x160) from PCOMM.
>
> My ISPF terminal settings are:
>
> Screen format   3   (MAX)
>
> Terminal Type   28  (3278L1 for code page setting 1047 which allows me
> to use "real" EBCDIC square brackets X'AD' and X'BD')
>
> HTH
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Seymour J Metz
> Sent: Monday, December 6, 2021 9:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What determines the effective terminal size?
>
> EXTERNAL EMAIL
>
> I forgot to mention that OSA-ICC is a TN3270 server that presents the
> appearance of a local non-SNA controller, which means that there is no
> exchange of BIND. What's in the LOGMODE that you're using?
>
>
> --
> Shmuel (Seymour J.) Metz
>
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!eyVjdivF1-lcxrN1dYmRRl-p0KULDqDn4ERbh-nY-ht2KWbO-pVz1GnFgv5nDAOVbMe-pQ$
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Christian Svensson [022ad63487ef-dmarc-requ...@listserv.ua.edu]
> Sent: Monday, December 6, 2021 5:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: What determines the effective terminal size?
>
> Hi folks,
>
> I am trying to go back to basics a bit and figure out some things that I
> have always treated as magic.
> Right now it is how a 3270 terminal connected to a z/OS determines the
> size of the terminal. In this case through OSA-ICC (zBC12, OSA-Express5)
> and not TCPIP,
>
> On systems where I have configured VTAM with TCPIP the terminal size seems
> to almost always "just work".
> Let's take a look at an example. I have configured X3270 with model
> "3279-4-E" and oversize set to "133x60".
>
> 1) What does the z/OS VTAM screen look like?
> Over OSA-ICC: 80x24
> Over TCPIP: 80x24
>
> So far so good.
>
> 2) What does the TSO screen look like?
> Over OSA-ICC: 80x24
> Over TCPIP: 80x24
>
> Ok, no change.
>
> 3) What does the ISPF screen look like?
> Over OSA-ICC: 80x24
> Over TCPIP: 133x60
>
> Oh! But why? I do not know! Also, after I exit ISPF back to TSO, the TSO
> screen is now correctly filling the full screen!
>
> I also note that z/VM's login screen seems to behave similarly. Over
> OSA-ICC the size seems to be fixed at 80x24, but over TCPIP it follows what
> I configured X3270 to use.
> Dialing a z/OS VTAM terminal through the z/OS login screen (connected via
> TCPIP) seems to result in a 133x60 screen both in TSO and ISPF. However if
> I ATTACH an OSA-ICC terminal straight to a z/OS guest, ISPF gets 133x60 but
> TSO only 80x24 - *but only if I reconnect to an existing user session.* If
> I log out and try to log in again I get IKT00405I "Screen erase caused by
> error recovery procedure".
>
> As you can see I am a mess when it comes to understanding how this a

What determines the effective terminal size?

[Christian Svensson]

Hi folks,

I am trying to go back to basics a bit and figure out some things that I
have always treated as magic.
Right now it is how a 3270 terminal connected to a z/OS determines the size
of the terminal. In this case through OSA-ICC (zBC12, OSA-Express5) and not
TCPIP,

On systems where I have configured VTAM with TCPIP the terminal size seems
to almost always "just work".
Let's take a look at an example. I have configured X3270 with model
"3279-4-E" and oversize set to "133x60".

1) What does the z/OS VTAM screen look like?
Over OSA-ICC: 80x24
Over TCPIP: 80x24

So far so good.

2) What does the TSO screen look like?
Over OSA-ICC: 80x24
Over TCPIP: 80x24

Ok, no change.

3) What does the ISPF screen look like?
Over OSA-ICC: 80x24
Over TCPIP: 133x60

Oh! But why? I do not know! Also, after I exit ISPF back to TSO, the TSO
screen is now correctly filling the full screen!

I also note that z/VM's login screen seems to behave similarly. Over
OSA-ICC the size seems to be fixed at 80x24, but over TCPIP it follows what
I configured X3270 to use.
Dialing a z/OS VTAM terminal through the z/OS login screen (connected via
TCPIP) seems to result in a 133x60 screen both in TSO and ISPF. However if
I ATTACH an OSA-ICC terminal straight to a z/OS guest, ISPF gets 133x60 but
TSO only 80x24 - *but only if I reconnect to an existing user session.* If
I log out and try to log in again I get IKT00405I "Screen erase caused by
error recovery procedure".

As you can see I am a mess when it comes to understanding how this all fits
together! It seems pretty much random to me, except that TCPIP "almost
always works" and OSA-ICC "almost never works".
I would love to learn more, but I don't even know where to begin.

Regards,

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

Re: Gotchas with CBDQDISP / HCM?

[Christian Svensson]

Hi folks,

I have debugged this a bit further, and it appears that my SSHD is
also behaving strangely.
If I connect to port 22 I can see the SSH-version string (you know,
the "SSH-2.0-OpenSSH_8.4p1 Debian-5" equivalent) - but it is sent in
EBCDIC!
I can also see the connection closed with the message "Protocol
mismatch", also in EBCDIC - of course it would since the z/OS SSHD
server would be getting absolute gibberish from its point of view.

If I try to login to my CBDQDISP as the user "" I see the same in
the logs - that it registered an attempt to login as "".

I am pretty sure I am to blame for this in my journey to level up my
sysprog skills, but I have no idea what I could have done to enable an
"extra" EBCDIC/ASCII conversion.

Any ideas?

Regards,


On Wed, May 12, 2021 at 7:17 PM Christian Svensson  wrote:
>
> Hi folks,
>
> I am playing a bit with CBDQDISP and trying to get it to run with HCM for 
> z/OS.
> I tried using the SYS1.PROCLIB(CBDQDISP) and SYS1.SAMPLIB(CBDQDISJ), the 
> latter while adding SYS1.SAMPLIB to APF (lab system, so no harm done security 
> wise).
>
> The issue I am having is that when connecting with HCM (trying with user-ID 
> "TEST") I get the following error in SDSF:
> CBDG983I CBDQTDIS -- start-agent request for user (   received
> CBDG985I CBDQTDIS -- HCM validation for client user id <(  > failed
>
> On HCM I receive the following error on HCM: https://imgur.com/RO0rRIv.
>
> Are the error messages simply missing an EBCDIC conversion and something else 
> is the issue, or am I missing something crucial with the communication?
>
> Regards,

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

Gotchas with CBDQDISP / HCM?

[Christian Svensson]

Hi folks,

I am playing a bit with CBDQDISP and trying to get it to run with HCM
for z/OS.
I tried using the SYS1.PROCLIB(CBDQDISP) and SYS1.SAMPLIB(CBDQDISJ), the
latter while adding SYS1.SAMPLIB to APF (lab system, so no harm done
security wise).

The issue I am having is that when connecting with HCM (trying with user-ID
"TEST") I get the following error in SDSF:
CBDG983I CBDQTDIS -- start-agent request for user (   received
CBDG985I CBDQTDIS -- HCM validation for client user id <(  > failed

On HCM I receive the following error on HCM: https://imgur.com/RO0rRIv.

Are the error messages simply missing an EBCDIC conversion and something
else is the issue, or am I missing something crucial with the communication?

Regards,

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

Re: IPv6 on z/OS under z/VM

[Christian Svensson]

+IBMVM of course

On Tue, May 11, 2021 at 12:51 AM Christian Svensson 
wrote:

> Hi folks,
>
> I am trying to understand how you can run IPv6 on z/OS under z/VM.
>
> I have come to the following conclusion:
>  - From https://www.vm.ibm.com/devpages/altmarka/vswitch1.pdf I learned
> that Layer3 VSWITCH only supports IPv4.
>  - From https://www.mail-archive.com/ibmvm@listserv.uark.edu/msg31590.html
> I have learned that z/OS does not work with a Layer2 VSWITCH.
>
> Are these assumptions wrong?
> Am I required to DEDICATE an OSA adapter to z/OS for it to run IPv6?
>
> Regards,
>

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

IPv6 on z/OS under z/VM

[Christian Svensson]

Hi folks,

I am trying to understand how you can run IPv6 on z/OS under z/VM.

I have come to the following conclusion:
 - From https://www.vm.ibm.com/devpages/altmarka/vswitch1.pdf I learned
that Layer3 VSWITCH only supports IPv4.
 - From https://www.mail-archive.com/ibmvm@listserv.uark.edu/msg31590.html
I have learned that z/OS does not work with a Layer2 VSWITCH.

Are these assumptions wrong?
Am I required to DEDICATE an OSA adapter to z/OS for it to run IPv6?

Regards,

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

Re: Debugging "A high error rate was detected on the Optical Link network." HMC alert

[Christian Svensson]

Hello,

I understand that ideally I would find the error - but all the values seem
correct in my eyes.
The optical values are fine, no errors shown on the interfaces, etc.

This bugs me a bit. I did not have this issue when it was connected to
another mainframe, but it has it now...

Regards,

On Tue, Apr 6, 2021 at 3:32 PM Radoslaw Skorupka 
wrote:

> You can disable that using HMC features (it is called Optical Network
> Errors or similar).
> However DON'T DO IT.
> This is symptom of some problem. It can be pinched FO cable, dirty
> connector or failing SFP module.
> Unfortunately it is almost good, so there is no simple way to know
> whether cable change helped or not.
> We like more consistent failures ;-)
> However I would start from visual inspection and then cable change.
>
> --
> Radoslaw Skorupka
> (looking for new job)
> Lodz, Poland
>
>
>
> W dniu 05.04.2021 o 12:25, Christian Svensson pisze:
> > Good day,
> >
> > Recently I have been getting these kinds of alerts from my HMC. It all
> > started when I connected an old DS6800 and the details are:
> >
> > Node 1
> > Machine: 2498-B40
> > Serial: IBMCA107312B
> > Physical Interface: 6620
> > Logical Interface: 0020
> >
> > Node 2
> > Machine: 1750-511
> > Serial: IBM13715
> > Physical Interface: 0100
> > Logical Interface: 
> >
> > I keep getting these errors about 3-4 per day with the exact same
> > interfaces specified. No others, just these.
> >
> > When I look at the referenced SAN switch and I do a "porterrshow" things
> > seem fine:
> >frames  enccrccrctootoobadenc
>  disc
> >link   loss   loss   frjt   fbsy  c3timeoutpcs
> > tx rx  inerrg_eof  shrt   long   eof out   c3
> >   failsync   sig  txrx err
> >   20:4.8m  46.9k   0  0  0  0  0  0  0  0
> > 0  2  2  0  0  0  0  0
> >   32:   27.5k  17.7k   0  0  0  0  0  0  0  0
> > 0  0  0  0  0  0  0  0
> >   33:   19.3k  13.6k   0  0  0  0  0  0  0  0
> > 0  0  1  0  0  0  0  0
> >   36:   78 79  0  0  0  0  0  0  0  0
> > 0  0  1  1  0  0  0  0
> >   37:   56 57  0  0  0  0  0  0  0  0
> > 0  0  0  1  0  0  0  0
> >
> > I assume the interface given in the alert is in hex, so the error would
> be
> > about port 32 (which is indeed connected to the DS6800 controller 1, port
> > 0).
> > As you can see the port seems to be fine.
> >
> > The full portshow 32 is here:
> > portIndex:  32
> > portName: port32
> > portHealth: HEALTHY
> >
> > Authentication: None
> > portDisableReason: None
> > portCFlags: 0x1
> > portFlags: 0x1020b03 PRESENT ACTIVE F_PORT G_PORT U_PORT
> LOGICAL_ONLINE
> > LOGIN NOELP ACCEPT FLOGI
> > LocalSwcFlags: 0x0
> > portType:  17.0
> > POD Port: Port is licensed
> > portState: 1Online
> > Protocol: FC
> > portPhys:  6In_Sync portScn:   32   F_Port
> > port generation number:16
> > state transition count:3
> >
> > portId:662000
> > portIfId:43020017
> > portWwn:   20:20:00:05:1e:e8:74:30
> > portWwn of device(s) connected:
> >  50:05:07:63:0e:80:02:11
> > Distance:  normal
> > portSpeed: N2Gbps
> >
> > Credit Recovery: Inactive
> > Aoq: Inactive
> > FAA: Inactive
> > F_Trunk: Inactive
> > LE domain: 0
> > Peer beacon: Off
> > FC Fastwrite: OFF
> > Interrupts:0  Link_failure: 0  Frjt: 0
> > Unknown:   0  Loss_of_sync: 0  Fbsy: 0
> > Lli:   15 Loss_of_sig:  0
> > Proc_rqrd: 63 Protocol_err: 0
> > Timed_out: 0  Invalid_word: 0
> > Rx_flushed:0  Invalid_crc:  0
> > Tx_unavail:0  Delim_err:0
> > Free_buffer:   0  Address_err:  0
> > Overrun:   0  Lr_in:3
> > Suspended: 0  Lr_out:   0
> > Parity_err:0  Ols_in:   0
> > 2_parity_err:  0  Ols_out:  3
> > CMI_bus_err:   0
> >
> > As far as I can tell the port is doing just fine, and I have not received
> > any reports of connectivity issues to the actual DASDs.
> > Any suggestions on what is going on, or worst case - how I can disable
> > these alerts?
>
> --
> 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

Debugging "A high error rate was detected on the Optical Link network." HMC alert

[Christian Svensson]

Good day,

Recently I have been getting these kinds of alerts from my HMC. It all
started when I connected an old DS6800 and the details are:

Node 1
Machine: 2498-B40
Serial: IBMCA107312B
Physical Interface: 6620
Logical Interface: 0020

Node 2
Machine: 1750-511
Serial: IBM13715
Physical Interface: 0100
Logical Interface: 

I keep getting these errors about 3-4 per day with the exact same
interfaces specified. No others, just these.

When I look at the referenced SAN switch and I do a "porterrshow" things
seem fine:
  frames  enccrccrctootoobadenc   disc
  link   loss   loss   frjt   fbsy  c3timeoutpcs
   tx rx  inerrg_eof  shrt   long   eof out   c3
 failsync   sig  txrx err
 20:4.8m  46.9k   0  0  0  0  0  0  0  0
   0  2  2  0  0  0  0  0
 32:   27.5k  17.7k   0  0  0  0  0  0  0  0
   0  0  0  0  0  0  0  0
 33:   19.3k  13.6k   0  0  0  0  0  0  0  0
   0  0  1  0  0  0  0  0
 36:   78 79  0  0  0  0  0  0  0  0
   0  0  1  1  0  0  0  0
 37:   56 57  0  0  0  0  0  0  0  0
   0  0  0  1  0  0  0  0

I assume the interface given in the alert is in hex, so the error would be
about port 32 (which is indeed connected to the DS6800 controller 1, port
0).
As you can see the port seems to be fine.

The full portshow 32 is here:
portIndex:  32
portName: port32
portHealth: HEALTHY

Authentication: None
portDisableReason: None
portCFlags: 0x1
portFlags: 0x1020b03 PRESENT ACTIVE F_PORT G_PORT U_PORT LOGICAL_ONLINE
LOGIN NOELP ACCEPT FLOGI
LocalSwcFlags: 0x0
portType:  17.0
POD Port: Port is licensed
portState: 1Online
Protocol: FC
portPhys:  6In_Sync portScn:   32   F_Port
port generation number:16
state transition count:3

portId:662000
portIfId:43020017
portWwn:   20:20:00:05:1e:e8:74:30
portWwn of device(s) connected:
50:05:07:63:0e:80:02:11
Distance:  normal
portSpeed: N2Gbps

Credit Recovery: Inactive
Aoq: Inactive
FAA: Inactive
F_Trunk: Inactive
LE domain: 0
Peer beacon: Off
FC Fastwrite: OFF
Interrupts:0  Link_failure: 0  Frjt: 0
Unknown:   0  Loss_of_sync: 0  Fbsy: 0
Lli:   15 Loss_of_sig:  0
Proc_rqrd: 63 Protocol_err: 0
Timed_out: 0  Invalid_word: 0
Rx_flushed:0  Invalid_crc:  0
Tx_unavail:0  Delim_err:0
Free_buffer:   0  Address_err:  0
Overrun:   0  Lr_in:3
Suspended: 0  Lr_out:   0
Parity_err:0  Ols_in:   0
2_parity_err:  0  Ols_out:  3
CMI_bus_err:   0

As far as I can tell the port is doing just fine, and I have not received
any reports of connectivity issues to the actual DASDs.
Any suggestions on what is going on, or worst case - how I can disable
these alerts?

Regards,

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

Re: Mainframe Multi factor authentication possibilities

[Christian Svensson]

Hi,

Now, I have not written any RACF exits ever, but a project[1] I am
part of has just been open-sourced that solves generating one-time
codes from a central server.
The way it works on Linux is that when you enter your username in the
prompt instead of the classical "Password: " prompt you get a URL.
You go to that URL and it does whatever it needs to do to check if you
have access to log in as the user you are trying to log in as, on the
machine that you are trying to use.

The URL would look something like this:
https://auth.mainframe.corp/v1/AYUg8AmJMKdUdIt93LQ-91oNvzoNJjga9OukqY6qm05q0PU=/lpar:ZVMLPAR1/tso/IBMUSER/
The thing you get back can be configured to be whatever length you
want, we use 10 characters - but for a mainframe shop that would be
shorter I guess.

If the auth.mainframe.corp server thinks everything is OK you get this
code back and you can paste it in as the login password.
That way you can implement 2FA however you want (list of smart-cards,
list of finger-prints, etc) and apply custom logic to whom to allow
and when.

The protocol requires no communication between the system being logged
in and the authentication server, which hopefully would make a
security review easier.

Right now we only have it for Linux but making it for z/OS would
definitely be a cool project.

[1] https://github.com/google/glome/blob/master/docs/glome-login.md

On Tue, Aug 25, 2020 at 8:32 PM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Tue, 25 Aug 2020 13:08:17 -0500, Mike Schwab wrote:
>
> >SMTP.  Email to phonenum...@carrier.com
> >https://www.wikihow.com/Email-to-a-Cell-Phone
> >
> It may not be so simple.  The link above takes me ultimately
> to a service selling background information (for a previous
> owner of my phone number.)
>
> But a while ago, I discovered mine by sending an IM to my
> email address and scraping the From: address.
>
> But this seems not to work for the popular Comcast.
>
> What if someone steals your phone?
>
> >On Tue, Aug 25, 2020 at 10:42 AM Paul Gilmartin wrote:
> >>
> >> On Tue, 25 Aug 2020 08:50:34 -0500, Mike Schwab wrote:
> >>
> >> >Text a six digit number to a list of cell phone numbers?  Add the
> >> >number to the cell phone number so subtracting the six digit number
> >> >gives you the last 6 digits of the person's cell phone number?
> >> >
> >> Is there an app for that?
>
> -- 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

Re: ClefOS signing key

[Christian Svensson]

Thanks!

I don't wish to ignore the signatures :-).

On Mon, Aug 17, 2020, 08:14 At: Http://Doodle.Com/Poll/E5In4Utu77Dspg42 <
ne...@sinenomine.net> wrote:

> No, the ClefOS packages are signed with the key that gets installed with
> the distro: /etc/pki/rpm-gpg/RPM-GPG-KEY-ClefOS-7 which is in the
> centos-release RPM.
>
> -BEGIN PGP PUBLIC KEY BLOCK-
> Version: GnuPG v1
>
> mQINBFYG0eIBEACinswhGSisjaTeN6jfYcSsuYWrkNnSUyueC90xAtsTVxABu/+A
> BsK8tCqlAX4W8mlYJzhvaRNhe2zUcIz09MKjIRkrj8ZBmFScRIEDtQF44QZN7Q9Q
> /S1zYwbAtjshlq7x2GvNlzs7mHwoKgKuShO+VtMoFlOgBD0NwqxddEHZM7fB+XyY
> 7SrRaJUj6CCiWvKRJmRyY2Z3S3lZnfoRd6gtJau4yIyuUJiPTsN0R6luGOfLveFN
> OIaFS7MpXwm0Xew7prZEI9dUyUMrluyX1MYpxB9fZcBpfJrT5CInWrWBplHm0SKG
> DCgzhsCWBLXjqwSV2x9kw42QfyVqsuBP1uH9GRbD/sohLkdCxor8TZDAzQeEswqt
> 2mJ9JTYzEMPsex5Ey/vApE1q7Ua2EhISI68VjVQk/9VhUwjyfCgHNZ8oM+OPaTKY
> 0n3UlDIsOnkaIGuKxVb3QQ4u0MPBBMkIjk7+R/mQVRH5U7TAp6Oa6urfLBu4tZQG
> R0VS8jNKbpPlwrN1XwXJWdL6t3ASjLP69sag+84m+YqBO12Ye+5Pv4u2ZEapKvz0
> 8v7QcJRJHk6PCIX437WliJ6Bs+1icurG8EOTqO5prt9jjZVdljPYQ04LaOErBYCx
> bDtdtymuEQ+B8jnf31cG2w40elK4uM1F+tn9A93G5MYYykegy/1sIMAokwARAQAB
> tDhDbGVmT1MgNyAoQ2xlZk9TIDcgU2lnbmluZyBLZXkpIDxjbGVmb3M3QHNpbmVu
> b21pbmUubmV0PokCPgQTAQIAKAUCVgbR4gIbAwUJEswDAAYLCQgHAwIGFQgCCQoL
> BBYCAwECHgECF4AACgkQrmrvqNy7TQlC5xAAoQXsYC6sn20VhGDQuVyDui+4Wp+2
> cLj1Ji6YUn1OQrbVM4wp2ewp1ekfKPL2bMBIn9KqRqrx1CplwYi7VfUI3B4/eBA+
> k4Mn+DvQXnv4syQr+cEhgzbh4a9H/a5CxNif+19kJfdDc1G4gizYGX/XoQ6+3kpH
> i7ktWA5N1i9hCF3GCgBeAw0D+nSo2QuQ6PKDnSgr6wi0AvmAg956/ps9RL16NgFC
> Q88t3Ann5Go5sry6XKOftoKGdxMZ3BKR7/t5/A5/ceHT33AX7BqAgNsd02Xb0VzO
> 76H3Pq8NLcbKSs/ZJPAxzCGHp2AXd4nHP62Ks0Ks1HIleHBFrrKbZUwC9qD9p40m
> /NwRwmbpElyZBDjW1uH1MpmcIungh3kheA/wOK0ElMLAZrW6efFag9e/3wp+owOh
> OqrHzAu0WCwuwHuz368XMwsxHYSVol986T00I5T/t7TDDdBq/5RkzMHx2FEhzpwu
> BDMkxnkCqHAps9z29DmEhOZw6uwd/DeGUOhG4l/Wen2E7PkP9/TR4W+AdcB4PqYW
> gophBu4nwp8k0X9a0HZodG6swCkfEnZaC8BHIzm2vp+/5IUcmaxp8hrSp2jDrtYk
> EofgeHuhHbujq4usaS3BDaguSPbXDe6ou7Mx/EmwWIzF3QSSPzFPTv47+ZDGL+wE
> CCpa9qe1zeQtGK+5Ag0EVgbR4gEQANAheLsFQ3v+XV+As/RW71liAav1v8w4x25j
> nCoNF4GUmmyKPnrNny7mTPfmg3MHPoPDRgU+brIr6Xsm4e63G7I+asdFKkSlKXd4
> +uyH8aaTIIyKPODQk7RH6YPCIxDH1hNcQxVWCJaJiB5fo/VXLh9e8OQ1XXhu4dsp
> dyrNimpzA6JuMRVWBm1Vf4u6WSJ1uFZyRkOKkqgc7zJLwYcsASbKXgjA23hxMPHM
> O3bZkOO7BWPsMVr9rD5XlO2uSU8xfGAozt9qVIfVOCZ87A6GJOONqdENYXwyTDDa
> hiW9LsoYuxO5zbnvCOXfqjCqOJUH7I+2TCKWBZFwtKdMTZ0g8oVi/SMAuTz/dyA5
> 7dJsayGFLQknemNGFIzmCZqVzfbvwwRIHUkOZwRSFamVl8rkpd94OyEj/T29sXtx
> ycxWV+nUgsLaIMstoEABj6zVBnoapNQWLdjLYejdqCmUNGUzDSn5GpaGkU49KMQ4
> aEfGZVSTxncqWdnG7d362CvpcZxkiXGe9ZRtJeXacNeNqgiyz1ugdFSgaN95bAN0
> JXKWuvGDVaDnBjdBauJOHtdppFbZRXNxBKMGsYZkuGpKetjS8rvQUiSxTn6A0HDQ
> o2EBUPuc8Yql+3AiRWaEQ4WCPitx1FSTw/ZVQD6BByAjSfWCyKsPs922SSTNW6su
> rbVOsE//ABEBAAGJAiUEGAECAA8FAlYG0eICGwwFCRLMAwAACgkQrmrvqNy7TQl9
> hxAAjFHPH3FCNkLLCc/EQmjZ6DTEIQqvOukmpZnHPatZuo0iiKzBxHE0M0OQiKCQ
> hUuaPyw1FuopjozJ2MoxHZPBRAvC3kbqNhzW+zSYYA7uks2TLAI3noLlfwN/byGA
> oWBO5S3g4dAU+LaemqiD6rwLBNM3GLFuPc3HcBVcEmj76GIrCXtDwK8+yA3SXnhy
> gey+aWF4YWnZ9VT3eh/SGGPaD3N+V0dLpH45HznGuNCg8eqqDY8p1UIv8Vs3wZ5s
> VxG1q+7vV5iZSNiLRQ0LNp4TpREOVDhZEwxB5zn6g1fWJONd6cgyeQoxAN77ytMe
> s5ro0lgTKhIa6HcSi5EghPltmDwYJo+mNc1Ka66zxxDw91otmV+2raf0zV9VSO2m
> 6ZmCr+tK0IHJso4M9pzr9JM/+GRzxvJ6tNw8yB42EoSKwrDvOqAlp3ZlSO30xqLl
> MvhT9Ug8maRwjrM/nJ7zC+x+SRvzmxs2bwfDN78bdA2Yo4HGqVaaRgAv+TthlIbr
> 6QKXqK0jxvEq7t9LMPtCYyS14oxRPiqLwewKIzoJqDFcmgkVkZSK6D4ygJ0k20w2
> +UZkb1/+KkFwbKWbyzpeQogBhy35sQDShmBeImf1qHy7Q2cyBIyPCItQKLih5FE1
> yanqGMb6br06pUcy8Plbe5iXxOONRGsNEl/TLpls4VEMUOc=
> =R3bB
> -END PGP PUBLIC KEY BLOCK-
>
> You can always use the yum --nogpgcheck option to ignore signatures.
>
> Neale
>
> --
> 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: ClefOS signing key

[Christian Svensson]

Hi,

Many thanks.
What I'm trying to do is to use ClefOS packages in another distro, so I
need whatever key signed those. This seemed to be the key from my quick
exploration - is that not the case?

On Mon, Aug 17, 2020, 06:12 Neale Ferguson  wrote:

> It is within this package:
>
>
> http://download.sinenomine.net/epel/epel-7/noarch/sna-packages-7-1.0-0.noarch.rpm
>
> This key is only used for signing our own packages not ClefOS itself nor
> the ClefOS EPEL. What package is asking for it?
>
> -BEGIN PGP PUBLIC KEY BLOCK-
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> mQENBFGIWTYBCAC7V4LNdrZ/rVILySkPMwt2ag7WtFFCWGyfZ3KJDLuDyV3iTMye
> s6FH2A0se7CaONMJVoMlmC3CfM+b0lQHh/N7JAduZGCPZuoyNI1vL8hp30hDoa++
> oBbfWzuaLDULxGMfwKULO0Tg2QZNDHLD4p4yvNvFycUCJfOt8188E2t9N0/g301K
> 0onl1rYQ126rc1zwGbJXRWwTQ9U44V21XZ+DQntjVS+uscYqZj08CFbeNZ7H0GjV
> 9Yivb9s7Rx93r7LCnm3I9iCQPJ6gGRE83Yegpy4tAx8XcIGkCkweSk8jyvH9MHAr
> bvPwnb82/oSdlhk11ShXhaO5644H2OLt5ngbABEBAAG0LFNpbmUgTm9taW5lIEFz
> c29jaWF0ZXMgPGhlbHBAc2luZW5vbWluZS5uZXQ+iQE4BBMBAgAiBQJRiFk2AhsD
> BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCzOgftQMy7qqgYCACC9c+VhDJw
> Hns/ioNwIWrJNjpM3BPG2DSqKbtLUUxLU0q9ATzL6u+nSj/+4dPCWkSytUGjoGyE
> 2ZEl6Z3jP7oy9VF9mDvgaFVlNtsxrUbP0GzZ79eOeqfmood7yqPDVMSLlXpXfYi7
> F2iukJFyvVcHqilNtY5vnTXNCnKP07R13aSGPKGMLAa2fO+s7lMetvLJhEzcfsxR
> EJch4sEFrXpyzH8Ajoa+i04diMndfeZam6ghOya2dwShF89uXkEsvybvIi+9eKWd
> DdpUusLsF+2B+oStCfK13vGvuLpYiWtDI3PYW7MorAhhhs8nZOTIkd9yXVE82tJW
> dMjP/KaEeuwBuQENBFGIWTYBCADCwRfZWCUsTsJ3pMUcC6ypPNw8cqdk5K03bzRs
> CERGcIs3MV2UUSindQLajVLW7xHhqvg9YcGUV0+XRV8ay1uCLDZULSctxwBaHhVm
> 56rE4wMWPuP/6S8rg1edYxxTrvyPRZukfIvGhjMoteIWqgiN/eNZuXYoU91tkIZQ
> kCYCBexMdyqqlejxebDYM0gCUOI0MgfPd2l3j4RlaKLPM8O2/HUQO6ZyAO5VFuOP
> bRE6UQqmhk/ZT6JYYkUDx7AdLHgSMRn+pYZLtzuVR48FRRLM/HeWedzXN3PphG0A
> DLRxPBqmomxSoskhIImohxh1ATfKwbHBby4FIXKOUyZo/2DhABEBAAGJAR8EGAEC
> AAkFAlGIWTYCGwwACgkQszoH7UDMu6pWgwgAmV0zKyEC5Nym4kDjzuXe3SkXs/Yd
> 57LPdZfH1GFz2EvgCs4tXR+BqPtGSY38QYOiMDMK4B3dy4UrSIvTql/B0EFsmgUV
> X/P+3ViYvHerP/3fOmPyZ3k5u+EagrmNqUy4u4GxKp74WAutifMWiuVZ1KLqcnPg
> T7RWNGjsA85BdhiWNA8x8QjzXnt/iqnnhD4NBU4cW0Vhp55xBdpjqBq49tT8Z5CR
> GRrWcrMMfgX6CXxj4QOLZprx1W3OJ3BoX/Hx+zLcQMoMB0JVr9hrTDSFUPEsJXB2
> Gt5wut+HShv/VP2ppKqAVF7KgbKJmsu4FQcMunIJfKCVKs6kI03j23TJ6A==
> =VDUU
> -END PGP PUBLIC KEY BLOCK-
>
> Neale Ferguson
>
>
> --
> 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

ClefOS signing key

[Christian Svensson]

Hi,

I cannot seem to find a community to reach out to for ClefOS so I
guess this mailing list will have to work.
I am trying to find the signing key that is used for ClefOS -
RPM-GPG-KEY-SNA. It is supposedly somewhere in /etc/.

Usually repositories tend to publish their signing keys, but ClefOS
seems to only install it, and I am not in a position
where I can install ClefOS just to get the key.

Could anyone cat that file and send it over?

Thanks,

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

Re: Unable to VARY ONLINE DASD after SAN power outage

[Christian Svensson]

Thanks Jon,

I now see two new S/W problems, one mentioning that access to data has been
impacted. I looked when the SAN had booted but I guess I might have been a
bit too quick before that was self-diagnosed.

Oh well, reboot of the SAN it is.



On Sun, Aug 2, 2020 at 7:51 PM Jon Nolting  wrote:

> This could be the storage unit went into R/O mode to protect the existing
> data. We’ve had that happen on similar old storage devices.
>
> See if you can check the storage HMC which might reflect the condition. We
> had to “fix” whatever caused this protective condition allowing R/W access.
>
> Good luck
>
> Sent from my iPhone
>
> > On Aug 2, 2020, at 10:08 AM, Christian Svensson <
> 022ad63487ef-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Hi,
> >
> > I have an old DS6800 running alongside my z114. Due to a power outage the
> > SAN was shut down uncleanly and
> > while it does not appear to indicate any failures in its logs or status
> > displays, I'm having issues trying to IPL my LPARs from it.
> >
> > To try to debug this issue I loaded a z/VM installation DVD and had a
> look
> > at the devices.
> > To reduce the number of potential error sources, I created a new CKD
> volume
> > at 03F1 in the DS6800.
> > When I try to vary this device online I get:
> >
> > vary online 03f1
> > 12:59:33 HCPERP794E DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME
> > 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33
> > HCPERP794E DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME
> > 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33
> > HCPERP6306I DASD 03F1 AN EQUIPMENT CHECK WITH PERMANENT ERROR
> > 12:59:33 HCPERP6306I OCCURRED
> > 12:59:33 HCPERP6300I SENSE DATA FORMAT = 0F MSG CODE = 0C
> > 12:59:33 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = 63
> > 12:59:33 HCPERP6302I SEEK ADDRESS = 
> > 12:59:33 HCPERP6303I SENSE = 1090 F1FC 0800 0004 230002CB
> > 12:59:33 HCPERP6303I 0004F908 4082 0C00
> > 12:59:33 HCPERP6304I IRB = 01C04417 7FF0B010 0210 0080
> > 12:59:33 HCPERP6305I USERID = SYSTEM
> > 12:59:33 HCPERP2216I CHANNEL PATH ID = F5
> > 12:59:33 HCPERP2220I PHYSICAL CHANNEL PATH ID = 011D12:59:33 HCPERP794E
> > DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME
> > 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33
> > HCPERP794E DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME
> > 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33
> > HCPERP6306I DASD 03F1 AN EQUIPMENT CHECK WITH PERMANENT ERROR
> > 12:59:33 HCPERP6306I OCCURRED
> > 12:59:33 HCPERP6300I SENSE DATA FORMAT = 0F MSG CODE = 0C
> > 12:59:33 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = 27
> > 12:59:33 HCPERP6302I SEEK ADDRESS = 
> > 12:59:33 HCPERP6303I SENSE = 1090 F1FC 0800 0004 230002CB
> > 12:59:33 HCPERP6303I 0004F908 4082 0C00
> > 12:59:33 HCPERP6304I IRB = 00C04017 7FE95E50 0E00 0080
> > 12:59:33 HCPERP6305I USERID = SYSTEM
> > 12:59:33 HCPERP2216I CHANNEL PATH ID = F5
> > 12:59:33 HCPERP2220I PHYSICAL CHANNEL PATH ID = 011D
> > 12:59:33 HCPCRC8083I EREP record threshold has been exceeded for userid
> > OPEREREP. Currently 0006 records are enqueued.
> > 12:59:33 HCPCPN6277I Device 03F1 cannot be varied online because I/O
> errors
> > occurred.
> > 12:59:33 1 device(s) specified; 0 device(s) successfully varied online
> > Ready(06277); T=0.01/0.01
> >
> > This error is presented on the few other devices I've tried to vary
> online.
> >
> > Any suggestions of things to try? Worst come to worst I'll power
> everything
> > off and do a cold boot.
> > This is all a hobbyist setup so no IBM maintenance contract on anything
> I'm
> > afraid :-).
> >
> > Thanks,
> >
> > --
> > 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

Unable to VARY ONLINE DASD after SAN power outage

[Christian Svensson]

Hi,

I have an old DS6800 running alongside my z114. Due to a power outage the
SAN was shut down uncleanly and
while it does not appear to indicate any failures in its logs or status
displays, I'm having issues trying to IPL my LPARs from it.

To try to debug this issue I loaded a z/VM installation DVD and had a look
at the devices.
To reduce the number of potential error sources, I created a new CKD volume
at 03F1 in the DS6800.
When I try to vary this device online I get:

vary online 03f1
 12:59:33 HCPERP794E DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME
 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33
HCPERP794E DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME
 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33
HCPERP6306I DASD 03F1 AN EQUIPMENT CHECK WITH PERMANENT ERROR
 12:59:33 HCPERP6306I OCCURRED
 12:59:33 HCPERP6300I SENSE DATA FORMAT = 0F MSG CODE = 0C
 12:59:33 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = 63
 12:59:33 HCPERP6302I SEEK ADDRESS = 
 12:59:33 HCPERP6303I SENSE = 1090 F1FC 0800 0004 230002CB
 12:59:33 HCPERP6303I 0004F908 4082 0C00
 12:59:33 HCPERP6304I IRB = 01C04417 7FF0B010 0210 0080
 12:59:33 HCPERP6305I USERID = SYSTEM
 12:59:33 HCPERP2216I CHANNEL PATH ID = F5
 12:59:33 HCPERP2220I PHYSICAL CHANNEL PATH ID = 011D12:59:33 HCPERP794E
DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME
 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33
HCPERP794E DASD 03F1 - ACCESS IS PROHIBITED ON VOLUME
 12:59:33 HCPERP794E DUE TO STATUS ERROR - RC = 08 - 0004.2- 1-1112:59:33
HCPERP6306I DASD 03F1 AN EQUIPMENT CHECK WITH PERMANENT ERROR
 12:59:33 HCPERP6306I OCCURRED
 12:59:33 HCPERP6300I SENSE DATA FORMAT = 0F MSG CODE = 0C
 12:59:33 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = 27
 12:59:33 HCPERP6302I SEEK ADDRESS = 
 12:59:33 HCPERP6303I SENSE = 1090 F1FC 0800 0004 230002CB
 12:59:33 HCPERP6303I 0004F908 4082 0C00
 12:59:33 HCPERP6304I IRB = 00C04017 7FE95E50 0E00 0080
 12:59:33 HCPERP6305I USERID = SYSTEM
 12:59:33 HCPERP2216I CHANNEL PATH ID = F5
 12:59:33 HCPERP2220I PHYSICAL CHANNEL PATH ID = 011D
12:59:33 HCPCRC8083I EREP record threshold has been exceeded for userid
OPEREREP. Currently 0006 records are enqueued.
12:59:33 HCPCPN6277I Device 03F1 cannot be varied online because I/O errors
occurred.
12:59:33 1 device(s) specified; 0 device(s) successfully varied online
Ready(06277); T=0.01/0.01

This error is presented on the few other devices I've tried to vary online.

Any suggestions of things to try? Worst come to worst I'll power everything
off and do a cold boot.
This is all a hobbyist setup so no IBM maintenance contract on anything I'm
afraid :-).

Thanks,

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

Re: Encrypting z/OS SNMP traps to Windows SNMP server

[Christian Svensson]

What about using SNMPv3? It is encrypted if you tell it to enable privacy.

On Mon, Jul 20, 2020, 19:42 Charles Mills  wrote:

> Does SNMP flow by TCP or by UDP? UDP would be wrinkle. TLS-UDP is not
> unheard of but not super common in my experience. Does AT-TLS support UDP?
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Monday, July 20, 2020 9:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Encrypting z/OS SNMP traps to Windows SNMP server
>
> This is a new requirement from the higher ups in our new owning company. We
> are still on z/OS 1.12, so I don't have any new fancy stuff. We use
> CA-OPS/MVS to trap "abend" messages from the CA-7 Browse log. We send these
> messages to an Solar Winds "Orion" SNMP server so that it can interface
> with CA Service Desk to automatically open Service Desk tickets. This is
> all on internal (Data Center) LAN. But it is "server to server" by the
> standards of our new masters and so it MUST be encrypted or we must stop
> doing it.
>
> I have been trying to read up on AT/TLS, but it is totally over my head. I
> don't really know anything about IP encryption. Or Windows people are also
> ignorant of IP encryption on z/OS (of course).
>
> --
> People in sleeping bags are the soft tacos of the bear world.
> 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: Multi-channel OSA-ICC routing and TCP port behavior

[Christian Svensson]

+1 on Tony's remark - but I do find the discussions and experiences of the
people here always fascinating and entertaining :-).

As it was mentioned, the 3270 / console setting - I had to use the
"operator console" to get my z/VM 6.3 instance to play along. If I used the
3270 option for the SYSC the system would shut down and enter "Not
operating" state as soon as I disconnected from the ICC. I know the
"operator console" is listed as only supported for z/OS, but reading
between the lines it definitely seems like in order to use a SYSC for z/VM
you need something like DTD -- but that might be a topic for a 2020-edition
of an old thread (which I sadly can't seem to find again).


On Tue, Jul 21, 2020 at 4:30 PM Dana Mitchell  wrote:

> We recently migrated to z14's and I was working on setting up the ICC
> definitions on the new boxes.  One of the docs I ran across pointed out the
> fact that there is only one gateway address,  and had a nice diagram
> showing one of the ports connected to the outside world,  and the other
> port relegated to connecting to a local non-routable LAN.  Not sure which
> pdf it was in.
> Dana
>
> On Tue, 21 Jul 2020 09:23:59 -0400, Tony Thigpen  wrote:
> >It had to do with the limited IP configuration when using both ports. He
> had it
> >working with one port, but he thought he was misunderstanding the
> >limitations on the second port because, IMHO, they are confusing. He had
> >it right even though it looked wrong.
> >
> >Tony Thigpen
> >
>
> --
> 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: Multi-channel OSA-ICC routing and TCP port behavior

[Christian Svensson]

Thanks Tony, it makes calmer knowing I'm not the only one being confused
about this :-)

On Sun, Jul 19, 2020 at 3:18 PM Tony Thigpen  wrote:

> Christian,
> I was dismayed too when I first discovered this limitation. The OSA-C
> was originally intended to eliminate the local 3174 requirement. It was
> not really designed to replace the 3172-003, which is what many are
> using it for today.
>
> And, you also need to look back at the OSA-C's roots which was the 3274
> emulation in the P370, P390 and the MP3000.
>
> Tony Thigpen
>
> Christian Svensson wrote on 7/19/20 8:40 AM:
> > Thanks for the input folks.
> >
> > Brian: I have it working just fine, the setup was easy as you said - the
> > reason I started this thread was because I couldn't understand why the
> > limitations on the TCP port number and the philosophy behind the routing.
> >
> > It seems pretty weird to me that IBM implemented ICC this way, but hey -
> > I'm just a stranger on the internet :-)
> >
> >
> > Regards,
> >
> > On Sun, Jul 19, 2020, 06:52 Brian Westerman <
> brian_wester...@syzygyinc.com>
> > wrote:
> >
> >> You can set up some of the ports to be local VTAM terminals, then you
> can
> >> use VISTA (or any 3270 emulator) to connect into the ICC port 3270, and
> use
> >> the LUNAME of the 3270 you defined as a local 3270 terminal.  Since you
> can
> >> have over 100 terminals per port, making them all os consoles is a
> waste,
> >> so having a bunch of them as local 3270's that you can give to your
> carious
> >> LPARs (and use EE to connect to the LPARs they are not connected to),
> is a
> >> great way to use them.
> >>
> >> I like to make the first 16 to 32 devices OS consoles and the rest of
> them
> >> local 3270s.
> >>
> >> So you are using TCP to get to them inside the ICC, but they are
> >> technically local 3270 terminals.  I think you can make some of them
> >> printers if you want, but that seems like a waste.
> >>
> >> If you need more detailed directions, there are samples in the OSA
> express
> >> 3 manual (and the newer ones).   Or I can send you some screen shots of
> how
> >> to set them up.  Various sites I support are also z/114's so it's not a
> >> problem.  The entire time to set them up will probably take you on the
> >> order of 15 seconds for each terminal. (if that)
> >>
> >> Brian
> >>
> >> --
> >> 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
>

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

Re: Multi-channel OSA-ICC routing and TCP port behavior

[Christian Svensson]

Thanks for the input folks.

Brian: I have it working just fine, the setup was easy as you said - the
reason I started this thread was because I couldn't understand why the
limitations on the TCP port number and the philosophy behind the routing.

It seems pretty weird to me that IBM implemented ICC this way, but hey -
I'm just a stranger on the internet :-)


Regards,

On Sun, Jul 19, 2020, 06:52 Brian Westerman 
wrote:

> You can set up some of the ports to be local VTAM terminals, then you can
> use VISTA (or any 3270 emulator) to connect into the ICC port 3270, and use
> the LUNAME of the 3270 you defined as a local 3270 terminal.  Since you can
> have over 100 terminals per port, making them all os consoles is a waste,
> so having a bunch of them as local 3270's that you can give to your carious
> LPARs (and use EE to connect to the LPARs they are not connected to), is a
> great way to use them.
>
> I like to make the first 16 to 32 devices OS consoles and the rest of them
> local 3270s.
>
> So you are using TCP to get to them inside the ICC, but they are
> technically local 3270 terminals.  I think you can make some of them
> printers if you want, but that seems like a waste.
>
> If you need more detailed directions, there are samples in the OSA express
> 3 manual (and the newer ones).   Or I can send you some screen shots of how
> to set them up.  Various sites I support are also z/114's so it's not a
> problem.  The entire time to set them up will probably take you on the
> order of 15 seconds for each terminal. (if that)
>
> Brian
>
> --
> 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

Multi-channel OSA-ICC routing and TCP port behavior

[Christian Svensson]

Hi,

I have been experimenting with setting up OSA-ICC cards on a z114.
These are OSA Express3 cards with 4 ports / 2 channels. Let's look at a
single channel in this card, named CHPID 200.

These are the configuration parameters for this card:

>  Channel ID: 0200
>  LAN port type: OSA-ICC 3270
>
>  Physical Port 0
>  Server name: [empty]
>  Host IP address: 10.0.0.10
>  TCP port (1-65535): 23
>  Subnet mask: 255.255.255.0
>  MTU size(B): 1492
>
>  Physical Port 1
>  Server name: [empty]
>  Host IP address: 10.0.1.10
>  TCP port (1-65535): 3270
>  Subnet mask: 255.255.255.0
>  MTU size(B): 1492
>
> Default gateway: 10.0.0.1

My most pressing confusion is related to the IP. A configuration with the
two ports in the same subnet is considered invalid, yet there is only a
single channel-level gateway that seems to be definable.
If I try to assign e.g. 10.0.0.10 and 10.0.0.20 with default gateway
10.0.0.1 I get the following error:

>  // @@@ Error 1057: Host IP for Physical Port 0 and Physical Port 1 are
defined in the same segment

If I can only define a single channel-level gateway, and the ports cannot
be in the same L2, how is this second port intended to be used? One port
routable and one port accessible only from the same L2?

My second question is if there is any way around the TCP port number not
being able to be reused. I would love all my OSA-ICC to use TCP port 23,
but it seems that even though the ports need separate IP addresses, the TCP
port cannot be the same between the two ports.
Is that correct? The error I get when I try to re-use the same port is:

> // @@@ Error 1055: Host port value used for previous physical port
definition: 23 for PORT 0.

Thanks for any insights / experiences.

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

Re: Mainframe co-op

[Christian Svensson]

That's correct, happy to answer any questions about the project :-)
Possibly as a new thread it better suited.

Deeply honored to be mentioned on this list, thanks Grant!


On Sat, Jul 4, 2020, 09:52 Mike Schwab  wrote:

> I would assume the goal to be 'use PC disks as mainframe DASD'.
>
> On Sat, Jul 4, 2020 at 3:46 AM kekronbekron
> <02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > Would love to know more about what your FICON buddy is working on Grant.
> > If you wanna share (prefer off-list?), please email :)
> >
> > Unless IBM explicitly sets up college courses or NDA-tied free-roam
> access or whatever, it's only going to be the likes of zAcademy, i.e.,
> restricted lab environments to basically market at the command-line, much
> like walking the dotten line in an acquarium/zoo/etc. (if you turn to your
> right, you can issue 2 commands to Spark on Z)
> >
> > Funny though, because isn't this exactly what Time Sharing Option was,
> when it was first introduced?
> >
> > - KB
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Friday, July 3, 2020 9:48 PM, Grant Taylor <
> 023065957af1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > On 7/3/20 10:12 AM, Grant Taylor wrote:
> > >
> > > > I know multiple people that have CPCs.  But they don't currently have
> > > > DASD.  I think at least one of them has a line on legal licenses for
> > > > z/OS for his CPC.
> > >
> > > One of the people I know is developing his own FICON connected DASD by
> > > reading any and all documents he can get his hands on.
> > >
> > > What do we, as the mainframe community, and IBM, as the big name, need
> > > to do to encourage these extremely creative, resourceful, and driven
> > > people better access to a functioning mainframe so that they can use
> > > their creative talents and drive to help further the mainframe?
> > >
> > > There are a group of hobbyists and enthusiasts that have taken MVS
> 3.8j,
> > > which decidedly does not include REXX or prerequisites therefor, and
> > > backported (?) REXX to it, including re-creating any prerequisites.
> > >
> > > This is the creative and enthusiastic spirit that created Unix 50 years
> > > ago and helped Linux become what it is today. Just think for a moment
> > > where the mainframe could be in 10 or 20 years if even some of these
> > > creative efforts were directed at enhancing the mainframe.
> > >
> > >
> > >
> -
> > >
> > > Grant. . . .
> > > unix || die
> > >
> > > -
> > >
> > > 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
>
>
>
> --
> 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
>

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

Re: z114 retroactive height reduction (FC 9975) for transportation

[Christian Svensson]

Thanks for the clarification, very useful!

On Fri, Jun 12, 2020, 08:58 Parwez Hamid  wrote:

> Short answer - YES.
>
> FC 9975 is basically to reduce the 'height' for shipping/delivery purposes
> i.e if there isn't enough height clearance for the doorway. If a system is
> ordered with this feature, it just enlongates the install time. Nothing to
> stop 'you' to remove and reinstall the top bit. Just be careful with the
> cabling etc.
>
> Regards
>
> Parwez Hamid​
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Christian Svensson <022ad63487ef-dmarc-requ...@listserv.ua.edu>
> Sent: 11 June 2020 23:34
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: z114 retroactive height reduction (FC 9975) for transportation
>
> Hi,
>
> A bit of a niche question maybe, but this list usually enjoys those!
>
> I need to move my z114, and sadly I don't have the possibility of
> inspecting it physically right now. I was wondering if anyone knows if it
> is possible to reduce the height of the z114?
> In the IMPP there is a FC 9975 which separates the top portion in the
> installation, but I have no idea if my individual has that feature.
> Looking at older pictures of the frame there appears to be a "cut" between
> the BPA and where the battery is supposed to be, so it looks like maybe
> removing the side panels, the door, and then one might be able to detach
> the top - but that's hard to say for sure on the pictures.
>
> Does anyone have any experience removing the top portion for
> transportation of a z114? Or similar experiences?
>
> Thanks,
>
> --
> 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

z114 retroactive height reduction (FC 9975) for transportation

[Christian Svensson]

Hi,

A bit of a niche question maybe, but this list usually enjoys those!

I need to move my z114, and sadly I don't have the possibility of
inspecting it physically right now. I was wondering if anyone knows if it
is possible to reduce the height of the z114?
In the IMPP there is a FC 9975 which separates the top portion in the
installation, but I have no idea if my individual has that feature.
Looking at older pictures of the frame there appears to be a "cut" between
the BPA and where the battery is supposed to be, so it looks like maybe
removing the side panels, the door, and then one might be able to detach
the top - but that's hard to say for sure on the pictures.

Does anyone have any experience removing the top portion for
transportation of a z114? Or similar experiences?

Thanks,

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

Re: TCPIP IPv6 reachability issue after link restart on VM and zLinux

[Christian Svensson]

I see something I should clarify directly:
" I see packets going out and replies coming in - but Linux does not appear
to get any traffic (RX counters not increasing)" - when I say "I see
packets going out and replies coming in" that's on the switch side, not in
the zLinux LPAR.

On Tue, Jan 28, 2020 at 9:40 PM Christian Svensson  wrote:

> Hi,
>
> I'm operating a z114 with OSA Express 4S 1G and 10G cards.
> I'm having the following issue on both zLinux (kernel 5.3.0) and z/VM 630.
> When TCPIP is restarted, either in VM as "FORCE TCPIP" + "XAUTOLOG TCPIP"
> (or linux as "ip link set down" followed up "up"), or a re-IPL in either
> OS, the IPv6 address will not be pingable again (and no other IPv6
> traffic either).
>
> The things I've noted that will make the instance reply to ping again are:
>
>1. Cycling the port in the switch ("shutdown" + "no shutdown")*
>2. In the VM case, pinging out through the gateway
>   1. This does *not* help in zLinux oddly enough, I see packets going
>   out and replies coming in - but Linux does not appear to get any traffic
>   (RX counters not increasing)
>   2. Using *another* IPv6 address on zLinux works without issue
>
> * However, it seems like the qeth driver in zLinux is made to forget the
> IP address in case of a link-flap (which is not how conventional network
> cards behave in Linux).
>
> I am pretty confident that it is not the switch that is acting up, I can
> see the traffic counters increasing on the switch side.
> The network is IPv6 only so trying with IPv4 traffic will be quite
> troublesome, and replacing the switch is not really feasible as well.
> First I thought it was some odd issue in my setup of zLinux, but when I
> started testing z/VM and hit this similar issue I started to wonder if this
> is some known issue.
>
> Has anyone seen similar behaviour in their environments?
>
> Thanks,
>

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

TCPIP IPv6 reachability issue after link restart on VM and zLinux

[Christian Svensson]

Hi,

I'm operating a z114 with OSA Express 4S 1G and 10G cards.
I'm having the following issue on both zLinux (kernel 5.3.0) and z/VM 630.
When TCPIP is restarted, either in VM as "FORCE TCPIP" + "XAUTOLOG TCPIP"
(or linux as "ip link set down" followed up "up"), or a re-IPL in either
OS, the IPv6 address will not be pingable again (and no other IPv6
traffic either).

The things I've noted that will make the instance reply to ping again are:

   1. Cycling the port in the switch ("shutdown" + "no shutdown")*
   2. In the VM case, pinging out through the gateway
  1. This does *not* help in zLinux oddly enough, I see packets going
  out and replies coming in - but Linux does not appear to get any traffic
  (RX counters not increasing)
  2. Using *another* IPv6 address on zLinux works without issue

* However, it seems like the qeth driver in zLinux is made to forget the IP
address in case of a link-flap (which is not how conventional network cards
behave in Linux).

I am pretty confident that it is not the switch that is acting up, I can
see the traffic counters increasing on the switch side.
The network is IPv6 only so trying with IPv4 traffic will be quite
troublesome, and replacing the switch is not really feasible as well.
First I thought it was some odd issue in my setup of zLinux, but when I
started testing z/VM and hit this similar issue I started to wonder if this
is some known issue.

Has anyone seen similar behaviour in their environments?

Thanks,

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

Re: Defining SCSI in DS8k box

[Christian Svensson]

>From the Linux documentation
https://www.kernel.org/doc/Documentation/s390/DASD it certainly seems that
ECKD disks are well supported. That aligns with my recollection of
experimentation of testing various zLinux in Hercules.

On Tue, Dec 17, 2019, 09:32 Laurence Chiu  wrote:

> Slightly outside my area of knowledge but since z/VM is the OS that is
> attached to the DS8K, it's doing the physical IO. And this is usually
> FICON.
>
> The Linux guest is being provided a virtual disk from z/VM so the disk
> protocol is probably not relevant. Plus I don't think a Linux guest can
> actually see a CKD volume - it would all look ike FB.
>
> Others feel free to chip in here
>
> On Tue, Dec 17, 2019 at 4:45 PM Peter  wrote:
>
> > I believe giving a dasd 3390(CKD) to linux guest and internally it
> converts
> > that into SCSI.
> >
> > So having SCSI alone for Linux guest would be better interns of
> performance
> > ?
> >
> > On Tue, 17 Dec, 2019, 12:54 AM Laurence Chiu,  wrote:
> >
> > > I asked my z/VM and DS8K person this question and he wasn't sure what
> you
> > > were asking.
> > >
> > > He said he defines all the storage on his ds8k box as CKD though he
> could
> > > have chosen fixed block and assigns all that storage to the z/vm host.
> > >
> > > For each Linux instance that requires storage he just carves out the
> hunk
> > > of storage on Z/VM and assigns it to the Linux guest .
> > >
> > > SCSI is irrelevant because the Linux guest is virtual and doesn't need
> to
> > > know about the disk protocol.   And his z/VM host is connected via
> FICON.
> > >
> > > He said the only time one might need to go back to the ds8k is if some
> of
> > > the storage on that box hadn't been defined and needed to be redefined
> > and
> > > then attached to the z/vm host. But he's never had to do that in 10
> years
> > > of running that system.
> > >
> > >
> > >
> > > On Tue, Dec 17, 2019, 7:28 AM Peter  wrote:
> > >
> > > > Hello,
> > > >
> > > > Could someone please recommend a manual which describes step by step
> > > > procedure to define SCSI on DS8K.
> > > >
> > > > I need this procedure to define SCSI disk for my Linux guest running
> on
> > > > zVM.
> > > >
> > > > Peter
> > > >
> > > >
> --
> > > > 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
> >
>
> --
> 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: MIPS chart for all IBM hardware model

[Christian Svensson]

Peter,

Are you perhaps referring to topgun-tech's site?
https://www.topgun-tech.com/specs/imb-zsystems-mainframes/ibm-z114-ibm-2818/

Regards,
Christian

On Thu, Nov 7, 2019, 08:41 Parwez Hamid  wrote:

>
> https://www-01.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprITRzOSv2r2?OpenDocument
> IBM Resource Link: IBM Z LSPR ITR ratios for IBM processors where each
> model is configured with multiple z/OS images based on an average LPAR
> profile of client systems<
> https://www-01.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprITRzOSv2r2?OpenDocument
> >
> This IBM Resource Link web page is the source for IBM Z LSPR ITR ratios
> for IBM processors where each model is configured with multiple z/OS images
> based on an average LPAR profile of client systems.
> www-01.ibm.com
>
>
> Regards
>
> Parwez Hamid​
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Peter 
> Sent: 07 November 2019 07:16
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: MIPS chart for all IBM hardware model
>
> Hi All
>
> I am looking for a document which describes all the IBM machine model with
> their MIPS, SU/sec etc .
>
> There used to be used to be site which used to provide but i am unable to
> find it.
>
> Could someone please forward it to me?
>
> Peter
>
> --
> 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: Blank fanout z114 CPC adapter

[Christian Svensson]

It's all good - I didn't mention it, so you couldn't have known.

On Mon, Sep 16, 2019 at 10:34 PM Edward Finnell <
000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:

> Sorry, wasn't paying attention.
>
> In a message dated 9/16/2019 3:32:59 PM Central Standard Time,
> 022ad63487ef-dmarc-requ...@listserv.ua.edu writes:
> Because I bought it on eBay :-)
>
> --
> 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: Blank fanout z114 CPC adapter

[Christian Svensson]

Hi,

Because I bought it on eBay :-).



On Mon, Sep 16, 2019 at 10:13 PM Edward Finnell <
000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:

> Why isn't your CE handling this?
>
> In a message dated 9/16/2019 3:00:58 PM Central Standard Time,
> 022ad63487ef-dmarc-requ...@listserv.ua.edu writes:
> This is why I'm thinking of removing the actual adapters.
>
> --
> 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: Blank fanout z114 CPC adapter

[Christian Svensson]

Hi,

Thanks. You're right that it is a z196, but I hoped that the slots would
have the same form factor so I could use them. Maybe too sneaky :-).

I removed the cables to the adapter but the SE complains. It recommends me
to order a cable cleaning kit for the I/O adapter - I doubt it will help
:-).
I have removed the drawer (thanks for correcting me!) from the SE's Frame
Layout, so I'm guessing that it is unhappy because all links are down on
the adapter.

This is why I'm thinking of removing the actual adapters.


On Mon, Sep 16, 2019, 15:04 Parwez Hamid  wrote:

> Slide 8 shows the fanouts for a z196 Book.
>
> CPC Drawer fanouts for a z114 shown below. I think, once you remove the
> I/O Drawer (not a a cage ) , unless you need the I/O drawer fanouts for a
> different type of fanout, you can just leave the I/O drawer HCA2-C fanouts.
> Shouldn't do any harm.
>
> Unable to imbed a picture of the z114 CPC drawer. If you want one I can
> send it direct to your email.
>
> Regards
>
> Parwez Hamid​
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Christian Svensson <022ad63487ef-dmarc-requ...@listserv.ua.edu>
> Sent: 15 September 2019 22:19
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Blank fanout z114 CPC adapter
>
> Hi,
>
> I'm in the process of removing the old I/O cage and just using my PCIe
> cage.
> I can see from some pictures in SHARE slides
> <
> https://share.confex.com/share/118/webprogram/Handout/Session10617/S10617%20-%20Introducing%20the%20new%20z114%20and%20z196%20PCIe%20IO%20and%20Coupling%20Infrastructure%20Mar9a%20.pdf
> >
> (slide
> 8) that there is a fanout dummy adapter, i.e. what I assume is just a metal
> shell that protects the CPC adapter connector during operation.
>
> Anyone out there on the mailing list that happen to know the part number?
>
> Thanks,
>
> --
> 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

Blank fanout z114 CPC adapter

[Christian Svensson]

Hi,

I'm in the process of removing the old I/O cage and just using my PCIe cage.
I can see from some pictures in SHARE slides

(slide
8) that there is a fanout dummy adapter, i.e. what I assume is just a metal
shell that protects the CPC adapter connector during operation.

Anyone out there on the mailing list that happen to know the part number?

Thanks,

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

Re: vendor distributes their private key

[Christian Svensson]

Fwiw,

For client authentication we ask our clients to send us a Certificate
Signing Request for the keypair they want to use, and we sign them using
our internal Client Authentication CA. We set the CN and other options to
what we want for our systems to authorize them correctly, and then send the
client the resulting certificate back.

We never see their private key, and we have full control of validity of
their certificate (revocation and expiration).

On Fri, Aug 30, 2019, 10:15 Charles Mills  wrote:

> Andrew, that's a good thought. I'm not knowledgeable enough to tell
> whether it is perfect from a cryptographic point of view or not.
>
> FWIW though, that is not how X.509 standard client authentication works.
> It works the way I described, in accordance with RFC 5246 7.4.6.
>
> Passwords work, and are obviously THE most common form of client
> authentication. I think a primary usage of client certificate
> authentication is with unattended processes. (Think z/OS jobs!) There is no
> one available to key in a password, and passwords stored in files make the
> auditors very cranky.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Andrew Rowley
> Sent: Thursday, August 29, 2019 6:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: vendor distributes their private key
>
> On 29/08/2019 9:18 am, Charles Mills wrote:
>
> > But for certificate-based client authentication, the server admin must
> send the client admin a client certificate AND its private key. Why?
> Philosophically, because a client certificate signed by a trusted CA does
> not prove the authenticity of the client. A man-in-the-middle might have
> previously intercepted the certificate and now be sending it out from HIS
> client as its own.
>
> This doesn't sound right somehow. I suspect it is often implemented that
> way, but it sounds worse than password authentication with a good password.
>
> --
> 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: Integrated 3270 Console in HMC 2.12 in web browser

[Christian Svensson]

Hi,

Thanks - seems my options are limited on the z114 in this regard - OSA
Express4S is marked as z12BC only for copper 1Gbit. I wonder if anyone has
had any success running 4S or even 5S regardless? I'm guessing the models
are not part of the 93G driver.

What are my options? Is the Integrated 3270 console in the HMC sufficient
to run e.g. the master console of z/OS and z/VM?.

Thanks,


On Thu, Aug 22, 2019 at 8:28 PM Parwez Hamid 
wrote:

> Any PCIe based OSA Express 1000BASE-T feature defined as OSC supports
> OSA-ICC
>
> Regards
>
> Parwez Hamid​
>
> --
> 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: Integrated 3270 Console in HMC 2.12 in web browser

[Christian Svensson]

Hi,

I see - I tried with Internet Explorer and indeed things seems to be moving
further ahead. Some applets' certificates expired in 2016 so I think that
might one of the problems I'm hitting. I'll see about resigning them.

Regarding OSA-ICC. Is there a way to get that using PCIe cages only? I wish
to decom the ESCON bay in this z114 to conserve power, but I have not found
an OSA Express that has ICC in PCIe.

Thanks,

On Fri, Aug 16, 2019 at 12:29 AM Cieri, Anthony  wrote:

>
> Weather this is possible may depend upon the level of Java that
> you are using.
>
> I use FireFox to connect to the HMC for an older z10 machine. I
> also keep a Java Version 7 installed specifically for the Integrated 3270
> Console function.  I have colleagues here with similar PC configurations,
> that have Java Version 8 or later installed.  They can access some HMC
> functions via a remote Web Browser, but unfortunately the Integrated 3270
> console is NOT one of them.
>
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Christian Svensson
> Sent: Wednesday, August 14, 2019 2:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Integrated 3270 Console in HMC 2.12 in web browser
>
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders. ***
> ]]
>
>
> Hi,
>
> Is it possible to launch Integrated 3270 Console in HMC 2.12 when accessing
> the HMC using a web browser?
>
> When I click on the LPAR and choose Integrated 3270 Console nothing happens
> when using a remote web browser. It works locally on the HMC. The Chrome
> network request is:
>
> Request URL: https:///hmc/ui/dnd2/launch
> Request Method: POST
> Status Code: 204 No Content
> Remote Address: 10.114.2.10:443
> Referrer Policy: no-referrer-when-downgrade
> Date: Wed, 14 Aug 2019 06:00:22 GMT
> Server: zSeries management console embedded web server / 2.0
>
> Nothing more. Am I missing something? Some other actions at least say "this
> task cannot be used remotely" which makes me wonder if I'm doing something
> wrong.
>
> Bonus question: Can I connect to the LPAR 3270 console remotely in some
> other fashion?
>
> Thanks,
>
> --
> 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

Integrated 3270 Console in HMC 2.12 in web browser

[Christian Svensson]

Hi,

Is it possible to launch Integrated 3270 Console in HMC 2.12 when accessing
the HMC using a web browser?

When I click on the LPAR and choose Integrated 3270 Console nothing happens
when using a remote web browser. It works locally on the HMC. The Chrome
network request is:

Request URL: https:///hmc/ui/dnd2/launch
Request Method: POST
Status Code: 204 No Content
Remote Address: 10.114.2.10:443
Referrer Policy: no-referrer-when-downgrade
Date: Wed, 14 Aug 2019 06:00:22 GMT
Server: zSeries management console embedded web server / 2.0

Nothing more. Am I missing something? Some other actions at least say "this
task cannot be used remotely" which makes me wonder if I'm doing something
wrong.

Bonus question: Can I connect to the LPAR 3270 console remotely in some
other fashion?

Thanks,

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

Re: Source of initial HMC backup

[Christian Svensson]

Hi,

I managed to get a backup going by copying /console/data/iqyvpdc.xml from
my SE to my HMC and then running the backup. It seems to work just fine,
but if anyone can confirm / deny the sanity of doing that it would be
greatly appreciated :-).

Thanks,

On Mon, Aug 12, 2019 at 6:12 PM Christian Svensson  wrote:

> Hi,
>
> Yes - the drive is formatted and it shows up correctly. If I do not have
> it formatted it fails earlier in the process.
> I'm starting to suspect something is off with the VPD data. The little
> information I could find was from the
> "repair problem" flow that suggested that I replace the component named
> something like "VPD file".
>
> I managed to run backupccdata from a root shell on the HMC and it also
> complains about VPD.
> "VPD file: /console/data/iqyvpdc.xml was not found in the HDD, fail Backup
> script".
>
> Doing a "Rebuild VPD" on the CPC fails however, but maybe that's where I
> should be focusing
> my efforts?
>
> Thanks,
>
>
>
> On Mon, Aug 12, 2019 at 5:53 PM Dana Mitchell  wrote:
>
>> Did you format the USB using the 'Format Media' task in Console Actions?
>>
>> Dana
>>
>> On Mon, 12 Aug 2019 17:36:35 +0200, Christian Svensson 
>> wrote:
>> >
>> >Is there a way I can create this initial backup USB so I can make the HMC
>> >happy?
>> >
>>
>> --
>> 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: Source of initial HMC backup

[Christian Svensson]

Hi,

Yes - the drive is formatted and it shows up correctly. If I do not have it
formatted it fails earlier in the process.
I'm starting to suspect something is off with the VPD data. The little
information I could find was from the
"repair problem" flow that suggested that I replace the component named
something like "VPD file".

I managed to run backupccdata from a root shell on the HMC and it also
complains about VPD.
"VPD file: /console/data/iqyvpdc.xml was not found in the HDD, fail Backup
script".

Doing a "Rebuild VPD" on the CPC fails however, but maybe that's where I
should be focusing
my efforts?

Thanks,



On Mon, Aug 12, 2019 at 5:53 PM Dana Mitchell  wrote:

> Did you format the USB using the 'Format Media' task in Console Actions?
>
> Dana
>
> On Mon, 12 Aug 2019 17:36:35 +0200, Christian Svensson 
> wrote:
> >
> >Is there a way I can create this initial backup USB so I can make the HMC
> >happy?
> >
>
> --
> 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

Source of initial HMC backup

[Christian Svensson]

Hi,

I'm trying to set up an HMC to my z114 I bought on eBay. I have the SEs
running just fine, but when I'm trying to install the HMC it asks for a
backup USB.

If I bypass the dialog to launch the HMC with default settings, everything
seems to work fine.
I can run the backup of critical data for the CPC for example, but it seems
like the one the HMC requires is another type (it logs an error about not
finding hmcbkp.tar.pk1 or similar, while the SE/CPC backups are named
differently).

Trying to run the Backup Critical Console Data fails straight away with
next to no details. The message is "The backup tar file could not be
created" and the LIC error "Service is required" is emitted to HMC1 on
hardware messages.

Is there a way I can create this initial backup USB so I can make the HMC
happy?

Thanks,

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

Single phase power connector to z114

[Christian Svensson]

Hi,

This may be an odd question. I bought an z114 and I'm trying to figure out
how to power it.
I've arrived that the single-configuration BPR I have should happily accept
any AC between 200V-600V, and I managed to buy two 41U0108 (one per A/B
power). The power consumption should come out to less than 3kW of power, so
16A 230V should be perfect.

The connector to the frame seems to be 3W+PE - i.e. no neutral, so my
thinking is that this is a delta-system.

Adding these facts together my thinking is that I should be able to route
my 230V mains like this:

   - PH-1: Mains L
   - PH-2: Mains N
   - PH-3: Unconnected
   - GND: Mains GND
   - Wire shield: Mains GND

This should emulate pretty closely a 3-phase US system with only one
working phase is my thinking, so should not be that unconventional from the
eyes of the BPR.

My question is: does this match the single phase cables that IBM provide to
these systems?
I am mostly interested in what the recommendation is to connect PH-3 to,
but leaving it unconnected seems to be the least risky.

Thanks!

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

DS6000 Storage Manager in 2019

[Christian Svensson]

Hi,

I would like to use the DS6000 Storage Manager Offline Configuration /
Simulator tooling. It appears that it used to be available on IBMs website
but that seems to be no longer the case.

Is there any other way to acquire this utility today? I tried to search for
it in various ways but I came up short.

Thanks,

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

Re: In-rack FICON DASD

[Christian Svensson]

Thanks everyone for your wonderful replies!
This was exactly what I was looking for :-).

Thanks,

On Tue, 16 Apr 2019, 15:53 John Kaba  wrote:

> We have been using the Visara 8810 for almost a year, and it has been a
> reliable, cost effective, rack mounted solution for our older z890 running
> VM and VSE.  It has a small footprint, and is faster than what our old z890
> channels can handle, so it is limited only by our CPU.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Mike Shorkend
> Sent: Tuesday, April 16, 2019 8:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: In-rack FICON DASD
>
> Check out IBM's DS8882F.
>
>
> On Sun, 14 Apr 2019 at 17:56, Ken Bloom  wrote:
>
> > Check out the Visara vi-8810 DASD, 2U high, SSD dasd.  I can give you
> > more info offline.
> >
> > Regards
> > Ken
> >
> > Kenneth A. Bloom
> > CEO
> > Avenir Technologies Inc
> > /d/b/a Visara International
> > 203-984-2235
> > bl...@visara.com
> > https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.visara.com=E
> > ,1,c1RJve6w5qylHKFFZbk-1h0Nt1xjCkxMEMwHaCeWaFRUczvytiQme5hvswcgtmv81CF
> > a5TGZpT9rz1_qX9tSn5pRKFdG0yHcVMwsNRiPXznJ=1
> >
> >
> > > On Apr 14, 2019, at 10:42 AM, Christian Svensson <
> > 022ad63487ef-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > Hi,
> > >
> > > With the z14 ZR1's 16U reserved 19" space option available I'm
> > > curious if anyone has figured out a way to fit everything one needs in
> one rack?
> > > Adding two switches, and a conventional SAN is a no-brainer with
> > > space to spare - but what would you pick for FICON EKCD for supporting
> z/OS load?
> > >
> > > An old DS6800 would work but what if you want something that is a
> > > bit
> > newer
> > > and not EOL?
> > >
> > > Imagine this rack is for development purposes or something that is
> > > not mission critical, where the space (and power) is more of a premium.
> > >
> > > Thanks,
> > >
> > > 
> > > -- 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
> >
>
>
> --
> Mike Shorkend
> m...@shorkend.com
>
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.shorkend.com=E,1,w5UTp-OTVhMERCltq0wkfUSgfC5cJFaBMaYh3CJqCaCpUdGmOCETllsy2ZfGGHngC5tWSkiHPi1iQIjENro13yqXAfOg6V_VSyyT0KtbtTmBp_hfPQ,,=1
> Tel: +972524208743
> Fax: +97239772196
>
> --
> 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

In-rack FICON DASD

[Christian Svensson]

Hi,

With the z14 ZR1's 16U reserved 19" space option available I'm curious if
anyone has figured out a way to fit everything one needs in one rack?
Adding two switches, and a conventional SAN is a no-brainer with space to
spare - but what would you pick for FICON EKCD for supporting z/OS load?

An old DS6800 would work but what if you want something that is a bit newer
and not EOL?

Imagine this rack is for development purposes or something that is not
mission critical, where the space (and power) is more of a premium.

Thanks,

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

Re: z114 and z/OS 2.3

[Christian Svensson]

Thanks Jim, much appreciated!

On Wed, Apr 3, 2019 at 8:53 PM Jim Stefanik 
wrote:

> The documentation is correct. Anything older than EC12 (or BC12) will drop
> to a wait state. I've tried it on a z196 and almost instantly get a wait.
>
>
>
> ---
>
> Jim Stefanik
> Dallas Vintage Computing Center
> ________
> From: Christian Svensson <022ad63487ef-dmarc-requ...@listserv.ua.edu>
> Sent: Wednesday, 3 April 2019 22:31
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: z114 and z/OS 2.3
>
> Hi,
>
> I know that z114 is not officially supported on z/OS 2.3 - but I was
> wondering if anyone has had any success IPLing it just for experimental
> purposes on this platform?
>
> I see that the wait state documentation for z/OS 2.3 wait state 07B says
> that "Miscellaneous-instruction-extension facility" is required and that
> appears to have been added arch-level 10
> <
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcux01/archcop.htm>
>
> and
> z114 is arch-level 9. The other facilities appears to be present in z114.
>
> Still, I wonder if this is reflective of the reality.
> Does anyone on the list have any real life confirmations that it will
> indeed blow up in my face if I try it?
>
> Thanks,
>
> --
> 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

z114 and z/OS 2.3

[Christian Svensson]

Hi,

I know that z114 is not officially supported on z/OS 2.3 - but I was
wondering if anyone has had any success IPLing it just for experimental
purposes on this platform?

I see that the wait state documentation for z/OS 2.3 wait state 07B says
that "Miscellaneous-instruction-extension facility" is required and that
appears to have been added arch-level 10

and
z114 is arch-level 9. The other facilities appears to be present in z114.

Still, I wonder if this is reflective of the reality.
Does anyone on the list have any real life confirmations that it will
indeed blow up in my face if I try it?

Thanks,

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