Re: Multiple FTP Servers

[Statler, David]

Hi Roberto,

Yes, you can have multiple FTP servers running listening on different ports and 
only one TCP/IP stack.

We are doing this today. We have a unsecure FTP server (that we're actually 
trying to get rid of) and a FTPS server listening on different ports. 

Thanks, David


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Roberto Halais
Sent: Friday, September 4, 2020 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Multiple FTP Servers

Listers:

We are converting all our file transfer jobs from FTP to FTPS.
Our security people insist we do not use port 21 for our FTPS.
I see no way of adding another port to our current ftp server it listens on 
port 21.
Question:
Do I have to create another FTPD server listening on port 9921 (for example)?
Can I have more than one ftp server per tcp/ip stack one listening on port
21 and the other on port 9921?

I haven't encountered this before and Google hasn't helped.

Any ideas are welcome.

Roberto

--
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: setting up CSSMTP to use TLS-SSL

[Statler, David]

We have ours setup to use TLS from CSSMTP to an internal Proofpoint mail 
server. We have Secure set to Yes in the CSSMTP config and then use Policy 
Agent (AT-TLS) to handle the handshake.

David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian Westerman
Sent: Monday, August 31, 2020 11:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: setting up CSSMTP to use TLS-SSL

So does this all mean that (currently) no one on the list uses TLS-SSL to 
forward their mail from CSSMTP to the target mail server?

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

Re: Sending email from the Mainframe

[Statler, David]

You may be able to utilize the "Undeliverable" feature in the CSSSMTP Config 
setup. You can specify the action to take (store or delete) on a dead letter 
and a unix directory to store it in.

David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sasso, Len
Sent: Friday, August 28, 2020 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe and 
if it is unable to be delivered, for any reason, sends an email back to the 
Sender with a corresponding message?


Thank You and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: 
https://protect2.fireeye.com/v1/url?k=d6ec75ce-8aadedc4-d6eeb904-0cc47a6d17ce-a101fbc807c29bfb=1=755c3fc4-a8e5-4af5-b36f-63034689dc4b=http%3A%2F%2Fwww.gdit.com%2F





From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Friday, July 24, 2020 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Sending email from the Mainframe



 [External: Use caution with links & attachments]

Grant Taylor asks:
>What happens to email if CSSMTP (AT-TLS) is configured to *require* 
>encryption and the receiving system doesn't support encryption?

Fundamentally the same thing(s) that happen when the network connection is down 
or too slow (times out), for whatever reasons. Network encryption is part and 
parcel of the network path. This class of failures must already be catered for. 
In this case, Len Sasso's organization is mandating TLS 1.2+, and I agree with 
Shmuel Metz who wrote:
>If management has decreed that all SMTP traffic be encrypted, then 
>barring a configuration error the relay will accept encrypted traffic.

Moreover, it's entirely possible that your attitude would only increase relay 
administrators' burdens, the people who currently have to manage, support, 
monitor, and audit the e-mail traffic from the one and only system still 
transmitting over an unencrypted connection, a connection modality they'd very 
much like to retire as quickly as possible. You know, that "old, obsolete 
mainframe" that you're actively arguing should actually be as old and obsolete 
as you can possibly force it to be. (TLS is *really* not new.) Or it's entirely 
possible that the relay administrators aren't inclined or equipped to provide 
even mediocre service levels for unencrypted connections, or even that there's 
a lone dedicated relay gathering dust in a wiring closet somewhere to support 
this one unencrypted connection, a relay that nobody left in the organization 
even understands or really knows about, that isn't backed up or DR protected, 
that still runs on a 10 Mbps Ethernet segment that miraculously hasn't been 
disconnected yet. Hence the unencrypted connection is MORE prone to failure, 
not less. All very possible, even predictable and likely. And I haven't even 
gotten to the regulatory issues and penalties.

Conceivably you could also reduce or eliminate your personal security 
authentication failure planning and handling (hopefully automated) 
responsibilities if you effectively disable your SAF security provider, such as 
RACF. Then those few pesky authentication and authorization rejections wouldn't 
occur, and everyone could just go to the pub and stay there (or whatever). 
That's the logical consequence of your argument, isn't it? I don't think you've 
got a strong argument.

Sorry to be blunt here, but I feel compelled to offer my personal view (as 
always). My colleagues (and I mean that word expansively, in and out of
IBM) work really hard to deliver and support truly cutting edge capabilities, 
including downright amazing security capabilities, in/for this unique and 
indispensable platform. And this community, overall, often works really hard to 
put these capabilities into practice, in many cases literally to keep 
civilization functioning. Then there are a few people who manage a few of these 
systems, and...well, let's all strive to do better, OK?

[Why am I expecting a minor Twitter storm now? :-)]

