J.)
Sent: June 24, 2011 10:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Obtaining System Information from a COBOL program
In ac1ec69331ff27468be326e1db521758059ef67...@sd01cfmv0003.prod.net,
on 06/24/2011
at 08:50 AM, Haynes, Stan stan.hay...@cra-arc.gc.ca said:
The COBOL program has a static
And I agree that there is a TSS way to provide this security. That requirement
will be addressed. The issue is with creative appl programmers who think that
navigating control blocks the old-fashion way sans API will always work.
So to try framing this issue a bit:
Appl programmers, rightfully
-MAIN@bama.ua.edu
Subject: Re: Obtaining System Information from a COBOL program
In ac1ec69331ff27468be326e1db521758059ef67...@sd01cfmv0003.prod.net,
on 06/23/2011
at 09:09 AM, Haynes, Stan stan.hay...@cra-arc.gc.ca said:
Interestingly, this is something being discussed in our shop right
now. We
Interestingly, this is something being discussed in our shop right now. We have
an application with code that extracts a DSN by searching through the TIOT, in
order to perform some security check. We (z/OS support division) fear that this
user code is vulnerable to changes in z/OS control block
I feel like I should expand on my query.
We use CA-TSS as our security server. All datasets are protected. In this case,
the appl owners *need* to do a sec check to control the type of access. In
their own words:
an application makes a call to our business team (app). We then grant access
via
Our division (Host Technology Management) supports all software products in our
z/OS environments. Our staff is comprised of approx 75 sysprogs (the seniors
are advisors more than do'ers), and we support 2 prod sysplexes. As usual,
there's a z/OS team (z/OS/JES2, Thruput Manager, TSS and ACF2),
Don't know where D M=CPU gets the CPC name.
If by how I can get you mean via assembler or REXX ... Our IEFACTRT exit's
job summary includes the CPC name. We get it from the ECVT control block (field
ECVTHDNM). The ECVT is pointed to by CVT + x'8c'. ECVTHDNM is at offset x'150'
(see macro
SRCHFOR does indeed work from ISPF 3.4 .
Using 3.4 to list all our PROCLIBs, I just used it to look for a DSN qualifier
in any proc in any lib, and it works just fine. It worked when I typed SRCHFOR
VMA on the command line, but found no results when I typed SRCHFOR VMA.
Stan
This worked for me:
//ADDLINES PROC M=
//GENEREXEC PGM=IEBGENER
//SYSUT1 DD DSN=SZH120.PLAY.CNTL(M),DISP=OLD
// DD DSN=SZH120.TEST.CNTL(TWOLINES),DISP=SHR
//SYSUT2 DD DSN=SZH120.PLAY.CNTL(M),DISP=OLD
Would this approach work ?
1) put the new lines in a PDS member (member name TWOLINES, perhaps ?)
2) put Jon's JCL in a proc (instream would suffice):
//ADDLINES PROC M=
//STEP1EXEC PGM=IEBGENER
//SYSUT1 DD DSN=libtoupdate(M),DISP=OLD
// DD
We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by Thruput
Manager.
As a result of an application area reporting one of their critical jobs
abending S822 (issue since corrected), we found ourselves noticing a very old
parm value: default REGION size for all classes via the
@bama.ua.edu] On Behalf
Of Haynes, Stan
Sent: Wednesday, February 09, 2011 6:04 AM
To: IBM-MAIN@bama.ua.edu
Subject: Default REGION Size
We run a 4-system production sysplex using z/OS/JES2 1.11 augmented by
Thruput Manager.
As a result of an application area reporting one of their critical
12 matches
Mail list logo
