REXX as the only Ctrl Lang for MVS [was: JCL return code in REXX]
Farley, Peter x23353
migration to REXX...". An appropriately staged migration to REXX as the
sole control language for MVS would have introduced different default output
criteria for REXX, perhaps an efficient on-by-default statement TRACE
facility, better/more explanatory error messages, better
allocation/deallocation messages, SMF interfaces, Time/EXCP/Service Unit
reporting, etc. Remember, many of the JCL documentation and history
advantages you mention can be turned off with a simple MSGLEVEL=(0,0) in the
JOB card, so JCL is not immune to the "dedication and foresightedness of the
programmer and/or the standards in place at the time". It takes a whole
village of idiots to really create a FUBAR situation, not just (or not
always, anyway) one rogue programmer.
I did not contemplate eliminating JES, just enhancing it to use REXX for
it's control language instead of/in parallel to JCL as we have always known
it. "Instead of" is the goal, "in parallel to" is the judicious migration
plan.
It would have been possible, is all I was trying to say. It's still
possible, though much less probable IMHO due to the views and attitudes that
say "the mainframe is dead, no more mainframe investment".
And I still think the Armonk MVS bigots are the main reason it never
happened and probably won't. But then, I'm a product of the hippie 60's so
consiracy theories come easily to me... :)
Peter
> -----Original Message-----
> From: Robert Zenuk [mailto:Robz...@AOL.COM]
> Sent: Tuesday, December 21, 2004 12:47 PM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: JCL return code in REXX
>
> The thing that JCL/JES brings to the table is guaranteed
> output.
<Snipped>
> TSO CLIST and REXX can be the same way. If the coder decides
> to simply WRITE or SAY all the output to the screen, the
> data and results are lost forever. The thing that JCL
> brings to the table is it enforces good practices and
> insures you will have output for diagnostic purposes. When
> all the output control is in the hands of the developer, you
> are at the mercy of the dedication and foresightedness of
> the programmer and/or the standards in place at the time.
>
> I love REXX, but (like anything else) in the hands of someone
> with no foresight, you can have a mess on your hands. I am
> thankful MVS/JES has the extensive SYSLOG that shows every
> system command execution and the results. I am also
> thankful that any job that was run is recorded and the
> details are in the spool as well as SMF data to back it up.
> The JOBLOG, the JCL, the Allocation/Deallocation messages and
> all the SYSOUT's make problem determination much easier. If
> all this was done by interactive REXX, we might start
> missing stuff we can see today. REXX is extremely powerful,
> but (to quote Spiderman's
> Uncle) with great power comes great responsibility.
>
> Rob
_
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Bill Schoen
the control you enjoy rather than in Armonk. The challenges are first
technical, not political. There are a number of issues, but possibly one
of the most serious deals with job scheduling.
With REXX as the control language it would be necessary to loose C/I, at
least as we know it, along with the scheduling hooks most of your shops
probably rely on directly or through scheduling packages. It is not likely
that a dynamic language like REXX could be preprocessed in such a way that
all allocations would be known before the job runs (JES3) or step runs
(JES2), for in so doing, you loose much of the power of having a
programming language. This will lend itself to deadlocks and cancelled
jobs to break deadlocks due to allocation conflicts.
There was a brief prior discussion of the Burroughs control language
(called WFL, by the way) which was fairly dynamic in logic flow, although I
cannot imagine anyone confusing WFL with ALGOL. It is also not at all
similar to the system language as was suggested. BTW, the system language
was not really ALGOL but ESPOL and later NEWP as well as the special use
languages DCALGOL and DMALGOL, all somewhat (perhaps very) obscure dialects
of ALGOL 60. WFL had file declarations yet did not solve the general
resource scheduling issue which lead to deadlock type of problems when
external scheduling methods were not informed of required resources for all
jobs. Oversight was often probably due to complex program and recovery
flows through the WFL. These statements are based solely on my
recollection of many years of Burroughs experience through 1985, and that
has been a while.
Using a "real" programming language for job control seems to me to be
straddling the fence between interactive use and batch use. If you really
want to use REXX for job control today, it seems it shouldn't be that
difficult. You need a small JCL shell that has a couple DD statements and
EXEC PGM=IRXJCL. Code up your "job control" in REXX using Address MVS
"alloc..." to do your allocations (or bpxwdyn(), if you choose) and Address
ATTCHMVS to run your program. I have done hundreds of these type of things
as interactive tools, but very rarely expect this to be sufficiently
reliable for batch work.
Bill Schoen
Farley, Peter x23353
(now that you have listed them) remember the terms WFL, ESPOL, etc. It was
1975 when I last had access to a Burroughs environment, so my memory is
fainter than yours. My memory told me that at the time I did have access to
Burroughs, I had the impression that WFL was (very nearly) ESPOL, in kind if
not in all details. But I bow to your more extensive experience, I won't
insist on it.
You make cogent points about C/I and scheduling issues. On deeper
reflection of your reply I realized that it is, as you said, probably *not*
possible to scan a REXX (or other "programming" language) source to
statically identify all needed resources, barring explicit notification via
special-purpose scheduling-language elements, etc. Deadlocks are thus
entirely too possible.
And of course you are also correct that it is not very difficult to use
IRXJCL or even IKJEFTxx as the shell for REXX control of a job process if
you really want to do so.
I have just been frustrated sometimes by the inability to use JCL in a more
"programming" style. As usual in life, there are always tradeoffs and
compromises. I guess it isn't so bad to have to live with JCL, given the
potentials for FUBAR. But I *do* wish that idiotic 100-char PARM limit
would get lifted... :)
Thanks again for a thoughtful reply, and for the education along the way.
Peter
_
Bill Schoen
is undoubtedly one of the poorest languages I have had to use. It is not
only poor in capability but poor in syntax. There is no question in my
mind that the language could be significantly improved without loosing the
objectives it is intended to meet. It is unlikely there is anything on the
horizon to address any of this. I believe it will take a significant
community effort (or perhaps several and continuing efforts) through
communities such as SHARE to set correct objectives and priority for
investment in this area.
Bill Schoen
Ravikiran K N
I would like to any method to find the userids using a particular dataset.
I want to run in batch or rexx..and put all userids in a separate dataset
for further processing..like notifying them.
I did a lot of research for 2 to 3 months but i did not get any clue.
Please let me know if u know something about it.
Thanks in advance
Ravi
Robert Zenuk
/*********************************************************************/
/* REXX */
/*********************************************************************/
/* Purpose: Sample for QUERYENQ */
/*-------------------------------------------------------------------*/
/* Syntax: QUERYENQ major minor asname */
/*-------------------------------------------------------------------*/
/* Parms: major - The Major ENQ name (* for all, the default) */
/* minor - The Minor ENQ name (* for all, the default) */
/* asname - Address space name (defaults to userid) */
/* */
/* Example: ===> TSO QUERYENQ * userid.mydata * */
/* */
/* This shows all users of DSN userid.mydata */
/* */
/*********************************************************************/
/* Change Log */
/* */
/* Author Date Reason */
/* -------- --------- ----------------------------------------- */
/* R. Zenuk Sep 2004 Initial Creation */
/* */
/*********************************************************************/
arg major minor asname
if major = '' then major = '*'
if minor = '' then minor = '*'
if asname = '' then asname = userid()
address ISPEXEC
"QUERYENQ TABLE(QUERYENQ) QNAME(MAJOR) RNAME(MINOR) XSYS",
"REQ("asname") SAVE(ENQ)"
QRC = RC
if QRC < 8 then
do
if QRC = 2 then
zedlmsg = 'XSYS not specified and ENQ''s may exist on other',
'systems in the GRS Star'
if QRC = 4 then
zedlmsg = 'Number of ENQ''s exceeded the limit and the output',
'was truncated'
"SETMSG MSG(ISRZ000)"
"TBEND QUERYENQ"
prefix = sysvar('SYSPREF')
select
when prefix = userid() then
"BROWSE DATASET('"userid()".ENQ.ENQLIST')"
when prefix <> userid() then
"BROWSE DATASET('"prefix"."userid()".ENQ.ENQLIST')"
otherwise
do
zedlmsg = 'ENQ.ENQLIST DSN was not found'
"SETMSG MSG(ISRZ000)"
end
end
end
else
say 'QUERYENQ' major minor asname 'RC='RC
Rob
Ravikiran K N
It is working fine..
Thanks for ur time and ur response
Regards
Ravi
Stephen E. Bacher
>I have just been frustrated sometimes by the inability to use JCL in a more
>"programming" style. As usual in life, there are always tradeoffs and
>compromises. I guess it isn't so bad to have to live with JCL, given the
>potentials for FUBAR. But I *do* wish that idiotic 100-char PARM limit
>would get lifted... :)
There have been requests for this. But the problem is that you can't
just increase the limit, because there are millions of compiled programs
out there that are coded to take a PARM field that has a maximum length
of 100. Any JCL that passed a longer field would potentially cause a
buffer overflow in such programs.
Proposals to create a new parameter called XPARM or such have been
offered as an alternative, to retain compatibility.
- seb
pjfarley3
specious. Every program I have ever written that accesses the PARM
does so via it's address passed from the system. Individual elements
may be copied or moved around, but never the whole PARM area. One does
not store into the PARM, that's not allowed, so where's the harm?
Moving the whole PARM based on it's length? Bad coding practice, IMHO.
Look at it in place, pull out the pieces you need as you decode them.
And even if there are such programs, so what? Anyone who passes a
"large PARM" to an old program not coded for it deserves exactly what
they get - memory corruption and unpredictable behavior. PARM has to
be explicitly coded (and statically, at that) in JCL, so (mis)use is
entirely in the hands of the programmer that codes the JCL. The
programs are not the issue, it's JCL that is the issue.
My point is that "existing code" INCLUDES all the JCL that now confirms
to the 100-char limit. As long as the JCL is not changed, there is no
chance to affect the programs to which PARM is passed.
Just my US$0.02 worth.
Peter
Paul Gilmartin
> Date: Thu, 23 Dec 2004 08:00:30 -0500
>
> "Farley, Peter x23353" <Peter_...@ADP.COM> wrote:
>
> >I have just been frustrated sometimes by the inability to use JCL in a more
> >"programming" style. As usual in life, there are always tradeoffs and
> >compromises. I guess it isn't so bad to have to live with JCL, given the
> >potentials for FUBAR. But I *do* wish that idiotic 100-char PARM limit
> >would get lifted... :)
>
> There have been requests for this. But the problem is that you can't
> just increase the limit, because there are millions of compiled programs
> out there that are coded to take a PARM field that has a maximum length
> of 100. Any JCL that passed a longer field would potentially cause a
> buffer overflow in such programs.
>
Two ways of looking at this:
1. No breakage would be created. Those programs would continue to
work as they do today with the same PARMs they are passed today
in the JCL that invokes them today.
2. No breakage would be created. Those programs can today be passed
PARMs of up to 32,767 characters with Rexx "address 'ATTCHMVS'"
(this is TSO-REXX, isn't it?) or with assembler ATTACH. They
would continue to exhibit the same behavior when called from JCL
with long PARMs that they exhibit today when ATTACHed from Rexx
with the same PARMs.
Your argument is spurious.
> Proposals to create a new parameter called XPARM or such have been
> offered as an alternative, to retain compatibility.
>
I'll cheerfully accept that if the interface is R1 points to a list of
fullwords which point to strings prefaced by halfword lengths, so that
the programs that I now ATTCHMVS from Rexx with long PARMs can, with no
modification, be EXECed from JCL with equivalent XPARMs.
-- gil
--
StorageTek
INFORMATION made POWERFUL
Jeremy C B Nicoll
Paul Gilmartin <gil...@UNIX.STORTEK.COM> wrote:
> Two ways of looking at this:
> 1. No breakage would be created. Those programs would continue to
> work as they do today with the same PARMs they are passed today
> in the JCL that invokes them today.
I agree with that.
> 2. No breakage would be created. Those programs can today be passed
> PARMs of up to 32,767 characters with Rexx "address 'ATTCHMVS'"
> (this is TSO-REXX, isn't it?) or with assembler ATTACH. They
> would continue to exhibit the same behavior when called from JCL
> with long PARMs that they exhibit today when ATTACHed from Rexx
> with the same PARMs.
Yes, but one has to assume that when someone sets up an ATTCHMVS or
ATTACH call of such a program they look carefully at what the program
expects and can cope with, and tests what they are doing - in other
words, there's a programmer involved.
However a change of JCL to try to pass a longer parm to an existing
program will likely be done by someone who isn't a programmer and
doesn't even consider that they've changed anything.
At present anyone trying to put too much data into a PARM will generate
a JCL ERROR which protects the program from running with partial parms.
If the mechanism is changed so that JCL allows longer parms then a
program which can't cope with them can be called with a too-long parm
and the result is unpredictable.
I think your argument is only valid if anyone changing the JCL for use
of a particular program is careful & knowledgable.
--
Jeremy C B Nicoll - my opinions are my own.
Stephen E. Bacher
>> PARMs of up to 32,767 characters with Rexx "address 'ATTCHMVS'"
>> (this is TSO-REXX, isn't it?) or with assembler ATTACH. They
>> would continue to exhibit the same behavior when called from JCL
>> with long PARMs that they exhibit today when ATTACHed from Rexx
>> with the same PARMs.
>
>Yes, but one has to assume that when someone sets up an ATTCHMVS or
>ATTACH call of such a program they look carefully at what the program
>expects and can cope with, and tests what they are doing - in other
>words, there's a programmer involved.
>
>However a change of JCL to try to pass a longer parm to an existing
>program will likely be done by someone who isn't a programmer and
>doesn't even consider that they've changed anything.
Correct. In fact, it may not even involve a JCL "deck" change. If a
PROC is invoked that includes a symbolic in a PARM string, and the job
is generated by a TSO SUBMIT inside a CLIST or REXX (bringing it back
on topic) with an argument provided "on the fly" by an end user...
>If the mechanism is changed so that JCL allows longer parms then a
>program which can't cope with them can be called with a too-long parm
>and the result is unpredictable.
Using an alternative name for the other mechanism (XPARM or whatever)
would do this. It would use the exact same interface for parameter
passing that PARM does. However, a user that wanted to make use of it
would have to request it explicitly by specifying XPARM instead of PARM.
This would protect existing JCL streams from opening themselves up to
severe problems.
- seb
Bob Bridges
Services Guide. What does it do and where can I read more about it?
---
Bob Bridges, robert...@discoverfinancial.com, 224 405-0811
rhb...@attglobal.net, 847 520-1684 xt 243
/* Happiness isn't getting what you want, it's wanting what you've got.
-Garth Brooks */
Robert Zenuk <Robz...@AOL.COM>
2004-12-22 23:35
To: TSO-...@VM.MARIST.EDU
cc:
Try this.
Robert Zenuk
robert...@DISCOVERFINANCIAL.COM writes:
Wups! What's this ISPEXEC QUERYENQ thingy? I don't see it in the ISPF
Services Guide. What does it do and where can I read more about it?
I think it showed up with ISPF z/OS 1.2?
Rob
Imbriale, Donald , Exchange
for z/OS 1.2.
Don Imbriale
>-----Original Message-----
>From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On
Behalf Of
>Bob Bridges
>Sent: Thursday, December 23, 2004 12:13 PM
>To: TSO-...@VM.MARIST.EDU
>Subject: Re: To OUTTRAP "TSO WHOHAS"
>
>Wups! What's this ISPEXEC QUERYENQ thingy? I don't see it in the ISPF
>Services Guide. What does it do and where can I read more about it?
>
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
Chambers, David W.
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU]On Behalf
Of Bob Bridges
Sent: Thursday, December 23, 2004 12:13 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: To OUTTRAP "TSO WHOHAS"
Wups! What's this ISPEXEC QUERYENQ thingy? I don't see it in the ISPF
Services Guide. What does it do and where can I read more about it?
---
Bob Bridges, robert...@discoverfinancial.com, 224 405-0811
rhb...@attglobal.net, 847 520-1684 xt 243
/* Happiness isn't getting what you want, it's wanting what you've got.
-Garth Brooks */
Robert Zenuk <Robz...@AOL.COM>
2004-12-22 23:35
To: TSO-...@VM.MARIST.EDU
cc:
Subject: Re: To OUTTRAP "TSO WHOHAS"
Try this.
Bob Bridges
if we have OS/390 at our shop, not z/OS, then QUERYENQ won't be available?
And will one of the MVSVAR or SYSVAR readings tell me what -- oh, here it
is, mvsvar('SYSOPSYS'). Looks like I have z/OS after all. Guess I'd
better switch all my IBM manual references around, then. Thanks, guys.
---
Bob Bridges, robert...@discoverfinancial.com, 224 405-0811
rhb...@attglobal.net, 847 520-1684 xt 243
/* Happiness isn't getting what you want, it's wanting what you've got.
-Garth Brooks */
"Imbriale, Donald (Exchange)" <DIMB...@BEAR.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
2004-12-23 11:22
Please respond to TSO REXX Discussion List
To: TSO-...@VM.MARIST.EDU
cc:
Subject: Re: To OUTTRAP "TSO WHOHAS"
QUERYENQ IS described in the ISPF Services Guide. It was added in ISPF
for z/OS 1.2.
Don Imbriale
>-----Original Message-----
>From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On
Behalf Of
>Bob Bridges
>Sent: Thursday, December 23, 2004 12:13 PM
>To: TSO-...@VM.MARIST.EDU
>Subject: Re: To OUTTRAP "TSO WHOHAS"
>
>Wups! What's this ISPEXEC QUERYENQ thingy? I don't see it in the ISPF
>Services Guide. What does it do and where can I read more about it?
>
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
----------------------------------------------------------------------
Paul Gilmartin
> Date: Thu, 23 Dec 2004 11:58:27 -0500
>
> >> 2. No [new] breakage would be created. Those programs can today be passed
> >> PARMs of up to 32,767 characters with Rexx "address 'ATTCHMVS'"
> >> (this is TSO-REXX, isn't it?) or with assembler ATTACH. They
> >> would continue to exhibit the same behavior when called from JCL
> >> with long PARMs that they exhibit today when ATTACHed from Rexx
> >> with the same PARMs.
> >
> >Yes, but one has to assume that when someone sets up an ATTCHMVS or
> >ATTACH call of such a program they look carefully at what the program
> >expects and can cope with, and tests what they are doing - in other
> >words, there's a programmer involved.
> >
Oh, you dreamers! I believe that many coding JCL have more
knowledge of MVS Concepts and Facilities than I, and many
coding Rexx have less. It might well be the opposite of what
you assume. I suspect the wise old dinosaur is more likely
to be found coding JCL and the impetuous PFCSK is more likely
to be found coding Rexx.
> >However a change of JCL to try to pass a longer parm to an existing
> >program will likely be done by someone who isn't a programmer and
> >doesn't even consider that they've changed anything.
>
Call me an impetuous PFCSK. I've invoked many programs with
ATTCHMVS, often with PARMs >100 characters. I've never looked
at the source code to see what implicit limitations there may
be on PARM length. Sometimes I can't; they're OCO. Nor have I
looked for such limitations in the RMs. How many programs
document limitations on their PARM length, anyway? (Usually
all I find are JCL examples, and I have been told by IBM
support on issues other than PARM length that invoking the
utility involved other than from JCL is unsupported.)
And if I were a developer (which I sometimes am), and I were
to impose a limit on PARM length (which I wouldn't do), I'd
consider it far more important to validate the length of the
PARM in the code than document the restriction in the manual.
> Correct. In fact, it may not even involve a JCL "deck" change. If a
> PROC is invoked that includes a symbolic in a PARM string, and the job
> is generated by a TSO SUBMIT inside a CLIST or REXX (bringing it back
> on topic) with an argument provided "on the fly" by an end user...
>
Why do you assume that the Rexx coder would write to a file and
SUBMIT rather than writing directly to SYSOUT,WRITER=INTRDR?
The latter is certainly my coding style.
> Using an alternative name for the other mechanism (XPARM or whatever)
> would do this. It would use the exact same interface for parameter
> passing that PARM does. However, a user that wanted to make use of it
> would have to request it explicitly by specifying XPARM instead of PARM.
> This would protect existing JCL streams from opening themselves up to
> severe problems.
>
We're in strong agreement here. And that mechanism would prevent
the most serious hazard, not previously discussed here. Buffer
overflow is most dangerous to an Authorized Program; then it
carries a threat to security. With a distinctive XPARM keyword
the initiator could be enhanced to EXEC programs only in
unauthorized state if XPARM was specified.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Stephen E. Bacher
>> PROC is invoked that includes a symbolic in a PARM string, and the job
>> is generated by a TSO SUBMIT inside a CLIST or REXX (bringing it back
>> on topic) with an argument provided "on the fly" by an end user...
>>
>Why do you assume that the Rexx coder would write to a file and
>SUBMIT rather than writing directly to SYSOUT,WRITER=INTRDR?
I don't (that was just an instance), but it wouldn't make any
difference anyway, as far as the // EXEC statement on the JCL is
concerned.
>We're in strong agreement here.
Finally. I hoped we would be.
>And that mechanism would prevent
>the most serious hazard, not previously discussed here. Buffer
>overflow is most dangerous to an Authorized Program; then it
>carries a threat to security. With a distinctive XPARM keyword
>the initiator could be enhanced to EXEC programs only in
>unauthorized state if XPARM was specified.
That sounds excessive. Rather, programs that execute authorized
ought to be responsible themselves for checking parameter lengths.
- seb
Paul Gilmartin
> Date: Thu, 23 Dec 2004 15:31:28 -0500
> >>
> >Why do you assume that the Rexx coder would write to a file and
> >SUBMIT rather than writing directly to SYSOUT,WRITER=INTRDR?
>
> I don't (that was just an instance), but it wouldn't make any
> difference anyway, as far as the // EXEC statement on the JCL is
> concerned.
>
You're right, of course. A mental lapse. What I was thinking
when I wrote something else is that when possible I'll just
ATTCHMVS the program rather than building a job and SUBMITting
it. And that provides no safeguard against buffer overflow.
(I'll ATTACH rather than SUBMIT for reasons discussed here
lately: Better monitoring of flow; simple indication of
program completion.)
> >And that mechanism would prevent
> >the most serious hazard, not previously discussed here. Buffer
> >overflow is most dangerous to an Authorized Program; then it
> >carries a threat to security. With a distinctive XPARM keyword
> >the initiator could be enhanced to EXEC programs only in
> >unauthorized state if XPARM was specified.
>
> That sounds excessive. Rather, programs that execute authorized
> ought to be responsible themselves for checking parameter lengths.
>
Little is excessive when security matters. And if authorized
programs can be expected to check parameter lengths, can't
unauthorized programs be expected to do the same?
I sense a red herring here. The exposure to excessive PARM
lengths already exists in most ways (probably all but two)
in which a program can be invoked. It's being dealt with.
I've never heard a programmer wish for an external mechanism
for restricting PARM length. Extending the capability
of long PARMs to the remaining two techniques will broaden
the exposure little and provide enormous convenience to
users. I flinch whenever I'm told of the alternatives:
Rexx wrappers; SYSIN-to-PARM utilities from the CBT site,
etc. I consider the prevalence of such circumventions an
argument for, rather than against, the requirement.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Stephen E. Bacher
>>> [...] Buffer
>>>overflow is most dangerous to an Authorized Program; then it
>>>carries a threat to security. With a distinctive XPARM keyword
>>>the initiator could be enhanced to EXEC programs only in
>>>unauthorized state if XPARM was specified.
>>
>> That sounds excessive. Rather, programs that execute authorized
>> ought to be responsible themselves for checking parameter lengths.
>>
>Little is excessive when security matters. And if authorized
>programs can be expected to check parameter lengths, can't
>unauthorized programs be expected to do the same?
"With great power comes great responsibility."
There are far fewer authorized programs than non-authorized ones,
and far fewer authorized program programmers as well. Programmers who
write authorized programs are expected to exercise greater care,
experience and understanding than those who write only "regular"
programs.
>I've never heard a programmer wish for an external mechanism
>for restricting PARM length.
But that's effectively what you are asking for above, in restricting
PARM length to 100 when invoking APF authorized programs.
Of course, there are other issues, such as the bogosity of requiring
IEBCOPY et al. to run authorized. This leads to various "exception"
environments, like the old ISPF IEBCOPY SVC, which opened up all sorts
of exposures. Authorization should be limited to a small and
well-defined set of operations. But I digress.
- seb
Paul Gilmartin
> Date: Thu, 23 Dec 2004 16:05:59 -0500
>
> >I've never heard a programmer wish for an external mechanism
> >for restricting PARM length.
>
> But that's effectively what you are asking for above, in restricting
> PARM length to 100 when invoking APF authorized programs.
>
That was rhetoric. But if it should be done right, let's
submit a requirement that:
o Each load module be provided with a new attribute: a flag indicating
whether it can accept a PARM >100 chars (or even a half word
indicating the maximum PARM length.
o ATTACH, LINK, and XCTL be modified to validate the actual PARM
length against that attribute, and fail if the actual PARM
exceeds the permissible max. Programs that take PARMS in
nonstandard format should specify x'FFFF' as their max.
Yeah, I know, more rhetoric. But if there's a real hazard,
there should be genuine protection.
I suspect some rationalization: we despair of getting relief
from IBM, so we seek virtues in the restriction and blind
ourselves to the greater value of being freed from it.
> Of course, there are other issues, such as the bogosity of requiring
> IEBCOPY et al. to run authorized. This leads to various "exception"
> environments, like the old ISPF IEBCOPY SVC, which opened up all sorts
> of exposures. Authorization should be limited to a small and
> well-defined set of operations. But I digress.
>
I'll run with that. From:
# 2.542 "z/OS V1R6.0 MVS System Messages, Vol 7 (IEB-IEE)"
| 2.542 IEB1099I
___________________________________________________________________________________________________________
| IEB1099I *** IEBCOPY IS NOT APF AUTHORIZED ***
| Explanation: IEBCOPY has found that it is not authorized, and may not be
| able to perform the operation.
| The severity is 0.
| System Action: IEBCOPY will continue to determine if it can proceed
| without authorization and will issue IEB1099E when it can not avoid using
| a service requiring authorization.
Hmmm. A while ago, I received IEB1099I from a job and found the
message was undocumented, and that the behavior it describes is
not mentioned in the Utilities RM. I opened a PMR requesting
that IEB1099I be documented in M&C, and that the Utilities RM
describe clearly the conditions under which IEBCOPY can operate
without authorization.
IBM added IEB1099I to M&C but balked at updating Utilities RM,
stating that a description could be taken as a committment to
support, and they didn't want to do that.
In practice, I've never gotten the IEB1099E failure when INDD
and OUTDD are both PDSE.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
Steve Comstock
robert...@DISCOVERFINANCIAL.COM writes:
> Hmm...I'm a little fuzzy on z/OS vs OS/390, etc. I take it, though, that
> if we have OS/390 at our shop, not z/OS, then QUERYENQ won't be available?
>
> And will one of the MVSVAR or SYSVAR readings tell me what -- oh, here it
> is, mvsvar('SYSOPSYS'). Looks like I have z/OS after all. Guess I'd
> better switch all my IBM manual references around, then. Thanks, guys.
>
Well. Must be time for some training. How about, "Introduction to z/OS?" a
one day lecture / discussion about major z/OS features, for both folks new to
the IBM mainframe and experienced mainframe folks who might need a little
update? (see http://www.trainersfriend.com/A500Descrpt.htm)
Then maybe more updates such as ISPF / Dialog Manager, Assembler, COBOL,
PL/I; UNIX System Services; CICS TS; DB2 V7 / V8; you're sure to find something
interesting here: http://www.trainersfriend.com/zoscurric.htm
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
Frank Clarke
<200412231300...@support12.draper.com>
>There have been requests for this. But the problem is that you can't
>just increase the limit, because there are millions of compiled programs
>out there that are coded to take a PARM field that has a maximum length
>of 100. Any JCL that passed a longer field would potentially cause a
>buffer overflow in such programs.
As a matter of practice, I never code for less than 255 bytes of parameter even
if JCL cannot send that much to me.
As they say: better to have and not need than to need and not have.
(change Arabic number to Roman numeral to email)
Ravikiran K N
Just one more question for you..
Can i know how we can use the below code for other datasets like
'cg03.tso.source'
.But it does not come under my userid (CG52).
Regards
Ravi
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Robert Zenuk
Sent: Thursday, December 23, 2004 11:06 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: To OUTTRAP "TSO WHOHAS"
Robert Zenuk
raviki...@CGI.COM writes:
Just one more question for you..
Can i know how we can use the below code for other datasets like
'cg03.tso.source'
.But it does not come under my userid (CG52).
The QUERYENQ EXEC has 3 parameters:
Major ENQ name (defaults to '*')
Minor ENQ name (defaults to '*')
Address space name (defaults to Userid)
To see an ENQ for all address spaces set the last parameter to '*'.
===> TSO QUERYENQ * cg03.tso.source *
With all the discussion around the release level, here is a version that
checks your current OS/ISPF release level and will give an information message
if you are backleveled for the QUERYENQ service. I also added comments.
/*********************************************************************/
/* REXX */
/*********************************************************************/
/* Purpose: Sample for QUERYENQ */
/*-------------------------------------------------------------------*/
/* Syntax: QUERYENQ major minor asname */
/*-------------------------------------------------------------------*/
/* Parms: major - The Major ENQ name (* for all, the default) */
/* minor - The Minor ENQ name (* for all, the default) */
/* asname - Address space name (defaults to userid) */
/* */
/* Example: ===> TSO QUERYENQ * userid.mydata * */
/* */
/* This shows all users of DSN userid.mydata */
/* */
/*********************************************************************/
/* Change Log */
/* */
/* Author Date Reason */
/* -------- --------- ----------------------------------------- */
/* R. Zenuk Sep 2004 Initial Creation */
/* R. Zenuk 12/27/04 Added a message for backleveled OS/ISPF */
/* */
/*********************************************************************/
/* Accept parms */
/*********************************************************************/
arg major minor asname
if major = '' then major = '*'
if minor = '' then minor = '*'
if asname = '' then asname = userid()
address ISPEXEC
/*********************************************************************/
/* Determine the release level */
/*********************************************************************/
"VGET (ZISPFOS) PROFILE"
parse var zispfos . . os osrelv '.' osrelr '.' osrelm .
if os = 'OS/390' | (osrelv = 1 & osrelr < 2) then
do
zedlmsg = 'QUERYENQ is not supported under' zispfos
"SETMSG MSG(ISRZ000)"
exit 20
end
/*********************************************************************/
/* Query for ENQ's and save the results in a dataset */
/*********************************************************************/
"QUERYENQ TABLE(QUERYENQ) QNAME(MAJOR) RNAME(MINOR) XSYS",
"REQ("asname") SAVE(ENQ)"
QRC = RC
if QRC < 8 then
do
if QRC = 2 then
zedlmsg = 'XSYS not specified and ENQ''s may exist on other',
'systems in the GRS Star'
if QRC = 4 then
zedlmsg = 'Number of ENQ''s exceeded the limit and the output',
'was truncated'
/*********************************************************************/
/* Set an error message if warnings occurred */
/*********************************************************************/
"SETMSG MSG(ISRZ000)"
/*********************************************************************/
/* End the QUERYENQ table */
/*********************************************************************/
"TBEND QUERYENQ"
prefix = sysvar('SYSPREF')
/*********************************************************************/
/* Determine which dataset to browse */
/*********************************************************************/
select
when prefix = userid() then
"BROWSE DATASET('"userid()".ENQ.ENQLIST')"
when prefix <> userid() then
"BROWSE DATASET('"prefix"."userid()".ENQ.ENQLIST')"
otherwise
do
zedlmsg = 'ENQ.ENQLIST DSN was not found'
"SETMSG MSG(ISRZ000)"
end
end
end
else
/*********************************************************************/
/* Unexpected error */
/*********************************************************************/
Ravikiran K N
I have included ur code in member QUERYENQ in my personal dataset.
When i give TSO QUERYENQ * cg52.tso.source * in command line
It is returning Return code '8' with message "QUERYENQ * CG52.TSO.SOURCE *
RC=8"
Please throw some light on this problem.
Regards, Ravi
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Robert Zenuk
Sent: Monday, December 27, 2004 9:35 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: To OUTTRAP "TSO WHOHAS"
Ravikiran K N
but TSO QUERYENQ * cg03.tso.source * isnot working..
Ravi
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Robert Zenuk
Sent: Monday, December 27, 2004 9:35 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: To OUTTRAP "TSO WHOHAS"
Robert Zenuk
raviki...@CGI.COM writes:
TSO QUERYENQ is working fine
but TSO QUERYENQ * cg03.tso.source * isnot working..
Not quite sure what to tell you. It is working fine for me. You might try
putting a "trace i" in the EXEC and watch what happens...
You could also hardcode the MINOR name to the DSN you want and change the
ASNAME to '*', but all this would make the EXEC less functional...
Robert Zenuk
raviki...@CGI.COM writes:
I have included ur code in member QUERYENQ in my personal dataset.
When i give TSO QUERYENQ * cg52.tso.source * in command line
It is returning Return code '8' with message "QUERYENQ * CG52.TSO.SOURCE *
RC=8"
Please throw some light on this problem.
Oops, sorry I did not notice you had the RC=8 in this email. RC=8 means
there are NO ENQ's for the request.
Here is the link to the ISPF Services Guide:
_http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ISPZSG10/2.27.5?SH
ELF=ISPZPM10&DT=20010618134533_
(http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ISPZSG10/2.27.5?SHELF=ISPZPM10&DT=20010618134533)
Here is a new copy of the code that spells that out explicitly:
/*********************************************************************/
/* REXX */
/*********************************************************************/
/* Purpose: Sample for QUERYENQ */
/*-------------------------------------------------------------------*/
/* Syntax: QUERYENQ major minor asname */
/*-------------------------------------------------------------------*/
/* Parms: major - The Major ENQ name (* for all, the default) */
/* minor - The Minor ENQ name (* for all, the default) */
/* asname - Address space name (defaults to userid) */
/* */
/* Example: ===> TSO QUERYENQ * userid.mydata * */
/* */
/* This shows all users of DSN userid.mydata */
/* */
/*********************************************************************/
/* Change Log */
/* */
/* Author Date Reason */
/* -------- --------- ----------------------------------------- */
/* R. Zenuk Sep 2004 Initial Creation */
/* R. Zenuk 12/27/04 Added a message for backleveled OS/ISPF */
/* R. Zenuk 12/28/04 Added a message for no ENQ exists */
if QRC <= 8 then
do
if QRC = 2 then
zedlmsg = 'XSYS not specified and ENQ''s may exist on other',
'systems in the GRS Star'
if QRC = 4 then
zedlmsg = 'Number of ENQ''s exceeded the limit and the output',
'was truncated'
if QRC = 8 then
zedlmsg = 'No ENQs exist for MAJOR='major 'MINOR='minor,
'ASNAME='asname
/*********************************************************************/
/* Set an error message if warnings occurred */
/*********************************************************************/
"SETMSG MSG(ISRZ000)"
if QRC = 8 then exit 8
/*********************************************************************/
/* End the QUERYENQ table */
/*********************************************************************/
"TBEND QUERYENQ"
prefix = sysvar('SYSPREF')
/*********************************************************************/
/* Determine which dataset to browse */
/*********************************************************************/
select
when prefix = userid() then
"BROWSE DATASET('"userid()".ENQ.ENQLIST')"
when prefix <> userid() then
"BROWSE DATASET('"prefix"."userid()".ENQ.ENQLIST')"
otherwise
do
zedlmsg = 'ENQ.ENQLIST DSN was not found'
"SETMSG MSG(ISRZ000)"
end
end
end
else
/*********************************************************************/
/* Unexpected error */
/*********************************************************************/
say 'QUERYENQ' major minor asname 'RC='RC,
'Look in the ISPF Services Guide'
Ravikiran K N
I am getting good results if am using 'TSO QUERYENQ * CG02.TSO.SOURCE C*'
instead of
'TSO QUERYENQ * CG02.TSO.SOURCE *'. All userids start with C* so i have no
problem in getting
the result.But
I am not getting all users list.If this utility is run in TSOP3, I will get
only users who are logged into TSOP3 sessions and not those who are logged
into TSOP4.
To get all users..i need to execute in both sessions.
Is it possible to get all users executing only in one session.???
Ravi
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Robert Zenuk
Sent: Tuesday, December 28, 2004 11:59 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: To OUTTRAP "TSO WHOHAS"
Chambers, David W.
Robert Zenuk
raviki...@CGI.COM writes:
I am getting good results if am using 'TSO QUERYENQ * CG02.TSO.SOURCE C*'
instead of
'TSO QUERYENQ * CG02.TSO.SOURCE *'. All userids start with C* so i have no
problem in getting
the result.But
I am not getting all users list.If this utility is run in TSOP3, I will get
only users who are logged into TSOP3 sessions and not those who are logged
into TSOP4.
To get all users..i need to execute in both sessions.
Is it possible to get all users executing only in one session.???
The XSYS parm does this. Check IBMLink, there is some maintenance that's
needed to make this work.