cobol, How to disable a panel in CICS without making program changes

I have a series of CICS panels in my legacy COBOL application. Is there a
way to disable access to specific panels without making changes to the
source code and recompiling? I vaguely remember issuing a CEMT TRANS command
once, but it appears it disables ALL the panels, not just one.

On Wed, 24 Jun 2009 10:29:16 -0400, "Ubiquitous" < XXXX@XXXXX.COM >



There is a way but it would probably make the transaction crash. By
"panel" I'm assuming you mean screen since I've never heard of a
"panel" in CICS. Each screen is really composed of two things...a
copybook and a phase. You could disable the phase without recompiling
the main program. Having never done this I'm not sure what the exact
effect would be on the program that contains the screen. I'm guessing
it will crash. You need to test it. If it doesn't work, like I
suspect, than the short answer to your question is, NO.

Regards,
////
(o o)
-oOO--(_)--OOo-

"Step aside everyone! Sensitive love letters are my specialty.
'Dear Baby, Welcome to Dumpsville. Population: you.'"

-- Homer Simpson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

You're right, they are screens, not panels.
I also realized that the command is CEMT PROG.

Specifically, what I am trying to do more is prevent users from accessing a
particular screen without temporarily changing and recompiling the source
code for the panel to display some sort of "THIS SCREEN IS NOT AVAILBALE"
message. I can use CEMT PROG to disable a screen but then it crashes with a
"DFHAC2206 15:16:47 CICST1 TRANSACTION screen-name FAILED WITH ABEND AEI0."
message. Surely, there must be a way to test if screen-name is enabled or
disabled and gracefully handle it?

In article < XXXX@XXXXX.COM >,


[snip]


Now we're getting somewhere... CEMT, as I recall it, updates the PCT with
the latest compiled version of the program (it 'CEMenTs the load/mapset
module in is how I remember it). Usually used by developers with the SET
keyword, I think the INQ keyword supplies information about transaction in
question.


It sounds like you are attempting to use CEMT to direct flow of program
execution to different SENDs based on different conditions; to the best of
my knowledge this cannot be done. You've built two maps, one with a Real
Data Entry screen and the other with a display of 'CANNOT DO THIS, TODAY
IS TUESDAY' or the like. CEMT, as far as I know, has nothing to do with
what happens once a transaction has begun; you'll have to build in those
maps and the conditions to execute them yourself.

Now, a question: what is the logic behind permitting a production user
(not a tester) access to any code that has not been fully debugged and
ready to do what it was written to do? This is one of the reasons that
TEST regions are developed, so that testers can see if the code is
working... what you seem to be asking for is 'is there a way to put into
Prod a transaction with some features disabled without recompiling it?'

Stuff goes into Prod only after it is fully tested and the user signs off
on it... putting anything else there is asking for trouble.

DD

I agree! This is a legacy COBOL CICS accounting system they've been
threatening to migrate or replace for several decades now. Annually, when we
close out the fiscal year, we want to prevent certain transactions by
disabling specific screens. In the past, we have done this by altering the
screen (or its exit) to display
a message and compiling it to PROD, then restoring the original version once
we have finished closing the fiscal year. That approach make me nervous.
What I'd like to do is add code to the source code that would display a
message instead of abnormally terminating (and the help desk getting calls
from the users) if we used CEMT PROG to disable a screen. I suspect the
solution involves using EXEC CICS HANDLE CONDITION to catch the error, but
my COBOL is rusty and it doesn't seem to be working.

In article < XXXX@XXXXX.COM >,



[snip]


'We agree? One of us must be wrong!', he cried, Wildely.


That's fine... but until the new system is spec'd, coded, tested, tweaked,
re-tested, signed-off-on and shows accurate results for (minimally) a
year's worth of parallel testing... you got what you got.


How is the beginning of 'annually' determined? Date, week-of-year, phase
of moon, Dictatorial Fiat from the Top Floor... when/how do the
programmers know 'all right, now the users cannot be allowed into these
screens'? This criterion may help in directing folks towards a most
efficient solution.


Touching code should be done with caution, aye. Putting code into Prod,
where the functions of the business are accomplished, should be approached
very, very carefully, lest one fat-finger OAII-DEST to OAII-DFST and all
of your widgets get sent to Lithuania.


Let me get this straight... you'd like to modify what will become Prod
code with skills you admit to be 'rusty'? You'll deserve what you get.

First, I'd say, is to get someone who knows what they are doing. If you
are dealing with figures that regularly contain US dollar amounts having
more than two commas in them then you want A Professional. Letting a
self-admittedly 'rusty' coder make Prod-implemented changes on a regular
basis (at least twice a year, from what you describe... regular-to-special
and special-to-regular again) is an invitation to inaccuracy.

(oh... and when your budget request for A Professional gets shot at with
the usual 'Costs too much!' the *immediate* riposte should be 'costs less
than finding out we've been misplacing a decimal-point for six months')

DD

that approach might make you nervous... but it is an approach that works.

why does this approach 'make me nervous'?

from my 10+ years of command-level cics i agree with doc that this issue
is be resolved programatically (sp) and not through manipulation of the
cics tables.

again. you have a solution to the problem that is proven to work. my
guess is you have other work waiting to be done. it's your time; spend
it as you like.

sss

In article <b65ae$4a4398fd$6216307d$ XXXX@XXXXX.COM >,



Perhaps because he knows that code should be touched as little as possible
and a machine-based solution for a regularly-occurring situation is, in
general, more reliable than a human-based one... else we'd all still be
adding up bills of lading with quill pens.

