-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul
Gilmartin
Skickat: den 22 januari 2011 01:11
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: If Else JCL question
On Fri, 21 Jan 2011 13:28:51 +0100, Thomas Berg wrote:
I would have
Officially, the answer to all three is *NO*. IBM does not vouch for
integrity in these situations. (update while open w/DISP=SHR).
Experience indicates the actual answer to all three is yes (with
cautions). This should not be attempted by a sysprog wannabe).
In some cases (e.g. SYS1.PROCLIB,
On Mon, 24 Jan 2011 12:37:38 +0100, Thomas Berg wrote:
My main dislike with IF..THEN etc. is that the resulting JCL
is not easy to read (for me at least). With a keyword at
each EXEC it is at least more compact. And You don't have to
FSVO easy to read and compact. Compare CM Poncelet's
At 07:33 -0600 on 01/24/2011, Staller, Allan wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
Officially, the answer to all three is *NO*. IBM does not vouch for
integrity in these situations. (update while open w/DISP=SHR).
Experience indicates the actual answer to all three is yes
On Sun, 23 Jan 2011 19:05:32 -0600, Chris Mason wrote:
Poor design IMHO.
+1
In other words - in principle - I agree. There is an excuse in that the poor
developers have had constantly to try to deal with the fact that there is a
continuum of JCL including procedure override capabilities and
On Fri, 21 Jan 2011 14:17:42 -0500, Bruce Wheatley bwheat...@cds.ca wrote:
So we have set up the SSH server on z/os with it's host key pair in a RACF
certificate, z/os SSH client keys in certificates in RACF , but public
keys for clients like WINSCP are in /$HOME/.ssh2/authorization.
We would
On Mon, 24 Jan 2011 08:14:43 -0600, Paul Gilmartin paulgboul...@aim.com wrote:
At the very least, IBM should assist the customer by reporting a
JCL error for the conflicting (ineffective explicit and effective
implicit) declarations of MODE.
I hate JCL!
Of course, this discussion is not really
snip
I assume that the potential exposure in case 1 when adding as opposed
to replacing a program is that the directory is in a state of flux
involving moving entries from one block to the next (a replace would
usually only rewrite a single block up update the TTR). I know that
there is an EXC
On 1/24/2011 7:58 AM, Staller, Allan wrote:
snip
I assume that the potential exposure in case 1 when adding as opposed
to replacing a program is that the directory is in a state of flux
involving moving entries from one block to the next (a replace would
usually only rewrite a single block up
On Mon, 24 Jan 2011 06:04:55 -0800 (PST), in bit.listserv.ibm-main, Costin
Enache wrote:
Hi,
Is is possible to connect a new, Linux-based HMC (v2.10.2) to an old,
really old, OS/2-based SE (v1.6.1)? I have tried to do this, via Add
Object Definition, the HMC tries to communicate with the SE on
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul
Gilmartin
Skickat: den 24 januari 2011 14:55
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: SV: If Else JCL question
On Mon, 24 Jan 2011 12:37:38 +0100, Thomas Berg wrote:
My main
OK. Not mainframe oriented, per se. But a major announcement, none the less.
http://www.informit.com/store/product.aspx?isbn=0201038048rll=1
I ordered it via Amazon, it was a bit less expensive.
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard
On Sat, 22 Jan 2011 22:04:50 +0100, Jürgen Kehr wrote:
Hello,
today I have a question regarding HIPER PTFs or APARs. Until now I
thought that a HIPER PTF is a PTF which addresses a HIPER APAR. You may
get a list of all HIPER PTFs, if you download the file
/s390/assigns/hiper_prp.txt from
Hello group,
I'd be much appreciate that someone can help this SDSF problem.
We recently migrated from z/OS 1.9 to 1.11 and some TSO users can't access
other people's spool output anymore.
We have RACF JESSPOOL class activated and some users had profiles defined to
protect JOB output in
You should not need an exit to accomplish an override of JESSPOOL by
specific users under SDSF. What you need to do is set up your systems
folks with destination operator authority, in the SDSF class profiles.
As to z/OS 1.11, nothing has changed. There was an error at z/OS 1.10/11
that has a
Thanks Hayim,
For some reasons that I unknown of, our shop has SDSF/GSDSF class inactive.
So this is not an option.
regards,
Harry
On Mon, 24 Jan 2011 11:06:20 -0500, Hayim Sokolsky hsokol...@dtcc.com wrote:
You should not need an exit to accomplish an override of JESSPOOL by
specific users
Even in native SDSF, you do not need an exit to give them destination
operator authority. You can give them CMDAUTH=DEST and DSPAUTH=ADEST,
along with DEST= pointing to a list of destinations that you are
authorizing.
Hayim
_
Hayim Sokolsky, CISSP
Anyone, I have an associate that is trying to subscribe to IBM-MAIN.
He gets to the Join screen and it says it will send him an email, which never
arrives.
Can somebody please point me to the List Admin/Owner so he can contact
them?
Thanks in advance,
Pat L.
Have him check his junk mail filters, both at the client (email program)
level and at the server (ISP or corporate IT) level.
I'm sure about 50 listers will tell you that the admin is Darren Evans-Young
[dar...@bama.ua.edu].
Charles
-Original Message-
From: IBM Mainframe Discussion List
On Mon, 24 Jan 2011 09:14:30 -0800, Charles Mills charl...@mcn.org
wrote:
Have him check his junk mail filters, both at the client (email program)
level and at the server (ISP or corporate IT) level.
I'm sure about 50 listers will tell you that the admin is Darren Evans-Young
Gil's right. It's a scoping issue. Once you declare a variable inside your
PROC it should be yours forever no matter what else happens outside of that
scope.
In sympathy to IBM, this stuff was set in stone back in about 1964 when (a.)
scoping was not so well-established a principle as it is now;
All three of the OP's scenarios involve the update of a PDS/Directory
while the information in that PDS/Directory is in a state of flux.
I don't think so. How does the ongoing execution of a program from a STEPLIB
put its directory in a state of flux?
Charles
-Original Message-
From:
A problem that no one has pointed out is that if a job is using a STEPLIB
DISP=SHR and we say it is okay to update that library DISP=SHR, then how can
we be sure that TWO people won't try to update it at the same time DISP=SHR?
The problem -- and I'm being analytical and technical here, not
You could have him try it the old fashioned way by sending the following
message to lists...@bama.ua.edu
SUBSCRIBE IBM-MAIN
--
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov
The difference between a conviction and a prejudice is that you can explain a
conviction without
This is going to sound weird. It is in conjunction with some other strangeness
that I am considering. But I need to create a z/OS task in my TSO region which
does not go away (abend) when the TSO command which starts it terminates.
I.e. it would be a TSO DAEMON to mix TSO and UNIX terminology.
Integrity is ensured by requiring the updater to have exclusive control
(for the duration) of the resource being updated.
If *ANY* other entity in the SYS(tem or plex) is accessing whatever is
being updated, the item is in flux and a potential for
invalid/corrupted data is present.
This can be a
Patrick,
Odd you should mention this. Some of my newer team mates also have
tried to join IBM-MAIN the last few years, and have the same problem.
No, the return mail isn't stuck in a junk folder either. Almost like
blacklisted or something.
I personally joined with this email address 6 years
Hello,
thanks for your response. First of all: Everything you said I totally
agree with, but unfortunately that does not solve the problem I have.
Let's just remember:
In one of my last orders I got PTFs UK63710 (which addresses HIPER
(DATALOSS) APAR PK88044) and UK63686 (which addresses
On Mon, 24 Jan 2011 09:35:29 -0800 Charles Mills charl...@mcn.org wrote:
:As Gil points out, IBM could now give us a warning. Or even implement the
:scoping we describe. It would not break any existing PROCs (hopefully --
:well it WOULD break any that were depending on a declared symbol being
Charles
I'm trying here to keep up with something in which I only dabbled some years
ago now.
I was going to say the curtailed post to Paul until I realised this is what
you
meant in it's essence by
declare a variable inside your PROC
Since this didn't jump out at me - not necessarily the
Sorry, if I got things confused.
We have JESSPOOL class ACTIVE, but SDSF class INACTIVE.
There are a few profiles defined in class JESSPOOL. To allow certain user
access job output even its RACF protected with JESSPOOL, we use PRESAF exit
point in ISFUSER to set RC=04 (fall back to ISFPARMS);
PMJI, I think the problem is the way in which the START command is processed.
In the MSTJCL, there an STCINRDR DD. The START command (in the CONSOLE address
space?) creates a job which it submits to JES by doing a put to this DD.
The code in the START command processor does not READ the JCL for
On Mon, 24 Jan 2011 12:41:07 -0600 McKown, John
john.mck...@healthmarkets.com wrote:
:This is going to sound weird. It is in conjunction with some other
strangeness that I am considering. But I need to create a z/OS task in my TSO
region which does not go away (abend) when the TSO command which
OK, I'll try to explain what I want. My code is often sick. I do a fair
amount of UNIX work. I also use TSO a lot. I don't really want to have both a
TSO session and a UNIX shell session going. Yes, that may be what I end up
doing. So, I want to run a UNIX shell script, which may be fairly
On Mon, Jan 24, 2011 at 3:52 PM, McKown, John
john.mck...@healthmarkets.com wrote:
OK, I'll try to explain what I want.
snip
This is very interesting, but I'm not sure I grok in fullness.
Maybe a sample use for this would help folks (me, anyway) understand
the scenario better?
Meanwhile,
At 09:43 -0800 on 01/24/2011, Charles Mills wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
A problem that no one has pointed out is that if a job is using a STEPLIB
DISP=SHR and we say it is okay to update that library DISP=SHR, then how can
we be sure that TWO people won't try to
An example. OK. I use Dovetailed Technologies' dspipes in this example to read
a z/OS dataset and then write it. My command might be something like:
SH fromdsn SYS3.DISK.SYSLOG | awk '$1 ~ /IEF40[34]I/ {print $0;}' | todsn
MYID.JOBSTART.END
Yes, I could do the same with ISPF VIEW. I'm trying
-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Farley, Peter x23353
Sent: Monday, January 24, 2011 3:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: TSO daemon subtask
John,
PMFJI here, but just as an aside I don't believe that
Thanks for the advice, I'll post only via the listserv.
This calls for driver DR26W (1.6.2), and I currently have DR24Q on the
SE (1.6.1). Does anybody else have experience with this? I dream of an
easy setting on the SE, to activate the required services :) Currently
both the SE and HMC have the
On Mon, 24 Jan 2011 14:52:59 -0600, McKown, John wrote:
OK, I'll try to explain what I want. My code is often sick. I do a fair
amount of UNIX work. I also use TSO a lot. I don't really want to have both
a TSO session and a UNIX shell session going. Yes, that may be what I end up
doing. So, I
Cross posted to IBMVM, IBMMAIN, Linux390
The System z Technology Summit came to my attention in a recent issue
of the IBM SW newsletter. Looks to have a variety of topics and tracks
(abstracts are provided on the web page).
Summits are planned for several cities in the US and Canada, now
Robert A. Rosenberg wrote
begin snippet
As I noted, if the updating is being done by Linkedit/Binder (as opposed to
IEBCOPY) there is an ENQ lock (QNAME=SYSIEWL [I think] with RNAME=the DSN) that
prevents other Linkedit/Binder instances from accessing the PDS/PDSE while it
is being updated.
The Linkedit/Binder still uses a hardware reserve.
2011/1/24 john gilmore john_w_gilm...@msn.com
Robert A. Rosenberg wrote
begin snippet
As I noted, if the updating is being done by Linkedit/Binder (as opposed to
IEBCOPY) there is an ENQ lock (QNAME=SYSIEWL [I think] with RNAME=the DSN)
On Mon, 24 Jan 2011 18:01:35 -0500, Scott Rowe wrote:
The Linkedit/Binder still uses a hardware reserve.
Isn't there a capability in GRS (or am I thinking of MIM)
to convert a RESERVE to an ENQ?
-- gil
--
For IBM-MAIN
Ah. Thanks (again). Doesn't IEBCOPY use the binder under the covers for load
modules, or am I thinking of a different problem?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Robert A. Rosenberg
Sent: Monday, January 24, 2011 1:25
On Mon, Jan 24, 2011 at 4:27 PM, Charles Mills charl...@mcn.org wrote:
Ah. Thanks (again). Doesn't IEBCOPY use the binder under the covers for
load
modules, or am I thinking of a different problem?
Definitely for PDSE. Not 100% sure about PDS
Charles
-Original Message-
From:
Scott Rowe wrote:
| The linkedit/Binder still uses a hardware reserve.
I has been a very long time since it did so, materially as opposed to formally.
For the Linkage Editor the reserve has been converted into a global enq using
GRS for many years. Moreover, whjil;e I cannopt prove it in
At 22:42 + on 01/24/2011, john gilmore wrote about Re: Long-r
unning job s, PDS, an d DISP=SHR =?windows-1256?:
Robert A. Rosenberg wrote
begin snippet
As I noted, if the updating is being done by Linkedit/Binder (as
opposed to IEBCOPY) there is an ENQ lock (QNAME=SYSIEWL [I think]
with
At 16:27 -0800 on 01/24/2011, Charles Mills wrote about Re:
Long-running jobs, PDS, and DISP=SHR:
Ah. Thanks (again). Doesn't IEBCOPY use the binder under the covers for load
modules, or am I thinking of a different problem?
Charles
I think only for PDSEs. There is no need for the BINDER
49 matches
Mail list logo
