Wednesday, August 30, 2006

Web 2.0verkill?

As an addendum to Trevor's post on Monday regarding "Web 2.0" (it feels like less of a buzzword if I use quotes), I found an interesting project aggregating "Web 2.0 sites" (www.web2list.com). The considerable breadth associated with "Web 2.0" development is on full disply in this listing-- a veritable sea of gradient hues and shiny reflections, it seems that "Web 2.0" is here to stay... or at least linger very convincingly for a while. So, "Web 2.0verkill"? Certainly not yet-- this is about as exciting as web development has been for a while-- but put that one in your pocket because I think it may come in handy in the future.

Monday, August 28, 2006

Web 2.0 – more than just “marketecture”

Back in the 1990s, when everyone started predicting the exact date when the last mainframe would be turned off and IBM wasn’t having a particularly great time, IBM tried to counter the bad news by having lots of initiatives – rather like governments do. Governments want you to think that you can’t get rid of them because they are just launching radical reforms to education and health (and anything else their media friends tell them the public want to hear). IBM, similarly, although without saying the words, tried to form the impression that mainframes (they were fashionably calling them servers at the time) would not go away because there were so many exciting and important things happening with them. The old Xephon (www.xephonusa.com) “Handbook of IBM Terminology” defines marketecture as, “A wonderful coinage to describe grand designs whose existence owes more to the creative intellect of marketers than to the industry of product developers. IBM is the past master of creating marketectures, outdoing even the people who write manifestos for politicians”. Web 2.0 sounds like it might be a piece of marketecture. At first it sounds like a proper product announcement. You think you could go out and buy this new version of the Web, but, of course, you can’t. What separates Web 2.0 from being marketecture and what makes it so great is the underlying concept – one that everyone seems to understand without necessarily being able to define it exactly themselves. The term Web 2.0 was coined following a meeting between two companies – O’Reilly and MediaLive International. Web 2.0 is a way of separating companies (or really Web sites) that make use of the latest Web-based techniques from less innovative sites. So how can you tell whether your company’s Web site is Web 2.0? Well that’s hard to say exactly. You know when you visit a site whether it could be called Web 2.0, but you may not always know why exactly. Typically, Web 2.0 sites will be making use of techniques such as AJAX (see last week’s blog), Web syndication, and public Web APIs. What I’m talking about are things like blogs, wikis (and who needs to buy Encarta when the wonderful wikipedia – www.wikipedia.org – is only a click away), RSS, and podcasts. Web 2.0 sites successfully use information from their site’s visitors – for example Amazon (www.amazon.com) recommends similar books that you might like when you order a book. Web 2.0 sites can also easily update the software they use – and do. This means that each time you browse the site the experience can be slightly different, but should be better (faster and easier). Web 2.0 sites can incorporate or link to pages from other sites to improve the browser experience (mash-ups). For example the Google Earth maps can be overlaid with bus routes (for example). Check out the following sites, which are considered to be Web 2.0: www.myspace.com, maps.google.com, flickr.com, www.blogger.com, del.icio.us, and digg.com. eBay (www.ebay.com) is also a Web 2.0 company. It makes virtually no profit when an item is sold on eBay. But (and this is a really big “but”) because there are so many transactions, each tiny amount of money adds up to a very reasonable income. I think eBay is one of the first of what will be a multi-million dollar industry as companies realize that collaboration makes Internet trading easy and effective. The other big change in the way users work introduced by Web 2.0 is that (like I said last week with AJAX) it is operating system agnostic. You are no longer tied to Windows or Linux (or whatever) as your user platform. So, there is definitely a Web 2.0 experience to be enjoyed at many Web sites out there. There are also probably millions of sites that could learn from these Web 2.0-enabled sites. There is definitely much more to Web 2.0 than simple marketecture.

Friday, August 25, 2006

An update to the screen viewing utility (for CICS)

