Q
Problem solve Get help with specific problems with your technologies, process and projects.

Need help creating a user-written listener

I'm required to create a user-written listener as my first venture into the world of sockets on CICS TS 1.3 under...

OS/390 2.10. The listener will be talking to a VB app on an NT server at a remote location. The listener will need to also interface to a COBOL application program in the same CICS region to update a database. I am interested in finding some sample code of a listener and any setup assistance.

The VB app is canned and inflexible, so I must create a listener that will work with this vendor supplied program. I have SC31-8518-01 and GG24-4026-00. My logic should be:


SOCKET
BIND
LISTEN
ACCEPT loop
   RECV
     CALL database program
   SEND
   SHUTDOWN
   CLOSE
SHUTDOWN
CLOSE

I know I must register the listener in the config file, but I am unsure of some of the PARMs. The manual says the listener must be in assembler. Is that correct or would COBOL due? Are there any other resources that you would recommend?

These native TCP/IP functions within CICS can be invoked from COBOL using Language Environment facilities -- it's just that the documentation is written assuming an assembler program.

From your query, it appears that you are going to get the potentially long-running listener transaction to do this actual work. This is, I think a bad idea: You do not want inbound requests queuing up simply because the listener is doing things. It also complicates UnitOfWork considerations.

I suggest that your listener only does the detection of a flow from your VB application, and when one arrives start a new CICS transaction to receive the flow, process it by doing the relevant work, and then returning the results. This is the Concurrent Server design (6.2.2 in sc31-8518). The listener task gets the socket address and does a GIVESOCKET before doing an XC START with the socketid in the commarea. This started task does a TAKESOCKET call and then off it goes.

As you cannot change the flow arriving in CICS, a design point is where the first flow from the client is handled. If this is relatively static -- by which I mean the function to be done is always the same -- then the started task should do the receive. If however, the 1st flow is more fluid and it contains something that could/should be used to start one of many service transactions, then you need to think about receiving and parsing this flow in the listener, and then pass it in the commarea to the relevant started transaction.

When I do this sort of thing, if there is more than one function to be done, I tend to get the Listener to start a fixed CICS transaction and then XC LINK in that to service whatever request is supplied. The listener is always trivially doing the same thing -- which because it's being multiple invoked from a 'foreign' entity is all to the good.

You need to update .PROFILE.TCPIP to map the port number number to the job name (or started task name) of the CICS region. If you are going to use multiple CICS regions to service the inbound request -- for availability or load balencing concerns -- then you want to enable the MVS TCP/IP port sharing function -- this is the SHAREPORT definition.

The capacity of the listener is set via the definitions in the EZACID VSAM file as is the CICS transaction ID of your listener, and you enable the function via the PLT.

Just something else to worry about: What security identity are you going to use for the started service transaction? Is it going to be fixed -- and so you are going to rely on the VB client being correctly authenticated and authorised -- or is it going to get a logonid+Password in from the VB Client (a bit unlikely this from your description) in which case are these fields scrambled in some fashion?

And an alternative suggestion for you to ponder over: There is now a version of CICS that runs under Windows NT/2000/XP. If security and firewall are potentially a problem than you might want to get your VB application to talk to that, and then do an XC LINK from the server CICS to the Mainframe CICS.

This was last published in November 2002

Dig Deeper on IBM system z and mainframe systems

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchWindowsServer

SearchServerVirtualization

SearchCloudComputing

Close