Automatic Deletion of TS (Temporary Storage) Queues for CICS TS v4.2

CICS TS (Customer Information Control System Transaction Server) is IBM’s general purpose TP (Transaction Processing) monitor, application server and a middleware for system z servers.

During its regular operation, CICS utilizes TS queues for temporary storage requirements together with other types of resources. It is easy to utilize, just write some data, read later and delete the queue when you finish with it. But if applications are not developed by-the-book then it becomes nightmare for operations people. Local TS data set fills up, tasks either freeze or abend (Abnormally end) after the message:

DFHTS1311 cicsname Temporary storage data set is full and cannot be extended

If operations people cannot judge which queues to “purge”, the region is recycled, TS being started COLD clearing up TS queues.

After a number of incidents, “Lastusedint” parameter of TS entry is considered. This parameter displays the elapsed time in seconds since the queue was last referenced. Following master operator command could be issued or set to automation system for that region to purge TS queues older than 1 hour (3600 seconds):

CEMT Set TSqueue(*) Delete Lastusedint(3600)

Some shops utilize SPI (Systems Programming Interface) programs executed periodically to browse TS queues and delete unreferenced queues after specified interval.

For CICS TS v4.2 a new attribute EXPIRYINT is introduced for TSMODEL resource definition.

CEDC View TSmodel( USRTSM01 )
TSmodel : USRTSM01
PRefix : +
XPrefix :
Location : Auxiliary Auxiliary ! Main
Expiryint : 00001 0-15000 (Hours)
RECovery : No No ! Yes
Security : No No ! Yes
POolname :
REMOTESystem :
REMOTEPrefix :
XRemotepfx :

Value of EXPIRYINT specifies expiry interval in hours and applicable nonrecoverable and local queues. Recoverable queues and queues created by CICS system are not effected.

Name prefix + (Plus sign) specifies model will match TS queues starting with any characters. Some more specific prefixes can be defined.

After installing model, it can be observed in TS models:

Tsm(DFHWEB ) Pre(DFHWEB ) Mai Exp(00000)
Tsm(DFHISLQ ) Pre(DFISLCLQ ) Aux Rec Exp(00000)
Tsm(USRTSM01) Pre(+ ) Aux Exp(00001)

If the TS queue name is matched to a TSMODEL with expiry interval, EXPIRYINT value of TS queue is set on creation.

Tsq(ESBV ) Num(00001) Len(0000000128) Aux
Tra(EKE2) Max(00128) Min(00128) Las( 00001003 ) Exp(00001)
Tsq(E346 ) Num(00001) Len(0000000128) Aux
Tra(EKE2) Max(00128) Min(00128) Las( 00002020 ) Exp(00001)
Tsq(IP31 ) Num(00005) Len(0000000640) Aux
Tra(EKE2) Max(00128) Min(00128) Las( 00002628 ) Exp(00001)
Tsq(I9IO ) Num(00001) Len(0000000128) Aux
Tra(EKE2) Max(00128) Min(00128) Las( 00002620 ) Exp(00001)
Tsq(KOJG ) Num(00002) Len(0000000256) Aux
Tra(EKE2) Max(00128) Min(00128) Las( 00004095 ) Exp(00001)
Tsq(KRBH ) Num(00001) Len(0000000128) Aux
Tra(EKE2) Max(00128) Min(00128) Las( 00002826 ) Exp(00001)
Tsq(KTAF ) Num(00006) Len(0000000768) Aux
Tra(EKE2) Max(00128) Min(00128) Las( 00003902 ) Exp(00001)
Tsq(KTBB ) Num(00001) Len(0000000128) Aux
Tra(EKE2) Max(00128) Min(00128) Las( 00001725 ) Exp(00001)
Tsq(MNBZ ) Num(00001) Len(0000000128) Aux
Tra(EKE2) Max(00128) Min(00128) Las( 00001829 ) Exp(00001)

CICS cleanup task periodically scans TS queues once in half an hour and deletes expired TS queues. Scanner issues a message similar to below message upon completion:

DFHTS1605 07/16/2012 12:12:26 CICS7248 Scan of local temporary storage queues completed. 30 local temporary storage queues were scanned and 8 were deleted.

Please note that expiry intervals of TS queues created before installing TS model with expiry interval do not change. Those queues should be deleted once and for all.

You could observe TS queues with last used interval larger than 3600 seconds (up to 5400 seconds actually) even if you set expiry interval to one hour. This is due to the execution periods of CICS scanner. It executes half an hour periods and some TS queues survive beyond 3600 seconds.

Posted in CICS Transaction Server | Tagged , , , , , , , , , , , , | Leave a comment

Shortening z/OS Recycling Time

IBM System z server workloads are comprised of heterogeneous transaction types. DB2 queries, WAS (Websphere Application Server), Websphere MQ (Message Queueing oriented middleware), CICS TS, CTG (CICS Transaction Gateway), RDZ (Rational Developer for System z), IMS (Information Management System) transactions. Together with builtin TCP/IP stack and Unix Systems Services, all of the facilities are served to enterprise ITC infrastructure through a lot of daemons.

Workloads are organized as address spaces. Address spaces are 64-bit addressable program and data containers. Initialization of server operating system consists of initialization of all address spaces one after the other.

Standalone zOS operating system instances have a few minutes of downtime per year. Clustering as Parallel Sysplex (Systems Complex) makes them available continuously. Although continuous operations is a daily routine for System z shops, scheduled recycling is necessary for release upgrades or testing initialization procedures for disaster recovery facilities.