We have found Richard Keane’s article, A screen viewing utility, published in CICS Update, extremely useful for our Help Desk facility. A modification was described in a later edition of CICS Update, to enable this utility to be CICS 4.1 compatible and to PEEK by user-id rather than by terminal-id. We have now added a further change to allow the automatic screen update every two seconds. We also tried a one-second delay, but this caused a problem on the terminal we tried to PEEK. In the original program the person doing the PEEKing had to press ENTER to retrieve the next PEEKed display. Here’s what happens – the Help Desk person logs on to a CICS terminal, clears the screen, and types PEEK USER-ID followed by the ENTER key. The next screen displayed will be the user’s terminal. In response to the PEEK command, program ITPEEK gets control and retrieves the user-id text from the originator’s terminal. It then attempts to find the terminal-id for that user-id. If the terminal-id cannot be located, an error message is sent back to the originator’s terminal and control returns to CICS, and that is the end of the story. However, if the terminal-id is located, the program starts TRANSID LOOK, passing a COMMAREA containing the user’s terminal-id, and returns to CICS. The RECEIVE in ITPEEK initially takes the data from the originator’s terminal – note this for later! The transaction-id LOOK is started on the user’s terminal. The program ITLOOK gets control next. Its first job is to check whether there is a COMMAREA attached to this terminal; if so, it needs to be saved for later. If no COMMAREA is attached, there is nothing to be saved. Next, the cursor position is saved and a RETRIEVE command performed to obtain the COMMAREA sent by ITPEEK. The terminal’s buffer is read and saved in a buffer, together with other information, and a START SHOW transaction is done with this buffer set as the COMMAREA. Now there are two possible exits. If no COMMAREA was detected at the start of ITLOOK, then there was no transaction waiting to run on this terminal, so a simple return to CICS is done. Otherwise, the transaction that was to run must be set up again by doing a return to it, specifying the COMMAREA found at the start of ITLOOK, and then returning to CICS to wait for the terminal operator to do what he was going to do before we jumped in! Transaction SHOW now gets control back on the originator’s terminal and program ITSHOW retrieves the COMMAREA, which contains the data from the user’s terminal’s buffer. A SEND command is used to display this on the originator’s terminal and a two-second delay is performed. The next thing to do is to check whether the originator has pressed PF3 – to end the loop – and, if so, simply exit to CICS. If PF3 has not been pressed then a RETURN IMMEDIATE command is executed using the INPUTMSG option. In the INPUTMSG option is the text PEEK USER-ID and the transaction-id specified is PEEKed. Once again the PEEK-LOOK-SHOW loop has been activated. The receive in ITPEEK now gets its data, not from the terminal, but from the INPUTMSG option of the return command. When the operation is complete, simply press PF3! You should ensure that the two terminals have the same number of lines and columns, or, at least, that the originator’s is the larger.
ITLOOK *********************************************************************** * PROGRAM : ITLOOK * * TRANSID : LOOK * *********************************************************************** *ASM XOPTS(NOPROLOG) DFHEISTG DSECT , DFHEISTG LOOK CSECT , DFHEIENT CODEREG=(3,8) MVC LCOMAREA(2),=H'Ø' INITIALIZE STORAGE AREAS * CHECK TO SEE IF A COMMAREA IS PRESET FOR THIS TERMINAL. IF SO WE * * MUST SAVE IT FOR THE NEXT TRANSACTION - WAITING TO RUN ON THIS TERM * LH 5,EIBCALEN COMMAREA LENGTH LTR 5,5 LENGTH ZERO ? BZ NOCOMARE YES, NO NEED TO SAVE STH 5,LCOMAREA NO, SAVE LENGTH L 4,DFHEICAP ADDRESS OF COMMAREA BCTR 5,Ø LESS ONE FOR EXECUTE CH 5,LENCOMSA CHECK LENGTH NOT TOO LARGE BH NOSHOW YES, TOO LONG, EXIT EX 5,MOVINCOM MOVE INTO SAVEAREA * RETRIEVE THE TERMINAL ID ON WHICH 'PEEK' WAS STARTED * NOCOMARE EXEC CICS RETRIEVE , X INTO(PARMS) , GET INVOKER'S TERM-ID X LENGTH(LPARMS) MVC PEEKTERM(4),TERMID INVOKER'S TERM-ID MVC LOOKTERM(4),EIBTRMID TARGET TERM-ID MVC CURSOR(2),EIBCPOSN CURSOR POS MVC LRBUFFER(2),SLRBUFER SET LENGTH OF RECEIVE BUFFER EXEC CICS RECEIVE , READ CONTENTS OF SCREEN X INTO(RBUFFER) X LENGTH(LRBUFFER) X BUFFER X ASIS X LEAVEKB LH 4,LRBUFFER LENGTH OF DATA READ AH 4,=H'1Ø' PLUS 1Ø BYTES FOR TRANS 'SHOW' STH 4,LPASDATA SAVE LENGTH * * IF THE TRANSACTION WHICH PREVIOUSLY RAN ON THIS TERMINAL WAS PSEUDO-* * CONVERSATIONAL IT WILL HAVE RETURNED TO CICS USING EXEC CICS * * RETURN TRANS-ID('XXXX'). * * WHEN THE USER ENTERED DATA TRANS-ID XXXX WOULD HAVE BEEN STARTED BY * * CICS. BECAUSE WE ARE RUNNING IN BETWEEN, WE MUST ALSO RETURN TO * * CICS, SETTING XXXX AS THE NEXT TRANSACTION TO BE STARTED. * * START TRANSACTION 'SHOW' AT INVOKER'S TERMINAL TO DISPLAY SCREEN * * STRTSHOW EXEC CICS START X TRANSID('SHOW') X TERMID(PEEKTERM) X FROM(CURSOR) X LENGTH(LPASDATA) CLC LCOMAREA(2),=H'Ø' WAS A COMMAREA PRESENT BE NOSHOW NO, RETURN NO COMMAREA EXEC CICS INQUIRE TERMINAL(EIBTRMID) NEXTTRANSID(LASTTRAN) CLC LASTTRAN(4),=CL4' ' WAS A TRANSACTION TO BE STARTED? BNE EXIT YES, RETURN WITH TRANS-ID NOSHOW EXEC CICS RETURN , NO, RETURN * RETURN TO CICS WITH TRANSID * EXIT EXEC CICS RETURN X COMMAREA(COMMAREA) X TRANSID(LASTTRAN) X LENGTH(LCOMAREA) * CONSTANTS * MOVINCOM MVC COMMAREA(*-*),Ø(4) DUMMY FOR EXECUTE SAVEREGS DC 18F'Ø' SAVE REGS AREA COMMAREA DC 3Ø72C' ' SAVE AREA FOR COMMAREA LENCOMSA DC H'3Ø72' LENGTH OF COMMAREA LCOMAREA DC H'Ø' LENGTH OF SAVED COMMAREA PARMS DS ØCL5 PASSED BY 'PEEK' TERMID DC CL5' ' INVOKER'S TERM-ID LPARMS DC AL2(*-PARMS) PEEKTERM DC CL4' ' HOLDING AREAS CURTERM DC CL4' ' CURSOR DC H'Ø' DATA PASSED TO SHOW LASTTRAN DC CL4' ' LOOKTERM DC CL4' ' RBUFFER DC 3ØØØC' ' RECEIVE BUFFER DS ØH LRBUFFER DC AL2(*-RBUFFER) LENGTH SLRBUFER DC AL2(*-RBUFFER-2) SAVE LENGTH LPASDATA DC AL2(LRBUFFER-CURSOR) LENGTH OF PASS DATA DFHEIEND END LOOK ITPEEK *********************************************************************** * PROGRAM : ITPEEK * * TRANSID : PEEK * *********************************************************************** DFHEISTG DSECT , DFHEISTG TRANSID DS CL4 MAP SCREEN FILLER DS CL1 USERID DS CL8 AAAAAAAA DS CL4Ø PEEK CSECT , EXEC CICS RECEIVE INTO(TRANSID) LENGTH(SLEN) NOHANDLE MVC TARGET,USERID MOVE IN TARGET USER-ID OC TARGET,=CL8' ' CONVERT TO UPPER CASE MVC TERMID(4),EIBTRMID SAVE INVOKER'S TERMINAL-ID EXEC CICS HANDLE CONDITION , IF TARGET TERM-ID NOT FOUND X TERMIDERR(WRONGTRM) X END(WRONGTRM) EXEC CICS INQUIRE TERMINAL START LOOP EXEC CICS INQUIRE TERMINAL (USTERM) NEXT * USERID(USERID) CLC USERID,TARGET BNE LOOP STARTLOO EXEC CICS START , START TRANSACTION LOOK X TRANSID('LOOK') , PASSING OUR TERMINAL-ID FOR X FROM(PARMS) , TRANSACTION 'SHOW' X LENGTH(LPARMS) X TERMID(USTERM) EXIT EXEC CICS RETURN , RETURN TO CICS * WRONGTRM MVC ERRTERM,TARGET MOVE TARGET NAME TO ERROR MSG EXEC CICS SEND , DISPLAY ERROR MESSAGE X FROM(EMSG) X LENGTH(LEMSG) X CTLCHAR(WCC) X ERASE EXEC CICS SEND CONTROL X FREEKB B EXIT EXIT * CONSTANTS * WCC DC X'F1' WRITE CONTROL CHARACTER SMSG DC X'1DC1' ATTRIBUTE, UNPROTECTED, MDT ON DC C'TRANSACTION LOOK STARTED FOR USER ' TARGET DC CL8' ' LSMSG DC AL2(*-SMSG) EMSG DC X'1DF2' ERROR MESSAGE 1 DC C'USER ' ERRTERM DC CL8' ' DC C' IS NOT CURRENTLY LOGGED ON ' LEMSG DC AL2(*-EMSG) PARMS DS ØCL5 COMMAREA PASSED TO 'LOOK' TERMID DC CL5' ' LPARMS DC AL2(*-PARMS) HEXNULL DS XL14'ØØ' USERMAND DS XL1'ØØ' USERNAME DS XL12'ØØ' LREC DC H'3ØØØ' SLEN DC H'57' RECORD DS 3ØØØC USTERM DS 4C END PEEK ITSHOW *********************************************************************** * PROGRAM : ITSHOW * * TRANSID : SHOW * *********************************************************************** DFHEISTG DSECT , DFHEISTG SHOW CSECT , MVC LRBUFFER(2),SLRBUFER SET LENGTH OF SEND BUFFER MVC LRECVBUF(2),SLRECVBU SET LENGTH OF RETRIEVE BUFFER EXEC CICS RETRIEVE , RETRIEVE DATA PASSED BY 'LOOK' X INTO(CURSOR) X LENGTH(LRECVBUF) LH 4,LRECVBUF LENGTH SH 4,=H'1Ø' LESS 1Ø BYTES WHICH ARE FOR US STH 4,LRBUFFER SET SEND LENGTH MVC LASTTRAN(4),NEXTTRAN TRAN NAME SCHEDULED ON TARGET EXEC CICS INQUIRE TERMINAL(PEEKTERM) USERID(PEEKED) EXEC CICS SEND , DISPLAY DATA ON SCREEN OF TARGETX FROM(RBUFFER) X LENGTH(LRBUFFER) X ERASE X CTLCHAR(WCC) EXEC CICS SEND CONTROL , SET CURSOR POSITION X FREEKB X CURSOR(CURSOR) EXEC CICS DELAY FOR SECONDS (2) CLI EIBAID,X'F3' BE EXIT EXEC CICS RETURN IMMEDIATE X TRANSID ('PEEK') X INPUTMSG (REPEAT) X INPUTMSGLEN (14) EXEC CICS RETURN , RETURN TO CICS EXIT EQU * EXEC CICS SEND , SEND 'PEEK USER-ID' WHICH IS X FROM(ENDMESS) , UNPROTECTED, ENABLING THE USER X LENGTH(LENDMSL) , TO JUST PRESS ENTER TO REINVOKE X ERASE , 'PEEK' EXEC CICS RETURN , RETURN TO CICS * CONSTANTS * DS ØF WCC DC X'F3' WRITE CONTROL CHARACTER REPEAT DC CL5'PEEK ' END MESSAGE PEEKED DC CL8' ' INFO DC C' NEXT TRANSACTION ID : ' LASTTRAN DC CL5' ' LREPEAT DC AL2(*-REPEAT) CURSOR DC H'Ø' RETRIEVE BUF.PREFIXED BY CURPOS, NEXTTRAN DC CL4' ' NEXT TRANS-ID OF TARGET TERMINAL PEEKTERM DC CL4' ' NAME OF THEN TERMINAL RBUFFER DC 3ØØØC' ' DATA OBTAINED BY 'LOOK' LRBUFFER DC AL2(*-RBUFFER) LENGTHS SLRBUFER DC AL2(*-RBUFFER-2) LRECVBUF DC AL2(LRBUFFER-PEEKTERM) SLRECVBU DC AL2(LRBUFFER-PEEKTERM) ENDMESS DC XL12'114Ø4Ø3C5D7C5F114EC31DE8' DC CL33'OK, I'm GOING then - See Yer !!!' DC XL2'1D4Ø' LENDMSL DC H'47' END SHOW
G Coates (UK) © 2006 This article was reprinted with permission.

