2011年8月27日 星期六

The history of CICS

You can find a brief survey of all CICS releases and some interesting side information over here.

Dynamic Scripting and CICS/TS 4.2

Are you using the new Dynamic Scripting Feature Pack? If so, you must be running CICS/TS 4.1 … There was only a limited SupportPac for CICS/TS V3, and IBM just announced that the Dynamic Scripting Featue Pack is not supported on CICS/TS 4.2.

CICS/TS 4.2 supports only 64-bit JVM’s, and the feature pack has environment variables set for using 31-bit JVM’s. We will be watching for an update from IBM soon, as supporting dynamic scripting was listed on the CICS/TS 4.2 Announcment Letter‘s Statement of Direction.

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.

2011年8月11日 星期四

Plan Your ESQA Carefully For z/OS Release 11

In z/OS Release 11 there is a requirement for an additional 1608 bytes of ESQA per address space. To put that in context, I'll do some obvious maths: That's about 1.6MB per 1000 address spaces. It just might be of interest to certain customers I know with thousands of CICS regions in a system, or very large TSO or Batch systems. It's probably not enough to trouble most people. But it reminds me of the importance of having a quick virtual storage check when migrating from one major product release to another.

There are several ways of checking for this particular one:

  • You can use Healthchecker VSM_SQA_THRESHOLD check.
  • You can process the SMF 78-2 Virtual Storage record.

The latter would be my favourite as using the SMF 78-2 data to look at usage by time of day can show some useful patterns. You might want to review, for example, whether (E)SQA threatens to overlow into (E)CSA. It's not a big tragedy if that happens but your installation might have views on such things.

(In case you're unfamiliar with such things the "E" in "(E)SQA" and "(E)CSA" refers to 31-bit areas whereas the names without the "E" refer to 24-bit areas, there being analogues above and below the line for both SQA and CSA.)

One other thing - in case you think ESQA and ECSA are unimportant having very large such areas can impact on the 31-bit Private Area virtual storage picture.

Deleting a File That Is “In Use”

Let’s step away from CICS for a minute and look at an issue that comes up from time to time … You want to delete a file, perhaps an old, uncataloged version of a dataset that is always open – say, SYS1.PROCLIB. If you go to the DSLIST screen in TSO (option 3.4) and enter the dataset name and volume, and try to delete it, you will be informed that the delete failed because the dataset was in use. There is a SYS1.PROCLIB in use, but it’s not the one you are trying to delete. You know what you are doing, but z/OS doesn’t trust you, it seems. (Actually, it’s just that z/OS enqueing is by dataset, not dataset and volume.) The way around this is to “zap” the VTOC to change the name of the dataset to something else that is not in use; then you can delete it.

To zap the VTOC of the volume containing the dataset to be deleted, first we need to find out exactly where the text specifying that name is. To do so, run the AMASPZAP utility, specifying the ABSTDUMP ALL paramter. Here is some sample JCL to dump the VTOC on volume VOL999:

//STP1    EXEC PGM=AMASPZAP,REGION=4096K

//SYSLIB DD DISP=OLD,DSN=FORMAT4.DSCB,
// UNIT=3390,VOL=SER=VOL999,
// DCB=(KEYLEN=44)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ABSDUMPT ALL

In the output from this utility, find the dataset name that you wish to change. The hardware address (CCHHR) will be shown for it. Enter that, along with the text to be changed, in another AMASPZAP job. Let’s assume that the output showed the VTOC entry to be at CCHHR 0517000507, and all we want to do is change the first letter, S (hex E2), to a Z (hex E9). Here is some sample JCL to accomplish this:

//STP1    EXEC PGM=AMASPZAP,REGION=4096K

//SYSLIB DD DISP=OLD,DSN=FORMAT4.DSCB,
// UNIT=3390,VOL=SER=VOL999,
// DCB=(KEYLEN=44)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
CCHHR 0517000507 VER 00 E2 REP 00 E9 /*

Anytime that AMASPZAP is used to change data, be very careful. I usually run such a job with just the VER (verify) statements to ensure that I am hitting the data I expect before adding the REP (replace) statement.

Finally, the VTOC index needs to be changed to the old “OS” format before the dataset can be deleted. To do this, use the ICKDSF utility:

//CNVTOS EXEC PGM=ICKDSF

//DD1 DD UNIT=3390,DISP=OLD,
// VOL=SER=VOL999
//SYSIN DD *
BUILDIX DDNAME(DD1) OS NOPURGE

Find the new dataset name for the file, ZYS1.PROCLIB in this example, and delete it using the DSLIST panel or any other way in which you feel comfortable. Then, convert the index back to “IX” format:

//CNVTIX EXEC PGM=ICKDSF

//DD1 DD UNIT=3390,DISP=OLD,
// VOL=SER=VOL999
//SYSIN DD *
BUILDIX DDNAME(DD1) IX

That’s it! Put this little process away into your systems programmer bag of tricks, as it is all but certain you will need it one day.

2011年8月5日 星期五

How to SAVE/PRINT SYSLOG to dataset?

1. Specify SYSLOG write outclass

CMD==/W L


2. Start write PROC

You should have a PROC like below, to write SYSLOG to dataset, usually in your site PROCLIB.

CMD==/S CPFSLOGW.stepname,,,L

//IEFPROC EXEC PGM=IASXWR00,PARM='PL'
//IEFRDER DD DSN=MIB.SYSLOG(+1),
// DISP=(NEW,CATLG),UNIT=SYSDA,SPACE=(CYL,(90,80),RLSE),
// DCB=(MIB.SYSLOG.DSCB,BUFNO=5,BUFL=4088)

3. Wait until this message pop up

IEF176I WTR L WAITING FOR WORK, CLASS=L, DEST=LOCAL

4. Stop PROC

CMD==/P CPFSLOGW.stepname