Large shops have automation tools with initialization, termination and recycling procedures. Recycling may be an operational burden for shops without such tools. There are two contradictory considerations in recycling live systems. First one is not to cause loss-of-data and keep data integrity and second one is to keep outage as short as possible.

Termination consists of shutting down each address space one after the other. Next question is which address space to shut down first? There are “client” address spaces and “server” address spaces. It is logical to think to close down client address spaces first. Then server address spaces become idle and it becomes possible to terminate them normally without causing data loss.

Most important single group of address spaces to terminate normally is database related address spaces. Most probably DB2 and related address spaces. So address spaces using services of DB2 should be terminated earlier. Those are so-called middleware address spaces like CICS TS, Websphere MQ, CTG, WAS. Among address spaces in a group terminated concurrently, again consider terminating in-group clients like CTG and Websphere MQ earlier than server in this case CICS TS.

DB2 not terminating normally? I am keeping the advice “Do not mention MODE(FORCE) termination option of DB2, it may have side effects and create problems..” of my colleague DB2 Expert! I am just summarizing his recommendations:

  1. Wait for “DSNYASCP ‘STO DB2’ NORMAL COMPLETION” message. Depending on number of active transactions and sizes of buffer pools, normal termination may take some minutes.
  2. If you do not receive normal completion display active threads and utilities using -DISPLAY THREAD(*) command. Wait for utilities to complete.
  3. Watch for batch, CICS protected threads, WAS and RRSAF connections. Either wait for completion or cancel using -CANCEL THREAD command.
  4. Terminate DDF using -STOP DDF command and wait for normal completion.
  5. If you sweat, keep cool and go to item number 1

For further information related with DB2, please refer to

Other groups of address spaces to terminate are as follows:

  1. Monitoring tools address spaces – Address spaces for monitoring tools like BMC MainView or Omegamon can be terminated after terminating DB2 address spaces.
  2. Printer related address spaces – They should be terminated before terminating communications server address spaces.
  3. Communications server address spaces – They are TCP/IP and VTAM. TCP/IP and related address spaces like TN3270E should be terminated before. Because OSA (Open system adapter) interface devices are defined to VTAM.
  4. SMS (System Management Storage) related address spaces – They are HSM (Hierarchical Storage Manager) and RMM (Removable Media Manager, cartridge management system) address spaces. They can be terminated any time provided that space management and cartridge I/O activities do not take place.

Printer signoff, inactivate, disconnect, line drain commands may flood system consoles for installations without console message automation. If this is the case, following messages can be suppressed by MPF (Message Processing Facility):


zOS consoles are 3270 terminals. Model 2 terminals have 19 lines for messages, model 4 terminals have 39 lines for messages. Consoles are designated to keep messages on screen at least for 1/4 seconds. So in one second at most 4 * 39 = 156 messages can be displayed. Termination messages for thousands of printers flood console screens for long time not to mention several messages for one printer and related line. During flood termination of other other address spaces may not be observed.

To wrap up, following procedure may be used for termination:

z/OS Shutdown Procedure

Date: ________________

Start Time: ________________

Command Description
Start a TSO session, a monitoring tool session and an HMC (Hardware Management Console) session Display SDSF screenDisplay DB2 threads screen
STOP CTG720MODIFY CICSxxxx,CEMT PERFORM SHUTDOWN IMMEDIATESTOP CHCPROC Terminate CTGTerminate CICS regionsTerminate IBM Infosphere CDC (Change Data Capture)

Terminate other DB2 client address spaces

-STOP DB2 Wait for normal completion
DISPLAY A,L See all CICS and DB2 address spaces are terminated
Terminate monitoring tool address spaces Logoff monitoring tool
SET MPF=(00,PR) Issue MPF command to suppress printer termination messages provided that MPFLST00 is standard MPF PARMLIB member and MPFLSTPR is the member prepared to suppress printer messages
STOP TN3270ESTOP TCPIP Logoff TSO (Time Sharing Option) session
STOP TSO Stop TSO address space
HALT EOD Make sure that SMF records are written
$P JES2,ABEND Reply like xxEND

End Time: ________________

Initials: ________________

Command Abbreviations











Posted in IBM zEnterprise Servers | Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | Leave a comment

Daylight Saving Time Settings in IBM Mainframes – IBM Büyük Sistemlerde Yaz Saati Uygulaması

Donanım ve yazılım platformlarında saatlerin ileri ve geri alınması genellikle otomatik olarak gerçekleşir. IBM büyük sistemlerde bu işlemler otomatik olarak yapılmaz.Önce zaman kavramlarını gözden geçirelim. Kullandığımız yerel saat, bulunduğumuz boylamın Greenwich kasabasından uzaklığıyla orantılı olarak belirlenmiştir. Greenwich kasabasındaki saate GMT (Greenwich Mean Time) veya daha güncel deyimle UTC (Coordinated Universal Time, Eşgüdümlü Evrensel Zaman) diyeceğiz. Ülkemiz doğuya doğru iki saat ileridedir.

Bu durumu aşağıdaki zaman çizgisinde görüyorsunuz.

Daylight saving time settings are performed automatically in most hardware, software and middleware platforms. This is not the case for IBM System z servers.First let’s go over time concepts. Local time we use is determined proportionally by the distance of the longitude of our location to Greenwich town. The time in Greenwich is called GMT (Greenwich Mean Time) or UTC (Coordinated Universal Time) as a more recent expression. Turkey is two hours ahead of beginning longitude.

You can observe the following timeline for details.