Monday, August 21, 2006

AJAX – a big step in the right direction

Every time there’s a great leap forward in computing, you kind of think that you would have thought of that (given enough time, etc etc). For example, when we were all working on mainframes with terminals attached and those guys struggling away in garages built small personal computers for the first time – I remember thinking it was brilliant idea and I’m sure I would have come up with the idea. Then we had a long period of swapping files between PCs using floppy disks, and sending diskettes through the post! That was the only way to share files. I can remember waiting for the Fed Ex man with his box of diskettes to arrive. The solution, of course, was the Internet. I’m sure I must have thought of that idea – didn’t you? Then we get to the stage where we work on notebook computers, talking across the Internet, and the Web server sends us a page, we make one change or entry and we send the whole page back. Then the Web server sends us a new page – one that probably looks 90% like the last one we saw. Did I say 90%, it could even look 99% similar, but the whole page was sent over the Internet to my browser. It must be time I had another of those "brilliant" thoughts! And that’s how we get to AJAX technology. AJAX is an acronym standing for Asynchronous Javascript And XML (eXtensible Mark-up Language), which was originally coined by Web design consultancy Adaptive Path (www.adaptivepath.com). Rather than the user pressing a button or hitting the Enter key triggering an HTTP request on the Web server, which then actions that request (by grabbing some data or calculating interest, or whatever), and finally sending back a new page, AJAX speeds things up by actually sitting on the end user’s computer and doing a lot of the work there. An AJAX engine will control most of what the user sees in their browser and be responsible for sending data to and from the Web server. By using hidden frames (typically) communication can be asynchronous, but (again typically) the AJAX engine will be able to handle most requests – which means that pages aren’t sent to and from the Web server. This makes things much faster and reduces network traffic. The other very interesting thing about AJAX is the fact it controls what the user sees on screen. And the reason this is important is because it allows applications like word processing or spreadsheets to be run from a Web server. And the reason that is important is because the application is platform agnostic and it can be updated anytime. Let’s unpick that last sentence a little. Basically, it means that users can run the same application on a Mac, a PC, or Linux – so long as they are connected to the Internet. It means they use the same application no matter whose computer they are working on. So gone are the days of people familiar with using MacWrite having to use Word, or AmiPro (or whatever). Users can always load their favourite word processor etc. And the other big advantage is that upgrades to the application happen easily and automatically. I use Word 2000 on one laptop, but have 2002 on a slightly newer one. They are very similar, but not the same. This would never happen with AJAX. As the application was developed, users would always download the latest version. AJAX can easily offer word processing etc because it allows drag-and-drop and those other facilities we’re all used to through using a GUI. But is this all pie-in-the-sky or is anyone really doing this? The answer is a definite yes. Google was a very enthusiastic supporter, and Google Earth (earth.google.com) uses it (although I can’t get Version 4 to work – Version 3 was excellent). Flickr (www.flickr.com) the photo sharing site uses it. And there are lots of others – so many that there’s no point my listing them here. IBM is a big AJAX supporter. Early this year IBM announced the AJAX Toolkit Framework (ATF) for building Integrated Development Environments (IDEs) for different AJAX run-time environments. IBM has said that it will give away its Eclipse-based code to Open AJAX – an organization supported by BEA, Borland, Eclipse, Google, Laszlo Systems, Mozilla, Novell, Openwave Systems, Oracle, Red Hat, and Yahoo. AJAX applications turn out to be particularly good at tasks such as updating or deleting records, returning simple Web queries, or expanding Web forms. This is because those activities don’t require a new page to be loaded. They can run on any platform that supports a browser. The skills required to write AJAX are really extensions to JavaScript and DHTML – which means there are plenty of developers who could do it. The other big plus for AJAX is that IBM has put its full weight behind it, and Microsoft is also now an AJAX supporter (see their ATLAS announcements). AJAX users may notice a big difference between AJAX doing the work and a refresh from the Web server. It’s important with AJAX development that users pressing the “back” button see what they expect, and that they see an icon indicating that the computer is doing something. It’s also necessary to use a browser that supports AJAX – some old ones don’t. On the whole, AJAX seems to offer next generation working today. It’s one of those developments that you think is so obvious you should have thought of it yourself. If AJAX itself isn’t the complete answer then it’s certainly a giant step in the right direction.

