Discussion:
TSO PREFIX, FTP and z/OS upgrade
(too old to reply)
Frank Swarbrick
2018-06-12 21:51:31 UTC
Permalink
Since I got such a good response to my last issue, I figure I'd try another one. This one has already been resolved, but we're still puzzled as to why it happened.

After our upgrade to z/OS 2.3 we had some "client initiated" FTP processes fail. These processes log on to our z/OS system with a user ID that we've reserved for this particular usage. In order to not require the distributed guys to understand MVS data set naming conventions we implemented this user ID with "TSO PROFILE PREFIX(PROD)". So when they upload a file with something like:
put myfile.txt RXMTIN.APPL.MYFILE
it is uploaded to data set 'PROD.RXMTIN.APPL.MYFILE'.

This all worked fine through several z/OS upgrades over the last few years. With the upgrade to z/OS 2.3 it no longer worked. The FTP server apparently reverted to using the actual user ID as the HLQ, and thus the above attempted to upload to 'OPSFTP.RXMTIN.APPL.MYFILE' (the user ID is OPSFTP). This failed because that user has access to write to an existing file, but no rights to create a file.

Anyway, very long story short, we ended up logging on to TSO with this user, doing TSO PROFILE to show that PREFIX(PROD) was still set, and then logging off of TSO. Once this was done things were back to normal. This happened with two user IDs, and the solution was the same for both.

The question is, why did we have to do this, where apparently we never had to do it before? Another possibility (unlikely, IMO) is the person who did the previous upgrades (no longer with the company) knew to do this, and the current person did not.

Did something change with z/OS 2.3? Is there a better way around this? As I said, these user ID's are supposed to be for FTP only, and other than for setting the profile prefix they are never used to log on to TSO.

There is some documentation regarding setting the profile prefix initially that says "At this point, the TSO prefix is defined for your current TSO session but is not known to RACF or the FTP server until you log off and log on." But this is not a new setting for the user, but is only an OS upgrade, and I see nothing that says this process must be done in that case.

Thanks,
Frank

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2018-06-12 22:19:52 UTC
Permalink
This might be OA55019 .

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick
Sent: Tuesday, June 12, 2018 2:51 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):TSO PREFIX, FTP and z/OS upgrade

Since I got such a good response to my last issue, I figure I'd try another one. This one has already been resolved, but we're still puzzled as to why it happened.

After our upgrade to z/OS 2.3 we had some "client initiated" FTP processes fail. These processes log on to our z/OS system with a user ID that we've reserved for this particular usage. In order to not require the distributed guys to understand MVS data set naming conventions we implemented this user ID with "TSO PROFILE PREFIX(PROD)". So when they upload a file with something like:
put myfile.txt RXMTIN.APPL.MYFILE
it is uploaded to data set 'PROD.RXMTIN.APPL.MYFILE'.

This all worked fine through several z/OS upgrades over the last few years. With the upgrade to z/OS 2.3 it no longer worked. The FTP server apparently reverted to using the actual user ID as the HLQ, and thus the above attempted to upload to 'OPSFTP.RXMTIN.APPL.MYFILE' (the user ID is OPSFTP). This failed because that user has access to write to an existing file, but no rights to create a file.

Anyway, very long story short, we ended up logging on to TSO with this user, doing TSO PROFILE to show that PREFIX(PROD) was still set, and then logging off of TSO. Once this was done things were back to normal. This happened with two user IDs, and the solution was the same for both.

The question is, why did we have to do this, where apparently we never had to do it before? Another possibility (unlikely, IMO) is the person who did the previous upgrades (no longer with the company) knew to do this, and the current person did not.

Did something change with z/OS 2.3? Is there a better way around this? As I said, these user ID's are supposed to be for FTP only, and other than for setting the profile prefix they are never used to log on to TSO.

There is some documentation regarding setting the profile prefix initially that says "At this point, the TSO prefix is defined for your current TSO session but is not known to RACF or the FTP server until you log off and log on." But this is not a new setting for the user, but is only an OS upgrade, and I see nothing that says this process must be done in that case.

Thanks,
Frank


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-06-13 18:27:11 UTC
Permalink
Could this be the result of the support for the "long" (going from 7 to 8 characters was a severe case of tunnel vision) TSO prefix?


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Frank Swarbrick <***@OUTLOOK.COM>
Sent: Tuesday, June 12, 2018 5:51 PM
To: IBM-***@listserv.ua.edu
Subject: TSO PREFIX, FTP and z/OS upgrade