Bu durumu işletim sistemine tanımlarız. Veri tabanı ve uygulama sunucusu gibi sunucular zaman bilgisini gerektikçe işletim sisteminden alır. Yani sistemler açılırken yerel saati belirtmemizin yanısıra bulunduğumuz zaman dilimini de belirtiriz. Zaman dilimimizi E02.00.00 gibi belirtiriz. Biz doğuya doğru iki saat ilerideyiz anlamına gelir. İşletim sürecinde bu yerel saat ve GMT (UTC) değerleri işletim sistemi tarafından güncel tutulur.Veri tabanı sistemleri güncellemeler ve geri dönüşler için kullandığı log kayıtlarını GMT (UTC) saatine göre damgalar. Uygulama sunucuları ise yerel saati kullanırlar.

Bazı kuruluşlar zaman dilimini Greenwich kasabasında imiş gibi tanımlarlar. Bu durumda yerel saat ve GMT (UTC) aynı olur. Bu iki saatin aynı olması yaz saati uygulaması prosedürleri açısından bir fark doğurmaz.

Şimdi sistem komutlarıyla saat ve zaman dilimi değiştirme özelliklerini gözden geçirelim.

SET CLOCK sistem komutu yalnızca yerel saati değiştirir. Aşağıdaki örnekte bunu görebilirsiniz. Önce ve sonra DISPLAY TIME komutları girerek SET CLOCK komutunun dökümantasyonda belirtildiği gibi yalnızca YEREL saati değiştirdiğini görürsünüz.

We define this parametrically to the operating system. Data base management servers, application servers and middleware received this information from the operating system whenever necessary. We define timezone like E.02.00.00. This means that we are ahead of two hours toward the east. In the process of operation local time and GMT (UTC) maintained current.Data base systems use GMT (UTC) time in log timestamps maintained for recovery purposes. Application servers use local time instead.

Some institutions use GMT (UTC) timezone as if they are operating in Greenwich town. In this situation local time is equal to GMT (UTC) time. This equality does not create a difference in setting operating procedures for daylight saving time.

Now let us go over changing clock and timezone parameters.

SET CLOCK system command changes local time. You can observe this at the following example. Entering display commands before and after command, you observe that command just changes local time as documented.

IEE136I LOCAL: TIME=10.09.40 DATE=2011.304 UTC: TIME=09.09.40 DATE=2011.304

SET CLOCK=11.10.00

IEE136I LOCAL: TIME=11.10.08 DATE=2011.304 UTC: TIME=09.10.44 DATE=2011.304

SET TIMEZONE komutu parametre olarak belirttiğimiz saat farkını GMT (UTC) değerine ekleyerek veya çıkararak yerel saati değiştiriyor. Yine önce ve sonra görüntüleme komutları yazarak bunu görebilirsiniz. Timezone change command takes time difference you mention and changes local time adding to or substracting from GMT (UTC) time. You can observe this by displaying before and after time settings.

IEE136I LOCAL: TIME=11.08.52 DATE=2011.304 UTC: TIME=09.08.52 DATE=2011.304


IEE136I LOCAL: TIME=10.09.40 DATE=2011.304 UTC: TIME=09.09.40 DATE=2011.304

Bu değişiklikleri yine zaman çizgilerinde görelim.Yaz saati başlangıcında sistem saatini veya zaman dilimini bir saat ileri aldığınızda yerel saatle oynamış oluyorsunuz. SET TIMEZONE komutunun 2008 yılında z/OS V1.9 sürümünde geldiğini tekrar hatırlatıyoruz. Let us review this changes in below timeline.When daylight saving time starts, you just change local time by changing system clock or timezone. Let us remember that SET TIMEZONE command is introduced at z/OS V1.9 in 2008.

Böylece sunucuyu bir anda Mogadişu kentine ışınlamış gibi oluyorsunuz. Greenwich kasabasındaki saat değişmediği için veri tabanı log kayıtlarıyla ilgili bir sorun olmuyor. Ama konumuz dışındaki yerel saatle ilgili sorunlar sizin ve değişiklik danışma kurulunun önünüzdedir.Aynı biçimde yaz saati uygulamasının sonunda da zaman dilimini bir saat azaltarak batıya alıyorsunuz. Sunucunuz Türkiye’ye geliyor ve GMT (UTC) yine değişmiyor. It is like sending your server immediately to Mogadishu. As the time in Greenwich town has not changed, there is no problem with data base log records. But local time related issues we will not mention here may be still waiting attention of you and your change control board.At the end of daylight saving time, you set timezone one hour west. Your server comes back to Turkey and GMT (UTC) does not change again.

İşletimsel Prosedürİşletimsel prosedürü hazırlarken SET TIMEZONE komutunu kullanmanızı öneririz. Çünkü saati değiştirirseniz yerel saatle GMT (UTC) arasında saniyeler düzeyinde de olsa fark oluşur. Bunu gidermek çok pratik değildir.

Adımları şöyle özetleyebiliriz.

E.02.00.00 gibi GMT (UTC) zaman diliminden iki saat ileride olduğunuz durum için yapacağız.

Yaz saati uygulamasının başlatılması

  1. Saati ileri alacağınız zaman zaman dilimini SET TIMEZONE=E.03.00 gibi ayarlayınız.
  2. PARMLIB(CLOCKxx) üyesinde TIMEZONE=E03.00.00 gibi değişiklik yaparak saatin sonraki kapanışlar, POR ve IPL işlemlerinde de doğru kalmasını sağlayınız.

Yaz saati uygulamasının bitirilmesi

  1. Saati geri alacağınız zaman zaman dilimini SET TIMEZONE=E.02.00 gibi ayarlayınız.
  2. PARMLIB(CLOCKxx) üyesinde TIMEZONE=E02.00.00 gibi değişiklik yaparak saatin sonraki kapanışlar, POR ve IPL işlemlerinde de doğru kalmasını sağlayınız.

