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:[email protected]] On Behalf Of Charles Mills Sent: Wednesday, March 07, 2012 1:08 PM To: [email protected] 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:[email protected]] On Behalf Of Ed Mackmahon Sent: Wednesday, March 07, 2012 12:47 PM To: [email protected] 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 [email protected] with the message: INFO IBM-MAIN
