Re: Interfacing with the MainFrame
Hi all. Many thanks for your answers (At least the ones that were trying to help) I am fully capable to develop and implement any solution I'll choose So scott if you don't mind I'll keep my bucks (-: , just want'ed to sense an interface direction from a few shops -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
In 5664523867703651.wa.dropipopigmail@bama.ua.edu, on 03/07/2012 at 02:47 PM, Ed Mackmahon dropip...@gmail.com said: How would you prefer a product running on a server outside the mainframe will interface with the mainframe? That would depend on what it was interfacing with. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Chris, Dude I am in agreement here ...obviously somebody wants a freebie. Describe what you want Ed. We could design it , just come up with the necessary specs and bucks .. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 5:44 PM, Chris Craddock crashlu...@gmail.com wrote: So basically, you're planning to create a product and you want us to describe how to do it? Sent from my iPad On Mar 7, 2012, at 3:51 PM, Ed Mackmahon dropip...@gmail.com wrote: Many thanks for your answers. Let me provide some more information I intend that the interface will logon to the mainframe and issue some operator commands, read some members etc... gather information and send it to the open systems server for further analysis. The user which will be used for logon to the mainframe will have specific RACF/TSS/CA1 display only authorities and the server is on the organization intranet not an out side server. Having that, I am still looking for the preferred way for interfacing in a way that most organization will have no problem to authorize and using most common services available on most organizations (don't want to impose implementing other services as a preq) - that was the reason I was thinking on FTP and Rexx server... Any other comments / Ideas ? Thanks Ed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
zMan, Yep sure do Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 5:36 PM, zMan zedgarhoo...@gmail.com wrote: On Wed, Mar 7, 2012 at 5:31 PM, Scott Ford scott_j_f...@yahoo.com wrote: That would be another way, httpd on z/os , have a cgi do the work, tats. Good one Ed. Scott, Web services doesn't mean httpd+cgi, it means SOA (WSDL, etc.). Which has already been suggested. Whatever you do, you want to use SSL or equivalent. FTP is dead in the water. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Ed Just in case there could be something in the MQ concept for you, first try this redpaper (1999): http://www.redbooks.ibm.com/abstracts/redp0021.html and then, if appealing, look around the redbook site for current implementations: http://www.redbooks.ibm.com/ Chris Mason On Wed, 7 Mar 2012 15:51:21 -0600, Ed Mackmahon dropip...@gmail.com wrote: Many thanks for your answers. Let me provide some more information I intend that the interface will logon to the mainframe and issue some operator commands, read some members etc... gather information and send it to the open systems server for further analysis. The user which will be used for logon to the mainframe will have specific RACF/TSS/CA1 display only authorities and the server is on the organization intranet not an out side server. Having that, I am still looking for the preferred way for interfacing in a way that most organization will have no problem to authorize and using most common services available on most organizations (don't want to impose implementing other services as a preq) - that was the reason I was thinking on FTP and Rexx server... Any other comments / Ideas ? Thanks Ed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
In 4274496589392669.wa.dropipopigmail@bama.ua.edu, on 03/07/2012 at 03:51 PM, Ed Mackmahon dropip...@gmail.com said: I intend that the interface will logon to the mainframe and issue some operator commands, If you really mean *operator* commands, that conflicts with The user which will be used for logon to the mainframe will have specific RACF/TSS/CA1 display only authorities You need more than that to issue operator commands. What commands do you need to issue and why? Having that, I am still looking for the preferred way for interfacing in a way that most organization will have no problem to authorize If you need to run your own code on the mainframe, why bother with FTP at all? Why not let a single address space do all the work, communicating to the other server with TCP, or SCTP if you need to get fancy? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Interfacing with the MainFrame
Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? Any other ideas would be appreciated... Thanks Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
On Wed, Mar 7, 2012 at 12:47 PM, Ed Mackmahon dropip...@gmail.com wrote: Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? Hi Ed - You have suggested several different solution. However, the problem being solved has not been stated. That makes it very difficult to provide any useful feedback. Can you please state (at a high-level) what you are trying to accomplish? thanks, Sam Any other ideas would be appreciated... Thanks Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Ed, I would use a Service Oriented Architecture approach. Glenn -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 3:47 PM To: IBM-MAIN@bama.ua.edu Subject: Interfacing with the MainFrame Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? Any other ideas would be appreciated... Thanks Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. By replying to this e-mail, you consent to SunTrust's monitoring activities of all communication that occurs on SunTrust's systems. SunTrust is a federally registered service mark of SunTrust Banks, Inc. Live Solid. Bank Solid. is a service mark of SunTrust Banks, Inc. [ST:XCL] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
I have a lot of experience designing commercially successful products that ran with one foot on the mainframe and one foot on a little white box. Can you say (without divulging that which you are not willing to divulge) what in broad strokes the product is going to accomplish? Your 1. is a technique that was common in the early days of PC-mainframe integration. http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping . I think screen scraping has kind of fallen into disrepute. Your 2. sounds like a solution to a different problem than 1. Using FTP with no exits you can build JCL and data files, submit the JCL as a mainframe job, wait for it to complete, and bring back both the system messages and the output files. If that does the job for you, it's a lot of work getting it perfect but it's a very valid technique. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 12:47 PM To: IBM-MAIN@bama.ua.edu Subject: Interfacing with the MainFrame Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? Any other ideas would be appreciated... Thanks Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Interfacing with the MainFrame
Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? Any other ideas would be appreciated... Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
I should add that some (many?) shops ban FTP onto the mainframe, so that may be a problem with 2. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Charles Mills Sent: Wednesday, March 07, 2012 1:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interfacing with the MainFrame I have a lot of experience designing commercially successful products that ran with one foot on the mainframe and one foot on a little white box. Can you say (without divulging that which you are not willing to divulge) what in broad strokes the product is going to accomplish? Your 1. is a technique that was common in the early days of PC-mainframe integration. http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping . I think screen scraping has kind of fallen into disrepute. Your 2. sounds like a solution to a different problem than 1. Using FTP with no exits you can build JCL and data files, submit the JCL as a mainframe job, wait for it to complete, and bring back both the system messages and the output files. If that does the job for you, it's a lot of work getting it perfect but it's a very valid technique. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 12:47 PM To: IBM-MAIN@bama.ua.edu Subject: Interfacing with the MainFrame Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
I want to echo what evened said ..what are you trying to do ? What kind of application are you talking to ? Network type ? Security type ? Firewalls ? Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 3:47 PM, Ed Mackmahon dropip...@gmail.com wrote: Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? Any other ideas would be appreciated... Thanks Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
'Screen scrapers' are a bad idea. BTDT. Using the credentials of the requestor is a good idea. FTP or some such can be too slow to be tolerable. I'd suggest a client that crafted a, say, CICS transaction using the user's credentials then format/display the result. However, you may be describing a server based application that fetches data from the MF and presents it to the user. These are usually bad ideas as they are wonderful attack vectors. It's usually better to use a host based transaction processor. But, too many variables and we don't know your business problem to be addressed. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 2:47 PM To: IBM-MAIN@bama.ua.edu Subject: Interfacing with the MainFrame Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? Any other ideas would be appreciated... Thanks Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Greetings from the CABAL. Have you considered using UNIX services? I don't know all that you want your product to do. But to communicate with the mainframe, you can use SSH to send a UNIX command to z/OS and receive the response back. This is basically simple line mode functionality. To me, this is rather easy to implement if the white box is running UNIX or Linux or MAC OS/X. It is more difficult with Windows because, IMO, Windows does not play nice with others. Or you could just have a server running on the mainframe which uses TCPIP to receive commands and return replies to your code. The format of these commands and replies would be the protocol you designed for your supplied server. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 3:11 PM To: IBM-MAIN@bama.ua.edu Subject: Interfacing with the MainFrame Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? Any other ideas would be appreciated... Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Many thanks for your answers. Let me provide some more information I intend that the interface will logon to the mainframe and issue some operator commands, read some members etc... gather information and send it to the open systems server for further analysis. The user which will be used for logon to the mainframe will have specific RACF/TSS/CA1 display only authorities and the server is on the organization intranet not an out side server. Having that, I am still looking for the preferred way for interfacing in a way that most organization will have no problem to authorize and using most common services available on most organizations (don't want to impose implementing other services as a preq) - that was the reason I was thinking on FTP and Rexx server... Any other comments / Ideas ? Thanks Ed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
If I recall using SSH on the USS impose on the client to implement IBM ported tools which not all clients do... would it be a fare preq ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Hi Hal. Thanks for your comments... I will use the FTP just for lets say putting the Rexx in an AXR eligable dataset and using the exit make it run, gather information into a dataset and do an FTP get... something like that The volume of the data is not big so I suppose performance won't become an issue... What do you think? Any ideas / comments would be appreciated. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Ugh Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 5:01 PM, Ed Mackmahon dropip...@gmail.com wrote: Hi Hal. Thanks for your comments... I will use the FTP just for lets say putting the Rexx in an AXR eligable dataset and using the exit make it run, gather information into a dataset and do an FTP get... something like that The volume of the data is not big so I suppose performance won't become an issue... What do you think? Any ideas / comments would be appreciated. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Ah. Good point. I implement everything that I can get my hands on and is free (as in beer). SSH is likely not as prevalent in z/OS UNIX as I'm used to in the UNIX world, in general. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 3:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interfacing with the MainFrame If I recall using SSH on the USS impose on the client to implement IBM ported tools which not all clients do... would it be a fare preq ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Ed, I design this stuff professionally, you need more than just an outside program..you need various authorizations on the security subsystem, incoming firewallthat's just for starters, to operator commands with running a batch process requires authorization Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 4:50 PM, McKown, John john.mck...@healthmarkets.com wrote: Greetings from the CABAL. Have you considered using UNIX services? I don't know all that you want your product to do. But to communicate with the mainframe, you can use SSH to send a UNIX command to z/OS and receive the response back. This is basically simple line mode functionality. To me, this is rather easy to implement if the white box is running UNIX or Linux or MAC OS/X. It is more difficult with Windows because, IMO, Windows does not play nice with others. Or you could just have a server running on the mainframe which uses TCPIP to receive commands and return replies to your code. The format of these commands and replies would be the protocol you designed for your supplied server. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 3:11 PM To: IBM-MAIN@bama.ua.edu Subject: Interfacing with the MainFrame Hi How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Some Ideas i had: 1. Using a macro emulator that simulate a user which logon as a regular user, snap shot the screen display and parse the results on the open. 2. Using FTP exits in order to submit a job / moving a rexx to be ran under AXR etc... will this be a problem in your organization? Any other ideas would be appreciated... Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
I like free beer...I though SSH was part of z/os if not racfcert... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 5:04 PM, McKown, John john.mck...@healthmarkets.com wrote: Ah. Good point. I implement everything that I can get my hands on and is free (as in beer). SSH is likely not as prevalent in z/OS UNIX as I'm used to in the UNIX world, in general. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 3:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interfacing with the MainFrame If I recall using SSH on the USS impose on the client to implement IBM ported tools which not all clients do... would it be a fare preq ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
OpenSSH is a separately orderable and installable feature from z/OS base. I.e. you can order it from ShopzSeries in the same order as your z/OS order and install it during the z/OS installation. There appear to be five Ported Tools packages altogether. I guess that's why I consider it to be part of the base. Like SDSF, DFSMSdss, and DFSMShsm, all of which I also order in the z/OS order. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Wednesday, March 07, 2012 4:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interfacing with the MainFrame I like free beer...I though SSH was part of z/os if not racfcert... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 5:04 PM, McKown, John john.mck...@healthmarkets.com wrote: Ah. Good point. I implement everything that I can get my hands on and is free (as in beer). SSH is likely not as prevalent in z/OS UNIX as I'm used to in the UNIX world, in general. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 3:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interfacing with the MainFrame If I recall using SSH on the USS impose on the client to implement IBM ported tools which not all clients do... would it be a fare preq ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Hi. I supposed that if an organization have FTP implemented getting the standard FTP authorizations such as FW, NETACCESS, PORTACCESS, STACKACCESS etc... The only unique user profile would be display commends (another option is to use surrogate and run with different user..) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
On 3/7/2012 12:47 PM, Ed Mackmahon wrote: How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Web services? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
You might also consider using Co:Z SFTP along with Ported Tools OpenSSH, since only z/OS Unix files are supported in the the SFTP that comes with Ported Tools OpenSSH. http://dovetail.com/products/sftp.html Co:Z SFTP is free to download and use; commercial license and support contracts are also available. with Co:Z SFTP, your remote SSH/SFTP client could: - upload and download z/OS datasets or Unix files - submit jobs - get job output - everything would be secure and encrypted on a single SSH socket (no firewall hassles like FTP) Any SSH/SFTP client would work, including OpenSSH, a Java SSH/SFTP client, etc Regards, Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Mar 7, 2012 at 4:20 PM, McKown, John john.mck...@healthmarkets.comwrote: OpenSSH is a separately orderable and installable feature from z/OS base. I.e. you can order it from ShopzSeries in the same order as your z/OS order and install it during the z/OS installation. There appear to be five Ported Tools packages altogether. I guess that's why I consider it to be part of the base. Like SDSF, DFSMSdss, and DFSMShsm, all of which I also order in the z/OS order. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Wednesday, March 07, 2012 4:08 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interfacing with the MainFrame I like free beer...I though SSH was part of z/os if not racfcert... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 5:04 PM, McKown, John john.mck...@healthmarkets.com wrote: Ah. Good point. I implement everything that I can get my hands on and is free (as in beer). SSH is likely not as prevalent in z/OS UNIX as I'm used to in the UNIX world, in general. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 3:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interfacing with the MainFrame If I recall using SSH on the USS impose on the client to implement IBM ported tools which not all clients do... would it be a fare preq ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
That would be another way, httpd on z/os , have a cgi do the work, tats. Good one Ed. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 5:28 PM, Edward Jaffe edja...@phoenixsoftware.com wrote: On 3/7/2012 12:47 PM, Ed Mackmahon wrote: How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Web services? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Btdt on screen scraping, extremely ugly and of course inflexible..a better way being an application API of some sort .. Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 7, 2012, at 5:24 PM, Ed Mackmahon dropip...@gmail.com wrote: Hi. I supposed that if an organization have FTP implemented getting the standard FTP authorizations such as FW, NETACCESS, PORTACCESS, STACKACCESS etc... The only unique user profile would be display commends (another option is to use surrogate and run with different user..) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
On Wed, Mar 7, 2012 at 5:31 PM, Scott Ford scott_j_f...@yahoo.com wrote: That would be another way, httpd on z/os , have a cgi do the work, tats. Good one Ed. Scott, Web services doesn't mean httpd+cgi, it means SOA (WSDL, etc.). Which has already been suggested. Whatever you do, you want to use SSL or equivalent. FTP is dead in the water. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
On Wed, Mar 7, 2012 at 4:28 PM, Edward Jaffe edja...@phoenixsoftware.comwrote: On 3/7/2012 12:47 PM, Ed Mackmahon wrote: How would you prefer a product running on a server outside the mainframe will interface with the mainframe? Web services? You might look at IBM's z/OS Jobs REST Interface This new web services API is shipped as part of z/OS MF, and oddly is documented in the z/OS MF Configuration Guide (SA38-0652-06) == The z/OS jobs REST interface is an application programming interface (API) implemented through industry standard Representational State Transfer (REST) services. This interface allows a client application to perform operations with batch jobs on a z/OS system. With the z/OS jobs REST interface, an application can use REST services to perform the following operations with batch jobs: v Obtain the status of a job v List the jobs for an owner, prefix, or job ID v List the spool files for a job v Retrieve the contents of a job spool file v Submit a job to run on z/OS v Cancel a job v Change the job class of a job v Cancel a job and purge its output. = Kirk Wolf Dovetailed Technologies http://dovetail.com +1 636.300.0901 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
Hi. Thanks for your comments. Can you elaborate on the requirement on client side for using Web services? - Does in involve CICS / IMS DC? - Can you impement WEB service under AXR ? - Does the CICS should interface with TCP ? is this more eligible then FTP? - How would the Web Service can gather information such as operator output commands? - Is this common practice for most organizations ? for your organization ? Thanks again Ed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
So basically, you're planning to create a product and you want us to describe how to do it? Sent from my iPad On Mar 7, 2012, at 3:51 PM, Ed Mackmahon dropip...@gmail.com wrote: Many thanks for your answers. Let me provide some more information I intend that the interface will logon to the mainframe and issue some operator commands, read some members etc... gather information and send it to the open systems server for further analysis. The user which will be used for logon to the mainframe will have specific RACF/TSS/CA1 display only authorities and the server is on the organization intranet not an out side server. Having that, I am still looking for the preferred way for interfacing in a way that most organization will have no problem to authorize and using most common services available on most organizations (don't want to impose implementing other services as a preq) - that was the reason I was thinking on FTP and Rexx server... Any other comments / Ideas ? Thanks Ed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
On that note, I'd suggest Web 2.0 and Cloud Computing. You can always set things up in WebSphere(apache even, perhaps?) with CGI and use AJAX to pass messages, should be client independent even. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Craddock Sent: Wednesday, March 07, 2012 4:45 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interfacing with the MainFrame So basically, you're planning to create a product and you want us to describe how to do it? Sent from my iPad On Mar 7, 2012, at 3:51 PM, Ed Mackmahon dropip...@gmail.com wrote: Many thanks for your answers. Let me provide some more information I intend that the interface will logon to the mainframe and issue some operator commands, read some members etc... gather information and send it to the open systems server for further analysis. The user which will be used for logon to the mainframe will have specific RACF/TSS/CA1 display only authorities and the server is on the organization intranet not an out side server. Having that, I am still looking for the preferred way for interfacing in a way that most organization will have no problem to authorize and using most common services available on most organizations (don't want to impose implementing other services as a preq) - that was the reason I was thinking on FTP and Rexx server... Any other comments / Ideas ? Thanks Ed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
**IF** you FTP ensure you can use TLS. We disallow any non TLS FTP sessions Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 2:01 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Interfacing with the MainFrame Hi Hal. Thanks for your comments... I will use the FTP just for lets say putting the Rexx in an AXR eligable dataset and using the exit make it run, gather information into a dataset and do an FTP get... something like that The volume of the data is not big so I suppose performance won't become an issue... What do you think? Any ideas / comments would be appreciated. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
On Wed, 7 Mar 2012 17:36:39 -0500, zMan wrote: Whatever you do, you want to use SSL or equivalent. FTP is dead in the water. Have you discussed this with the developers of, e.g., the SMP/E RECEIVE FROMNETWORK command? I'm waiting breathlessly for the next release. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
On 7 March 2012 16:51, Ed Mackmahon dropip...@gmail.com wrote:
Many thanks for your answers.
Let me provide some more information
I intend that the interface will logon to the mainframe and issue some
operator commands, read some members etc... gather information and
send it to the open systems server for further analysis.
In passing, is this server more open than the mainframe?
The user which will be used for logon to the mainframe will have specific
RACF/TSS/CA1
display only authorities and the server is on the organization intranet not
an out side server.
Having that, I am still looking for the preferred way for interfacing in a way
that most organization will have no problem to authorize and using most
common services
available on most organizations (don't want to impose implementing other
services as a preq)
- that was the reason I was thinking on FTP and Rexx server...
Any other comments / Ideas ?
Sigh. This is a question we've encountered many times under various
circumstances, and the results have never been good.
In the worst case (1), it's at a customer site, where the sysprogs and
their management are in a snit because they have been [asked|told] to
install a userid with SPECIAL or uid(0) or root for the use of some
vendor product that they had never heard of until the request/demand
came in, usually already purchased by another part of the organization
reporting to a different VP.
In a variation (2) perhaps more like today's, we are asked for advice
on how to log into the mainframe and, you know do some commands to
collect information and list users and stuff. This request has
arrived from every kind of place from surprisingly well known huge
software vendors to one-man-show consultants, and everyone in between.
Usually our first response is to ask *What* on the mainframe is it
that you want to log on to?, and it usually goes down hill from
there, passing through variations on telnet, dumb ASCII, 3270?,
shell prompt, there are different operating systems on the
mainframe?, and a few other things on the way.
This all said, I don't want to [mis]caricature your questions or
knowledge, and it is good that you seem closer to category (2) than
(1), but you should be aware that the approach is likely to lead to an
unhappy situation. I trust that you will not take offence at what I
have to say.
Generally these questions arise when a vendor with no z/OS experience
wants to integrate the mainframe into their existing or proposed
product. From their point of view, and the customer organizations
they've sold to, installing any kind of software on the mainframe is a
huge barrier, both because it requires cooperation from a customer IT
division they'd rather not be involved with, and because the vendor
has no idea how to write such agent software in the first place. Hence
agentless, you don't have to install anything at all on the
{evil|complicated|legacy|etc.} mainframe. We just log on on remotely
and do what we need..
You should be aware that an agentless approach is not likely to be a
selling point at all to the z/OS maintainers.
Questions likely to be raised by your customers' z/OS sysprogs and
security people when faced by the request for an ID that will be
logging on include: What z/OS application do you want to log on to?
TSO? CICS? UNIX? Something else? Multiple apps? Do you need to log on
to a particular system image, or can we load balance? Exactly what
privileges do you require, and why? Please document your use of each
required privilege in detail, and list all commands you intend to
issue. Are these commands hard coded, or can they be changed/scripted
based on configuration from the non-z/OS platform? How will access to
these commands and their results be controlled on that non z/OS
platform? Will you be making logs available to us from that platform?
Do you have Audit approval for implementation of this product? How
will transmission of sensitive information be protected on the wire?
What is the intended volume of data in each direction, and if it is
significant, how will flow control be managed? Will these commands be
issued at particular times of day? Etc. Etc. Etc.
If they are sufficiently interested, they may point out that screen
scraping is not a defined interface to anything (no matter which
platform it is performed on), and that the layout of various command
output can vary from one system to another, and over time. Certainly
they will not be interested in guaranteeing that the output stays the
same.
So... You mention (System) REXX and FTP, which suggests you know a
fair bit about z/OS (though I'm not sure where FTP exits would come
into play). Others have given you some very good approaches to look
at, and I suggest that you avoid like the plague any kind of remote
logon and scrape approach. Define a data stream of some sort
(preferably using an existing standard), install a small agent with
very well defined privileges, use defined z/OS interfaces