Eğer normal operasyonda GMT (UTC) saat dilimini kullanıyorsanız yaz saati uygulamasına başlarken zaman dilimini E.01.00 olarak ayarlamanız, yaz saati uygulamasını bitirirken E.00.00 olarak ayarlamanız gerekir.

İşletimsel prosedürleri hazırladıktan sonra veri tabanı geri alma ve kurtarma işlemlerinin beklediğiniz gibi olduğunu test sistemlerinizde gördükten sonra canlı sistemlerde uygulayabilirsiniz.

Gördüğünüz gibi yapılacak işlemler iki yönlüdür ve ilkini doğru yapmazsanız ikincisinde sıkıntı oluşur.

Operational ProcedureI recommend that you use SET TIMEZONE command. If you change clock, just local time changes and there would be a small difference with GMT (UTC). It is not so easy to get rid of this difference due to typing delay.

Steps are as follows.

Let us assume you are two hours ahead of GMT (UTC) with the definition E.02.00.00.

Starting daylight saving time

  1. When you set time ahead set timezone as SET TIMEZONE=E.03.00
  2. In PARMLIB(CLOCKxx) set TIMEZONE= E03.00.00 so time services are started correctly after later shutdown, POR and IPL procedures.

Ending daylight saving time

  1. When you set time behind set timezone like SET TIMEZONE=E.02.00
  2. In PARMLIB(CLOCKxx) set TIMEZONE= E02.00.00 so time services are started correctly after later shutdown, POR and IPL procedures.

If you are using GMT (UTC) timezone, set timezone as E.01.00 as you start daylight saving time and set timezone as E.00.00 as as you end daylight saving time.

After preparing operational procedures and testing data base recovery and rollback functionalities, you should observe results as you expect and then you could deploy these procedures to live systems.

As you may observe, operations is two-fold. If you do not perform first part then you could experience trouble and need to apply temporary workarounds.

Posted in IBM zEnterprise Servers | Tagged , , , , , , | Leave a comment

Migration of System z Servers

In Memory of Levent Durdu

Perfect friend, unfailing colleague, guiding leader we lost very early
1955 – 24 April 2008
Levent Durdu
Levent Durdu Anısına
Erken yitirdiğimiz mükemmel dost, yorulmaz iş arkadaşı, yol gösterici lider
1955 – 24 Nisan 2008

Existing Environments

  1. System test (a.k.a. SYST)
  2. Development and application test system (a.k.a. TEST)
  3. Production system (a.k.a. PROD)

Existing Software

  1. z/OS V1.4
  2. CICS/TS V2.3
  3. DB/2 V7.1
  4. Content Manager V8.2
  5. Monitoring tools

Migration Targets

  1. z/OS V1.10
  2. DB/2 V 8.1
  3. Monitoring tools

Extensively Utilized Components

  1. VTS (Virtual tape server)
  2. RMM (Removable media manager, cartridge management system)
  3. HSM (Hierarchical storage manager)
  4. Infoprint server
  5. SMTP server

Discontinued Components

  1. CICS/TS V1.3
  2. ACF/NCP (Advanced communication functions/Network control program)
  3. JES328X (Job entry subsystem 328X) Print Facility

Migration Steps

  1. Apply toleration, coexistence and fallback maintenance on existing software
  2. Migrate Content Manager CICS/TS system from V1.3 to 2.3
  3. Install z/OS V1.10
  4. Customize z/OS V1.10 as SYST (System test)
  5. Install DB/2 V8.1 as SYST
  6. Clone SYST system for TEST (Development and application test)
  7. Migrate TEST system to z/OS V1.10
  8. Clone TEST system for PROD
  9. Migrate PROD system to z/OS V1.10
  10. Install DB/2 V8.1 to TEST system
  11. Install TEST system to DB/2 V8.1
  12. Install DB/2 V8.1 to PROD system
  13. Install PROD system to DB/2 V8.1

DASD (Direct Access Storage Devices) Planning

  • 3390 Model 9 device geometry
  • 2 volumes for system catalog
  • 2 volumes for distribution libraries
  • 2 volumes for target libraries
  • 3 volumes for SMF (System Management Facility) data gathering
  • 6 volumes for paging
  • 6 volumes for spool
  • 1 storage volume for TSO (Time Sharing Option) datasets [For business continuity purposes]
  • 1 public volume for temporary datasets and dynamic dumps [For business continuity purposes]
  • 2 volumes for shared subsystem CDSs (Control datasets) [RMM and HSM]
  • 1 volume for DB/2 V8.1 installation system libraries
  • 1 volume for DB/2 V8.1 installation system catalog and table spaces

SSA (System Specific Alias) Planning

  • Installation naming conventions
  • Completion of missing aliases for existing datasets [Due to past re-creations/enlargements]

Stand-alone Editor ZZSA

  • IPLable CD verification, documentation and filing next to HMC (Hardware Management Console)


  • Full dump DSS (Dataset services) backups of system disks on cartridge
  • Retention period one month
  • Perform daily after modifications or weekly
  • Verification of stand-alone DSF (Device support facility) and stand-alone DSS cartridges

Catalog Considerations

  • Connect all existing user catalogs
  • Define all existing aliases
  • Connect master catalog of existing z/OS V1.4 system
  • Define SSA of existing z/OS V1.4 system as alias
  • Define SSAs of z/OS V1.10 system datasets
  • Define alias of SSA of z/OS V1.10 system as alias to other systems
  • SSA not usable for IBMUSER and SYSADM datasets, lengths of some dataset names are close to maximum. Aliases of IBMUSER4 and SYSADM4 will be used instead
  • Store all catalog listings on workstations in case of immediate access requirement

