-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Swarbrick
Sent: Friday, July 17, 2009 5:25 PM
To: IBM-MAIN@bama.ua.edu
Subject: LE options
There appears to be (at least) two ways to change LE runtime options
system wide.
There's
On Fri, 17 Jul 2009 19:25:28 -0400, Lizette Koehler
stars...@mindspring.com wrote:
Don't forget that there is also a JCL over ride now at z/OS V1.9 (IIRC) that
allows your programmers to put in the LE Parms there was well.
Actually 2 releases earlier, z/OS 1.7 - via CEEOPTS DD.
Not all options
Thanks for all of the thoughts. We are already using the PARMLIB member, and
it looks like we'll continue to do so. Just wanted to make sure that was the
right choice.
Frank
--
Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation
Lakewood,
Thanks for all of the thoughts.
We are already using the PARMLIB member, and it looks like we'll continue to
do so.
Just wanted to make sure that was the right choice.
When I started in this business, almost everything was assembled tables and
required huge unnatural acts to get things changed.
Frank Swarbrick pisze:
I have read the manuals and understand there are many ways to set them. I'm
interested in more fully understand, however, the pros and cons of CEEDOPT
versus CEEPRMxx. Manuals too often tell you *how* to do things but not *why*.
I think, its quite obvious. There is
that the PARMLIB way allows for multiple systems to share the
same LE libraries and still have different LE options, if desired. Is this the
reason for is its existence? If we use the PARMLIB way is there anything that
has to be done with the macros and can't be done with the PARMLIB?
Honestly
On Fri, 17 Jul 2009 15:25:26 -0600, Frank Swarbrick
frank.swarbr...@efirstbank.com wrote:
There are more ways (CEEROPT, CEEUOPT and more). Check the manuals
for more details about the order of settings. Also understand the term
LE enclave and how the LE options takes effect for some
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Swarbrick
Sent: Friday, July 17, 2009 4:25 PM
To: IBM-MAIN@bama.ua.edu
Subject: LE options
There appears to be (at least) two ways to change LE runtime options
system wide.
There's
Frank,
As others have pointed out, there are still other ways to do set LE
options.
One difference between the old ways (e.g. CEEDCOPT) and the new ways
(PARMLIB) is that the old ways allowed for fixed options, i.e. system
defaults that could NOT be overridden by the programmer or later methods
options, if desired. Is this the
reason for is its
existence? If we use the PARMLIB way is there anything that has to be
done with
the macros and can't be done with the PARMLIB?
Honestly, there are so many ways to change LE options that it's hard to
keep them all
straight
...@efirstbank.com wrote:
There are more ways (CEEROPT, CEEUOPT and more). Check the manuals
for more details about the order of settings. Also understand the term
LE enclave and how the LE options takes effect for some application
especially
under CICS.
BTW: SHOWzOS shows the CEEDOPT
Don't forget that there is also a JCL over ride now at z/OS V1.9 (IIRC) that
allows your programmers to put in the LE Parms there was well.
That's been around a lot longer than 1.9!
IIRC, it was around during OS/390.
The option(s) are specified by:
//STEP EXEC PGM=appl,PARM='appl/LE'
Or vice
anuals too often tell you *how* to do things but not *why*.
I guess, in my case, it's because it's dynamic and more flexible. So, I prefer
PARMLIB.
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff /
Actually I was talking about the //CEEOPT DD statement that can be added to
JCL rather than the PARM.
Lizette
Don't forget that there is also a JCL over ride now at z/OS V1.9 (IIRC)
that allows
your programmers to put in the LE Parms there was well.
That's been around a lot longer than
SHOWzOS and COBANAL display the CEExOPT settings but not for CEEROPT.
However the code should also work for CEEROPT unless you modify it and load
the CEEROPT entry. Starting with z/OS R9 (?) IBM deliver a macro (CEEOCB?)
to map the CEExOPT.
Regards
Roland
Is there some utility out there
Is there some utility out there where you supply as input the CEEROPT load
module, and the utility reports on what options it specifies?
I'd hate to write one only to find out that I re-invented the wheel...
Thanks.
Adam Johanson
IMS Systems Programming
USAA
Is this for IMS, CICS, Batch or other environment? What level of z/OS would
you be running this on?
Cics has CLER for seeing the options, and I think IMS may also have one for the
online side.
If you are at z/OS V1.9 then the parms might be maintained in CEEPRMxx in
SYS1.PARMLIB or a CEEOPT
It's for an IMS MPR. We're at z/OS 1.9.
What I'd really like is for the utility to take the load module, and output
the
CEEXOPT macro, complete with options contained in the CEEROPT module.
--
For IBM-MAIN subscribe /
To: IBM-MAIN (IBM-MAIN@BAMA.UA.EDU)
Subject: Fw: Utility for LE Options?
I don't know if this is what you are looking for, but at LE
1.9, you can
A) create a CEEROPT stand-alone module with
RPTOPTS(ON)
(You may or may not want to modify MSGFILE as well)
See:
http
-MAIN (IBM-MAIN@BAMA.UA.EDU)
Subject: Utility for LE Options?
OOPS, my idea won't work. It is the CEEROPT module itself
that you are trying to find what options are set.
I do not know of a dis-assembler for a CEEROPT load module.
-Original Message-
From: Bill Klein [mailto:wmkl
I don't know if this is what you are looking for, but at LE 1.9, you can
A) create a CEEROPT stand-alone module with
RPTOPTS(ON)
(You may or may not want to modify MSGFILE as well)
See:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea2180/1.9.2
B) place the resuliting load
On Mon, 7 Jan 2008 20:30:53 -0600, Ed Gould wrote:
//STEP1 EXEC PGM=BPXBATCH,PARM='PGM /bin/sleep '
//STEP2 EXEC PGM=IEFBR14,COND=(0,LE)
//SYSUT99 DD DISP=OLD,DSN=SYS1.PARMLIB
... but RACF won't help you there.
But the initiator might stop you as RMF has (assuming
On Mon, 7 Jan 2008 20:30:53 -0600, Ed Gould wrote:
On Jan 7, 2008, at 12:32 PM, Paul Gilmartin wrote:
Take my remark as largely rhetorical. IIRC, I was rebutting a prior
post expressing a phobic delusion that if PARMLIB had UACC=READ, an
incompetently or maliciously crafted job might ABEND
On Jan 8, 2008, at 7:21 AM, Paul Gilmartin wrote:
On Mon, 7 Jan 2008 20:30:53 -0600, Ed Gould wrote:
//STEP1 EXEC PGM=BPXBATCH,PARM='PGM /bin/sleep '
//STEP2 EXEC PGM=IEFBR14,COND=(0,LE)
//SYSUT99 DD DISP=OLD,DSN=SYS1.PARMLIB
... but RACF won't help you there.
But
In [EMAIL PROTECTED], on 06/27/2007
at 02:19 PM, Paul Gilmartin [EMAIL PROTECTED] said:
But, as discussed here recently, prohibiting read access doesn't prevent
the allocation, and it might be more likely that a program that ABENDs on
OPEN will exit abnormally without doing the FREE.
On Mon, 7 Jan 2008 12:46:34 -0500, Shmuel Metz (Seymour J.) wrote:
In [EMAIL PROTECTED], on 06/27/2007
Time warp?
at 02:19 PM, Paul Gilmartin said:
But, as discussed here recently, prohibiting read access doesn't prevent
the allocation, and it might be more likely that a program that ABENDs
On Jan 7, 2008, at 12:32 PM, Paul Gilmartin wrote:
On Mon, 7 Jan 2008 12:46:34 -0500, Shmuel Metz (Seymour J.) wrote:
In [EMAIL PROTECTED], on 06/27/2007
Time warp?
at 02:19 PM, Paul Gilmartin said:
But, as discussed here recently, prohibiting read access doesn't
prevent
the
In
[EMAIL PROTECTED],
on 06/21/2007
at 02:58 PM, Tom Savor [EMAIL PROTECTED] said:
Funny how it's ok for SYSPROGs to cruise Applications and tell us
what needs to be changed or how to tune our application (when we
didn't ask for their opinion), but it's not ok for us to cruise your
PARMLIB
On Wed, 27 Jun 2007 09:13:09 -0300, Shmuel Metz (Seymour J.) wrote:
If your system security is setup properly, I can see no harm in
browsing anything on the system.
One problem, which has been discussed here before, is users who
allocate systems data sets and don't free them when they're done
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Ed Gould
On Jun 22, 2007, at 7:05 AM, Thomas Berg wrote:
== Ed Gould == wrote2007-06-21 21:58:
On Jun 21, 2007, at 4:44 AM, Thomas Berg wrote:
--SNIP--
The consultants
The consultants were using our resources to compile programs
for the consultants essentially stealing resources from our
company. The two steps we made to stop the process was taking
away access to sys1.maclib and also not allowing assembler to
be invoked.
You let them off easy!
I would
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
The consultants were using our resources to compile programs for the
consultants essentially stealing resources from our company. ...
You let them off easy!
I would have dismissed them, right
On Jun 25, 2007, at 7:50 AM, Chase, John wrote:
--SNIP-
The consultants were using our resources to compile programs
for the consultants essentially stealing resources from our
company. The two steps we made to stop the process was
== Ed Gould == wrote2007-06-23 13:09:
On Jun 23, 2007, at 4:15 AM, Thomas Berg wrote:
-SNIP
That explains it. But what were they expected to do, btw ?
Thomas Berg
--
I am not sure I understand the question. They were expected to
== Ed Gould == wrote2007-06-23 01:49:
On Jun 22, 2007, at 7:05 AM, Thomas Berg wrote:
Still don't understand why they wasn't allowed to assemble their
programs.
Were they doing private programming or what ?
Thomas Berg
---SNIP
The standard company wide
On Jun 23, 2007, at 4:15 AM, Thomas Berg wrote:
-SNIP
That explains it. But what were they expected to do, btw ?
Thomas Berg
--
I am not sure I understand the question. They were expected to work
on any work that was assigned to them by our
Ed Gould wrote:
I am not sure I understand the question. They were expected to work on
any work that was assigned to them by our company. Not use their time
there for some other use. We had one consultant that was an ISV and was
using our system to do development work on his product. THEN he
On Jun 23, 2007, at 12:57 PM, Gerhard Postpischil wrote:
Ed Gould wrote:
I am not sure I understand the question. They were expected to
work on any work that was assigned to them by our company. Not use
their time there for some other use. We had one consultant that
was an ISV and was using
Chase, John wrote:
[...]
ITYM dumb rather than stupid (dumb is curable via education;
stupid is as stupid does).
That was actually a stated policy in a university (!!) where I worked
previously. In that boss's own words, If we allow you more training,
your marketability will be enhanced and
This thread was originally entitled How to list LE Options.
One of the responses was to browse the LE options member of PARMLIB. I
see this as a valid requirement for an application programmer. Hence
they need READ access to PARMLIB.
However I, from a system programmers perspective, know
need to see the LE
options (or something else) would automatically be able to see your
passwords.
A popular response to my why do you need that is people dreaming up
some possible emergency situation that never happened but might occur
some day (when everyone else is sick and there is a sev 1, so
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Thomas Berg
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List För Ed Gould
The consultants howled as
they could no longer assemble programs (no access to sys1.maclib)
???
If you hire
== Ed Gould == wrote2007-06-21 21:58:
On Jun 21, 2007, at 4:44 AM, Thomas Berg wrote:
--SNIP--
The consultants
howled as
they could no longer assemble programs (no access to sys1.maclib)
???
Our official language was COBOL nothing else was permitted into
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Barkow, Eileen
that in most medium to large organizations, lines do need
to be drawn
in order to keep people focused on the jobs they are hired to do
I take this to mean keep them stupid so that they cannot
On Fri, 22 Jun 2007 16:27:40 +1000, Ken Brick [EMAIL PROTECTED] wrote:
All valid many years ago but today with the ability to concatenate
PARMLIB we, the system programmers, just need to put a little effort
into segregating members into READ/NOREAD areas. This will still not
satisfy every one
All AUDITOR does is give me READ access to profiles and doesn't let me
circumvent security in any way, but every year during audit my manager and the
security manager have to sign off on the access and explain it.
Doesn't it also allow you to make changes using SETROPTS?
-
Too busy driving to
O
SNIP
ITYM dumb rather than stupid (dumb is curable via education;
stupid is as stupid does).
That was actually a stated policy in a university (!!) where I worked
previously. In that boss's own words,
On Fri, 22 Jun 2007 16:27:40 +1000, Ken Brick wrote:
This thread was originally entitled How to list LE Options.
One of the responses was to browse the LE options member of PARMLIB. I
see this as a valid requirement for an application programmer. Hence
they need READ access to PARMLIB.
Since
---snip--
Funny how it's ok for SYSPROGs to cruise Applications and tell us what
needs to be changed or how to tune our application
--unsnip-
In our shop, it was called Quality Assurance Review and we caught some
Chase, John wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Barkow, Eileen
that in most medium to large organizations, lines do need
to be drawn
in order to keep people focused on the jobs they are hired to do
I take this to mean keep them stupid so
On Jun 22, 2007, at 6:48 AM, Chase, John wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Thomas Berg
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List För Ed Gould
The consultants howled as
they could no longer assemble programs (no
On Jun 22, 2007, at 7:05 AM, Thomas Berg wrote:
== Ed Gould == wrote2007-06-21 21:58:
On Jun 21, 2007, at 4:44 AM, Thomas Berg wrote:
--SNIP--
The consultants
howled as
they could no longer assemble programs (no access to sys1.maclib)
???
Our official
- Original Message -
From: Rick Fochtman [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Friday, June 22, 2007 12:44 PM
Subject: Re: PARMLIB(s) (Was: how to list LE options)
---snip--
Funny how it's ok
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] För Ed Gould
Skickat: den 21 juni 2007 04:49
Till: IBM-MAIN@BAMA.UA.EDU
Ämne: Re: how to list LE options
The consultants
howled as
they could no longer assemble programs (no access to sys1
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Phil Knight
Sent: Wednesday, June 20, 2007 9:24 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: how to list LE options
Dittoever have users cruise your parmlib and then tell you how to
tune
On Thu, 21 Jun 2007 10:10:31 -0400, Farley, Peter x23353
[EMAIL PROTECTED] wrote:
Dittoever have users cruise your parmlib and then tell you how to
tune the system? Solution: UACC(NONE).
Oh really? And did you then publish elsewhere the contents of LNKLST, the
APF list, and other
To: IBM-MAIN@BAMA.UA.EDU
Sent: Thursday, June 21, 2007 10:10 AM
Subject: Re: how to list LE options
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Phil Knight
Sent: Wednesday, June 20, 2007 9:24 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: how to list
--snip---
Dittoever have users cruise your parmlib and then tell you how to
tune the system? Solution: UACC(NONE).
-unsnip-
I always figured it was b ecause that user had too much spare time.
Solution: notify
ever have users cruise your parmlib and then tell you how to tune the
system? Solution: UACC(NONE).
I have yet to see a single member of PARMLIB that is any business of anybody
outside SYSPROGs.
-
Too busy driving to stop for gas!
In this case politics led to security. Management decision (as it should
be).
- Original Message -
From: Rick Fochtman [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Thursday, June 21, 2007 11:46 AM
Subject: Re: how to list LE options
Good relations between sysprogs and application programmers are crucial to
business success. Locking yourself and your data in a closet does not
help.
I'm with Peter on this one. His comment above, says it all.
Mike Hill
Saffron Services
tel: +44(0)1-322-337338
e-mail: [EMAIL PROTECTED]
they cannot update?
Certain applications programmers can also utilize things like linklists
and apf datasets as well as LE options so they should have
the right to at least look at how they are defined to the system.
a long time ago the MVS group here would not even allow the CICS and
other groups
:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Thursday, June 21, 2007 9:44 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: how to list LE options
There are pros and cons like everything else. If you want or need tight
security controls, then on a need to know basis is a good approach.
You picked a bad
PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Thursday, June 21, 2007 11:46 AM
Subject: Re: how to list LE options
--snip---
Dittoever have users cruise your parmlib and then tell you how
to tune the system? Solution
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Thursday, June 21, 2007 10:44 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: how to list LE options
Snipped
There are pros and cons like everything else. If you want or need
applications programmers can also utilize things like linklists
and apf datasets as well as LE options so they should have
the right to at least look at how they are defined to the system.
unsnip-
Each shop has its own needs and viewpoint. In our
On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL [EMAIL PROTECTED] wrote:
:ever have users cruise your parmlib and then tell you how to tune the
system? Solution: UACC(NONE).
:I have yet to see a single member of PARMLIB that is any business of anybody
outside SYSPROGs.
How much of PARMLIB
, June 21, 2007 1:43 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: how to list LE options
-snip---
that in most medium to large organizations, lines do need to be drawn
in order to keep people focused on the jobs they are hired to do
I take
Because some fool of an auditor doesn't understand mainframes? That's just BS
IMHO. Fire the auditor for incompetence
An auditor doesn't set the rules.
They just report on compliance.
I still see no reason for a non-SYSPROG to have access to PARMLIB!
-
Too busy driving to stop for gas!
How much of PARMLIB cannot be detected by examining storage in a live system -
not using APF or anything special?
Security by obscurity is useless.
I (honestly) do not understand your point.
-
Too busy driving to stop for gas!
On Thu, 21 Jun 2007 09:44:21 -0500, Mark Zelden wrote:
... Do you really think the
APF list should be published?!
Yes. Why not? It is readily available. Using the APF list as the excuse for
preventing read access to PARMLIB is a red herring.
The APF command in ISRDDN is one of the
Binyamin Dissen wrote:
On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL [EMAIL PROTECTED] wrote:
:ever have users cruise your parmlib and then tell you how to tune the
system? Solution: UACC(NONE).
:I have yet to see a single member of PARMLIB that is any business of anybody
outside SYSPROGs.
On Thu, 21 Jun 2007 18:29:05 + Ted MacNEIL [EMAIL PROTECTED] wrote:
:How much of PARMLIB cannot be detected by examining storage in a live system
- not using APF or anything special?
:Security by obscurity is useless.
:I (honestly) do not understand your point.
That by securing parmlib
Ted MacNEIL wrote:
Because some fool of an auditor doesn't understand mainframes? That's just BS
IMHO. Fire the auditor for incompetence
An auditor doesn't set the rules.
They just report on compliance.
I still see no reason for a non-SYSPROG to have access to PARMLIB!
Assuiming there is
On Thu, 21 Jun 2007 12:55:58 -0400, Barkow, Eileen [EMAIL PROTECTED]
wrote:
And just why is it a security breach to allow someone to look at a
dataset they cannot update?
Please give me read access to the data set that has your SS# and
credit card information. I promise not to update it.
Binyamin Dissen wrote:
On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL [EMAIL PROTECTED]
wrote:
:ever have users cruise your parmlib and then tell you how to tune
the system? Solution: UACC(NONE).
:I have yet to see a single member of PARMLIB that is any business of
anybody outside SYSPROGs.
Funny how it's ok for SYSPROGs to cruise Applications and tell us what needs
to be changed or how to tune our application
Funny how I haven't worked at a shop (for over 20 years) that allowed me to
cruise applications.
Record layouts also need to be protected.
-
Too busy driving to stop for
:[EMAIL PROTECTED] On
Behalf Of Farley, Peter x23353
Sent: Thursday, June 21, 2007 12:33 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Security vs knowledge [was: RE: how to list LE options]
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent
On Thu, 21 Jun 2007 14:58:28 -0400, Tom Savor wrote:
Another pet-peave, why do companies buy tools, then SYSPROG decides that
only they get to use it. Example: My customer has purchased
CICS/Abend-Aid, but has only configured it for CICS dumps.
None of the applicatioin dumps can access it. I
On Jun 21, 2007, at 4:44 AM, Thomas Berg wrote:
--SNIP--
The consultants
howled as
they could no longer assemble programs (no access to sys1.maclib)
???
Our official language was COBOL nothing else was permitted into
production. The consultants had a habit of doing the
Funny how it's ok for SYSPROGs to cruise Applications and tell us what
needs to be changed or how to tune our application (when we didn't ask
for their opinion), but it's not ok for us to cruise your PARMLIB
settings Never heard of a PARMLIB setting getting screwed-up by
looking at it.
Wayne Driscoll wrote:
In the JES2 Init deck, you can specify clear text passwords for RJE
lines. That is a great reason for specifying UACC(NONE).
It is also good reason to get rid of such solution.
However, if - for any reason - it cannot be done, this is really good
reason for UACC(N).
On Thu, 21 Jun 2007 15:14:00 -0500, Robert Justice [EMAIL PROTECTED] wrote:
Funny how it's ok for SYSPROGs to cruise Applications and tell us what
needs to be changed or how to tune our application (when we didn't ask
for their opinion), but it's not ok for us to cruise your PARMLIB
settings
[EMAIL PROTECTED] wrote:
Binyamin Dissen wrote:
On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL [EMAIL PROTECTED]
wrote:
:ever have users cruise your parmlib and then tell you how to tune
the system? Solution: UACC(NONE).
:I have yet to see a single member of PARMLIB that is any business of
On 6/21/2007 3:40 PM, Wayne Driscoll wrote:
In the JES2 Init deck, you can specify clear text passwords for RJE
lines. That is a great reason for specifying UACC(NONE).
But why would you want to have clear-text RJE passwords in the JES2 init
deck when JES2 supports using RACF to perform
@BAMA.UA.EDU
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Security vs knowledge [was: RE: how to list LE options]
Date: Thu, 21 Jun 2007 15:40:02 -0400
In the JES2 Init deck, you can specify clear text passwords for RJE
lines. That is a great reason for specifying UACC(NONE).
Wayne Driscoll
Product
guy cannot
understand the application guy's point, that is
a problem.
From: Ted MacNEIL [EMAIL PROTECTED]
Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: PARMLIB(s) (Was: how to list LE options)
Date: Thu, 21 Jun 2007 18:29:05 +
How much
On Jun 21, 2007, at 1:08 PM, Barkow, Eileen wrote:
as for SMPE datasets, I was only referring to being able to look at
other compoenents SMPE datasets for which there is a real
need for in debugging a product using a different SMPE environment.
Which SMPE datasets a product uses is a function
On Jun 21, 2007, at 2:40 PM, Wayne Driscoll wrote:
In the JES2 Init deck, you can specify clear text passwords for RJE
lines. That is a great reason for specifying UACC(NONE).
Wayne Driscoll
Product Developer
JME Software LLC
NOTE: All opinions are strictly my own.
Wayne,
Not to disagree
I don't know about your shop, but at ours it gets to be a
pain when users call to complain because:
my job is 20th on the queue
Hit Enter.
Tell them:
Stop hitting enter because all the computer has time to do is service your
request to see if it moved up in the queue. Put a NOTIFY=SYSUID
@BAMA.UA.EDU
Subject: Re: Security vs knowledge [was: RE: how to list LE options]
On Jun 21, 2007, at 2:40 PM, Wayne Driscoll wrote:
In the JES2 Init deck, you can specify clear text passwords for RJE
lines. That is a great reason for specifying UACC(NONE).
Wayne Driscoll
Product Developer
JME
I keep looking thru the manuals, but all I see is the use of RPTOPTS(ON)
on some current LE using program.
I am sure (ok.. hoping) that there is a way list out all LE run-time
options?
-Rob Schramm
This e-mail transmission contains information that is confidential and may be
privileged. It
On Wed, 20 Jun 2007 12:38:44 -0400, Schramm, Rob [EMAIL PROTECTED] wrote:
I keep looking thru the manuals, but all I see is the use of RPTOPTS(ON)
on some current LE using program.
I am sure (ok.. hoping) that there is a way list out all LE run-time
options?
-Rob Schramm
If you don't know of a
:
Sorry about the length of this one. I clipped most of the comments and
unnecessary junk from the program, but it's still pretty long. Just compile the
program and run the JCL and you'll get an LE report. This is the only way I
know of to list currently active LE options
Schramm, Rob wrote:
I keep looking thru the manuals, but all I see is the use of RPTOPTS(ON)
on some current LE using program.
I am sure (ok.. hoping) that there is a way list out all LE run-time
options?
-Rob Schramm
If you are at zOS 1.7 or above this command seems to work;
D
Under z/OS V1.7 and above you can use the CEEPRMxx member in Parmlib to set
global parms. For onlines, you may need to look somewhere else for the
answers. If you are below z/OS V1.7, then you need to look at CEEUOPT,
CEECOPT, and CEEDOPT for what is set.
First, WHICH LE options do you want
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs
Schramm, Rob wrote:
I keep looking thru the manuals, but all I see is the use of
RPTOPTS(ON) on some current LE using program.
I am sure (ok.. hoping) that there is a way list out all LE run-time
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chase, John
Snipped
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs
Snipped
If you are at zOS 1.7 or above this command seems to work;
D
On Wed, 20 Jun 2007 12:19:42 -0500, Mark Zelden [EMAIL PROTECTED]
wrote:
If you don't know of a cobol program to run, compile/link the IVP:
see hlq.SIGYSAMP(IGYWFIV1)
I hadn't looked in a while. The sample name I quoted was from
COBOL for MVS VM. The same sample for Enterprise COBOL
is in
On 20 Jun 2007 09:39:22 -0700, in bit.listserv.ibm-main
(Message-ID:[EMAIL PROTECTED])
[EMAIL PROTECTED] (Schramm, Rob) wrote:
I keep looking thru the manuals, but all I see is the use
of RPTOPTS(ON)
on some current LE using program.
I am sure (ok.. hoping) that there is a way list out all
1 - 100 of 134 matches
Mail list logo