Since I got such a good response to my last issue, I figure I'd try another one. This one has already been resolved, but we're still puzzled as to why it happened.

After our upgrade to z/OS 2.3 we had some "client initiated" FTP processes fail. These processes log on to our z/OS system with a user ID that we've reserved for this particular usage. In order to not require the distributed guys to understand MVS data set naming conventions we implemented this user ID with "TSO PROFILE PREFIX(PROD)". So when they upload a file with something like:
put myfile.txt RXMTIN.APPL.MYFILE
it is uploaded to data set 'PROD.RXMTIN.APPL.MYFILE'.

This all worked fine through several z/OS upgrades over the last few years. With the upgrade to z/OS 2.3 it no longer worked. The FTP server apparently reverted to using the actual user ID as the HLQ, and thus the above attempted to upload to 'OPSFTP.RXMTIN.APPL.MYFILE' (the user ID is OPSFTP). This failed because that user has access to write to an existing file, but no rights to create a file.

Anyway, very long story short, we ended up logging on to TSO with this user, doing TSO PROFILE to show that PREFIX(PROD) was still set, and then logging off of TSO. Once this was done things were back to normal. This happened with two user IDs, and the solution was the same for both.

The question is, why did we have to do this, where apparently we never had to do it before? Another possibility (unlikely, IMO) is the person who did the previous upgrades (no longer with the company) knew to do this, and the current person did not.

Did something change with z/OS 2.3? Is there a better way around this? As I said, these user ID's are supposed to be for FTP only, and other than for setting the profile prefix they are never used to log on to TSO.

There is some documentation regarding setting the profile prefix initially that says "At this point, the TSO prefix is defined for your current TSO session but is not known to RACF or the FTP server until you log off and log on." But this is not a new setting for the user, but is only an OS upgrade, and I see nothing that says this process must be done in that case.

Thanks,
Frank

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Frank Swarbrick
2018-06-13 18:37:01 UTC
Permalink
I couldn't say, but it seems like a reasonable possibility! I'm hoping our Systems group opens an SR for this, but figured I'd ask here as well.
________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Seymour J Metz <***@GMU.EDU>
Sent: Wednesday, June 13, 2018 12:27 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: TSO PREFIX, FTP and z/OS upgrade

Could this be the result of the support for the "long" (going from 7 to 8 characters was a severe case of tunnel vision) TSO prefix?


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Frank Swarbrick <***@OUTLOOK.COM>
Sent: Tuesday, June 12, 2018 5:51 PM
To: IBM-***@listserv.ua.edu
Subject: TSO PREFIX, FTP and z/OS upgrade

Since I got such a good response to my last issue, I figure I'd try another one. This one has already been resolved, but we're still puzzled as to why it happened.

After our upgrade to z/OS 2.3 we had some "client initiated" FTP processes fail. These processes log on to our z/OS system with a user ID that we've reserved for this particular usage. In order to not require the distributed guys to understand MVS data set naming conventions we implemented this user ID with "TSO PROFILE PREFIX(PROD)". So when they upload a file with something like:
put myfile.txt RXMTIN.APPL.MYFILE
it is uploaded to data set 'PROD.RXMTIN.APPL.MYFILE'.

This all worked fine through several z/OS upgrades over the last few years. With the upgrade to z/OS 2.3 it no longer worked. The FTP server apparently reverted to using the actual user ID as the HLQ, and thus the above attempted to upload to 'OPSFTP.RXMTIN.APPL.MYFILE' (the user ID is OPSFTP). This failed because that user has access to write to an existing file, but no rights to create a file.

Anyway, very long story short, we ended up logging on to TSO with this user, doing TSO PROFILE to show that PREFIX(PROD) was still set, and then logging off of TSO. Once this was done things were back to normal. This happened with two user IDs, and the solution was the same for both.

The question is, why did we have to do this, where apparently we never had to do it before? Another possibility (unlikely, IMO) is the person who did the previous upgrades (no longer with the company) knew to do this, and the current person did not.

Did something change with z/OS 2.3? Is there a better way around this? As I said, these user ID's are supposed to be for FTP only, and other than for setting the profile prefix they are never used to log on to TSO.

There is some documentation regarding setting the profile prefix initially that says "At this point, the TSO prefix is defined for your current TSO session but is not known to RACF or the FTP server until you log off and log on." But this is not a new setting for the user, but is only an OS upgrade, and I see nothing that says this process must be done in that case.

Thanks,
Frank

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

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

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