SMP/E (System Management Program/Extended) and Open MVS (a.k.a. OMVS) Datasets for Existing Subsystems

  • CICS/TS, DB/2 V7.1 and Content Manager SMP/E and OMVS datasets had been created using z/OS system default high-level qualifiers
  • Replication planned as they should be cataloged in the master catalog of z/OS V1.10 system

z/OS V1.10 Installation and Cloning

  • Initialize disks
  • Create master catalog
  • Clone distribution and target library disks
  • Allocate JES checkpoint and spool datasets
  • Define SMF clusters
  • Allocate static dump datasets
  • Define page datasets
  • Define couple datasets
  • Allocate and copy primary and backup RACF datasets
  • Update z/OS V1.10 templates for RACF datasets
  • Catalog RACF database name table
  • Move started task users from ICHRIN03 to STARTED profile for ease of maintenance
  • Catalog a dummy ICHRIN03 started task module
  • Allocate and copy UADS dataset

Cloning Existing CICS/TS V2.3 and DB/2 V7.1 Subsystems

  • Clone existing CICS/TS V2.3 and DB/2 V7.1 subsystems if not available to z/OS V1.10

Customer Specific Initialization and Customization Libraries

  • One set for each SYSPLEX (Systems Complex)
  • Protect generically
  • Do not modify z/OS V1.10 system libraries


  • Eligible for user modules
  • Add to LNKLST (Link list)
  • Authorize through PROG00 PARMLIB member


  • Operational jobstreams
  • Start using S RDR,J=member-name


  • Add to SYS1.IPLPARM(LOADxx) member
  • Modified initialization members will be stored here
  • Other PARMLIB libraries will have unmodified initialization members
  • Parameters of operational jobstreams will also be stored here
  • Load UNICODE conversion tables


  • Add to master JCL PARMLIB member
  • Add to JES procedure
  • Modified procedures and installation specific procedures will be stored


  • Installation, maintenance and modification jobstreams related with z/OS V1.10
  • Only one library as opposed to other customer specific libraries
  • Accessible by all other systems through SSA like SEZOS10.SYS1.USR.SAMPLIB


  • TCP/IP, FTP, TELNET 3270 and SMTP initialization parameters
  • Performance related parameters are migrated from PROD system
  • Separate TN3270E parameters from TCP/IP startup file for z/OS V1.10


  • Define to VTAM start procedure
  • Define to TN3270E start procedure
  • Authorize through PROGxx PARMLIB member
  • Eligible for USSTAB and other VTAM modules
  • Display system name and system specific VTAM APPLIDs on USSTAB


  • Define to VTAM start procedure
  • All modified VTAM start members are stored here
  • Members on other VTAMLST libraries are not modified


  • TGSPACE set to allow 6 full DASD spool space

SMF (System Management Facility)

  • Create 4 datasets for TEST system
  • Create 6 datasets for PROD system
  • Install IEFACTRT step termination exit
  • Setup RMF records collection
  • Migrate data gathering jobstreams

First IPL

  • Format JES2 spool
  • Examine SYSLOG to remove obsolete initialization statements and parameters
  • Examine SYSLOG to correct misplaced parameters
  • Compare SSI (Subsystem Interface) entries by D SSI,ALL
  • Compare authorized libraries by D PROG,APF
  • Compare Link list libraries by D LNKLST,NAME=CURRENT
  • Execute installation verification procedures (a.k.a. IVPs)


  • Define CDSs (Control datasets)
  • Enter new installation SYST objects manually
  • Migrate TEST and PROD SCDS datasets
  • Copy ACS routines to SYS1.USR.SMS library
  • Validate and activate SMS
  • Compare existence of all objects
  • OMVS and TCP/IP will be available after SMS activation


  • Connect VOLCAT to new system
  • Verify existence of cartridge volumes


  • Perform all security related modifications to clone system by batch jobstreams. It will be easier to repeat immediately before cutover


  • Define OPERLOG and LOGREC logstreams
  • Migrate DB/2 V7.1 RRS logstreams

WLM (Workload Manager)

  • Migrate definitions from PROD
  • Create TN3270E started task goal if not defined


  • Migrate Turkish translation table
  • Migrate SMTP specific Turkish translation table
  • Perform MAKESITE
  • Migrate TN3270E printer definitions
  • Migrate TN3270E LU groups


  • Execute SYSMOD listings for z/OS V1.10
  • Execute SYSMOD listings for CICS/TS V2.3, DB/2 V7.1 and Content Manager V8.2
  • Prepare and apply dummy MACLIB and LOADLIB SYSMODS


  • Perform DB/2 V7.1 customization and binds

Infoprint Server

  • Export z/OS V1.4 Infoprint Server configuration
  • Allocate a large HFS dataset for Infoprint Server
  • Mount temporarily to copy existing z/OS V1.10 configuration
  • Copy /var/Printsrv
  • Add HFS dataset to BPXPRMFS PARMLIB member to mount permanently
  • Import z/OS V1.4 printer configuration
  • Verify printer configuration from ISPF/PDF Infoprint Server panels
  • Migrate JES, VTAM and TCP/IP printer definitions
  • Test printing


  • Use DASD volumes for shared subsystems
  • Define Master CDS cluster
  • Copy z/OS V1.4 master CDS using IDCAMS REPRO utility
  • Update CDS ID using EDGUTIL
  • Allocate Journal dataset
  • Copy z/OS V1.4 journal dataset
  • Start DFRMM subsystem
  • Verify existence of cartridge libraries


  • Use DASD volumes for shared subsystems
  • Define CDS clusters
  • Copy CDS clusters from z/OS V1.4 system using IDCAMS REPRO utility
  • Allocate backup datasets
  • Allocate and copy journal dataset using IEBGENER utility
  • Migrate startup PARMLIB parameters
  • Prepare and include ADDVOL statements for newly installed z/OS V1.10 DASD volumes
  • Start DFHSM subsystem
  • Compare parameter configurations