- - - - - - - - - -
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: Pagent hangover

[Statler, David]

In your Pagent config, on the TcpImage statement, are you coding the FLUSH and 
PURGE options?

If so, when you recycle Pagent, it should then pick up the new settings.

You can also use the Modify Refresh command which should flush the old 
settings, so that you don't have to stop/start the started task.

David


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skippy the Ancient
Sent: Wednesday, August 5, 2020 2:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Pagent hangover

I'm working with Pagent, adding an FTPS started task and port.  (because the 
client said so)  It was getting some sort of TTLS rule error.
I saved the current ATTLS member off and pulled in the sample ATTLS from 
/usr/lpp/tcpip/samples/pagent_TTLS.conf.  I issued a refresh.  PASEARCH shows 
the changes have been picked up.

Or have they?
I turn debug logging on for my FTPS demon.  I see a handshake error, just as 
before.  In fact, the log shows it's using the old ATTLS values.   PASEARCH 
still shows the changes I expect.

OK.  Fine.  Drop all these started tasks; FTPD, FTPSD, PAGENT, SYSLOGD.
Start all.PASEARCH shows the new changes.

Debug still shows old rule values that aren't even in ATTLS member any more.

What am I doing wrong?

Thank you for your time,
Skippy the Ancient.  And puzzled.

--
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: Cl/Supersession

[Statler, David]

We also use CL/SuperSession.

Users connect to the system using a TN3270 client. Depending on their subnet, 
some users get the SuperSession logon screen when they connect, others get the 
VTAM MSG10 screen.  That is all controlled inside the telnet server of course.  
From the MSG10 screen, they just type in "S" to take them to the SuperSession 
logon screen.

When we first started using SuperSession, we did all of the user administration 
via the SuperSession panels (building the menus, etc.).  Now a user's menu list 
is built using RACF. Whatever applications they are permitted to in RACF will 
show up on their SuperSession menu screen.  Inside of SuperSession are config 
settings to tell it to use a special class you define in RACF for doing this.

We also use VTAM Application modeling in VTAMLST for building the virtual 
netnames.

David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Tuesday, June 2, 2020 8:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: FW: Cl/Supersession

I've come up to a couple silly questions

Would you send me a screen shot or your VTAMLST member for CLSS?
How are you having the users logging on to CLSS from the 10 Screen?
Have you had to add every user to CL/SuperSession?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edgington, Jerry
Sent: Monday, June 1, 2020 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cl/Supersession

For the TN3270 traffic into SuperSession?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Monday, June 1, 2020 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cl/Supersession

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


Are you using Secure Sockets?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Monday, June 1, 2020 2:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cl/Supersession

We have just installed at a customer site to replace Solvacc. What is your 
question?

On Tue, Jun 2, 2020, 05:10 Edgington, Jerry < 
jerry.edging...@westernsouthernlife.com> wrote:

> I wouldn't say I speak SuperSession, but I support it at one of my sites.
> So, I will try to help.
>
> Jerry
>

--
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: PCOMM printer session display is blank

[Statler, David]

Jake,

Once you start up the PCOMM printer session, you will see it Active in VTAM, 
but you won't see the ACT/S until it is in session with something (like getting 
Acquired in a CICS region).

We use a different emulator than PCOMM, so I can't really speak to how it's 
supposed to act.  If we start a PC attached printer session, the screen shows a 
basic "Printer ready for work" message.

David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jake Anderson
Sent: Saturday, September 21, 2019 11:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PCOMM printer session display is blank

Hi,

Cross posted.


This is regarding PCOM 5.7.

I have configured the PCOM for a printer session with Telnet 3270. When I see 
printer LU, I see it as active but not with ACT/S.

What I am expecting here is when I configure and connect PRINTER session in 
PCOMM, long time back I remember we used to receive a printers session display 
on PCOMM screen showing what is connected. For me it just shows blank but at 
the bottom it says connected.

Is there any driver files that might be missing to show up the desired printer 
display screen in PCOMM ?

Could someone please provide your direction on where I might be looking in ?

Jake

--
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: SFTP Special Charcters

[Statler, David]

My terminal emulator was using a setting called "Default Code Page".  I went 
and changed it to "1047 USA, Canada" and now the character is displaying 
correctly!

Thank you very much!!
David


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, September 19, 2019 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SFTP Special Charcters

On Thu, 19 Sep 2019 14:07:40 -0500, Mike Schwab wrote:

>If the hex value seems correct, then try the target software.  Your 
>viewing product (ISPF?) may be using a different code page.
>
More likely the terminal.  What does your terminal (emulator) say for the host 
code page (readily configurable, at least with x3270.) This should match the 
MBDATACONN value.

