On Mon, 12 Mar 2012 19:26:26 -0700, Edward Jaffe edja...@phoenixsoftware.com
wrote:
On 3/12/2012 7:40 AM, Mark Zelden wrote:
I don't know what you are doing wrong. You can use my CLIST as is and it
should work.
The key is the TSOLIB prior to invoking ISPF and using a modified BLSCLIBD
Mark,
Your CLIST is almost identical to my REXX exec. Except I have to push
the TSOLIB command onto the stack as it won't run under rexx, even with an
address TSO in front, and I therefore also push ISPF as well.
I tried typing in your commands at the TSO ready prompt. Still no joy
On Mon, 12 Mar 2012 04:15:59 -0500, Ron MacRae ronmac...@hotmail.co.uk wrote:
Mark,
Your CLIST is almost identical to my REXX exec. Except I have to
push the TSOLIB command onto the stack as it won't run under rexx, even with
an address TSO in front, and I therefore also push ISPF
On Mon, 12 Mar 2012 04:15:59 -0500, Ron MacRae ronmac...@hotmail.co.uk wrote:
Mark,
Your CLIST is almost identical to my REXX exec. Except I have to
push the TSOLIB command onto the stack as it won't run under rexx, even with
an address TSO in front, and I therefore also push ISPF
In 3302630680439302.wa.ronmacraehotmail.co...@bama.ua.edu, on
03/12/2012
at 04:15 AM, Ron MacRae ronmac...@hotmail.co.uk said:
Unless I can work out what's wrong I'll have to resort to messing
with ISPLLIB etc.
What's wrong is that you have then new library in ISPLLIB, which
overrides[1] the
On 3/12/2012 7:40 AM, Mark Zelden wrote:
I don't know what you are doing wrong. You can use my CLIST as is and it
should work.
The key is the TSOLIB prior to invoking ISPF and using a modified BLSCLIBD that
has LIBRARY ID instead of DATASET in the libdef. I didn't post that
CLIST
and
In
ofdc6a24ea.c6e99770-on482579be.000263a1-482579be.00036...@us.ibm.com,
on 03/11/2012
at 08:37 AM, Timothy Sipples timothy.sipp...@us.ibm.com said:
I did not post my (unofficial) thoughts as merely an academic,
theoretical exercise. In particular, I'm aware of one customer that
grabbed
Ron MacRae writes:
I've got a REXX exec that sets up an IPCS environment for z/OS levels
other than my current release With this REXX exec I can select a
version of IPCS modules/panels/ for every release of z/OS from 2.10
up to 1.13.
Bearing in mind that I do not speak for IBM, I'd like
In 4631765647494587.wa.ronmacraehotmail.co...@bama.ua.edu, on
03/09/2012
at 05:48 AM, Ron MacRae ronmac...@hotmail.co.uk said:
With this REXX exec I can select a version of IPCS
modules/panels/
You seem to be missing the ...
Q1) Any idea why TSOLIB ACTIVATE DDNAME(IPCSLIBS) appears to
On Sat, 10 Mar 2012 16:49:48 +0800, Timothy Sipples wrote:
If you're running OS/390 V2R10's
IPCS, you haven't stopped running OS/390 on your machine. Which means you
wouldn't be eligible for sub-capacity licensing.
Say what ???. How does running a module constitute running OS/390 ?.
So IBM is
OK, by now you see the potential problem. If you're running OS/390
V2R10's
IPCS, you haven't stopped running OS/390 on your machine. Which means
you
wouldn't be eligible for sub-capacity licensing.
That is of course not correct. IPCS (the dump viewing
program for z/OS) is distributed in
On 10 Mar 2012 00:51:45 -0800, in bit.listserv.ibm-main you wrote:
Ron MacRae writes:
I've got a REXX exec that sets up an IPCS environment for z/OS levels
other than my current release With this REXX exec I can select a
version of IPCS modules/panels/ for every release of z/OS from 2.10
Q2) Am I wasting my time here. Should the latest version of IPCS work
with all older dumps?
No, what you are trying to do is necessary. IPCS is not backwards
compatible.
Sure it is.
Not it isn't, if by backwards compatible in this case one means that
z/OS 1.13 IPCS can be relied upon to
Just ask IBM first, officially, that's all.
I did not post my (unofficial) thoughts as merely an academic, theoretical
exercise. In particular, I'm aware of one customer that grabbed Language
Environment from OS/390, ran it on z/OS, and... well, that wasn't (isn't)
free.
And yes, it's
Hi all,
I've got a REXX exec that sets up an IPCS environment for z/OS levels
other than my current release. We have SYSRES volumes for every release but
don't have all the levels IPLed. With this REXX exec I can select a version of
IPCS modules/panels/ for every release of z/OS
] On Behalf Of
Ron MacRae
Sent: Friday, March 09, 2012 6:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Backlevel IPCS issue at z/OS 1.13
Hi all,
I've got a REXX exec that sets up an IPCS environment for z/OS levels
other than my current release. We have SYSRES volumes for every release
Q1) Any idea why TSOLIB ACTIVATE DDNAME(IPCSLIBS) appears to work at z/OS
1.11 but not at 1.13?
No idea.
Q2) Am I wasting my time here. Should the latest version of IPCS work with all
older dumps?
No, what you are trying to do is necessary. IPCS is not backwards compatible.
Q3) If the answer
i Bob Shannon bshan...@rocketsoftware.com wrote:
Q1) Any idea why TSOLIB ACTIVATE DDNAME(IPCSLIBS) appears to work at z/OS
1.11 but not at 1.13?
No idea.
Q2) Am I wasting my time here. Should the latest version of IPCS work with
all older dumps?
No, what you are trying to do is
I've got a REXX exec that sets up an IPCS environment for z/
OS levels other than my current release. We have SYSRES volumes for
every release but don't have all the levels IPLed. With this REXX
exec I can select a version of IPCS modules/panels/ for every
release of z/OS from
On Fri, 9 Mar 2012 11:20:54 -0500, Don Poitras sas...@sas.com wrote:
i Bob Shannon bshan...@rocketsoftware.com wrote:
Q1) Any idea why TSOLIB ACTIVATE DDNAME(IPCSLIBS) appears to work at z/OS
1.11 but not at 1.13?
No idea.
Q2) Am I wasting my time here. Should the latest version of IPCS
If you do not invoke IPCS from TSO READY, before invoking PDF, and
then invoke IPCS, and you have a tasklib (Via STEPLIB, TSOLIB, ISPLLIB,
etc),
you may see a horrendous performance problem when you hit PF3 to terminate
an
IPCS report. There is recently opened APAR will will address this
21 matches
Mail list logo