Customer Specific TSO/E logon procedures

  • Administrators
  • Group administrators
  • Developers
  • Developers with Content Manager DB/2 access
  • Operators
  • Modified TSO/E logon procedures to SYS1.USR.PROCLIB
  • Modified ISPF/PDF panels to SYS1.USR.PANELIB
  • Display system name on each panel
  • Display user type header on each panel
  • Keep TSO/E and ISPF/PDF target libraries intact
  • Test all procedures

Batch and Online Program Compilation

  • Perform batch LE (Language environment) customization
  • Perform online LE customization
  • Copy z/OS V1.4 CICS/TS V2.3 and DB/2 V7.1 compilation jobs to SYS1.USR.PROCLIB
  • Convert jobstreams to Enterprise PL/I for z/OS
  • Test and document in SYS1.USR.SAMPLIB
  • Distribute to users

Compare z/OS V1.10 Clone System vs z/OS V1.4 System Members and Parameters

  • Logstreams
  • SMS objects
  • Infoprint Server

Final Tasks from z/OS V1.4 System Before Migration

  • Copy RACF and UADS
  • JES2 spool offload
  • SMF switch and collection
  • PARMLIB CONSOL00 member
  • TCPPARMS IP number
  • Final shutdown

First IPL from z/OS V1.10 System After Cutover

  • Record IPL address and LOADPARM for z/OS V1.4 system
  • Record IPL address and LOADPARM for z/OS V1.10 system
  • First IPL
  • Control IPL SYSLOG
  • JES2 restore spool
  • Migrate, validate and activate SMS
  • Check VTAM network connections
  • Check TCP/IP network connections, perform SITEINFO
  • Check Infoprint Server printers
  • Start DB/2 V7.1 subsystems
  • Start CICS/TS systems
  • Migrate and start RMM
  • Migrate and start HSM

End of Migration

  • Celebrate
Posted in IBM zEnterprise Servers, Project Management | Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | Leave a comment

Proje Risk Yönetiminde Bilgelik – Bilgi Yönetimi

Bu makale risk yönetimi süreçleri içindeki araç ve teknikleri değerlendirerek bu süreçler içinde bilgi yönetimi kavramlarının kullanılışını anlatıyor. Önce bilgi yönetimindeki veri, enformasyon, bilgi ve bilgelik kavramları açıklanıyor. Ardından proje risk yönetimi süreçleri gözden geçiriliyor. Süreçler içindeki araç ve tekniklerin uygulanmasında kullanılan bilgi yönetimi kavramları örneklerle açıklanıyor.
This article explains usage of knowledge management concepts in tools and techniques of risk management processes. First data, information, knowledge and wisdom concepts explained. Then risk management processes reviewed. Knowledge management concepts used in tools and techniques of risk management are explained with examples finally.


Çağımızın bilgi çağı olduğunu hep vurgularız. Bilginin sürekli ve hızlı değişimi, deyim yerindeyse taşması, kabarması ve bilgi seli oluşturması proje risk yönetiminde işimizi kolaylaştırmamaktadır. Bu dinamik ortamda planlama yapmak ve öngörüde bulunmak zorlaşmaktadır (1).

İzleyen satırlarda proje risk yönetiminin süreçlerini, araç ve tekniklerini gözden geçirirken, bilgi yönetimi kavramlarını nasıl kullanacağımızı örneklerle ele alacağız.

Belirsizliklerle bilgiyi birlikte ele almak başlı başına risk taşıyan bir iş olsa da tahterevallide bilgi yönünde hareket ettikçe belirsizlikten uzaklaşıp bilgiye ve giderek bilgeliğe ulaşabiliriz.

Bilgi Yönetimi Kavramları

VEBB piramitiBilgi yönetiminin kökeni 1980’li yıllara dayanıyor. Benim rastladığım en derli toplu ele alınışı ITIL BT servis yönetimi içinde olanı (2).

Bilgi yönetimi Veri, Enformasyon, Bilgi ve Bilgelik hiyerarşisi biçiminde ifade ediliyor. Buna VEBB piramiti deniyor. İngilizcesi de Data, Information, Knowledge ve Wisdom hierarchy diye anılıyor ve DIKW pyramid adıyla isimlendiriliyor.

Bilgi Yönetimi konusunda Türkçe kaynaklar içinde Behlül Çalışkan Hoca’nın ders notlarını öneririm (3).

Veri niceliksel bir değer, bir gözlem, bir ölçümdür. Veri işlenmemiştir, hamdır ve fazla bir anlam ifade etmez. Not defterinizdeki arkadaşınızın telefon numarası, tarayıcınızın sık kullanılanlar sayfasına eklediğiniz bir internet adresi, bir kağıda yazdığınız bir e-posta adresi, termometre üzerinde okuduğunuzu değer veriye örnektir.

Enformasyon, verinin yapılandırıldıktan sonraki halidir. Analiz edilmiş, işlenmiş, düzenlenmiş, sıraya konmuş, derlenmiş verilerdir. Enformasyon nitelikseldir ve karar alma sürecine yardımcı olur. Telefon rehberiniz, bilgisayarınızdaki sık kullanılanlar sayfası, kentinizdeki geçen ayın günlük sıcaklık dereceleri tablosu enformasyona örneklerdir.