I have found ISPF to be quite alert and friendly to terminal code pages, even 
Viewing a UTF-8 file with a Cyrillic x3270 and a UTF-8 desktop.  There's an 
ISPF function to show the terminal code page.

(I hate EBCDIC!)

>On Thu, Sep 19, 2019 at 1:46 PM Statler, David wrote:
>>
>> In the mainframe's FTP server settings (in FTP.DATA), you can set what your 
>> "default" will be with the SBDATACONN (or MBDATACONN) parm.
>>
>> In my case I have SBDATACONN(IBM-1047,IBM-850) coded.
>>
>> I was trying to FTP from Windows a file that contains the character " é " to 
>> the mainframe.  When looking at the transferred file on the mainframe, it 
>> looked like it was trying to use a multibyte character.
>>
>> Per IBM's instructions, they had me issue the following in my Windows FTP 
>> client:
>>
>> quote site encoding=mbcs
>> quote site mbdataconn=(IBM-1047,UTF-8)
>>
>> Now looking at the mainframe file, the hex it shows looks correct (x51), but 
>> the displayed character is still wrong. It shows an underlined capital "J" 
>> character.

-- 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: SFTP Special Charcters

[Statler, David]

In the mainframe's FTP server settings (in FTP.DATA), you can set what your 
"default" will be with the SBDATACONN (or MBDATACONN) parm.

In my case I have SBDATACONN(IBM-1047,IBM-850) coded.

I was trying to FTP from Windows a file that contains the character " é " to 
the mainframe.  When looking at the transferred file on the mainframe, it 
looked like it was trying to use a multibyte character.

Per IBM's instructions, they had me issue the following in my Windows FTP 
client:

quote site encoding=mbcs
quote site mbdataconn=(IBM-1047,UTF-8)

Now looking at the mainframe file, the hex it shows looks correct (x51), but 
the displayed character is still wrong. It shows an underlined capital "J" 
character.

David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, September 19, 2019 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SFTP Special Charcters

On Thu, 19 Sep 2019 13:21:43 -0500, Mike Schwab wrote:

>Different IBM MVS software packages used different characters sets.
>APL and C files are usually the ones that require a different 
>translation.  IBM MVS printers often used two different code pages too.
> 
What ways are there to find which code page you're using?

o UNIX "locale" command?

o Terminal emulator settings?

o  Software package documentation?

o Other (specify)?

>> quote site sbdataconn=(IBM-1047,ISO8859-1)
>>

Possibly:
   quote site ENCODING MBCS
   quote site mbdataconn=(IBM-,UTF-8)
   quote site mbdataconn=(IBM-,IBM-1208) (or, pre-filter with iconv and 
transfer in binary.)

-- 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: SFTP Special Charcters

[Statler, David]

I'm dealing with the exact same thing (except going from Windows to Mainframe).

In your FTP client, you should be able to have it issue the following command:

quote site sbdataconn=(IBM-1047,ISO8859-1)

Which should help in the translation, but it's not working for me.  I've got an 
open case with IBM right now in trying to get it figured out.

David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ron 
Thomas
Sent: Thursday, September 19, 2019 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SFTP Special Charcters

Hello

we are doing a SFTP from Mainframe to Windows machine (EBCDIC to ASCII) using 
reflection FTP client  and we are seeing some special characters in the file is 
getting translated  to others . For e.g Á (x'65') to 'Ý' x'AD'

Is there a way we can keep this data ASIS during the ftp ? if so how this can 
be done ?

Regards
Ron T

--
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: CA-1 migration to RMM

[Statler, David]

Try this:

http://www.redbooks.ibm.com/abstracts/sg246241.html

David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Nai, Dean
Sent: Wednesday, September 18, 2019 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CA-1 migration to RMM

We are planning on migrating from CA-1 to RMM. Does anyone know where there 
might be some good documentation, maybe a Redbook, or some scripts to help with 
the migration. Thanks in advance. 

Dean Nai




>

--
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: SSL FTP....

[Statler, David]

After issuing the userid and password to log in to the remote server, issuethe 
locsite command of Firewall Friendly:

LOCSITE FWF

Hope that helps!
David Statler


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian France
Sent: Thursday, June 27, 2019 1:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SSL FTP

Trying to establish a SSL FTP over port 990 with a winders servers. Have done 
this in the past with no issues but now it seems with a newer version of 
winders maybe combined with FW rules I can't obtain a data channel. Connection 
over port 990, cert navigation, passing of userid and password even issuing a 
cd command all work fine. BUT when I try to list the directory or do data 
transfer I don't get the data channel due I believe how they've secured it. I 
thought I found the answer in PASSIVEDATAPORTS setting and tried it only to see 
it not work and then I came to understand it's a z/OS ftp server option only. 
Can't seem to find one for the client. Anyone got any ide'ers they can share?

--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC Rm 25 Shields 
Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

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