Is it possible to call a CICS program from JCL batch?
If yes how? If no why not?
Yes. Technically, a COBOL batch program is communicating with CICS, and you execute the COBOL batch program from JCL. You can read more in the CICS Transaction Server manual.
The external CICS® interface is an application programming interface that enables a non-CICS program (a client program) running in MVS™ to call a program (a server program) running in a CICS region and to pass and receive data by means of a communications area. The CICS application program is invoked as if linked-to by another CICS application program.
Introduction to the external CICS interface
I believe that your CICS program cannot use maps (must be conversational), but it's been a while since I've worked with CICS, so I might be mistaken.
There are three ways to do this:
Use EXCI, which is IBM's standard way to do this. It has a moderate amount of setup. It does not support multiple occurs depending correctly. It has just recently been expanded to support containers (exceed the 64k COMMAREA limit).
Call the CICS program through the network, like you would call it from some PC application. This is all kinds of strange and not fun, but it's possible. You would need to write a program in COBOL to implement HTTP using TCP/IP and call it from batch.
But 3rd party product, like Shadow from DataDirect. They basically simplify what IMB's EXCI interface does.
Or if possible, just don't do it. Move the logic to a share, or share data in DB2, something else.
Related
I've an idea and I don't know if it is doable in Cobol or not, I want to use Online VSAM file in online program, so my online VSAM file has multiple of records and i want if there is new record added to the file my online program detect that and do some of process, is it doable and please give me some of hint
What your describing is basically a trigger based on an event. You described COBOL as the language but in order to achieve what you want you also need to choose a runtime environment. Something like CICS, IMS Db2, WebSphere (Java), MQ, etc.
VSAM itself does not provide a triggering mechanism. An approach that would start to achieve what you want would be to create an MQ queue that processes the records to be written and they could write the record and take additional action. MQ cuts across all the runtimes listed above and is probably the most reliable.
Another option is to look at using Db2 where you could create a Triggers or user defined function that might achieve what your looking for. Here is a reference article that describes many methods.
Here is a list of some of the articles in the link mentioned above:
Utilizing Triggers within DB2 by Aleksey Shevchenko
Using Stored Procedures as Communication Mechanism to a Mainframe by
Robert Catterall
Workload Manager Implementation and Exploitation
Stored Procedures, UDFs and Triggers-Common Logic or Common Problem?
If you are looking to process records simply written from any source to VSAM there are really no inherent capabilities to achieve that in the Access Method Services where VSAM datasets are defined.
You need to consider your runtime environment, capabilities and goals as you continue your design.
If this is a high volume application you could consider IBM's "Change Data Capture" product. On every update to a chosen VSAM file it will dump a before and after image of the record into a message queue. Which can then be processed by the language and platform of your choice.
Also worth considering is if by "online" you mean a CICS application, then, the VSAM file will be exclusively owned by a single CICS region, and all updates will be processed by programs running in this region. You may be able to tweak the application to kick off some post processing (As simple as adding "EXEC CICS START yourtransacion ..." to the existing program(s).
Check out CICS Events. You can set an event for when the VSAM file is written to and action it with a COBOL program. There are several event adapters, you will probably be interested in the one that writes to a TS queue.
I am working with two tcl files. One is a program that connects to a thermal scanner to get information from it via ethernet. I have integrated the other tcl GUI that can reflash the scanner via ethernet. How do I use the connection from the first one to use the flash utility on the second GUI? At first, the two GUI's were separate but I had to combine them for customers.
-let me know if you need any code, the programs are about 4000 lines long so I didnt want to put them on here.
A single TCP connection can only really be used by one process (at each end) at a time; trying to do otherwise causes confusion. Can you just get each program to talk to the thermal scanner directly? At least theoretically, it ought be able to support multiple simultaneous connections, and that'd be a simple way to work.
But if the device won't work that way, the easiest way to multiplex the communications is to have a single process that actually talks to the device and for the other programs to talk to that multiplexer process (probably via a local socket). The multiplexer doesn't need to have a GUI, but would be told to do things like “flash this file to the scanner” or “stream values out of the scanner”. The details of how to do all this will depend very much on what's actually going on with the communications, but the fcopy command is highly likely to be useful in this, as it can be used to efficiently stream data from one Tcl channel to another.
Quick disclaimer: I'm a .Net developer and may not have provided all the information you need about the environment, but can get the information on request. We have COBOL programmers, but they have never done this.
We are converting a mainframe application with a DB2 database to a .Net MVC application with SQL database. There is one mainframe COBOL batch program that we would like to call from a COBOL stored procedure on the DB2. I've read this can be done, but I haven't found a good example of how to create a COBOL stored procedure that calls a COBOL program. The COBOL batch program takes about 5 input parameters, but does not return anything.
We already have a linked server that we are using to call native sql stored procedures on DB2 from a SQL server.
Edited for future reference below
We looked into two ways of solving our problem - creating a COBOL stored procedure that could be used by DB2-mainframe running on z/os where we'd copy/paste our COBOL from the CICS program and tweak it to run as a stored procedure (thus cutting out CICS completely) or using CICS to host a web service end point that can call to the CICS program we wanted to invoke, much like described on slide 21 of this PowerPoint.
We have decided to move forward with the second option because there is precedent for doing it that way already, so it's going to be the easier path for us.
Interesting question!
I was thinking of why not let your LUW DB2 stored procedure call a transaction manager which will execute your cobol program? This if you use a transaction manager in mainframe (which I assume you do!). If you are not familiar with this, just check your mainframe guys if you use transaction manager as CICS or IMS.
I have not done this, but it should work.
(alternative, call a http/webservice from db2 sp which will execute an ims transaction that executes your cobol program...)
I must add that I ve not tried any of above, I have´nt used db2 luw. But maybe the ideas are worth to mention here?
I use WM_COPYDATA to enable communication between my two processes A and B. There is no problem to exchange data with basic data types.
Now I have a problem, in some case I want to pass an Interface (IDispatch) from my process A to my process B. Is it possible?
It is not possible to directly pass an interface pointer to another process. Like any other pointer, an interface is only valid in the process address space that instantiates it at runtime. COM has its own mechanism for marshaling interfaces and data across process boundaries, even across different apartments in the same process. In the case of interfaces, that involves proxies and stubs which run in each process/apartment and communicate with each other using various IPC mechanisms, such as pipes, RPC, or TCP/IP. Have a look at these articles for how using interfaces across processes/apartments is accomplished:
Inter-Object Communication
Understanding Custom Marshaling Part 1
To do what you are asking for, without resorting to implementing custom marshaling, you would have to make one of the processes act as an out-of-process COM server, and then the other process can use CoCreateInstance() or GetActiveObject() to obtain an interface pointer to the server's object that works within its local address space, and let COM handle the marshaling details for you.
It can't be done directly, but you can use a Client-Server service framework, which may be interface based.
For instance, see the last feature of our Open Source mORMot framework: Interface based services sample code and this link.
You can execute an interface on a remote process. The feature handles all communication means of the framework, i.e. in-process call, GDI messages, named pipes and TCP/HTTP. Internally it will use WM_COPYDATA for GDI messages, then transmit the parameters and results as JSON. Use this link to download the source code (use the http://synopse.info/fossil 1.16+ version) and the documentation (there are several pages about how to implement those services).
It is an Open-Source project, working with Delphi 6 up to XE2.
You can also expose your interface with a SOAP or DataSnap Client-Server (if you have the corresponding version of Delphi), or n-Tier commercial packages (like http://www.remobjects.com/da). This is similar to the method implemented in mORMot.
COM is also a good candidate, native to Windows, but it is more difficult to initialize: you'll have to register the COM on each PC (with administrator rights), and you won't be able to make it work over a network (DCOM is deprecated, remember). COM is good if you want your service to be shared with other languages, like .Net, but only locally.
How might you call a Lisp program from a Rails application?... For example, allow the end user to enter a block of text in the Rails web app, have the text processed by the Lisp program and return results to the Rails app?
There are a couple ways that come to mind:
Execute the lisp program with Process. Communicate with the Lisp program via standard in, and have the Lisp program output its result over stdout.
Do the same thing as above, but communicate via named pipes instead. Have your Ruby code write data into a named pipe, then have the Lisp program read from that pipe, and write data out over another named pipe which you then read with your Ruby app. The Lisp program can either run in the background as a daemon that checks for data on its incoming pipe, or you can fire it up as-needed using Ruby's command-line utilities (as above).
Find a Ruby-Lisp bridge. I have no experience with such a bridge (nor do I know off-hand if one even exists) and I think the above 2 mechanisms are easier, but your mileage may vary.
Another simple way is to have Lisp running a HTTP server and contact Lisp from the outside via HTTP requests.
CL-JSON supports JSON-RPC. It's very easy to set up with a web server such as Hunchentoot to have a Lisp-based web service that anything that speaks JSON-RPC (e.g. this) can use.
It would depend on how often it's going to happen.
If it's once in a blue moon, then just run a backquote command that starts the lisp interpreter, or popen it and write to it.
If it happens all the time, you will need to have Lisp already running, so the question then is how to communicate. Any of the interprocessor mechanisms will work, but I would suggest a TCP socket for development, testing, and production flexibility.
If it happens a million times a day, but a toy Lisp would be good enough, it is a simple matter to implement Lisp with Ruby classes. This was done as chapter 8 of Practical Ruby Projects.