Enformasyonu farklı kaynaklardan sentezleyerek, deneyimlerle çerçeveleyerek, birikimli bir duruma getirerek, aralarında ilişkiler kurarak, zaman dizileri haline getirerek, uzman görüşü alarak bilgiye ulaşılır. Fazla miktarda enformasyona sahip olmak bilgi oluşturmaya yetmez. Bilgi elde edilmesi uzun bir süreçtir. Veri tabanı tabloları, raporlar ve bildiriler şeklinde olabilir. Basılı veya elektronik ortamda olabilir. Tüm kişisel ve aile bilgilerinin yer aldığı veri tabanı sistemleri, haftalık doğum günlerinin listeleri bilgiye örneklerdir.

Bilgi yönetimi veri, enformasyon ve bilginin hepsini birden kullanarak bilgelikle tamamlanır. Doğru kararlar vererek, ortak bir avantaja ve iyi sonuçlara vararak bilgeliğe erişilmiş olur.

Rich Maltzman, Bilgi yönetiminin temel kavramlarını, proje yönetimi için anlatıyor (4). Proje yöneticisini firavun olarak nitelendirse de bizi çok keyifli bir eski Mısır yolculuğuna çıkarıyor.

Belirsizlikler ve Proje Yönetimi

Proje, Proje Yönetimi Bilgi Birikimi Kılavuzunda benzersiz bir ürün, hizmet ya da sonuç yaratmak için yürütülen geçici bir girişim olarak tanımlanır (5). Bu kılavuz proje yönetiminin uluslararası meslek kuruluşlarından biri olarak nitelendirilebilecek PMI (Project Management Institute) kuruluşunun proje yönetimi için hazırladığı metodolojidir. Aynı zamanda bir ISO standardı olarak yayınlanmıştır ve Project Management Body of Knowledge (PMBOK) kılavuzu adıyla anılır.

Riskler, Fırsatlar ve Proje Risk Yönetimi

Türkçesi de yayınlanmış olan Proje Yönetimi Bilgi Birikimi Kılavuzunda risk, gerçekleşmesi halinde proje hedeflerinden bir ya da daha fazlasının etkileneceği olay ya da durum olarak tanımlanır. Belirsizliği yalnızca olumsuz yönüyle düşünmemek gerekir. Proje hedeflerini olumlu etkileyebilecek belirsizlikleri de fırsat olarak nitelendirmek söz konusudur.

Proje yönetimini oluşturan kapsam yönetimi, zaman yönetimi, maliyet yönetimi yanı sıra belirsizlikler, riskler ve fırsatların yönetimiyle ilgili bir bilgi alanı var ve risk yönetimi adıyla anılıyor.

Öncelikle risk yönetiminin süreçlerini gözden geçirelim:

  1. Planlama
  2. Tanımlama
  3. Niteliksel analiz
  4. Niceliksel analiz
  5. Risk yanıtlarını planlama
  6. İzleme ve kontrol

Planlama aşamasında risk yönetiminin nasıl gerçekleştirileceği tanımlanır. Kapsam bildirimi, maliyet ve zaman planı belgeleri girdi olarak alınır ve çıktı olarak risk yönetim planı üretilir.

Proje yönetim ekibi risk yönetim planını oluşturduktan sonra sıra riskleri tanımlamaya gelir. Bu noktada proje verileri yağmaya başlar. Maliyet tahminleri, zaman çizelgesi tahminleri, yapılacak üretim veya hizmetleri gösteren kapsam temel çizgisi (baseline) detaylı olarak gözden geçirilir. Neler ters gidebilir? Maliyet tahminleri gerçekçi mi? Teslimatlarda gecikme olabilir mi? İzin planlamasında aksama olursa uzman gereksinimimizi nasıl karşılarız? Kalite güvencesi için 6 adam/ aylık bir çalışma ve 3 aylık süremiz var ama elimizde iki uzman var, çalışmayı nasıl planlayalım? Bu soruları yanıtlayabilmek için hangi verileri toplamamız, enformasyon haline getirmemiz gerekecek? Bedeli karşılığında sektörel enformasyon bulabilecek miyiz? Yoksa verilerden oluşturmamız mı gerekecek? Burada bizi yoğun bir çalışma bekleyecek.

Risk yönetimi ile süreçlere tüm paydaşları katmak gerekir. Çevresel etkileri göz önünde bulundurarak, dış paydaş dediğimiz proje ekibi içinde olmasa da projenin sonuçlarından etkilenecek kişi ve kuruluşlarla ilişki kurmak gerekecektir. Bazı paydaşları dışarıda bırakmak, projenin başarısızlığı ile sonuçlanabilir. Tüm paydaşların kontak verilerini derleyerek kontak listeleri oluşturmak yine önemli bir bilgi yönetimi aktivitesi olarak önümüzde duracaktır. Burada Enformasyonu elde ettik diyelim. Bilgiye ulaşabilecek miyiz? Bilgiye ulaşmanın hiç kolay olmadığını söylemiştik. Zaman ve maliyet içeren bilgiye ulaşma projenin yaşam döngüsü dışında kalabilir. Bir şansımız projeyi gerçekleştiren sponsor kuruluşun önceki projelerden derlenen ve öğrenilmiş dersler kapsamında sonraki projelere aktardığı veri ve enformasyon ile artık bilgiye ulaşmış olması olabilir. Bunu gerçekleştirmiş bir kurum, hafta başında paydaş veri tabanından liste oluşturarak doğum günleri o hafta olanları kutlayabilir.

