Re: Favorite Way(s) for COBOL as HTTP Client?
Under the restrictions and assumptions I mentioned, I now think cURL for z/OS is the best way to get the job done (via BPXBATCH probably). It looks very clean, simple, and exactly on point. I'm a big believer in the avoid needless coding principle, in homage to Strunk White. Thus cURL has a lot of appeal. (So do CICS TS and IMS if you've got them. There's a reason why transaction managers are so valuable.) cURL for z/OS also returns detailed error conditions if something fails, and it sports many security-related features, including encryption support. IBM will take PMRs on it, so it's supportable. If anyone still has other ideas, though, please feel free to volunteer them. Thanks everybody. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Favorite Way(s) for COBOL as HTTP Client?
Hi Timothy, use the TCP/IP socket API to connect to port 80 or whatever the HTTP server listenen and send the HTTP request and receive the data back. In case of XML use the Cobol XML parser to extract the data. Roland I got a question asking for recommendations on how to write a COBOL application (on z/OS) to act as an HTTP client. That is, the COBOL program makes an outbound HTTP request, provides some input data, and receives some data back. The data format is arbitrary -- could be XML, could be just simple strings. Further assumptions: there's only Enterprise COBOL (compiler) and base z/OS (including any standard and no charge features). Also, there are significant bonus points awarded for high service quality attributes (RAS, security, performance, etc.) It broke! is not adequate diagnostic information if something fails, like the network or authentication to the remote HTTP server. :-) The same method could be used with Enterprise PL/I programs without any material differences. Anyway, with those conditions, here's the list of options I came up with: 1. Java application written using standard java.net HTTP client logic and JZOS record conversion classes. Invoked as a JZOS job step. 2. Same as #1, but invoked via COBOL INVOKE. 3. CBT tape 556 (REXX HTTP client sample). 4. Via cURL for z/OS, part of the z/OS Ported Tools. Options #2 and #4 are currently my favorite (again, given these restrictions). Along the lines of #1 and #2 there are probably Perl and Python avenues as well. Anybody got any better (or at least different) ideas? Yes, I know this is rather easy in CICS Transaction Server (EXEC CICS WEB ...), for example. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Favorite Way(s) for COBOL as HTTP Client?
Hi Timothy, you could use a mix of 1 und 2 and code/embedd the Java statements in a mixed mode COBOL application. Enterprise COBOL compiler allows that without the need to create a java class file. For IMS as runtime you could use the ICAL DL/I call which allows synchronous outbound calls, it will be available very soon for IMS V10. Denis. -Original Message- From: Roland Schiradin [EMAIL PROTECTED] To: IBM-MAIN@BAMA.UA.EDU Sent: Thu, 23 Oct 2008 8:02 am Subject: Re: Favorite Way(s) for COBOL as HTTP Client? Hi Timothy, use the TCP/IP socket API to connect to port 80 or whatever the HTTP server listenen and send the HTTP request and receive the data back. In case of XML use the Cobol XML parser to extract the data. Roland I got a question asking for recommendations on how to write a COBOL application (on z/OS) to act as an HTTP client. That is, the COBOL program makes an outbound HTTP request, provides some input data, and receives some data back. The data format is arbitrary -- could be XML, could be just simple strings. Further assumptions: there's only Enterprise COBOL (compiler) and base z/OS (including any standard and no charge features). Also, there are significant bonus points awarded for high service quality attributes (RAS, security, performance, etc.) It broke! is not adequate diagnostic information if something fails, like the network or authentication to the remote HTTP server. :-) The same method could be used with Enterprise PL/I programs without any material differences. Anyway, with those conditions, here's the list of options I came up with: 1. Java application written using standard java.net HTTP client logic and JZOS record conversion classes. Invoked as a JZOS job step. 2. Same as #1, but invoked via COBOL INVOKE. 3. CBT tape 556 (REXX HTTP client sample). 4. Via cURL for z/OS, part of the z/OS Ported Tools. Options #2 and #4 are currently my favorite (again, given these restrictions). Along the lines of #1 and #2 there are probably Perl and Python avenues as well. Anybody got any better (or at least different) ideas? Yes, I know this is rather easy in CICS Transaction Server (EXEC CICS WEB ...), for example. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Favorite Way(s) for COBOL as HTTP Client?
Hi, In respect of: I got a question asking for recommendations on how to write a COBOL application (on z/OS) to act as an HTTP client. That is, the COBOL program makes an outbound HTTP request, provides some input data, and receives some data back. The data format is arbitrary -- could be XML, could be just simple strings. Given the criteria of the requirement being COBOL, I am not sure why Java enters the picture other than perhaps being an enticement for alternative skill sets. This is especially true given the comment about it being easy in CICS Transaction Server. Why over complicate things? It just so happens that I can vouch for the easy of implementation in standard CICS/TS, with COBOL using CICS WEB Services as I did this very exercise in the last week. It took around 3 days to do, and the only reason it didn't take 2 was that I encountered an unexpected CODEPAGE change which needed to be resolved. Note that until earlier this year I had not written a CICS Command Level program, I only had a rudimentary knowledge of COBOL and a general back ground in CICS to work with. The concept was tested by creating both the Client and Server sides and loading into 2 different CICS Regions. The Client requested information from a file owned by the Server region. I'm sorry if this sounds like blowing my own trumpet, but the serious aim is to demonstrate how easy it should be for anybody with more experience of CICS and COBOL than me. Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore, Sheffield, S17 3LA, UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Company Reg: 3767263 at the above address All outgoing E-mail is scanned, but it remains the recipient's responsibility to ensure their system is protected from spy-ware, trojans, viruses, and worms. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Favorite Way(s) for COBOL as HTTP Client?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples I got a question asking for recommendations on how to write a COBOL application (on z/OS) to act as an HTTP client. ... Further assumptions: there's only Enterprise COBOL (compiler) and base z/OS (including any standard and no charge features). ... Yes, I know this is rather easy in CICS Transaction Server (EXEC CICS WEB ...), for example. But CICS is not a part of base z/OS, and certainly is not a no-charge feature. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Favorite Way(s) for COBOL as HTTP Client?
To fully implement http, you would want to support forwarders, etc. So writing raw socket code yourself is more work than you think. As one of the original author's of JZOS, I'm usually in favor of using it, but perhaps not in this case as you would have to start a Java JVM just to make the request. You might consider using an open source http client written in in C and calling it from Cobol, although the suggestion for using curl is also interesting. Kirk Wolf Dovetailed Technologies On Thu, Oct 23, 2008 at 1:02 AM, Roland Schiradin [EMAIL PROTECTED]wrote: Hi Timothy, use the TCP/IP socket API to connect to port 80 or whatever the HTTP server listenen and send the HTTP request and receive the data back. In case of XML use the Cobol XML parser to extract the data. Roland I got a question asking for recommendations on how to write a COBOL application (on z/OS) to act as an HTTP client. That is, the COBOL program makes an outbound HTTP request, provides some input data, and receives some data back. The data format is arbitrary -- could be XML, could be just simple strings. Further assumptions: there's only Enterprise COBOL (compiler) and base z/OS (including any standard and no charge features). Also, there are significant bonus points awarded for high service quality attributes (RAS, security, performance, etc.) It broke! is not adequate diagnostic information if something fails, like the network or authentication to the remote HTTP server. :-) The same method could be used with Enterprise PL/I programs without any material differences. Anyway, with those conditions, here's the list of options I came up with: 1. Java application written using standard java.net HTTP client logic and JZOS record conversion classes. Invoked as a JZOS job step. 2. Same as #1, but invoked via COBOL INVOKE. 3. CBT tape 556 (REXX HTTP client sample). 4. Via cURL for z/OS, part of the z/OS Ported Tools. Options #2 and #4 are currently my favorite (again, given these restrictions). Along the lines of #1 and #2 there are probably Perl and Python avenues as well. Anybody got any better (or at least different) ideas? Yes, I know this is rather easy in CICS Transaction Server (EXEC CICS WEB ...), for example. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Favorite Way(s) for COBOL as HTTP Client?
I should mention that if your requirements allow you to get the data in a separate step, it would be pretty easy to use cURL and pipe the output to a DD allocated to a temporary dataset passed into a COBOL step, which reads/parses the XML. The todsn command that is part of the free Co:Z makes this easy to do: // EXEC DTLSPAWN run a login shell... //STDIN DD * curl http://my.url | todsn //DD:XML //XML DD DSN=XML,DISP=(NEW,PASS), //* // EXEC PGM=COBPGM On Thu, Oct 23, 2008 at 8:27 AM, Kirk Wolf [EMAIL PROTECTED] wrote: To fully implement http, you would want to support forwarders, etc. So writing raw socket code yourself is more work than you think. As one of the original author's of JZOS, I'm usually in favor of using it, but perhaps not in this case as you would have to start a Java JVM just to make the request. You might consider using an open source http client written in in C and calling it from Cobol, although the suggestion for using curl is also interesting. Kirk Wolf Dovetailed Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Favorite Way(s) for COBOL as HTTP Client?
I got a question asking for recommendations on how to write a COBOL application (on z/OS) to act as an HTTP client. That is, the COBOL program makes an outbound HTTP request, provides some input data, and receives some data back. The data format is arbitrary -- could be XML, could be just simple strings. Further assumptions: there's only Enterprise COBOL (compiler) and base z/OS (including any standard and no charge features). Also, there are significant bonus points awarded for high service quality attributes (RAS, security, performance, etc.) It broke! is not adequate diagnostic information if something fails, like the network or authentication to the remote HTTP server. :-) The same method could be used with Enterprise PL/I programs without any material differences. Anyway, with those conditions, here's the list of options I came up with: 1. Java application written using standard java.net HTTP client logic and JZOS record conversion classes. Invoked as a JZOS job step. 2. Same as #1, but invoked via COBOL INVOKE. 3. CBT tape 556 (REXX HTTP client sample). 4. Via cURL for z/OS, part of the z/OS Ported Tools. Options #2 and #4 are currently my favorite (again, given these restrictions). Along the lines of #1 and #2 there are probably Perl and Python avenues as well. Anybody got any better (or at least different) ideas? Yes, I know this is rather easy in CICS Transaction Server (EXEC CICS WEB ...), for example. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
