Re: Pronunciations (spun off of another thread)
Phil, About brazilians.. :) We use to say : "siks" Dan Sent from Yahoo Mail for iPhone On Sunday, May 9, 2021, 3:57 AM, Meir Zohar wrote: CICS pronounced Chicks/Thicks in Italy/Spain ... Took a moment to figure out what the speaker was talking about ... MZ -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Sunday, May 9, 2021 6:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) Hi Bob, This reminds me of a story. Back in 2000, I was doing an ACF2 to RACF conversion and one of the customer's people kept saying Ra-Keff (instead of Rack-Eff.) This REALLY got on my nerves. As an aside, a former colleague (with a British accent) always says ZOSS (instead of Zed-Oh-Ess or Zee-Oh-Ess). (He's not really British.) Have you ever heard ANYONE say IMZ (instead of Eye-Emm-Ess)? Regards, David On 2021-05-08 17:02, Bob Bridges wrote: > I grew up with "doss" and "see-eye-see-ess", but even here in the East I've > heard "kicks" often enough that I can adjust now if that's what the current > crowd uses. Actually I think sysprogs say "kicks" more than application > programmers, for some reason. > > I've heard "sicks" just once, I believe, but I don't remember where the > speaker was from. > > "Rack-eff", of course, so I guess I could excuse either "pee-rack-eff" or > "prack-eff". Dunno what it is, though. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* One of the quickest ways I've found to look foolish is to state > positively what God will not do. -Bob Bridges */ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of David Spiegel > Sent: Friday, May 7, 2021 17:10 > > (I'm also from Southern Ontario -- I say doss and cics.) > > -- > 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: Pronunciations (spun off of another thread)
What if you spell it ÇICS? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Meir Zohar [zme...@bezeqint.net] Sent: Sunday, May 9, 2021 2:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) CICS pronounced Chicks/Thicks in Italy/Spain ... Took a moment to figure out what the speaker was talking about ... MZ -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Sunday, May 9, 2021 6:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) Hi Bob, This reminds me of a story. Back in 2000, I was doing an ACF2 to RACF conversion and one of the customer's people kept saying Ra-Keff (instead of Rack-Eff.) This REALLY got on my nerves. As an aside, a former colleague (with a British accent) always says ZOSS (instead of Zed-Oh-Ess or Zee-Oh-Ess). (He's not really British.) Have you ever heard ANYONE say IMZ (instead of Eye-Emm-Ess)? Regards, David On 2021-05-08 17:02, Bob Bridges wrote: > I grew up with "doss" and "see-eye-see-ess", but even here in the East I've > heard "kicks" often enough that I can adjust now if that's what the current > crowd uses. Actually I think sysprogs say "kicks" more than application > programmers, for some reason. > > I've heard "sicks" just once, I believe, but I don't remember where the > speaker was from. > > "Rack-eff", of course, so I guess I could excuse either "pee-rack-eff" or > "prack-eff". Dunno what it is, though. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* One of the quickest ways I've found to look foolish is to state > positively what God will not do. -Bob Bridges */ > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of David Spiegel > Sent: Friday, May 7, 2021 17:10 > > (I'm also from Southern Ontario -- I say doss and cics.) > > -- > 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: Pronunciations (spun off of another thread)
On Sun, 9 May 2021 12:14:25 +, Seymour J Metz wrote: >What if you spell it ÇICS? > Could that be added as a member alias? https://miro.medium.com/max/1400/1*Qvnk1NFFUeiNXiC7AF1owg.png -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STIMERM LT value
Perhaps the OP should try using GMT= instead of LT=, to see just how things work without the time zone offset coming into play. Is it still off by a minute when using GMT= ? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XMITIP - NLS support for Arabic character
Hello, Cross posted Is there anyone who has successfully used XMITIP NLS to build arabic character on email body ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XMITIP - NLS support for Arabic character
I might recommend a review of the website http://lbdsoftware.com/xmitip.html . See if there is any help there Second, you probably want to contact the owner of the product. It would be a better place for these types of questions. This is not a vendor product, but something someone wrote and provided to the universe which was very kind. So it front ends SMTP. That would make me ask the questions, are you using Arabic in any of your current applications? Do you have the code pages available for Arabic? Do you have CICS/IMS screens in Arabic? Do you currently create reports in Arabic? All SMTP would do is send your text data written in Arabic to another location/function I would suspect that you might need to set up something in SMTP for Arabic. By using internet search with words XMITIP ARABIC I found this entry, there are probably more ( this link is from you in 2019) https://www.mail-archive.com/ibm-main@listserv.ua.edu/msg88621.html You have not said what issue you are seeing with setting up Arabic. That would also be helpful to know. Do you have the code page available for Arabic Do you write other text/files/screens with Arabic What happens when you try to send with XMITIP and ARABIC Are you able to see and read the Arabic on the mainframe? What application are you sending to that the Arabic is not valid? Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Sunday, May 9, 2021 9:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XMITIP - NLS support for Arabic character Hello, Cross posted Is there anyone who has successfully used XMITIP NLS to build arabic character on email body ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pronunciations (spun off of another thread)
Can I get my CICS on Route 66? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, May 9, 2021 6:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) On Sun, 9 May 2021 12:14:25 +, Seymour J Metz wrote: >What if you spell it ÇICS? > Could that be added as a member alias? https://miro.medium.com/max/1400/1*Qvnk1NFFUeiNXiC7AF1owg.png -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
While I agree with your recommendations, the FTPS job does not work
without the ciphers I listed below. Apparently IBM needs to make some
adjustments first.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Michael Babcock
Sent: Wednesday, May 05, 2021 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order post May 1st
[[ SEI WARNING *** This email was sent from an external source. Do not open
attachments or click on links from unknown or suspicious senders. *** ]]
I would highly discourage the use of the ciphers listed. I would use these
more secure ciphers (I'm sure there are others that are acceptable).
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
On 5/5/2021 12:58 PM, Cieri, Anthony wrote:
> Dave,
> Here you go:
>
> ##
> # #
> # Secure FTP Application #
> # #
> ###
>
>
> TTLSRule secure_ftp_client_rule
> {
>RemotePortRange 21 # This should be set to the port the FTP
> # listening on
>Direction Outbound
>TTLSGroupActionRef secure_ftp_client_group
>TTLSEnvironmentActionRef secure_ftp_client_env
> }
>
>
> TTLSGroupAction secure_ftp_client_group
> {
>TTLSEnabled On
>Trace 7
> }
>
>
> TTLSEnvironmentAction secure_ftp_client_env
> {
>TTLSKeyringParms
>{
> Keyring /u/ftps/zos17dbf.kdb
> KeyringStashFile /u/ftps/zos17dbf.sth
>}
>HandshakeRole Client
> TTLSEnvironmentAdvancedParms
>{
> ApplicationControlledOn
> SecondaryMap On
> SSLV3Off
> TLSV1Off
> TLSV1.1 Off
> TLSV1.2 On
>}
>TTLSCipherParmsRef ftp_client_ciphers # to cust ciphers
> }
>
>
> TTLSCipherParms ftp_client_ciphers
> {
> # Sample ciphers. Should be customized!
> V3CipherSuitesTLS_RSA_WITH_AES_256_CBC_SHA
> V3CipherSuitesTLS_RSA_WITH_3DES_EDE_CBC_SHA
> V3CipherSuitesTLS_RSA_WITH_NULL_SHA
> }
>
>
> -Original Message-
> From: IBM Mainframe Discussion List On
> Behalf Of Dave Jousma
> Sent: Wednesday, May 05, 2021 1:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMPE Receive Order post May 1st
>
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders.
> *** ]]
>
>
>> Well, for what it's worth, I just tried it and my job was
>> successful, however, I also received the SSLv23/TLSv1 messages. So I
>> used the standard job that IBM provided (RFNJOBS) and I turned on Debug SEC.
>> Here is what I got
> (snip)
>
> Hey Tony, Thanks for this. For some reason we are still struggling.
> Would you be willing to share what your pagent policy for these items:
>
> FU2420 TTLSRule: secure_ftp_client_rule
> FU2426 TTLSGroupAction: secure_ftp_client_group
> FU2432 TTLSEnvironmentAction: secure_ftp_client_env
>
> looks like? I dont think there is anything sensitive, and if you'd rather,
> you can send to me off-list (david.jou...@53.com)
>
> --
> 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
Re: XMITIP - NLS support for Arabic character
On 2021-05-09, at 10:08:45, Peter wrote: > > Cross posted > > Is there anyone who has successfully used XMITIP NLS to build arabic > character on email body ? > Hmmm... In "XMITIP User Reference Guide" I see merely: Note that all data on the mainframe is stored in the EBCDIC character set and is translated to the ASCII character set during the transmission. Any data that should not be translated should be attached in Binary format. That's pretty meager. It fails to state: o What EBCDIC code page is presumed, nor whether the user has any choice. o How characters with no ASCII equivalent are treated. (128/256) Is your Arabic data IBM-420? What if the source is Roman with Arabic insertions? I understand that mainframes tend to store Arabic text backwards. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pronunciations (spun off of another thread)
Sure. State Farm and Country Companies in Bloomington Normal IL are on Route 66 (4 lane bypass Veterans Parkway). Illinois State University has their computer center a few blocks off the downtown route. Horace Mann does and Franklin Life used to in Springfield IL on old Route 66 (5th&6th / 9th). Central Management Services, Secretary of State, formerly State Police for State of Illinois a couple of blocks off the 2nd street route. And that would cover the segment between Joliet and Edwardsville in Illinois. And not certain there weren't other mainframes. On Sun, May 9, 2021 at 12:40 PM Charles Mills wrote: > > Can I get my CICS on Route 66? > > Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pronunciations (spun off of another thread)
So I guess it's not true what Paul Revere and the Raiders sang? CICS just keep getting' harder to find Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Sunday, May 9, 2021 12:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) Sure. State Farm and Country Companies in Bloomington Normal IL are on Route 66 (4 lane bypass Veterans Parkway). Illinois State University has their computer center a few blocks off the downtown route. Horace Mann does and Franklin Life used to in Springfield IL on old Route 66 (5th&6th / 9th). Central Management Services, Secretary of State, formerly State Police for State of Illinois a couple of blocks off the 2nd street route. And that would cover the segment between Joliet and Edwardsville in Illinois. And not certain there weren't other mainframes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pronunciations (spun off of another thread)
Silly rabbit, TRICS are for kids . Chris Hoelscher Lead Sys DBA IBM Global Technical Services on assignmemt to Humana Inc. T 502.476.2538 or 502.407.7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Sunday, May 9, 2021 6:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Pronunciations (spun off of another thread) [External Email: Use caution with links and attachments] So I guess it's not true what Paul Revere and the Raiders sang? CICS just keep getting' harder to find Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Sunday, May 9, 2021 12:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) Sure. State Farm and Country Companies in Bloomington Normal IL are on Route 66 (4 lane bypass Veterans Parkway). Illinois State University has their computer center a few blocks off the downtown route. Horace Mann does and Franklin Life used to in Springfield IL on old Route 66 (5th&6th / 9th). Central Management Services, Secretary of State, formerly State Police for State of Illinois a couple of blocks off the 2nd street route. And that would cover the segment between Joliet and Edwardsville in Illinois. And not certain there weren't other mainframes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pronunciations (spun off of another thread)
Coming from England, we always pronounce "route" with a long sound, like "root". I understand that in the USA it is usually pronounced the same as "rout". No problem. But in the song "Route 66" it is pronounced the same way we do in England. Why is that? Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 09 May 2021 18:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) Can I get my CICS on Route 66? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, May 9, 2021 6:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) On Sun, 9 May 2021 12:14:25 +, Seymour J Metz wrote: >What if you spell it ÇICS? > Could that be added as a member alias? https://miro.medium.com/max/1400/1*Qvnk1NFFUeiNXiC7AF1owg.png -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This email has been scanned by BullGuard antivirus protection. For more info visit www.bullguard.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pronunciations (spun off of another thread)
CICS are for Trids. On 2021-05-09 20:35, Chris Hoelscher wrote: Silly rabbit, TRICS are for kids . Chris Hoelscher Lead Sys DBA IBM Global Technical Services on assignmemt to Humana Inc. T 502.476.2538 or 502.407.7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Sunday, May 9, 2021 6:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Pronunciations (spun off of another thread) [External Email: Use caution with links and attachments] So I guess it's not true what Paul Revere and the Raiders sang? CICS just keep getting' harder to find Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Sunday, May 9, 2021 12:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) Sure. State Farm and Country Companies in Bloomington Normal IL are on Route 66 (4 lane bypass Veterans Parkway). Illinois State University has their computer center a few blocks off the downtown route. Horace Mann does and Franklin Life used to in Springfield IL on old Route 66 (5th&6th / 9th). Central Management Services, Secretary of State, formerly State Police for State of Illinois a couple of blocks off the 2nd street route. And that would cover the segment between Joliet and Edwardsville in Illinois. And not certain there weren't other mainframes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, ancestry, age, disability, sex, marital status, gender, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese):注意:如果您使用繁體中文,您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- 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: 3270 emulator / telnet with encryption
Seymour J. Metz wrote: >What's wrongwith running a 3270 client in an encrypted VPN? Grant Taylor replied: >IMHO, nothing. >I think the problem comes from complications around VPNs, not the least >of which include: >1) Complex configurations. -- Does the mainframe support being a VPN >endpoint itself? IPsec? Something else? z/OS does: IPsec (IKEv2). The major issue is that one VPN tunnel can be shared. When you operate this way, there's no security segregation per connection. The TN3270E traffic rides alongside NFS, HTTP, MQ, JDBC, ODBC, Enterprise Extender, and any other protocols you're using. Moreover, TN3270E Session A rides alongside Session B, Session C, etc. Usually you don't want multiple connections sharing the same private encryption keys, because the producers and consumers of data flowing over connection #1 should be kept cryptographically separated from the producers and consumers of data flowing over connection #2. Your connection to Production LPAR A has no business being in the same cryptographic "zone" as your connection to Test LPAR B, for example. (And maybe YOU shouldn't have those two connections either, but at least you can avoid cryptographically unifying these connections.) You could hypothetically solve this shortcoming by carefully configuring multiple active VPN connections with separate credentials and routing rules, but that can be quite difficult in practice. Thus the usual/typical best practice is to encrypt each connection separately (TLS-encrypted TN3270E, for example) insofar as possible *and* use a VPN at least if you're traversing a public network (and often also even if you're not). There's nothing wrong with double, triple, or even quadruple encryption! In this case, if someone or something manages to compromise your VPN connection, that someone or something still won't decipher each connection's separately encrypted traffic and would have to compromise each one separately since they use separate private keys. If you are restricted to using one and only one TN3270E session, with no other sessions of any type, and if the IPsec endpoints are the same endpoints that you would get with TLS-encrypted TN3270E, then IPsec/IKEv2 would provide a similar level of security compared to TLS-encrypted TN3270E. However, even then the end user wouldn't get visible, on screen assurance that the network path is reasonably secured because the magic padlock (or similar symbol) wouldn't appear on his/her emulator's screen. That's subpar because you're knocking the user out of the security equation. End user collaboration is really important to maintain a good or better security posture. As an aside, emulators should complain more loudly and forcefully when they're being asked to establish unencrypted sessions. I see some movement in that direction already, and it's a welcome development. Anyway, in summary, if you haven't already, get AT-TLS-encrypted TN3270E turned on, and shut off the unencrypted stuff. You've been able to avoid this class of security risks for literally a quarter century, and it's way, way past time to avoid them if you haven't already. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3270 emulator / telnet with encryption
On 5/9/21 8:11 PM, Timothy Sipples wrote: z/OS does: IPsec (IKEv2). The major issue is that one VPN tunnel can be shared. When you operate this way, there's no security segregation per connection. The TN3270E traffic rides alongside NFS, HTTP, MQ, JDBC, ODBC, Enterprise Extender, and any other protocols you're using. Moreover, TN3270E Session A rides alongside Session B, Session C, etc. I'd have to refresh myself on how granular you can target things, but I believe you can definitely differentiate between NFS, HTTP, MQ, JDBC, ODBC, Enterprise Extender, and any other protocols you're using based on the different ports that they operate on. I agree that multiple TN3270E client sessions would (likely) be targeting the same mainframe IP and port. But there might be a way to extend the granularity used to match different service ports on the mainframe to also granularly match the different ephemeral ports that the client is using for each connection. Aside: It looks like I can get extremely granular with the manual IPsec management method 'ip xfrm policy' command on Linux. Thus I would assume that IKE also supports such granularity. Usually you don't want multiple connections sharing the same private encryption keys, because the producers and consumers of data flowing over connection #1 should be kept cryptographically separated from the producers and consumers of data flowing over connection #2. I'm going to assume that IKE can do what I can do with the 'ip xfrm policy' command until someone corrects me. Thus, it should be quite possible to have different keying material for different TCP / UDP connections. Your connection to Production LPAR A has no business being in the same cryptographic "zone" as your connection to Test LPAR B, for example. I'd expect that different LPARs to have different IP addresses. Thus they would be in different IPsec security associations and have different keying material. (And maybe YOU shouldn't have those two connections either, but at least you can avoid cryptographically unifying these connections.) That's a different conversation. You could hypothetically solve this shortcoming by carefully configuring multiple active VPN connections with separate credentials and routing rules, but that can be quite difficult in practice. I get the impression that you're thinking a more traditional /tunnel/ connection with different (inside) tunnel IPs at each end. I'm talking about /transport/ mode, which is explicitly between two end system IPs. I'm also assuming that it's possible to have different security associations per source IP, destination IP, source port, and destination port tuples. Thus TN3270E Session A would be in a different cryptographic zone from TN3270E Session B to the same endpoint. Other protocols / services would also be in different cryptographic zones. Thus the usual/typical best practice is to encrypt each connection separately (TLS-encrypted TN3270E, for example) insofar as possible *and* use a VPN at least if you're traversing a public network (and often also even if you're not). There's nothing wrong with double, triple, or even quadruple encryption! I disagree. Each layer of encryption (or more generically, tunneling) introduces it's own overhead and consumes usable space in packets, thus requiring more packets to get the same amount of data from end to end. There are many factors that come into play as to if this overhead causes problems or not. In this case, if someone or something manages to compromise your VPN connection, that someone or something still won't decipher each connection's separately encrypted traffic and would have to compromise each one separately since they use separate private keys. That would be the case with discrete security associations per per tuple. If you are restricted to using one and only one TN3270E session, with no other sessions of any type, and if the IPsec endpoints are the same endpoints that you would get with TLS-encrypted TN3270E, then IPsec/IKEv2 would provide a similar level of security compared to TLS-encrypted TN3270E. However, even then the end user wouldn't get visible, on screen assurance that the network path is reasonably secured because the magic padlock (or similar symbol) wouldn't appear on his/her emulator's screen. That's subpar because you're knocking the user out of the security equation. End user collaboration is really important to maintain a good or better security posture. I've found that relying on the end user for security to be a weaklink in the chain. I would *much* rather rely on technology to enforce the security. Aside: I can configure Linux so that IPsec protected packets are allowed while unprotected packets are rejected. I don't know if similar can be done on the mainframe or not. As an aside, emulators should complain more loudly and forcefully when they're being asked to establis
Re: Pronunciations (spun off of another thread)
It is indeed odd. We pronounce it both ways. Indeed, we say "root" 66. But "I took a different 'rout' across town." Further, here we root for our favorite sports teams. My understanding is that in England, rooting is not something one does in polite company. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lennie Dymoke-Bradshaw Sent: Sunday, May 9, 2021 5:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pronunciations (spun off of another thread) Coming from England, we always pronounce "route" with a long sound, like "root". I understand that in the USA it is usually pronounced the same as "rout". No problem. But in the song "Route 66" it is pronounced the same way we do in England. Why is that? Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Storage Zoning clarification
Hello All, Good evening I am trying to understand on how the ZONING part works when the connectivity to storage box or the tape device goes through a SAN switch. How does the ZONING is done and is there any documentation with an example to understand better. I am trying to google to see if I can find the one am looking but I am not successful yet. Is there any pointer or example if someone can help me with ? It will be of a big help to proceed further. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3270 emulator / telnet with encryption
Grant Taylor wrote: >I'd have to refresh myself on how granular you can target things, but I >believe you can definitely differentiate between NFS, HTTP, MQ, JDBC, >ODBC, Enterprise Extender, and any other protocols you're using based on >the different ports that they operate on. Perhaps you can...and that may not actually matter very much in this context. It might make network-related security practices a little more complicated, though. How much complexity do you want? :-) >I get the impression that you're thinking a more traditional /tunnel/ >connection with different (inside) tunnel IPs at each end. I'm talking >about /transport/ mode, which is explicitly between two end system IPs. >I'm also assuming that it's possible to have different security >associations per source IP, destination IP, source port, and destination >port tuples. Thus TN3270E Session A would be in a different >cryptographic zone from TN3270E Session B to the same endpoint. Other >protocols / services would also be in different cryptographic zones. First of all, (purported) source IP and port don't offer anything except a minor speed bump, if that. Hypothetically you *could* do this, but I have the same question about complexity. Complexity itself can make it more difficult to achieve a particular security outcome. I'm not sure what problem(s) you're trying to solve here. TLS-encrypted TN3270E works *really* well -- not to the exclusion of other available options and practices, of course. I wrote: >There's nothing wrong with double, triple, or even quadruple encryption! Grant replied: >I disagree. Each layer of encryption (or more generically, tunneling) >introduces it's own overhead and consumes usable space in packets, thus >requiring more packets to get the same amount of data from end to end. >There are many factors that come into play as to if this overhead causes >problems or not. OK, but "most often not" and, as time marches on, "progressively less often than most often not." Programming with two digit years made some sense back when each digit's worth of storage was precious. We don't live in that world any more and haven't for a long, long time. Likewise, we don't live in a world of expensive encryption any more. In all likelihood your mobile phone is quadruple encrypting certain data, after all. I'm highly confident the vast majority of installations can easily (and probably often should) double encrypt TN3270E traffic (TLS-encrypted TN3270E and VPN). If you're working on a project involving a High Frequency Trading (HFT) over TN3270E communication system, then we *might* have something(s) to talk about here. :-) I wrote: >That's subpar because you're knocking the user out of the security >equation. End user collaboration is really important to maintain a good >or better security posture. Grant replied: >I've found that relying on the end user for security to be a weaklink in >the chain. I would *much* rather rely on technology to enforce the >security. Who said anything about *relying* on end users? I pointed out, correctly, that there's danger in *excluding* end users from participating in security defense. They often raise the first alarms. The more security allies, the better. Engineering something that assures padlocks never appear on their emulator session windows is...not good. Also bear in mind that encryption/decryption isn't the only thing TLS provides. It also provides server and/or client certificate authentication, also surfaced to the end user typically in the form of a padlock and/or error messages/halts if the certificate authentication fails. All great stuff from a security point of view. If there's a DNS hijack, IP redirection, miskeyed address, etc., etc., all bets are off without TLS certificate authentication. Conceivably you could "hardwire" the client to a VPN and adopt particularly rigid routing and addressing rules (in a 10.x.y.z network for example), and that might help to some degree, but...what problem(s) are we trying to solve again? :-) I wrote: >Anyway, in summary, if you haven't already, get AT-TLS-encrypted >TN3270E turned on, and shut off the unencrypted stuff. You've been able >to avoid this class of security risks for literally a quarter century, >and it's way, way past time to avoid them if you haven't already. Grant replied: >Sure. Hurray! - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ERBSCAN in batch
On Sat, 8 May 2021 at 13:10, kekronbekron < 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > Is it possible to run the erbscan line command in a batch job? > Hi KB. Yes, it is possible. I was able to run ERBSCAN by editing the REXX, commenting out statements like SETMSG MSG(ISRZ001) and VIEW/BROWSE DATAID, substituting instead an LMCOPY to an output data set. This ran just fine invoked via an ISPSTART in an IKJEFT1B batch job which also allocated the output data set. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ERBSCAN in batch
Hi Peter, That's great, can you share more info (where's the REXX) here or separately? - KB ‐‐‐ Original Message ‐‐‐ On Monday, May 10, 2021 11:50 AM, Peter Vels wrote: > On Sat, 8 May 2021 at 13:10, kekronbekron < > 02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote: > > > Is it possible to run the erbscan line command in a batch job? > > Hi KB. > > Yes, it is possible. > > I was able to run ERBSCAN by editing the REXX, commenting out statements > like SETMSG MSG(ISRZ001) and VIEW/BROWSE DATAID, substituting instead an > LMCOPY to an output data set. This ran just fine invoked via an ISPSTART > in an IKJEFT1B batch job which also allocated the output data set. > > 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