Risk listeleri ortaya çıktıktan sonra risk olasılıkları ve etkileri hesaplanır. Etkilerine göre sıraya dizilir. Bu süreç niteliksel risk analizidir. Gerçekleştiklerinde projeye etkileri az olan riskler izlenme listesine alınır.

Proje hedeflerini belli ölçüde etkileyeceği hesaplanan riskler niceliksel risk analizi sürecinden geçirilir. Tarihsel veriler ve ölçümler yanı sıra, alan deneyimleri kullanılır. Görüşme ve toplantı teknikleri ile eldeki veriler enformasyona dönüştürülür. Duyarlılık analizi, beklenen parasal değer analizi, Monte Carlo tekniği, karar ağacı şeması gibi matematiksel ve simülasyon modelleri kullanılır.

Gerçekleştikleri zaman bazı proje hedeflerini etkileyecek risk ve fırsatların etkilerinin sayısal boyutları elde edildikten sonra risklere karşı önlem ve stratejiler geliştirilir. “Kaçınma” stratejisi ile proje kapsamı daraltılabilir veya zaman çizelgesi uzatılabilir. Bazı riskler bir prim karşılığında sigorta kuruluşlarına “devredilir”. Riski ortadan kaldırmaz ama yönetilme sorumluluğunu sigorta şirketine devreder. Geri kalan riskler için olağanüstü durum yedekleri oluşturulur ve bu riskler “kabul edilir”.

Belirsizliklerin negatif boyutunun riskler, pozitif boyutunun fırsatlar olduğunu söylemiştik. Fırsatları değerlendirmek daha zor olsa da stratejiler geliştirilir. Projeyi daha erken ve daha az maliyetle bitirebilmek için ek kaynaklar atanması mümkün olabilir. Organizasyon olarak tüm fırsatları değerlendirmek mümkün görünmüyorsa paylaşmak için kurumsal birliktelikler oluşturulabilir. Diğer fırsatlar da kabul edilerek değerlendirme niyetleri ortaya konur ama gerçekleşinceye kadar başka girişimde bulunulmayabilir.

Risklerin ve fırsatların zaman içinde izlenmesi ve kontrol edilmesinde de bilgi yönetimi yöntemleri kullanılır. Periyodik toplantılarla güncel ölçüm ve gözlem verileri işlenerek, sıraya konarak, analiz edilerek karar alma süreçlerine yardımcı kılınır.

Ayrıca risk yönetimi süreçlerinin doğrusal değil sarmal olduklarını vurgulamak gerekir. Bir kez yapılıp bırakılmaz. Proje boyunca bir çok kez tekrarlanır ve sonuçları daha sonraki süreçlere girdi yapılır. Süreçler tamamlandıkça tekrar başa dönülerek yeniden ve yeniden gerçekleştirilirler.


Bilgi çağında belirsizliklerle baş etmeye çalışmak çelişkili gibi görünse de çağımızın bir karakteristiğinin dinamizm olduğunu vurguladık. Bu ortamda bilgiye erişme yolculuğunun ana hatlarıyla birlikte proje risk yönetiminin temellerini ve belirsizlikleri aşma yöntemlerini gözden geçirdik.

Günlük yaşantımızda bilgi deyip geçtiğimiz kavramın farklı aşamalarının özelliklerini gözden geçirirken bunların farklı isimlerle nitelendirilmesi bizi şaşırtabilir.

Kapatmadan son bir soru sorayım. Bilgi çağında ve bilgi toplumunda yaşadığımızı kabul ediyoruz. Peki bu hangi bilgi? Veri mi, enformasyon mu yoksa bilgeliğe ulaşmamızı sağlayan bilgi mi?

Notlar (Geçersiz bağlantıları lütfen bildiriniz)

(1) İşletmelerde Risk Yönetimi, Dr Yalçın Balıkçı, Cinius Yayınları, 2009
(2) ITIL (IT Infrastructure Library, BT Altyapı Kitaplığı, Sürüm 3)
(5) Proje Yönetimi Bilgi Birikimi Kılavuzu PMI Türkiye’nin web sayfasındaki bağlantıdan sipariş edilebilir

Posted in IT Service Management, Project Management, Risk Management | Tagged , , , , , , , , , , , , , , , , , , , , , , , , | Leave a comment

Ana Sayfama Neden Kaya Tırmanıcısı Resmi Koydum?

Kaya dizmeGünlük ana sayfası için fotoğraf arıyordum. Önce kaya dizme fotoğrafları ilgimi çekti. Gerçekten zor iş. Çeşitli boyutlardaki taş ve kayaları üst üste koyuyorlar. Sonra fotoğraflarını çekiyorlar. Eh biz de zor işlerin adamıyız diye bir tane koyacaktım, baktım aradığım boyu kısa eni geniş fotoğraflar yok.

Doğa fotoğraflarından ikrah geldi.. Ne yapayım, ne yapayım diye düşünürken aklıma kurumsal şirketlerin medya seçimleri geldi.. Karlı buzlu zirvelere tırmanan dağcılar veya serbest kaya tırmanıcıları. Tamam dedim, en zor iş bu, zaten tercih te ediliyorlar, benim seçmemde hiç bir risk olamaz..

Yalnız dikine tırmananlar benim işimi görmüyor. Yanlamasına bir resim lazım. Ana sayfamda gördüğünüz kayanın alt yüzeyinde gezinen tırmanıcıyı seçtim.

Kolay olanı herkes yapar..

Posted in General | Leave a comment