On Mon, 12 Mar 2012 19:26:26 -0700, Edward Jaffe
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
>> that
>> has "LIBRAR
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
an
In <3302630680439302.wa.ronmacraehotmail.co...@bama.ua.edu>, on
03/12/2012
at 04:15 AM, Ron MacRae 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 TASKLIB created by T
On Mon, 12 Mar 2012 04:15:59 -0500, Ron MacRae 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" as well.
>
>I tried
On Mon, 12 Mar 2012 04:15:59 -0500, Ron MacRae 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" as well.
>
>I tried
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 I
In
,
on 03/11/2012
at 08:37 AM, Timothy Sipples said:
>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.
Never m
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 occasionall
>> 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
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
> 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 i
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
In <4631765647494587.wa.ronmacraehotmail.co...@bama.ua.edu>, on
03/09/2012
at 05:48 AM, Ron MacRae 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
>work at z/OS 1.11
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 lik
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
pr
On Fri, 9 Mar 2012 11:20:54 -0500, Don Poitras wrote:
>i Bob Shannon 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?
> 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
i Bob Shannon 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 necessary. IPCS is not backw
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 answe
ist [mailto:IBM-MAIN@bama.ua.edu] 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 volu
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 fro
21 matches
Mail list logo
