Brian Westerman wrote: >The don't have CICS, that would have made this almost easy.
Yes. >z/OS, Adabas, Com-Plete on the mainframe, the open system server >is Windows Server 2018, the application is looking for the "next" >available date to schedule their task, but the "owner" of that >schedule is on the mainframe. The "old" application would jsut >go to Adabas, grab the next available empty schedule slot, and >mark it used. The "new" application still needs to get that >schedule "slot" from the mainframe, but does everything else on >it's own. So they need to ask the mainframe to run a task that >will go to Adabas, get the next avaiable slot, mark it used, and >pass it back to the Windows server. OK. In the IBM product portfolio, z/OS Connect Enterprise Edition or, if direct to ADABAS, Data Virtualization Manager for z/OS would likely be the preferred, elegant approaches. However, if you want to cobble something together without too much effort as a "one off," and with something your customer already has licensed, I would look at the z/OS Management Facility and its REST interface for jobs. Details are available here (z/OS 2.3 information): https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.izua700/IZUHPINFO_API_RESTJOBS.htm The Windows Server would submit a z/OS job using this REST interface, and that z/OS job would then execute whatever program logic and ADABAS database update(s) are required, then return the result (the schedule slot). Probably what you'd do is use the z/OSMF REST interface to submit a job (and have the client check to make sure the HTTP return code is one of the return codes that indicates z/OS received the request), then use the z/OS Client Web Enablement Toolkit so that z/OS can return the result to the Windows Server (and can invoke a REST interface on the Windows Server available for that purpose). I've seen people suggest FTP and ssh paths, and they involve the same basic principle (submit a job, get a result), but I think those paths are less future proof and would involve some more work for error handling. I also have greater security concerns with those paths and think the necessary work to make these REST interfaces secure would be less onerous. Sockets are rather hard. There are hacky ways for z/OS to take action after another system places a file on a network drive (NFS) shared between that system and z/OS, but I don't like idea at least in this case. The Windows Server could have a 3270 emulator installed, such as IBM Personal Communications, which runs a macro that then makes its request and receives its response over an encrypted TN3270E connection to the "normal" 3270 application for getting a schedule slot. That's not my favorite path either. Another possible approach is to use Software AG's HTTP Server that's embedded in its Com-plete transaction processor. It's pretty basic, but it does support CGI. (I suspect Software AG was inspired by CICS Web Support.) I don't think Com-plete's HTTP Server supports HTTPS on its own, but fortunately you can (and should) use z/OS's AT-TLS to solve that problem. Here's some information on how you would set up AT-TLS with CICS Transaction Server if CICS is using HTTP (not HTTPS): https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.5.0/security/web/dfht3_attls.html The AT-TLS setup with Com-plete's HTTP Server should be quite similar. Alternatively, you could set up an IPSec tunnel between the Windows machine and z/OS. One problem with a Com-plete-based approach is that it won't work for your other customers that don't have Com-plete. It also wasn't inherently designed for application-to-application integration (as REST interfaces are), although it can be used that way in a pinch. I would think about how to avoid "double booking" and other such issues. Do they need transaction scope across both systems? -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, 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