Friday, August 18, 2006

‘Killing’ CICS tasks with CICS Performance Monitor

A question often asked is, “What capabilities exist to ‘kill’ a task from a given CICS system via CICS Performance Manager?”. (Here we are using the term ‘kill’ to refer to the action provided by many performance management monitors.) CICS Performance Monitor bases its facilities on those of CICSPlex System Manager. CICSPlex SM itself is an EXEC CICS application, and therefore provides the ability to PURGE and FORCEPURGE tasks. Those facilities are exploited by CICS PM. Killing a task in a CICS region can have catastrophic consequences; for instance, no data integrity is guaranteed. As an example, consider the consequences of purging a task in a DB2WAIT condition. Having killed the task, the DB2 subsystem could subsequently post an ECB in the CICS system where the storage is no longer the requestor’s ECB. This could have disastrous results. Nevertheless, the customer may deem this risk acceptable. Whilst this is a concern to CICS system programmers or operators, this function is used in the scenario where a region would have to be brought down anyway to resolve the problem, and killing the task will allow the region to continue processing critical work for some time. An example would be resolving a problem in a trading organization just before the market closes. The problem is actually subtler than this, and can be broken down into the following items:
  • Which system is the problem in?
  • Which task do I want to kill?
  • How do I kill it?
So, we need to know which task to kill before we can kill it. In order to understand this topic, some appreciation is required of the underlying architecture of CICSPlex SM (upon which CICS PM is built), along with a classification of types of work running within the CICS system, and the CICS system’s current state. CICSPLEX SM AGENT ARCHITECTURE CICSPlex SM (CPSM) provides single system image management through a network of CICS Managing Address Spaces (CMASs). These CMASs communicate with CPSM agents running in the target CICS regions. For example, these agents are responsible for INQUIREing and SETting the attributes of CICS resources. Communication from the CMAS to the CPSM agent is achieved through a communications agent, also running in the CICS region, which mediates requests from the CMAS. Communication with this agent is via MVS cross-memory services (not CICS communication services). The communications agent, query, and set agents, along with other CPSM infrastructure services, are initialized at CICS initialization via PLT processing. This establishes long-running tasks that, essentially, process requests for the lifetime of the CICS region. These resources run on the QR TCB. This does expose them to the possibility of being blocked because looping tasks dominate the QR TCB, or delayed through resource shortage (eg storage). CICS WORKLOAD TYPES CICS workloads can be classified into various types for the purposes of this discussion as follows:
  • Normally executing tasks – the vast majority of CICS tasks. These are susceptible to a CEMT PURGE TASK command.
  • Looping tasks – these are tasks that can be looping within themselves (and therefore susceptible to CICS runaway task detection process, ICVR process). They are looping through the CICS exec layer issuing EXEC CICS commands.
  • Tasks in a purgable wait – these are susceptible to a CEMT FORCEPURGE TASK command.
  • Tasks in a non-purgable wait (eg a DB2WAIT) – these are not susceptible to a CEMT FORCEPURGE command, but are susceptible to a kill command. It should be noted that the number of situations in which tasks are placed into a nonpurgable wait has reduced with each CICS release. For example, dispatcher and DB2 changes in CICS TS 2.2 have resulted in the ability to purge tasks in a DB2WAIT state without the need for kill.
