How to set-up a CICS environment.

[Kaku]

Hi,

How to set-up a CICS environment? I can understand that this question is over broad and it might sound foolish for me to ask here but I've a work in hand which is not fully under my job responsibilities.

The shop already have some CICS LPARs and sub-systems however, they are migrating one part of their applications to CICS/VSAM/DB2/COBOL world and for that matter, I plan to look for : How can I decide on the new system strategy? In doing so, how do I choose the new CICS transactions and the definitions/resources for different files? Do we usually use some default logging functions in a CICS environment?

[Robert Sample]

The CICS bookshelf has a manual with the title of System Definition Guide. You should start reading this manual. However, what you are asking really falls under your site support group's mission; attempting to set up a CICS region at your site without their help and advice could lead to adverse consequences for you (up to and including termination of employment).

[Kaku]

I understand what are you saying Robert. The person responsible for this had to leave abruptly and we are trying to do it now.

I've downloaded the pdf you've mentioned you suggested and goin gthrough it. I know, asking it again might sound stupid - but when someone star setting up new environment what are the thing one should start with? Later we'll involve a system programmer to do the actuall installation however, as 'care taker' of application I'd like to create a check list of things so that we don't miss on anything as the sys-programmer is not from our team (for the obvious reaons I stated).

[Robert Sample]

Some of the major considerations:
- VTAM APPLID must be generated (and must be unique to the site)
- use an existing or new CSD file?
- use an existing or new table set (SIT in particular)?
- setting up the start up list
- started task or batch job?
- SIT parameters may dictate new / existing (memory sizes for the various pools, for example)
- terminal session manager may need changing for the new APPLID

[Kaku]

Thanks Robert.

- VTAM APPLID must be generated (and must be unique to the site)

I looked at the IBM instruction for this: http://pic.dhe.ibm.com/infocenter/cicst ... c0054.html :- this shop have some existing CICS regions though for an old application (for which we need to do the migration) we plan to have a strategy. Should we start with the existing setup or should we create a new VTAM APPLID? I think it should already be there as there are some existing CICS regions already?

- use an existing or new CSD file?

As there are existing CICS regions, can we sue the existing CSD file?

I downloaded the "System Definition Guide" and for this looked at 'Chapter 1. Planning your CSD configuration', I've some questions to ask:

a. The manual says "Decide how much disk space you require." - on what factors it depends? Can you please advise.
b. The manual says,"Decide whether you want to use the CSD in RLS or non-RLS mode." After this there is an explnation which differntiate b/w RLS and non-RLS, however, if a system is existing already on the shop - should we just follow that?

c.

- use an existing or new table set (SIT in particular)?

- I've similar question if w've an existing CICS region - should we create from scratch?

Please advise on the above.

[Robert Sample]

You can use an existing VTAM APPLID -- as long as that CICS region is no longer used and will never be needed in the future. Each VTAM APPLID must be unique, so sharing them between regions does not work.

You can use a CSD file for multiple regions. CSD files are tied to groups (as used in the CEDA online resource definition transaction) and groups are tied to lists. Hence a single DD name (or transaction name or program name or ...) can be defined more than once in a CSD -- it is associated with different groups for each definition.

The space needed for the CSD depends upon the number of entries you are going to have in it. If nothing else, look at an existing CSD at your site and use the same space it has.

Use of RLS depends upon the site -- one informational source is http://pic.dhe.ibm.com/infocenter/cicst ... m_rls.html

An SIT can be common between regions, with the JCL (SYSIN) for the region containing the unique parameters (such as start up list name, PLT tables to use, APPLID, and so forth).

Whether or not you use existing ones or set up new ones depends, largely, upon your site and how it does things. Some sites want as much shared definition as possible to reduce the maintenance burden while other sites want each region to be unique to minimize cross-region issues. Ultimately, which way to go depends upon the site and its policies and procedures.

[Kaku]

Thanks a bunch Robert! Really appreciate your reply.

As I go through the document I might have some more questions, though in general - if we set up a new CICS environment is there some flow of 'events' wchih we follow usually?

Thanks again.

[Robert Sample]

Follow the CICS System Definition Guide manual. Start at the beginning and just work through the manual.

[Kaku]

Thanks again but that's a document of 460 pages. I'm not sure how many times I'm going to stuck!

[enrico-sorichetti]

Thanks again but that's a document of 460 pages. I'm not sure how many times I'm going to stuck!

Later we'll involve a system programmer to do the actuall installation however, as 'care taker' of application I'd like to create a check list of things so that we don't miss on anything as the sys-programmer is not from our team (for the obvious reaons I stated).

Sooner will be better than later,
and if You(Your organisation) hire a system programmer just to do the donkey work you(Your organisation) are just going to throw away Your money
the installation part is the simplest one ... ( the hard part is the design )

a system programmer with the appropriate skill level will save You a lots of time by just asking the right questions on how to fit Your application into the CICS infrastructure and suggesting the overall appropriate strategy

[byelen]

a system programmer with the appropriate skill level will save You a lots of time by just asking the right questions on how to fit Your application into the CICS infrastructure and suggesting the overall appropriate strategy

Very true. One of our practices is to keep a standard "template" region, along with the required jobs to create datasets, etc. Then we just "clone" it by running the jobs (changing DSN names as appropriate), copying the template's RDO definitions, etc. That way, we can generate a region in less than 20 minutes.

With regard to sharing the DFHCSD dataset between regions, DO NOT share a single dataset between your test and production region(s). Even if you're using separate naming conventions for test and prod, you'll always get into trouble. Keep the product RDO separate, and lock it down as much as you can to prevent accidents!

- Bruce

[Kaku]

Right but I'm not a decision maker so ... but I agree with however until we find one, I'm sole warrior!

Very true. One of our practices is to keep a standard "template" region, along with the required jobs to create datasets, etc. Then we just "clone" it by running the jobs (changing DSN names as appropriate), copying the template's RDO definitions, etc. That way, we can generate a region in less than 20 minutes.

With regard to sharing the DFHCSD dataset between regions, DO NOT share a single dataset between your test and production region(s). Even if you're using separate naming conventions for test and prod, you'll always get into trouble. Keep the product RDO separate, and lock it down as much as you can to prevent accidents!

Thanks for the hints Bruce.

But if there are multiple CICS region, is it a good practice to share the datasets, my inference is no, please help.

[byelen]

But if there are multiple CICS region, is it a good practice to share the datasets, my inference is no, please help.

Hi Kaku,

It really comes down to use:

Pros:

Easier to maintain one DFHCSD then multiple.
Very easy to share RDO groups between regions.

Cons:

Make a mistake, it affects everybody!
Can only be in CEDA one region at a time.
Can only copy definitions from one dataset to the other via the dfhcsdup batch utility.

I would never, NEVER share DFHCSD datasets between test and production. Sharing anything between test and production is a recipe for disaster. I think the final decision comes down to end-use. If you're running multiple regions with a load balancing setup, and each region has to support the same applications, etc., share the DFHCSD. You'll still need separate group lists as there are some configurations that you would want as region specific. A suggestion for you as the sysprog, set up a test region (and possibly an "acceptance" region depending on your policies). Create an additional region as your own personal "sandbox". That gives you a base to test out system software (a new version of debugger for example) without affecting everybody else!

Regards,

Bruce

[Kaku]

Thanks Bruce. I'm reading the System Definition Document and I should be back soon.