Or... perhaps because he's realised that he's moving away from doing COBOL
to the point where his skills are 'a little rusty', even though this same
change-the-code-CEMT-do-the-year-end-change-the-code-CEMT has worked for
decades... mayhaps a bit of mortality has manifested and he's suddenly
realised that this method - even though it has worked for years! - will be
a bit of an issue were he to get hit by a Mac truck.

There are many possible reasons for 'change, compile, change, compile' in
many systems... *none* of which I would call 'a good one'. When a program
starts throwing bad data I like to be able to read the load module (read
the load module? who does *that* any more?) and say 'this code hasn't been
touched in a decade so let's not waste time there, let's look at the
data'.


I'll match you and raise you one. There's a philosophy that says 'get a
program to do as much stuff in one load module as possible', there's
another that says 'one program produces one file, one program displays one
screen, one program generates one report'. The advantage to the first
approach is that it keeps down on the number of programs you have to keep
track of but it turns maintenance into a nightmare, the advantage to the
second is that it keeps it simple, sweetie, but causes more attention to
have to be paid to how the system library is managed.

Here we seem to have a situation of 'under almost all conditions we want a
program to do one thing, under one special set of conditions we want
another'.

Want a different result? Write a different program. Or... maybe there's
something Ops can do about this, once some code has been written.

Now I'm starting to give hints that are Worth Money... and this is the way
I make my living. I think I'll brew another pot of tea... it is past
noon, I'll avoid caffeine and whomp up some chamomille.

DD

PCT = Program Control Table - defines what transaction runs this
program and other attributes.

PPT = Processing Program Table - all programs (screens, subroutines
etc.) must be defined in this table.


Exactly right. What the OP wants to do must be done within the main
processing program.


Regards,
////
(o o)
-oOO--(_)--OOo-

"Step aside everyone! Sensitive love letters are my specialty.
'Dear Baby, Welcome to Dumpsville. Population: you.'"

-- Homer Simpson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Because it is unneccessary and could be accomplished with code and
thus leave everything in place. Too many bad things can happen when
you start bouncing programs, screens etc. in and out of production
even if it is only done once a year.


Regards,
////
(o o)
-oOO--(_)--OOo-

"Step aside everyone! Sensitive love letters are my specialty.
'Dear Baby, Welcome to Dumpsville. Population: you.'"

-- Homer Simpson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

I still support a CICS based application that becomes unavailable at 5
PM every day. The way we did it was by using batch jobs (MacKinney
Batch CEMT) to close and disable the VSAM application files in order to
make them available for nightly batch processing. The CICS application
programs were coded to detect the "NOT OPEN" errors and then issue a
message saying that files were closed for maintenance. When the files
are reopened in CICS, the application resumes working normally.

There are several ways the application could be modified to reject input
and report the application as currently not available, but if you don't
have the time, budget, or expertise to develop an application solution
there are other options.

If the CICS application is the only one used in CICS, then simply shut
down CICS and leave it down until you're ready to bring it back up.
Many shops have multiple applications in the same CICS, so this may not
be practical.

Rather than replacing a compiled MAP with another MAP, I would suggest
using CEMT to simply DISable the transactions (PCT entries), or the
programs (PPT entries) that you don't want executed and then live with
the help desk calls. You can re-enable those resources when you're
ready, and processing will resume normally. In my opinion that would be
a less risky way to manipulate the system. But I agree it is not as
user friendly as putting up a message that says "System not available
due to maintenance, please try again later".


--
http://arnold.trembley.home.att.net/

They've been threatening to do this for over twenty years now, so I'm
quite sure this legacy system's going to be around for awhile.


For all practical purposes, the cut-off dates are determined by the accounting
department and change each year, so hard-coding a cut-off date takes me back
to square one.


That's what Test is for, chap! :-)

My initial plan was to add a date check of some sort, but that turned
out to be impractical since the cut-off date changes year-to-year and
you can bet that some emergency will arise which requires the hard-coding
to be overridden.

After spending a day tinkering with EXEC CICS HANDLE CONDITIONS without
any success, I am reluctantly going to create versions of the screens
with the appropriate messages and use them each year.

Doc, that's pretty much what I would recommend, but it still requires
update access to a production file using FileAid. The Auditors might
object to that. It might be better if there were a special program and
MAP (with restricted security access) to update the byte switch that
turns the application on and off.


--
http://arnold.trembley.home.att.net/

In article < XXXX@XXXXX.COM >,




[snip]


Notice, Mr Trembley, that the change in what screen is used seems, in
effect, to be arbitrary.


[snip]


Yes... and no.


Bingo. The Original Poster was looking at a change in processing (which
MAP to SEND) based on change in data ('Word From on High', as it were) and
decided on a certain code-based solution which would have to be performed
twice (turn off The Usual, turn on Keep Out and then reversed) when Word
was given.

Instead of giving a complete and off-the-shelf solution (for a couple of
reasons, one being that I am not sufficiently familiar with the
environment to do so and another being that I like getting paid for Doing
My Job) I suggested that instead of concentrating on the code the
concentration be changed to data... code the program and MAPS once and
then let the data do the driving.

If Auditors - folks whom an Auditor once described to me as 'having the
job of going across the battlefield and bayonetting the not-yet-dead') -
are of concern then I would assume that they are already involved, that
when Word comes the program-change gets documented and all are kept
satisfied.

The FileAid solution was purposefully given as being quick, dirty and
out-of-Audit compliance... just start thinking *about the data instead of
the code*, that's all, and what could be changed in the data so that the
code need not be changed any more. How this gets done in a fashion that
satisfies all parties involved... well, I'd like to start discussing
rates, first.

DD