Tag Archives: cics tips

z/OS Explorer and CICS Explorer

CICS Explorer

I have just installed the new z/OS Explorer, and the latest version of CICS Explorer (5.1.1) under it. If you are not running CICS/TS V5, no worries; CICS Explorer V5.1.1 supports CICS/TS V3, V4, and V5. With the z/OS Explorer, now you can view/edit MVS and zFS datasets and review output on the JES spool from the same Eclipse environment where you define/control CICS resources. In this post, I will review the steps to install these (free) products and why.

The installation process is fairly simple, but if you have not started working with the CICS Explorer, you will find using it a big sluggish compared to the  CICSPlex WUI if your workstation is low on horsepower. It does take some resources to run the Eclipse environment, but that’s just the way things are going; mainframe support personnel need beefy client workstations as well as PC developers. Maybe not as beefy, but much more so than the thin clients many use today. After all, the mainframe is a server, too.

Here is an overview of the steps I took in installing the tools:

  1. Download the zip file containing z/OS Explorer and Installation Manager
  2. Expand the zip file and run launchpad.exe
  3. Select z/OS Explorer, Installation Manager, and Eclipse
  4. Load Installation Manager and add URL http://public.dhe.ibm.com/software/htp/zos/2/1/0 to Preferences > Repositories.
  5. Choose CICS Explorer SDK

From there, just point to your z/OS FTP servers and CICSPlexes (IP address/port number), and supply authentication info. Be sure to use your CICSPlex CMCI port rather than TCP/IP port, or else the CICS view will be read-only. (I made that mistake.)

The process is much easier than it once was; IBM has done a great job of bundling everything needed. IBM  also has some great information regarding installing the z/OS Explorer and installing the new CICS Explorer. Several scenarios are covered for the installation of CICS Explorer; the process I outlined above was Scenario 1 (“new to Installation Manager and CICS Explorer V5.1.1”).

If you haven’t started using CICS Explorer, now is the time to start. The CICSPlex WUI will be going way, all the CICS tools are being engineered to use this interface, as well as all the development tools, and MQ Explorer. Get z/OS Explorer today and get started!

Follow theCICSguy on twitter here

Advertisements

Try CICS TS 5.1 – For FREE!

If you are running anything other than CICS TS 5.1, you may wish to consider installing IBM’s Free CICS TS 5.1 Developer Trial. You can install 5.1 in a test environment and check out all of the new features; the only limitations are: limited time (though you can download a new copy and install it again at no cost), some performance and capacity restrictions (to ensure that it is used only in a test environment), and licensing (you agree to only use it to test, and not for production work).

IBM has done us a tremendous favor here – take advantage of it! Whether to just check out the new features, or to “pre-install” it to prepare for upgrading to TS 5.1 (which you can do with this trial and not have the clock ticking on having two releases installed), you can’t beat free!

Follow theCICSguy on twitter here

CICS-L Listserv

A great source of CICS information and help is the CICS-L Listserv. As of this post, there are over 1800 members, but only a handful of regular contributors. Still, it is a good resource for when you get stuck, and its archive is a great source of info. Since you are reading my blog, I highly recommend that you check out the CICS-L archives and consider subscribing.

Handy Listserv Commands

Below is a list of listserv commands you may find handy should you subscribe. All of these commands are issued by sending an email from the email address that is or that you wish to be subscribed to the CICS-L listserv.

Subscribe: Send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): SUBSCRIBE CICS-L

Temporarily Leave: If, for example, you are going on vacation, send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): SET CICS-L NOMAIL

Rejoin: When you are back from your vacation, send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): SET CICS-L MAIL

Leave Permanently: Send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): SIGNOFF CICS-L

For More Information: Send a message to LISTSERV@LISTSERV.UGA.EDU, with the following in the text (not the subject): HELP or INFO … HELP will have a short help message sent to you, where INFO will have a list of documents that you can order with more extensive help sent to you.

