Upper/Lower case in CICS screens
Bobby Herring
We are trying to start using upper/lower case text in our CICS maps. We
can
build the map and everything looks fine until enter is pressed. I have
all terminals
defined as UCTRAN(YES) in the typeterm definition.
If we allow the programmer to use the SP translator option, they can use
EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN)
This leaves a security hole since they can now SET things other than
terminals.
Has anyone come up with another way to do this? Any help will be
appreciated.
Bobby
Len Rugen
Write a set uctran/nouctran subroutine that they call.
Dan Cornelius
Bobby Herring wrote:
> We are trying to start using upper/lower case text in our CICS maps. We
> can
> build the map and everything looks fine until enter is pressed. I have
> all terminals
> defined as UCTRAN(YES) in the typeterm definition.
> If we allow the programmer to use the SP translator option, they can use
> EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN)
>
> This leaves a security hole since they can now SET things other than
> terminals.
>
> Has anyone come up with another way to do this? Any help will be
> appreciated.
>
> Bobby
We set uctran(tranid) in all TYPETERMs, and uctran(yes) in all
PROFILES. then, for all transactions that we want to receive
untranslated datastreams, we give them an equivalent PROFILE with
uctran(no). we do not permit any applications to do SETs.
Simon Dodge
> >If we allow the programmer to use the SP translator option, they can use
> >EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN)
> >
> >This leaves a security hole since they can now SET things other than
> >terminals.
Bobby.. Check with your RACF folks.. If your shop has implemented
"command" security you can protect the various SP commands
with standard RACF profiles. It will allow you a lot of granularity
and you can prevent "them" from issuing SET commands against other
resources, or PERF commands etc.
Check the CICS/RACF security Guide for details.
Tony Netley
Can you not get them to use ASIS on the receive?
Regards...Tony
----------
> From: Bobby Herring <bobhe...@JUNO.COM>
> To: CIC...@UGA.CC.UGA.EDU
> Subject: Upper/Lower case in CICS screens
> Date: 18 December 1997 18:12
>
> We are trying to start using upper/lower case text in our CICS maps. We
> can
> build the map and everything looks fine until enter is pressed. I have
> all terminals
> defined as UCTRAN(YES) in the typeterm definition.
> If we allow the programmer to use the SP translator option, they can use
> EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN)
>
> This leaves a security hole since they can now SET things other than
> terminals.
>
Barry Brooks
On Thu, 18 Dec 1997 13:12:51 EST Bobby Herring said:
>We are trying to start using upper/lower case text in our CICS maps.
>Has anyone come up with another way to do this? Any help will be
>appreciated.
We define all terminals with UCTRAN(TRANID) and then specify
UCTRAN(YES or NO) on the individual transaction definitions.
We use UCTRAN(YES) as the default for transaction definitions
but specify UCTRAN(NO) when the owner requests a transaction
be able to accept upper/lower case data. This seems to work
well for us.
What release of CICS are you running? We are 4.1.
Ruud van Zundert
We,too, used a called a common CICS module. Depending on a one character
indicator the common module set the case to upper or lower. Typically, your
program would do the following :
ind='L'
call common module
display screen
while (work to do)
process
display screen
end
ind='U'
call common module
One word of warning. If your program abends before the indicator is reset,
everything else will be lower case. You could either handle that in your
DFHPEP, or if you have a 'menu' system that everyone has to go through,
reset it there. Good luck,
Ruud van Zundert,
Windmill Programmes Ltd.
-----Original Message-----
From: Bobby Herring <bobhe...@JUNO.COM>
To: CIC...@UGA.CC.UGA.EDU <CIC...@UGA.CC.UGA.EDU>
Date: Thursday, December 18, 1997 06:13
Subject: Upper/Lower case in CICS screens
>We are trying to start using upper/lower case text in our CICS maps. We
>can
>build the map and everything looks fine until enter is pressed. I have
>all terminals
>defined as UCTRAN(YES) in the typeterm definition.
>If we allow the programmer to use the SP translator option, they can use
>EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN)
>
>This leaves a security hole since they can now SET things other than
>terminals.
>
>Has anyone come up with another way to do this? Any help will be
>appreciated.
>
>Bobby
>
Walkdavw
I am doing this in many of my programs, but since I am not at work I am
uncertain exactly how I am doing it. If you want to call me next week
(Sunday or Monday) I will be happy to look it up.
David Wakser, Dynatron, Newark, NJ (973) 648-6700 x318
FAdvice
Bobby,
Put the EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN) in a program you
write, and make them CALL or LINK to that program. You can then just compile
your program with the SP option, but theirs without SP.
Christopher Frank
STAR, Inc.
Wayne Fugere
I got bit on this a while ago where the EXEC CICS SET TERMINAL did not work
quite the way
I wanted it to if executed in a program running in an AOR. I do not know
about any other
release, but V4.1 has a PTF that will allow the SET TERMINAL UCTRAN to work
correctly in an
AOR.
Wayne
Greg Aldridge
We also did this exact same thing and it works fine. You may want to
redefine some of the standard CICS
trans, to do UCTRAN though, otherwise they will treat everything as mixed
case and give you unwanted results.
We've done this to CEMT,CECI,CEDF,CEBR,CEDF.
The problem with EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN) (from
memory) is that all subsequent transactions on the terminal get nouctran
also!
We are CICS 3.3/4.1. At version 2 we had a terminal input exit with an
internal table that did upper case translation on the TIOA for all
transactions not in the table. I think this is still a valid technique but
somewhat clumsy.
Luck, Greg
BA...@NERVM.NERDC.UFL.EDU on 19/12/97 08:26:32 AM
Please respond to CIC...@AKH-WIEN.AC.AT
To: CIC...@AKH-WIEN.AC.AT
cc: (bcc: Greg Aldridge/Westpac/NZ)
Subject: Re: Upper/Lower case in CICS screens
On Thu, 18 Dec 1997 13:12:51 EST Bobby Herring said:
>We are trying to start using upper/lower case text in our CICS maps.
...
>Has anyone come up with another way to do this? Any help will be
>appreciated.
We define all terminals with UCTRAN(TRANID) and then specify
UCTRAN(YES or NO) on the individual transaction definitions.
We use UCTRAN(YES) as the default for transaction definitions
but specify UCTRAN(NO) when the owner requests a transaction
be able to accept upper/lower case data. This seems to work
well for us.
What release of CICS are you running? We are 4.1.
The views expressed in this document do not necessarily reflect those of
Westpac Banking Corporation
Westpac Banking Corporation is incorporated in New South Wales, Australia
FAdvice
<< The problem with EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN) (from
memory) is that all subsequent transactions on the terminal get nouctran
also!
>>
when the task to be attached represents a new pseudoconversation.
Chris
Volker Bandke
** Reply to note from CICS List <CIC...@UGA.CC.UGA.EDU> Thu, 18 Dec 1997 20:17:12 -0000
> an you not get them to use ASIS on the receive?
Of course not - ASIS only works on the second and/or later receive in the same task, and as
every application must be pseudo-conversational - that is a no-no.
Regards
Volker Bandke
WinErr: 014 Keyboard locked - Try anything you can think of.
Jean-Claude Duffau
----------
> De : FAdvice <FAd...@AOL.COM>
> A : CIC...@VM.MARIST.EDU
> Objet : Re: Upper/Lower case in CICS screens
> Date : vendredi 19 dicembre 1997 03:45
the exit
gets control, is in NOUCTRAN mode.
Jean-Claude
John Chase
Bobby Herring wrote:
>
> We are trying to start using upper/lower case text in our CICS maps. We
> can
> build the map and everything looks fine until enter is pressed. I have
> all terminals
> defined as UCTRAN(YES) in the typeterm definition.
That's why...
> If we allow the programmer to use the SP translator option, they can use
> EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN)
>
> This leaves a security hole since they can now SET things other than
> terminals.
>
> Has anyone come up with another way to do this? Any help will be
> appreciated.
That you can/must specify the SP translator option implies that your
CICS is "current" enough to avail yourselves of UCTRAN=TRANID in the
TYPETERM and UCTRAN=YES/NO in the transaction PROFILE. With that
extended granularity you can control the case-translation attribute by
transaction as well as by terminal. The CICS (4.1) Resource Definition
Guide has a pretty good explanation of what to expect from various
combinations of the TYPETERM and PROFILE UCTRAN attributes (e.g., see
the table at the bottom of topic 4.7.1 on the CDROM (CICS/ESA V4R1
BookShelf)).
As an aside, you don't necessarily have to define your own profiles: the
IBM-supplied profiles DFHCICSP and DFHCICST specify UCTRAN=YES and
UCTRAN=NO respectively; they are otherwise identical.
As a further aside, the same granularity with regard to case-translation
attributes is described in the CICS/VSE 2.2 RDO manual; it has the
"revision bar" next to it indicating "new" for that release.
John Chase
NOTIS Development & Support
>
> Bobby
Bobby Herring
Thanks for all the suggestions. I think we will go with Barry's solution.
It seems like the
easiest solution. We are running 4.1. Converted from 212 in August.
>>On Thu, 18 Dec 1997 13:12:51 EST Bobby Herring said:
>>Has anyone come up with another way to do this? Any help will be
>>appreciated.
>
<BA...@NERVM.NERDC.UFL.EDU> writes:> >We define all terminals with
Len Rugen
Yes, that is a good way now. Those of us that are CICS dino's still
remember the LINK'ed programs that twiddled a bit in TCTTE...
Len Rugen
Sr. Systems Programmer
University of Missouri
401 Clark Hall
Columbia MO 65211
(573) 882-9237
FAdvice
<< You should be aware that the first input message wich is already read when
the exit gets control, is in NOUCTRAN mode.
>>
must be acceptable, because the program would have to get control in order to
change the value.
OTOH, if the goal here is to ensure UCTRAN is set BACK properly (for the
uppercase-only transactions) then you would in addition have to perform the
uppercase translation manually after resetting the bit. So your point is well
taken.
Chris Frank
STAR, Inc.
Bill Lynch
I know I'm joining this thread late, but what do you mean by "start
using upper/lower case text in our CICS maps"? We've specified mixed
mode INITIAL values in BMS maps for years. This just requires CAPS OFF
in the edit session of the BMS source. Do you mean you don't want the
operator's input translated? What's the benefit of this? We leave UCTRAN
on for input, makes editing a whole lot easier.
Bill Lynch
Bobby Herring wrote:
>
> We are trying to start using upper/lower case text in our CICS maps. We
> can
> build the map and everything looks fine until enter is pressed. I have
> all terminals
> defined as UCTRAN(YES) in the typeterm definition.
> If we allow the programmer to use the SP translator option, they can use
> EXEC CICS SET TERMINAL(XXXX) UCTRANST (NOUCTRAN)
>
> This leaves a security hole since they can now SET things other than
> terminals.
>
> Has anyone come up with another way to do this? Any help will be
> appreciated.
>
> Bobby