CICS STATE The state of the CICS system can also play a role in being able to kill a task. If the system is at maxtask or is short on storage, then a new task (such as CEMT) cannot be dispatched. This is an instance where CPSM’s long-running task architecture will be able to issue the appropriate command, whilst base CEMT would not. The scenarios are summarized in Figure 1.
ClassCEMT CPSM, CICS PMThird Party Tools
AYes YesYes – normal stuff
BNoYesYes – eg region at maxtask
CNoNoYes – unable to dispatch on QR TCB
DNoNo No – the rest
Class A is the majority of situations; Class B can still be performed by CPSM; Class C is a very small (and reducing) class because of CICS internal changes; Class D is minute and no-one addresses it. CICS PURGE PROCESSING The current CICS purge processing is as follows. Upon receipt of a purge request, the CICS dispatcher saves the purge request information. If the purge is not successful, a purge is retried each time the task is suspended, and a deferred abend request issued. The purge may be rejected because the task is not suspended, or the task is purge/forcepurge protected. OPPORTUNITIES TO EXTEND CICS TS IN THIS AREA CICS PM supports CICS TS 1.3 and CICS TS 2.2. Open Transaction Environment TCBs were introduced in CICS TS 1.3. These TCBs execute independently of the CICS QR TCB. It would be possible to provide communications endpoints and INQuire/SET services from an OTE TCB. In this way, management services would still be available when the QR TCB is hung up. Extensions to the ICVR and PURGE mechanisms could establish the need to kill a task; if not immediately attainable, this would be performed on subsequent traversal of the CICS exec layer. Other obvious places include RMI calls and DL/I command interfaces. This could exclude some of the current checks that are made to ensure data integrity. Purging of tasks could also be prioritized by age of the tasks. SUMMARY Some third-party performance products provide the ability to kill tasks in a CICS system. Extensions to CICS Transaction server have, in each release, reduced the need for such a function. The longrunning agent architecture of CICSplex SM also reduces the number of cases in which such a function is necessary. There is, however, a very small subset of scenarios where such a function is required. We are looking at ways in which to provide such function via CICS Transaction Server, which will be utilized by a future release of CICS Performance Monitor. Paul Johnson CICS Transaction Server Systems Management Planning/Development IBM Hursley (UK) © IBM Reprinted with permission