A few notes on listserv etiquette:

  • Do your homework before asking for help. Be sure you RTFM (read the fine manuals); you don’t want to ask a question and take up others’ time on something that you can look up yourself.
  • Be sure to include a descriptive subject line. E-mails received with no subject line may likely be perceived as spam by an email filter and be deleted before reaching the recipient’s inbox, and those with a concise subject are more likely to be read and/or answered.
  • Don’t just automatically hit “reply”; that will send your response to the entire list. If your response is only of interest to the person who wrote the message you are replying to, then cut their email address and send your message just to them.
  • Never use CICS-L to market a product. Posting independent reviews or help tips on CICS-related products is usually OK, but marketing is not acceptable.
  • Temporarily leave CICS-L when going on vacation. Please be aware that if you use an auto-responder while on vacation without setting your subscription options to NOMAIL, your “out of office” messages will be broadcast to everyone on the list. Most of them do not care and do not wish to receive such messages from other listserv members.

Follow theCICSguy on twitter here

Accessing “The Good Stuff” With CICS Explorer in CICS/TS 4.1

When I initially installed CICS/TS 4.1 in our Systems test environment, I started looking for what was new and improved in this version over the 3.2 we had been running. One thing I was looking forward to was seeing the “update” options available in CICS Explorer; in version 3 of CICS/TS, there were many options teasingly grayed out. However, when I loaded CICS Explorer and pointed it at my shiny new CICS/TS 4.1 region, those options were still grayed out!

After doing some web searches, I found information that indicated that to access the update functions, I would need to change the CICS Explorer connection type from CICSPlex SM Data Interface to CICS Management Interface. Of course, nothing is ever that easy …

When I changed the CICS Explorer to use  the CICS Management Interface, I got the following error when I tried to connect:

org.xml.sax.SAXParseException: The element type “HR” must be terminated by the matching end-tag “</HR>”

Boy, it is really clear what this means, isn’t it? Translated into English, this is what it is really saying:

“You tried to access a port with the wrong protocol; make sure you are using a CICSPlex SM Data Interface to access a WUI port, or a CICS Management Interface to access a CMCI port.”

Up to this point, I had never heard of a CMCI port. However, it was fairly trivial to define new WUI parm, CMCIPORT, and point CICS Explorer to that port when using the CICS Management Interface. Once that was done, I magically got all the update options.

IBM has a procedure documented for setting up CMCI in stand-alone (non-CICSPlex) CICS regions so that they, too, can be accessed with CICS Explorer. (Thanks go to Chris Hodgins over at The Master Terminal for that link!)

Follow theCICSguy on twitter here

Sending Email from CICS

If you are not sending email from CICS in your shop, you really need to add that capability. If you do not currently have a need for it, “build it and they will come” … The reasons for sending email from within CICS will start popping up like nobody’s business once it is in place.

Assuming you have SMTP set up on z/OS, sending email from CICS is a snap. If you do not have SMTP set up, I would recommend reviewing the info available on Lionel B Dyck’s site and Dave Alcock’s Planet MVS site. Once SMTP is set up, all you have to do is write records to the punch queue in the correct format, and SMTP will take care of the rest.

To get kick-started, I recommend reviewing three different products. They are all easy to use, and they are all FREE!

First, if you are not already running Lional B Dyck’s XMITIP, then go to his site now and download it. It is a facility to send email from batch, so you can integrate that into your batch processes and you can consider generating JCL from CICS that uses it to send email.

Next, take a look at IBM SupportPac CA1H. It shows how you can create the records in the correct format and send them to the punch queue so that SMTP will pick them up and send them out as an email message.

And if that’s too much work, grab a copy of XMITCICS. It is very easy to install, and with it you can just assign values to working storage and link to XMITCICS from your application to send email messages. It also has a convenient batch facility called XMITMAIL.

If you haven’t already done so, check these out and bring 21st century functionality to your CICS applications!

Finding the z/OS Sysname in CICS

Today I’ve got a simple but neat little tip to share. Have you ever had a need to know which z/OS system your CICS program is running in? I found myself in that situation today, needing a way to programmatically set the hostname in the URL in a CICS web application. The CICS web application could be running in any LPAR. The z/OS system running in each of our LPAR’s has a unique sysname, so if I could access that, I could determine the hostname for that z/OS.

