Re: Backlevel IPCS issue at z/OS 1.13
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 that has LIBRARY ID instead of DATASET in the libdef. I didn't post that CLIST and left that as an exercise for the reader, but if it helps, I'll post that also. Remember BLSCALTL needs one line changed too (I called my IPCSALTL). I won't post that CLIST, but here is the line: ALTLIB ACTIVATE APPLICATION(CLIST) DDNAME(SBLSCLI0) Our back-level IPCS execs require manual re-invocation under ISPF. I like you approach much better! Thanks. Being that you're at SHARE this week, the story behind why I create these CLISTs: Not being a software developer, I really have no need to use back level IPCS since anything I need to look at matches the system level I'm running (at least on some of the systems). But at my first SHARE (NY, 2004) I went to the IPCS dump reading / lab sessions. The dumps for the class were made available for FTP and I wanted other sysprogs at my site to be able to use them and go though the labs. However, the dump level matched a level of the OS we were just migrating off of and I already knew there was a problem using those dumps from the new OS after trying to go through the labs. Now I just use them out of convenience when I want to look at a dump from a small LPAR (one that may have few available cycles) at a different OS level. But even that is rare. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 ISPF/IPCS just isn't 'seeing' the TSOLIB. It works fine on LPARS running z/OS 1.11. It just doesn't work at z/OS 1.13 as BLSG gets loaded from ISPLLIB insted of the library set with TSOLIB. Unless I can work out what's wrong I'll have to resort to messing with ISPLLIB etc. Ron. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 as well. I tried typing in your commands at the TSO ready prompt. Still no joy ISPF/IPCS just isn't 'seeing' the TSOLIB. It works fine on LPARS running z/OS 1.11. It just doesn't work at z/OS 1.13 as BLSG gets loaded from ISPLLIB insted of the library set with TSOLIB. Unless I can work out what's wrong I'll have to resort to messing with ISPLLIB etc. I'm not sure I understand why your approach even works on 1.11, but it's a complex topic. As previously mentioned, if you have done a LIBDEF for ISPLLIB then in order to get that library concatenation used as a tasklib you have to use SELECT CMD, not SELECT PGM. However, if my understanding is correct, if you had an ISPLLIB DD allocated before you started ISPF, that library concatenation would be a tasklib for anything invoked under ISPF, either via SELECT PGM or SELECT CMD. So, if your correct IPCS library (proper SYS1.MIGLIB) is allocated as ISPLLIB before you start ISPF, or is allocated via LIBDEF and you use SELECT CMD, then everything should work. Your TSOLIB should be irrelevant if you have the wrong level of IPCS allocated as ISPLLIB before ISPF starts, and that should be true with either 1.11 or 1.13. The ISPLLIB allocated when ISPF starts is a tasklib for ISPF and its subtasks, and the TSOLIB as a higher level tasklib would only come into play when modules are not found in the pre-allocated ISPLLIB. -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 as well. I tried typing in your commands at the TSO ready prompt. Still no joy ISPF/IPCS just isn't 'seeing' the TSOLIB. It works fine on LPARS running z/OS 1.11. It just doesn't work at z/OS 1.13 as BLSG gets loaded from ISPLLIB insted of the library set with TSOLIB. Unless I can work out what's wrong I'll have to resort to messing with ISPLLIB etc. User error. :-) 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 left that as an exercise for the reader, but if it helps, I'll post that also. Remember BLSCALTL needs one line changed too (I called my IPCSALTL). I won't post that CLIST, but here is the line: ALTLIB ACTIVATE APPLICATION(CLIST) DDNAME(SBLSCLI0) Here is my IPCSALTD CLIST. You can see the changes marked MSZ. I have one other change that forces the DDIR dsn to be userid.DDIR as the normal BLSCDDIR will make it SYS1.DDIR if you run without a prefix. PROC 0 DSNAME() /* MSZ */ /* /* SPECIAL IPCS CLIST TO BE INVOKED FROM IPCSALT DRIVER CLIST TO /* RUN AN IPCS LEVEL DIFFERENT THAN THAT FROM THE RUNNING OS LEVE /* IT USES LIBRARY/DDNAME IN THE LIBDEFS INSTEAD OF DATASET NAME. /* / /* MODIFIED BLSCLIBD CLIST BELOW - LIBDEFS FOR DATASET CHANGED /* TO LIBDEFS FOR LIBRARY WITH DDNAME INSTEAD / CONTROL NOLIST ASIS /* CONTROL LIST CONLIST SYMLIST MSG /*---*/ /* TABLE, MESSAGE, SKELETON, AND PANEL LIBRARIES */ /*---*/ ALTLIB ACTIVATE APPLICATION(CLIST) DDNAME(SBLSCLI0) /* MSZ */ IF LENGTH(DSNAME)=0 THEN SET DSNAME=SYSUID..DDIR /* MSZ */ LISTDSI IPCSDDIR FILE NORECALL /* DUMP DIRECTORY FILE@05A*/ IF LASTCC4 THEN %BLSCDDIR VOLUME(LIBVSM) + DSNAME(DSNAME) /* MSZ */ ISPEXEC LIBDEF ISPMLIB LIBRARY ID(SBLSMSG0) COND/* MSZ */ ISPEXEC LIBDEF ISPPLIB LIBRARY ID(SBLSPNL0) COND/* MSZ */ ISPEXEC LIBDEF ISPSLIB LIBRARY ID(SBLSKEL0) COND/* MSZ */ /*---*/ /* INVOKE LIBDEF FOR ISPTLIB ONLY IF BLSGCMDS IS NOT */ /* AVAILABLE. 5@02A*/ /*---*/ ISPEXEC TBOPEN BLSGCMDS LIBRARY(ISPTLIB) NOWRITE SHARE IF LASTCC¬=0 THEN DO ISPEXEC LIBDEF ISPTLIB LIBRARY ID(SBLSTBL0) COND /* MSZ */ SET TLIBSET=YES END ELSE ISPEXEC TBCLOSE BLSGCMDS LIBRARY(ISPTLIB) /*---*/ /* START THE IPCS DIALOG AND SETUP THE IPCS CLIST AND REXX */ /* LIBRARY SYS1.SBLSCLI0 AS AN ALTLIB APPLICATION CLIST */ /* LIBRARY. */ /*---*/ /* ISPEXEC SELECT PGM(BLSG) NEWAPPL(BLSG) PASSLIB PARM(+ /* PGM(BLSGSCMD) PARM(EX 'SYS1.SBLSCLI0(BLSCALTL)')) /* @05C*/ ISPEXEC SELECT PGM(BLSG) NEWAPPL(BLSG) PASSLIB PARM(+ PGM(BLSGSCMD) PARM(EX 'ZELDEN.LIB.CNTL(IPCSALTL)')) /* @05C*/ /*---*/ /* LOGIC FOR IPCS SECONDARY TUTORIAL PANELS.8@01A*/ /*---*/ SET MYCC=LASTCC IF MYCC=8 THEN DO ISPEXEC SETMSG MSG(BLSMB002) COND /* @06C*/ IF LASTCC=4 THEN EXIT CODE(MYCC) /* @06C*/ WRITE DIALOG PROGRAM BLSG ENDED WITH RETURN CODE MYCC EXIT CODE(MYCC) /* @04C*/ END /*---*/ /* CANCEL THE DEFINITION AFTER THE IPCS DIALOG IS TERMINATED */
Re: Backlevel IPCS issue at z/OS 1.13
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 TASKLIB created by TSOLIB. Either remove the new MIGLIB from the the list or add the old MIGLIB in front of it. [1] For CMD(...) -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 left that as an exercise for the reader, but if it helps, I'll post that also. Remember BLSCALTL needs one line changed too (I called my IPCSALTL). I won't post that CLIST, but here is the line: ALTLIB ACTIVATE APPLICATION(CLIST) DDNAME(SBLSCLI0) Our back-level IPCS execs require manual re-invocation under ISPF. I like you approach much better! -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 Language Environment from OS/390, ran it on z/OS, and... well, that wasn't (isn't) free. Never mind free; it isn't supported even if you're paying for both. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 to caution you on something here. It's one critically important distinction between what's technically possible and what's actually permissible, at least financially speaking. The 2.10 you mention is not z/OS, it's OS/390 (V2R10). That's a different product, also licensed. As background, when IBM introduced z/OS almost 12 years ago IBM also introduced sub-capacity licensing for z/OS and for practically all IBM software products for z/OS, including CICS, IMS, DB2, MQ, and many others. However, there are a very few prerequisites that customers are required to implement before enjoying sub-capacity licensing. One highly relevant and very well publicized requirement is that you must stop running all OS/390 on your machine(s). That was (and is) part of the deal. 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. Be very, very careful here, folks. There are only a few simple rules. Follow them, please. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 work at z/OS 1.11 but not at 1.13? What gives you the idea that it doesn't work at 1.13? Using ISRDDN while in IPCS I can see the the BLSG module is being loaded from ISPLLIB, which contains the 1.13 version. Why doesn't it contain the older version up front? Adding a LIBDEF ISPLLIB LIBRARY ID(IPCSLIBS) STACK before the ISPEXEC SELECT PGM(BLSG) causes the older/correct version of BLSG to be loaded from IPCSLIBS but other modules appear to be 1.13 versions. Check what libraries they are in and where the 1.13 versions are coming from[1], then fix your concatenations to put the old ones first. Q2) Am I wasting my time here. Should the latest version of IPCS work with all older dumps? Q3) If the answer to 2) is no then how do other people do this? They include all of the old libraries in front of the new ones. [1] Probably MIGLIB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 coercing, nay *requiring*, (some of) its customers to break its (IBMs) licensing terms to support backlevel clients. And IBM documents such. Hmmm ... perhaps you'd better get your legal eagles to speak to the developers. And then let the world at large know the outcome. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 a special library (SYS1.MIGLIB) because it is intended that it can be run on various releases via a STEPLIB,TSOLIB/Tasklib. Running IPCS for OS/390 2.10 in this fashion on a supported release of z/OS does not constitute running OS/390 on your machine. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 up to 1.13. Bearing in mind that I do not speak for IBM, I'd like to caution you on something here. It's one critically important distinction between what's technically possible and what's actually permissible, at least financially speaking. The 2.10 you mention is not z/OS, it's OS/390 (V2R10). That's a different product, also licensed. As background, when IBM introduced z/OS almost 12 years ago IBM also introduced sub-capacity licensing for z/OS and for practically all IBM software products for z/OS, including CICS, IMS, DB2, MQ, and many others. However, there are a very few prerequisites that customers are required to implement before enjoying sub-capacity licensing. One highly relevant and very well publicized requirement is that you must stop running all OS/390 on your machine(s). That was (and is) part of the deal. 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. If I am using IPCS 2.10 under z/OS to read dumps submitted from another location, am I running OS390? I assume that modules compiled and linked with system routines from that or prior eras don't violate TC. Clark Morris Be very, very careful here, folks. There are only a few simple rules. Follow them, please. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 process successfully dumps from other releases. That cannot be relied upon. Of course on z/OS 1.13, via the MIGLIB approach, you can run a different release's IPCS in order to process that other release's dump. AFAIK, the proper technique remains unchanged. If used on 1.11, it would work on 1.13. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 occasionally possible that a vendor's licensing terms and conditions don't cover every reasonable use case. That's what communication and clarification help solve. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
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 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 2.10 up to 1.13. The REXX pre-allocates the uncataloged datasets, LIBDEF/ALTLIB/TSOLIBs them, and then kicks off IPCS. This rexx works fine on every system where the IPLed OS is anything to z/OS 1.11 and I can work on any level of IPCS corresponding to the level of the dump I'm looking at from any LPAR, up do and including dumps generated for z/OS 1.13. On a z/OS 1.13 LPAR the exec seems to work, i.e. no errors reported, but it always runs the 1.13 version of IPCS. Using ISRDDN while in IPCS I can see the the BLSG module is being loaded from ISPLLIB, which contains the 1.13 version. On a z/OS 1.11 LPAR BLSG is loaded from IPCSLIBS, which is the DD pointing to the non-cataloged older IPCS level, which is made available via TSOLIB ACTIVATE DDNAME(IPCSLIBS) command before starting ISPF. TSOLIB DISPLAY shows - Current load library not established by TSOLIB. TSOLIB search order (by DDNAME) is: DDNAME = IPCSLIBS in all cases. Adding a LIBDEF ISPLLIB LIBRARY ID(IPCSLIBS) STACK before the ISPEXEC SELECT PGM(BLSG) causes the older/correct version of BLSG to be loaded from IPCSLIBS but other modules appear to be 1.13 versions. Q1) Any idea why TSOLIB ACTIVATE DDNAME(IPCSLIBS) appears to work at z/OS 1.11 but not at 1.13? Q2) Am I wasting my time here. Should the latest version of IPCS work with all older dumps? Q3) If the answer to 2) is no then how do other people do this? Thanks in advance, Ron. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
If you are issuing the TSOLIB command prior to invoking ISPF, are you doing this in a logon exec? If so, try removing the start of ISPF and letting your TSO session get back to the READY prompt. Once you get the READY prompt, then invoke ISPF manually. I had this problem at another shop and once I changed my logon exec to get me to the READY prompt and THEN invoke ISPF, things worked as I expected. The problem, at least from what I found out, was that the TSOLIB command's action was stacked and didn't get performed until the TSO session got back to the READY prompt. C- Charles (Chuck) Hardee Senior Systems Engineer Database Administration Information Technology Services Thermo Fisher Scientific 300 Industry Drive Pittsburgh, PA 15275 724-517-2633 (Office) chuck.har...@thermofisher.com -Original Message- From: IBM Mainframe Discussion List [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 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 2.10 up to 1.13. The REXX pre-allocates the uncataloged datasets, LIBDEF/ALTLIB/TSOLIBs them, and then kicks off IPCS. This rexx works fine on every system where the IPLed OS is anything to z/OS 1.11 and I can work on any level of IPCS corresponding to the level of the dump I'm looking at from any LPAR, up do and including dumps generated for z/OS 1.13. On a z/OS 1.13 LPAR the exec seems to work, i.e. no errors reported, but it always runs the 1.13 version of IPCS. Using ISRDDN while in IPCS I can see the the BLSG module is being loaded from ISPLLIB, which contains the 1.13 version. On a z/OS 1.11 LPAR BLSG is loaded from IPCSLIBS, which is the DD pointing to the non-cataloged older IPCS level, which is made available via TSOLIB ACTIVATE DDNAME(IPCSLIBS) command before starting ISPF. TSOLIB DISPLAY shows - Current load library not established by TSOLIB. TSOLIB search order (by DDNAME) is: DDNAME = IPCSLIBS in all cases. Adding a LIBDEF ISPLLIB LIBRARY ID(IPCSLIBS) STACK before the ISPEXEC SELECT PGM(BLSG) causes the older/correct version of BLSG to be loaded from IPCSLIBS but other modules appear to be 1.13 versions. Q1) Any idea why TSOLIB ACTIVATE DDNAME(IPCSLIBS) appears to work at z/OS 1.11 but not at 1.13? Q2) Am I wasting my time here. Should the latest version of IPCS work with all older dumps? Q3) If the answer to 2) is no then how do other people do this? Thanks in advance, Ron. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 to 2) is no then how do other people do this? We copy the IPCS stuff to datasets with a different HLQ. As a vendor we receive dumps from a lot of back level systems so we keep the IPCS datasets forever. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 necessary. IPCS is not backwards compatible. Sure it is. Q3) If the answer to 2) is no then how do other people do this? We copy the IPCS stuff to datasets with a different HLQ. As a vendor we receive dumps from a lot of back level systems so we keep the IPCS datasets forever. You just need the proper SYS1.MIGLIB. Everytime we go to a new release, I make sure I have a copy. If I get a dump from a previous release, I place the older release in my TSO STEPLIB. (Actually, I have DDs allocated with older releases in the concat and just issue TSOLIB ACTIVATE.) Bob Shannon Rocket Software -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 2.10 up to 1.13. The REXX pre-allocates the uncataloged datasets, LIBDEF/ALTLIB/TSOLIBs them, and then kicks off IPCS. This rexx works fine on every system where the IPLed OS is anything to z/OS 1.11 and I can work on any level of IPCS corresponding to the level of the dump I'm looking at from any LPAR, up do and including dumps generated for z/OS 1.13. On a z/OS 1.13 LPAR the exec seems to work, i.e. no errors reported, but it always runs the 1.13 version of IPCS. Using ISRDDN while in IPCS I can see the the BLSG module is being loaded from ISPLLIB, which contains the 1.13 version. On a z/OS 1.11 LPAR BLSG is loaded from IPCSLIBS, which is the DD pointing to the non-cataloged older IPCS level, which is made available via TSOLIB ACTIVATE DDNAME (IPCSLIBS) command before starting ISPF. TSOLIB DISPLAY shows - Current load library not established by TSOLIB. TSOLIB search order (by DDNAME) is: DDNAME = IPCSLIBS in all cases. Adding a LIBDEF ISPLLIB LIBRARY ID(IPCSLIBS) STACK before the ISPEXEC SELECT PGM(BLSG) causes the older/correct version of BLSG to be loaded from IPCSLIBS but other modules appear to be 1.13 versions. In the archives: http://bama.ua.edu/cgi-bin/wa?A2=ind1201L=ibm-mainP=R62902I=1X=-Y=d10jhm1%40us.ibm.com An ISPF application that needs their LINKs, LOADs, ATTACHes and XCTLs to search the ISPLLIB should be started via SELECT CMD(youprog) rather than SELECT PGM(yourprog). With the CMD approach, the program runs with a TASKLIB of ISPLLIB and any LINKs, LOADs, and XCTLs done under that task will thus search ISPLLIB. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
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 work with
all older dumps?
No, what you are trying to do is necessary. IPCS is not backwards compatible.
Sure it is.
Q3) If the answer to 2) is no then how do other people do this?
We copy the IPCS stuff to datasets with a different HLQ. As a vendor we
receive dumps from a lot of back level systems so we keep the IPCS datasets
forever.
You just need the proper SYS1.MIGLIB. Everytime we go to a new release, I
make sure I have a copy. If I get a dump from a previous release, I
place the older release in my TSO STEPLIB. (Actually, I have DDs
allocated with older releases in the concat and just issue TSOLIB
ACTIVATE.)
Sorry if I'm coming into this late... I haven't been following threads closely
this week (busy doing z/OS 1.13 upgrades). Below is what I used to
invoke a different IPCS level from the running level. It is executed
from TSO READY.
Note that the IPCSALTD CLIST referenced below is a modified copy of
BLSCLIBD where I changed DATASET to LIBRARY ID and a DDNAME.
I also had to do the same thing with BLSCALTL, which is called from
BLSCLIBD, and I call it IPCSALTL.
PROC 0 VOL(RESMB0)
/*
/* SPECIAL IPCS CLIST TO BE INVOKED FROM TSO READY TO RUN AN IPCS
/* LEVEL THAT IS DIFFERENT FROM THE RUNNING OS LEVEL.
/*
/* SYNTAX: %IPCSALT OR %IPCSALT VOL(SYSRES)
/*
/* ONCE THIS CLIST IS INVOKED IT ENTERS ISPF.
/* TO INVOKE IPCS, TYPE TSO %IPCSALTD.
/*
/* THE CALLED IPCSALTD CLIST USES THE DDNAMES ALLOCATED IN
/* THIS CLIST FOR LIBDEFS VIA DDNAME (INSTEAD OF BY DSN).
/*
/* SYS1.MIGLIB/SYS1.SIEAMIGE ON VOL DOES NOT HAVE TO BE APF AUTHORIZED
/*
/* CONTROL LIST CONLIST SYMLIST MSG
WRITE
WRITE ALLOCATING IPCS LIBRARIES ON VOL
WRITE
ALLOC F(MIGLIB) DA('SYS1.MIGLIB') VOL(VOL) SHR REUSE
ALLOC F(SIEAMIGE) DA('SYS1.SIEAMIGE') VOL(VOL) SHR REUSE
ALLOC F(SBLSCLI0) DA('SYS1.SBLSCLI0') VOL(VOL) SHR REUSE
ALLOC F(SBLSMSG0) DA('SYS1.SBLSMSG0') VOL(VOL) SHR REUSE
ALLOC F(SBLSPNL0) DA('SYS1.SBLSPNL0') VOL(VOL) SHR REUSE
ALLOC F(SBLSKEL0) DA('SYS1.SBLSKEL0') VOL(VOL) SHR REUSE
ALLOC F(SBLSTBL0) DA('SYS1.SBLSTBL0') VOL(VOL) SHR REUSE
ALLOC F(IPCSPARM) DA('SYS1.IBM.PARMLIB') VOL(VOL) SHR REUSE
/* CONCATMZ (MIGLIB,SIEAMIGE) */
CALL *(BPXWDYN) 'CONCAT DDLIST(MIGLIB,SIEAMIGE) MSG(WTP)'
TSOLIB ACTIVATE FILE(MIGLIB)
/* ISPSTART CMD(%IPCSALTD) */
WRITE ***
WRITE *** AFTER YOU ENTER ISPF, TYPE***
WRITE *** TSO %IPCSALTD TO INVOKE IPCS***
WRITE ***
ISPSTART PANEL(ISR@PRIM) NEWAPPL(ISR) NOLOGO
TSOLIB DEACTIVATE
FREE F(MIGLIB)
FREE F(SBLSCLI0)
FREE F(SBLSMSG0)
FREE
Re: Backlevel IPCS issue at z/OS 1.13
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 problem. Apar: OA38921 Abstract: ONCE AN IPCS REPORTS BEGINS, IT CAN TAKE MINUTES BEFORE CONTROL IS RETURNED TO THE USER ERROR DESCRIPTION: It can take minutes for PF3 to end a large IPCS report when the following are conditions are true: 1. You are in split screen IPCS mode, and more than 1 screen session is in an IPCS report (so this PF3 is not terminating the last report. 2. IPCS was not invoked before PDF, so IPCS is using the TSO/E IKJURPS interface to manage IPCS functions which are common between the sessions. You can bypass this problem by going back to TSO READY, entering IPCS NOPARM , and then PDF. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