Monday, August 14, 2006

Host Access Client Package for Multiplatform announcement

Looking back over the evolution of mainframes, there have been a few “great leaps forward”, but the majority of improvements have come trickling through in a way that seems to go unnoticed – yet the way we’re working today is easier and quicker than last year and a million times better than ten years ago. And those of us who can remember how things were over twenty years ago – well … One such “trickle” announcement is IBM’s recently-announced HACP (Host Access Client Package) for Multiplatform and for iSeries, which are available 8 September. Both versions include Version 5.9 of Personal Communications for Windows and Version 10 of WebSphere Host On-Demand (HOD). HACP is marketed by IBM as “the solution to all of your host connection needs”. It supports SNA, APPC, HPR, and other related technologies. V5.9 of Personal Communications has a number of useful enhancements. It now supports Windows x64 platforms – including Windows XP Pro, and Windows Server 2003 Standard and Enterprise editions. The downside to this is that x64 support is available only in “compatibility mode” – ie it’s not available in SNA environments. I assume the thinking is that sites are all migrating away from SNA to IP networks so it’s not a problem. Another important update is support for Kerberos ticketing. On iSeries (or OS/400 platforms) using Kereberos-based Single Sign-On (SSO) reduces the number of passwords a user needs to know and use (or, as we’ve seen all too often, have written on post-it notes stuck to the side of the screen!). The list of enhancements also includes more centralized control for administrators – such as the power to control a user’s ability to modify their session’s view. Administrators are also able to identify when a product is being used or even installed – although this requires Tivoli Licence Manager to be already installed. There are some printing enhancements – allowing lots of print files to be collected and printed as a single job. It’s also possible to use Windows GDI (Graphics Device Interface) print capability for VT host printing. Finally, there’s support for concurrent IPv4 and IPv6 connections and support for Telnet security. Version 10 of WebSphere HOD now supports IBM’s Workplace software. This means that users can create HOD plug-ins that will run on any software based on Workplace Client Technology (WCT) on Windows. Support for JSR 168 allows HOD to create portlets that will run on any JSR 168-compliant portal server (which WebSphere is!). There are some other enhancements such support for FTP’s copy append function. Overall, quite a useful release upgrade to a useful connectivity package. And, like I say, a small trickle, a tiny advance, making computing better.

Friday, August 11, 2006

Quick log-off from CICS