Looking in SYS1.MACLIB(CVT), we see that z/OS has a control block called the CVT (Communications Vector Table) that contains the sysname 340 bytes into it. In the comments at the top of that member, we learn that there is a pointer to the CVT in the PSA (Prefixed Save Area) x’10’ bytes into it. The PSA is easy to find – it is at address 0. So, armed with this info, I wrote the sample code below, which you are welcome to use or incorporate into your own project. If you use this code, just define a PPT for it (if you do not use autoinstall for programs) and point a tranid to the program.

IDENTIFICATION  DIVISION.
PROGRAM-ID.     CVTTEST.

ENVIRONMENT  DIVISION.
DATA  DIVISION.
WORKING-STORAGE  SECTION.

01   WS-PSA-POINTER.
10   PSA-PTR-PIC9        PIC S9(8) COMP-5 VALUE  0.
10   PSA-PTR             REDEFINES PSA-PTR-PIC9 POINTER.

01   SEND-AREA.
10   FILLER              PIC X(1)  VALUE SPACE.
10   FILLER              PIC  X(11) VALUE 'CVTSNAME = '.
10   SA-CVTSNAME         PIC X(8)  VALUE  SPACES.

LINKAGE  SECTION.

01   PSA.
10   FILLER              PIC  X(16).
10   CVT-PTR             POINTER.

01   CVT.
10   FILLER              PIC  X(340).
10   CVTSNAME            PIC  X(8).

EJECT

PROCEDURE  DIVISION.

100-MAINLINE.

SET ADDRESS OF PSA TO  PSA-PTR.
SET ADDRESS OF CVT TO  CVT-PTR.

MOVE CVTSNAME TO  SA-CVTSNAME.

EXEC CICS SEND  FROM(SEND-AREA)
LENGTH(LENGTH OF  SEND-AREA)
END-EXEC.

999-RETURN.

EXEC CICS  RETURN
END-EXEC.

GOBACK.

CALL or LINK?

It’s an old question … In my CICS program, should I invoke a subprogram using a standard COBOL CALL, or should I use the EXEC CICS LINK API?

The traditional answer was, “LINK is easier to debug, CALL is more efficient.” However, there have been some changes in the CICS environment in recent years that blur the efficiency line and add other variables to consider.

The reason that LINK was considered easier to debug is that CALLs are “invisible” to CICS – you won’t see the transfer take place if using CEDF to debug. However, modern debug tools (e.g., Xpediter) have no problems showing CALLs, and virtually all shops use such a tool these days. So, if CALLs are more efficient and there is no debugging advantage to LINK, why use the CICS API?

The biggest advantage is probably the fact that using LINK can send control over to another CICS region. Since CICS has minimal involvement with a CALL, the processing stays in the same region; use LINK, and the program could be invoked in the same region, or it may be statically or dynamically routed to another region. If the program has special resource needs that are best served (or only served) in a particular region, statically route its execution to that region; if load balancing, let WLM route it to the least busy region. In my mind, those are huge. Other advantages include the fact that when using LINK, CICS will handle DATALOCATION (any/below) and EXECKEY (user/CICS) differences, and it will handle mode switches between THREADSAFE/QUASIRENT CONCURRENCY and OPENAPI/CICSAPI.

Another consideration that used to exist was that more than 32K could be passed in a CALL, but COMMAREA used to pass data in a LINK have that limit. However, use of CHANNELS and CONTAINERS overcome this limitation starting in CICS/TS 3.1.

My general rule of thumb is this … If invoking a subprogram that does not do “CICS stuff” (i.e., has no EXEC CICS statements), the same subprogram could easily be CALLed from batch, so use a COBOL CALL so that the interfaces are consistent. If it does “CICS stuff”, then use LINK. But that’s just a rule of thumb – if efficiency concerns override the advantages of using LINK, then it’s perfectly fine to CALL a program that has “CICS stuff” in. If there are issues with CONCURRENCY or other items mentioned above, using LINK to invoke a program with no “CICS stuff” is perfectly fine, too. Use the tool that is best fitted for the situation.