A colleague recently made the following request, having just converted from ACF/2 to RACF. ACF/2 allowed a quick log-off and disconnect from CICS by typing the transaction LOGO (as in LOGOFF). While the same function can be performed by typing the transaction CESF LOGOFF, users still wanted to be able to use the shortened command. As an exercise in using some of the new features introduced in CICS Version 4.1, as well as an exercise in using the SPI, the following programs were quickly developed. The programs are associated with the transaction LOGO, but could just as well be associated with a PF key to speed log-off. The first example uses the RETURN IMMEDIATE feature to process the request, and demonstrates how a message may be passed to the program so that the program receiving control treats the input message as if it were typed at the terminal.
PRINT NOGEN DFHEISTG DSECT MSG DS CL11 , AREA TO HOLD MESSAGE LEN DS H , LENGTH OF MESSAGE LOGO CSECT LOGO AMODE 31 LOGO RMODE ANY MVC MSG,=C'CESF LOGOFF' MOVE LOGOFF TEXT TO MSG MVC LEN,=AL2(L'MSG) SET LENGTH OF MESSAGE EXEC CICS RETURN TRANSID(=C'CESF') X IMMEDIATE INPUTMSG(MSG) INPUTMSGLEN(LEN) END LOGO The second program uses the SIGNOFF command and the SPI command INQUIRE TERMINAL, together with the CICS API command ISSUE DISCONNECT, to obtain the same results. Note: because this program was written as an exercise rather than as a production application, error handling is less than complete. PRINT NOGEN DFHEISTG DSECT DISC DS F MSG DS CL18 LOGO CSECT LOGO AMODE 31 LOGO RMODE ANY EXEC CICS INQUIRE TERMINAL(EIBTRMID) DISCREQST(DISC) CLC DFHVALUE(NODISCREQ),DISC BE SEND EXEC CICS SIGNOFF NOHANDLE EXEC CICS ISSUE DISCONNECT B RETURN SEND DS 0H MVC MSG,=C'LOGOFF NOT ALLOWED' EXEC CICS SEND FROM(MSG) LENGTH(=H'18') RETURN DS 0H EXEC CICS RETURN END LOGO
Donald H Blake Systems Programmer Key Services (USA) This article was reprinted with permission.©2006

Tuesday, August 08, 2006

A heads-up for CICS people

Because the August issue of Xephon’s CICS Update (http://www.xephonusa.com/) journal contains such interesting articles covering important technology areas for CICS users, I thought it was worth just drawing your attention to them. The first article is by Aseem Anand, a senior systems programmer with US-based Syntel, and it takes a detailed look at the always essential issue of CICS performance. The article is entitled “Analysing the performance of CICS systems”. It describes what can be achieved through CICS performance analysis, highlighting areas such as deviation from performance objectives, system modification, and calibrating individual transactions. It discusses which metrics are useful – such as processor usage, I/O rates, message or block sizes, virtual storage limits, paging rates, and error rates. It also goes on to talk about different methods that can be used for performance analysis – measuring a system under full production load and measuring single-application transactions – and how these can be achieved. CICS has gone from being a bet-the-business subsystem running on hardware locked away in darkened computer suites to being the bet-the-business system that anyone with a browser (and appropriate authority) can use. CICS transactions are now being made available as Web services. Another of the articles in CICS Update looks at the growth of CICS Web services. Laxminarayan Sriram’s article briefly looks at CICS’ first support for the Internet back in 1994, and runs through its evolution to where we are now – particularly highlighting important developments. In a way continuing the SOA theme, an article by John Bradley, a systems programmer with Meerkat Computer Services in the UK, takes an in-depth look at bridge environments. In the article, entitled “Determining the bridge environment model for your CICS environment”, John describes the four bridge models available – long-running monitor, two-task model, single-message monitor, and the direct model. The article provides the right questions to ask to help you decide on the right bridge environment, and dissects each one. In addition, the issue also contains articles looking CICS application architecture, a brief look at Attunity’s CICS-related products, and the first part of an article discussing CICS TS and Java. I’m not telling you to rush out and buy it, it’s just that sometimes with everyone’s busy schedules, interesting stuff like this can be completely missed and a lot of time can be spent later searching Google (or whatever) to collect the same information for an on-site project. So, if you’re interested in CICS performance or SOA at the moment, this is a heads-up for you.

Monday, August 07, 2006

A new CEMT program in COBOL to start and stop CICS

CICS is more than 30 years old, but it now supports applications written in C++ and Java, and it allows a single application image to be spread over several computer systems. To achieve such youthful longevity, CICS has undergone many transformations. IBM mainframe products get three levels of version number within a distinct named product. CICS is on its third distinct product name, and its fifth high-level version number. It has been maintained at two different IBM facilities since first being marketed. An OLTP manages transactions that exhibit the following four ACID properties, as explained in Gray & Reuter’s book (1993): Atomicity, Consistency, Isolation, and Durability. Although CICS did not have functions like journalling to support all of these properties at first, it did have them very early in its life. Like any OLTP, CICS has to interact with telecommunications networks, database managers, different programming languages, and the features and constraints of operating systems. Another way to look at CICS is that it allows a large number of users to share a relatively small number of resources with data integrity. The first versions of CICS were developed in a former IBM facility near Chicago. In 1973, IBM moved CICS development to Hursley, a village near Winchester, UK, where it has remained ever since. Today, no on-line system could survive without some way to access the World Wide Web. IBM introduced the CICS Web Interface product in 1996. Since then, there have been various solutions and enhancements to CICS to allow applications to interact with Web browsers. The latest version, CICS Transaction Server for OS/390 Version 2.2, allows legacy application programs to interact with Web browsers as if they were 3270 terminals, and it allows new programs to present a modern interface on Web browsers. To help customers give legacy applications a new look on the World Wide Web, the CICS team created the Front End Programming Interface (FEPI) in CICS/ESA Version 3.3 in 1992. FEPI allows a CICS transaction to emulate a 3270 terminal. The idea is to write a new FEPI transaction to sit between a legacy CICS application and a Web server. That way, the legacy application, which was written for 3270 terminals, can continue to run unchanged. I wrote a simple COBOL program to start and to stop CICS.
HOW TO INSTALL XCEM CEMT Submit the following job to compile the source program: //SRSTXCEM JOB SRS1ØØ44,SYSTEMES,CLASS=G,MSGCLASS=T,NOTIFY=&SYSUID // EXEC DFHC3LCL, //* INDTG=ESS, //* DEBUG=OUI, // SP=',SP', // OUTC=T //LIBR.SYSIN DD * -OPT LIST -DLM SRSTXCEM -ADD SRSTXCEM,SEQ=/81,6,1,1/ IDENTIFICATION DIVISION. PROGRAM-ID. SRSTXCEM. ********************** F U N C T I O N ************************** * * * stop CICS * * * ***************************************************************** ****************************** ****************************** * *cics stop command ***************************************************************** ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 77 W-DEBUT PIC X(8) VALUE 'SRSTXCEM'. 77 W-RETOUR-LIB PIC X(9) VALUE 'EIBRESP->'. 77 W-RETOUR PIC S9(8) COMP VALUE +Ø. 77 W-EIBFN-LIB PIC X(9) VALUE ' EIBFN ->'. 77 W-EIBFN PIC X(2) VALUE SPACES. Ø1 W-ANO-CN. Ø5 W-APPLID PIC X(8). Ø5 FILLER PIC X. Ø5 FILLER PIC X(5Ø) VALUE 'UTILIZATION OF XCEM FOR - ' NON AUTHORIZED USERS ('. Ø5 W-USERID PIC X(8). Ø5 FILLER PIC X(7) VALUE ') TERM('. Ø5 W-TERM PIC X(4). Ø5 FILLER PIC X VALUE ')'. Ø1 W-PARAM. Ø5 W-TRANS PIC X(4). Ø5 FILLER PIC X(76) VALUE SPACES. * PROCEDURE DIVISION. * *1- ANALYSE COMMAND ....... * 1ØØ-INIT. IF EIBTRMID(1:2) NOT = 'CN' MOVE EIBTRMID TO W-TERM EXEC CICS ASSIGN APPLID(W-APPLID) END-EXEC E XEC CICS ASSIGN USERID(W-USERID) END-EXEC EXEC CICS WRITE OPERATOR TEXT(W-ANO-CN) CRITICAL END-EXEC EXEC CICS RETURN END-EXEC END-IF EXEC CICS RECEIVE INTO(W-PARAM) RESP(W-RETOUR) END-EXEC MOVE 'CEMT' TO W-TRANS EXEC CICS XCTL PROGRAM('DFHEMTP') INPUTMSG(W-PARAM) INPUTMSGLEN(LENGTH OF W-PARAM) END-EXEC. -END /*
XCEM CEMT will run on any CICS from Version 4.1 upwards. Copy the member XCEM to a loadlib in the DFHRPL list of your desired CICS region. Enter the following commands, into either CEDA or the batch program DFHCSDUP:
DEFINE TRANSACTION(XCEM) GROUP(XCEM) DESCRIPTION(XCEM CEMT) PROGRAM(XCEM) TASKDATALOC(ANY) PRIORITY(255) DEFINE PROGRAM(XCEM) GROUP(XCEM) DESCRIPTION(XCEM CEMT) LANGUAGE(ASSEMBLER) DATALOCATION(ANY)
The transaction name can be changed, but should start with ‘C’ to allow it to run at Maxtasks. Use CEDA to install the group XCEM. Enter the transaction XCEM and enjoy! Claude Dunand Systems Programmer (France) This article was reprinted with permission.
©

Friday, August 04, 2006

The Evolution of Storage Technologies: Why You Need Disk-Based Rapid Recovery Systems, Not Just Tape

Mainframes have become increasingly central to business resiliency and information lifecycle management strategies. A reliable, resilient platform, mainframes are a logical choice to serve as a core technology for operational continuity and disaster recovery.

Tape storage has traditionally been the primary mainframe backup medium, but it no longer serves the purpose for which it was initially appropriate. Tape still has its place in a disaster recovery architecture, but it no longer sufficiently serves most or all an enterprise’s storage and recovery needs. Tape is physically insecure and a far less efficient means of quickly recovering the full range of information required to restore a business following a catastrophic failure.

Data: When It Absolutely, Positively Has to Be (Lost) Overnight

Tape has made dramatic advances in speed and capacity, but the security problem offsets those advances. Several states have enacted legislation similar to California Senate Bill 1386, which says companies or agencies that lose personal data “shall disclose any breach of the security of the system following discovery or notification of the breach in the security of the data to any resident of California whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person.” A similar initiative is being considered in the U.S. Senate, spearheaded by Judiciary Committee chairman Arlen Specter of Pennsylvania.

In this new, increasingly regulated environment, the advantages of disk-todisk backup and recovery compared to tape have become clearer. Experts will tell you a true disaster recovery and business continuity plan requires you to ship your information offsite and have it in position to quickly recover when things go wrong. Traditionally, that’s meant shipping tapes from point “A” to point “B,” within a relatively short drive of the main production point. (Large enterprises could spend millions of dollars on failover sites that can have businesses back up and running within moments, but most firms don’t have sufficient funding for that.)

But shipping tapes, even shipping removable hard drives offsite, has taken on increased peril; the list of companies that have reported tapes lost in shipment containing personal information in the last 24 months reads like a “who’s who”: Citigroup, TimeWarner, Amerigroup, Bank of America, and many more. They’re reporting these snafus only because stricter federal laws, such as Sarbanes-Oxley, the Health Information Portability and Accountability Act (HIPAA), and Gramm-Leach-Bliley, require them to do so.

Mary Jander, editor of “Byte and Switch,” an online news site devoted to data protection, put it succinctly: “If you’re dumb enough to send your data off in a can with somebody’s semi-employed driver,” she wrote last July, “you shouldn’t be surprised when things don’t turn out the way you’d planned.”

To read the rest of this article please visit z/journal magazine.

This excerpt is reprinted with permission.