z/OS System Programmer Position in Austin, TX
We have a position open for an experienced z/OS systems programmer: https://capps.taleo.net/careersection/304/jobdetail.ftl?job=4018&tz=GMT-06%3A00 Great state benefits, well staffed team and some teleworking permitted (but must reside locally). This is not a CICS position even though CICS is listed under preferred experience. We have a separate team of CICS systems programmers. The z/OS team supports z/OS and all the z/OS related products, DB2 and most of the ISV products. Somebody with strong Unix System Service skills and TCPIP skills would be a wonderful addition to our team. We are running z/OS 2.2 on a z13 and looking to get a new mainframe later in the year. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Phoenix Software International Announces IBM® JES3 Licensing Agreement
Congratulations and thank you for all the JES3 shops everywhere! Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RSU Maintenance: Asking For a Friend
The OP is referring to a shop that reinstalls z/OS as a way to get to a current RSU level. In the years in between releases of z/OS, they reorder everything at a higher maintenance level and then do a complete reinstall. Has anyone ever heard of this method for putting on maintenance? Can you see any benefits of this approach? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS performance question
You can get by with 1 logical cp on the sandbox but, I would still want 2. For a development LPAR with Db2, you need the 2 logical CPs. Has it always been restricted to 1 CP? If not, why was it changed? Everything on that LPAR will perform better with 2 CPs compared to 1 CP. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS performance question
By any chance do you have your Db2 address spaces in SYSSTC? If yes, get them moved out AND share give development uses of both logical CPs. IRLM should be there but the others should. On a 1 CP system, all regular work stops while a task in SYSSTC is using the CPU. High CPU users like Db2 should not be in SYSSTC; especially on a system with only 1 logical CP. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCF Policies, Best Practices
We use 4 policy names, POLICY#, in round robin fashion. When we get to the POLICY4 we go back to POLICY1. We also have a process we use for WLM changes that would allow us to quickly reactivate the policy the way it was before the last activation. Keeping back out options available are always important. Hope you never need them, but have them just in case you do. Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS hosting
Take a look at FNTS https://www.fnts.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe performance tool replacement
Look into using Pivitor, software as a service. It will provide more and better reports than you probably have today and not use any CPU or use any DASD, and is very reasonably priced. Plus you will get a yearly review of your system performance with performance subject matter experts. All you have to do is FTP the SMF data daily. You can also have them do a free cursory review of your data with you and that will also give you a good demonstration of Pivitor. https://www.pivotor.com/ I do not work for EPS but used their product in my last 2 positions and love it. Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ACS Routines Missing Source
Is there any way to recreate the ACS routines source from the SMS ACDS/SCDS? Anybody ever dealt with missing ACS routines dataset? If so, how did you recover? Thanks Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ACS Routines Missing Source
Thank you. Will see if DCOLLECT can help. There is no sign of the dataset in HSM. The last time we can tell it was used was almost 10 years ago so there is no telling when it was deleted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ACS Routines Missing Source
Thank you. I will try it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error
I went from 1.13 to 2.2 last May without any issue. You probably have already done this several times, but double check your parmlib members - IEAFIXxx, IEALPAxx, PROGxx. Any chance you have one that includes modifications of an exit or module from JES2 1.13? Also, perhaps review any jobs where you may have linked any JES2 exits or modifications to ensure you only picked up the 2.2 libraries. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CHPID TYPE OSE Port 1 of OSA Express3
We are having problems using port 1 of our new OSA Express3 T1000 on a z114 (4 ports with 2 PCHID). Running z/OS 1.12. The CHPID is defined as TYPE=OSE. For both of our two cards that we are trying to also use port 1, D M=CHP(xx) shows "PATH NOT OPERATIONAL" and "PATH NOT VALIDATED". Port 0 is fine on both of these. Based on information from our hardware vendor these are the definitions we used: CHPID PATH=(CSS(0),00),SHARED,* PARTITION=((all lpars,are listed here),(=)),PCHID=200,TYPE=OSE CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA IODEVICE ADDRESS=(FC00,032),CUNUMBR=(FC00),UNIT=OSA Because the paths are not operational, I don't think the problem is in our TCPIP profile but will share that as well for completeness: DEVICE OSAFC00 LCS FC00 AUTORESTART LINK ETH1ETHERNET 0 OSAFC00 DEVICE OSAFC10 LCS FC10 AUTORESTART LINK ETH1 ETHERNET 1 OSAFC10 FC00 is used on 1 LPAR and FC10 on another. FC00 - is attached to port 0 (and working) and FC10 should be port 1 (and is not working).Cabling has been checked multiple times. Our hardware vendor has a call into IBM, but I thought I might get an answer faster here from those that have BTDT. Thank you for any help or suggestions. Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID TYPE OSE Port 1 of OSA Express3
Donald, for LCS we have no VTAM definition only what is in the TCPIP profile. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID TYPE OSE Port 1 of OSA Express3
FYI - Looks like our hardware vendor has found the answer (I'll know for sure a bit later on): After spending a while researching and thinking about the OSA problem, here's what I think it is. For the OSE cards, when TCP/IP is started, it uses the information in the TCP/IP profile to load the port with IP address, etc, that the port needs to connect to the network. The default configuration that gets loaded onto the OSE chpids during POR has entries for unitadd 00 and 01, which makes the port 0 connections work. For port 1 the definitions are unitadd 10 and 11 for FC40 and FC10. Those unitadds do not get set up right in the card's default configuration. Here's the fix : In HCD, add a device definition for a device type OSAD at unitadd FE to each of the OSE chpids, like the following: CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA IODEVICE ADDRESS=(FC00,032),CUNUMBR=(FC00),UNIT=OSA IODEVICE ADDRESS=FCFE,UNITADD=FE,CUNUMBR=FC00),UNIT=OSAD <-- CNTLUNIT CUNUMBR=FC20,PATH=((CSS(0),04)),UNIT=OSA IODEVICE ADDRESS=(FC20,016),UNITADD=00,CUNUMBR=(FC20),UNIT=OSA IODEVICE ADDRESS=(FC40,016),UNITADD=10,CUNUMBR=(FC20),UNIT=OSA IODEVICE ADDRESS=FCFF,UNITADD=FE,CUNUMBR=FC20),UNIT=OSAD -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID TYPE OSE Port 1 of OSA Express3
The changes did not work. We have a copy of that Share document and have actually read it several times :( Here is the new definitions from IOCP: CHPID PATH=(CSS(0),00),SHARED,* PARTITION=((MVSD,MVSM,MVSP,MVSZ),(=)),PCHID=200,TYPE=OSE CHPID PATH=(CSS(0),04),SHARED,* PARTITION=((MVSD,MVSM,MVSP,MVSZ),(=)),PCHID=210,TYPE=OSE CHPID PATH=(CSS(0),05),SHARED, CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA IODEVICE ADDRESS=(FC00,032),CUNUMBR=(FC00),UNIT=OSA IODEVICE ADDRESS=(FCFE,001),CUNUMBR=(FC00),UNIT=OSAD CNTLUNIT CUNUMBR=FC20,PATH=((CSS(0),04)),UNIT=OSA IODEVICE ADDRESS=(FC20,016),UNITADD=00,CUNUMBR=(FC20),UNIT=OSA IODEVICE ADDRESS=(FC40,016),UNITADD=10,CUNUMBR=(FC20),UNIT=OSA IODEVICE ADDRESS=FCFF,UNITADD=FE,CUNUMBR=(FC20),UNIT=OSAD After dynamic activate and IPL, FC10 and FC40 paths are still not operational. Do you see what we missed? Here are some displays: D M=CHP(04) IEE174I 13.23.06 DISPLAY M 113 CHPID 04: TYPE=10, DESC=OSA EXPRESS, ONLINE DEVICE STATUS FOR CHANNEL PATH 04 0 1 2 3 4 5 6 7 8 9 A B C D E F 0FC2 + + $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ 0FC4 $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ 0FCF . . . . . . . . . . . . . . . + SWITCH DEVICE NUMBER = NONE PHYSICAL CHANNEL ID = 0210 SYMBOL EXPLANATIONS + ONLINE@ PATH NOT VALIDATED - OFFLINE. DOES NOT EXIST * PHYSICALLY ONLINE $ PATH NOT OPERATIONAL -D M=DEV(FC40) IEE174I 13.23.57 DISPLAY M 119 DEVICE 0FC40 STATUS=OFFLINE CHP 04 ENTRY LINK ADDRESS.. DEST LINK ADDRESS 0D PATH ONLINE Y CHP PHYSICALLY ONLINE Y PATH OPERATIONAL N PATHS NOT VALIDATED V PATH(FC40,04),ONLINE IEE386I PATH(FC40,04) NOT BROUGHT ONLINE IEE763I NAME= IECVIOPM CODE= 0004 IOS552I PATH NOT PHYSICALLY AVAILABLE IEE764I END OF IEE386IRELATED MESSAGES D M=DEV(FCFE) IEE174I 13.36.12 DISPLAY M 156 DEVICE 0FCFE STATUS=ONLINE CHP 00 ENTRY LINK ADDRESS.. DEST LINK ADDRESS 0D PATH ONLINE Y CHP PHYSICALLY ONLINE Y PATH OPERATIONAL Y MANAGED N CU NUMBER FC00 MAXIMUM MANAGED CHPID(S) ALLOWED: 0 DESTINATION CU LOGICAL ADDRESS = 00 D M=DEV(FCFF) IEE174I 13.36.30 DISPLAY M 158 DEVICE 0FCFF STATUS=ONLINE CHP 04 ENTRY LINK ADDRESS.. DEST LINK ADDRESS 0D PATH ONLINE Y CHP PHYSICALLY ONLINE Y PATH OPERATIONAL Y MANAGED N CU NUMBER FC20 MAXIMUM MANAGED CHPID(S) ALLOWED: 0 DESTINATION CU LOGICAL ADDRESS = 00 Thanks Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: I
Re: CHPID TYPE OSE Port 1 of OSA Express3
Thank you, Ed. I'll ask the CE about that test. We also have been reading the implementation guide. The guide and the Share presentation give you a lot of information and examples for QDIO but not so much for non-QDIO, type OSE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID TYPE OSE Port 1 of OSA Express3
Thank you Dale. I am going to try that now. Just getting in. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID TYPE OSE Port 1 of OSA Express3
Dale, I replied too soon. After looking further at your recommendation, I can't do this. The CHPID is type OSE and OSE can not have more than 1 CU. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID TYPE OSE Port 1 of OSA Express3
Please excuse all the replies. I'll go get some coffee now and will report back after I try the suggestion. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID TYPE OSE Port 1 of OSA Express3
We have not resolved the problem yet - waiting for change control process. We do now understand the problem. The problem is because the OSA cards do not come with a default OAT that includes port 1. To use PORT 1 for LCS you must use OSA/SF to complete the configuration. There are 2 changes required: 1 - to the CONFIG we need to add a port name and use that same port name in the TCPIP LINK statements in our PROFILE, 2 - modify the OAT to include definitions for port 1. The hardware definitions I modifed on Monday, it appears, will work. Adding the device with UA of FE and type OSAD was needed to use the OSA/SF facility. With the OSA/SF I was able to do a GET_CONFIG and GET_OAT for each of the CHPIDs. The required changes are staged and ready to be loaded. As soon as change control is approved and an approriate time for the change agreed upon, I think it will work. We previously had never needed to use OSA/SF and that is why our initial configuration didn't include a device with UA of FE and type OSAD. Thank you all for your input. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID TYPE OSE Port 1 of OSA Express3
Yes Chris I did state this wrong "For the OSE cards, when TCP/IP is started, it uses the information in the TCP/IP profile to load the port with IP address, etc, that the port needs to connect to the network." Good thing I am not the communication person here :) The bottom line (for us) was that to use port 1 on a OSA with a CHPID type of OSE and LCS in the TCPIP definitions, we need to use OSA/SF to load the ODAT for port 1 and set the portname in the config. When we only had 1 port per CHPID, OSA/SF was not required. For our z114 installation/implementation there is another hardware vendor that we have been working with. The CE is from IBM but our other support during the installation/implementation is not. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES3 BDT (Bulk Data Transfer) Migration?
Phoenix Software has BDT now, it is now PHX-BDT. They also have JES3Plus, which is a simple install and migration from JES3. I did over a weekend and had no issues. Going to JES3PLUS would allow you to still work on a migration to JES2 without pressure of being off JES2 before your next z/OS upgrade, if that is what you really want to do, or you could stay with JES3Plus. Phoenix Software isn't just maintaining JES3Plus for JES3 sites, they are adding new functionality and improvements. Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 & 2.2 on z16?
Brian, Could you please share what type of z/OS 2.2 things did not work on the z16? Thank you, Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 & 2.2 on z16?
Thank you all for the replies. I didn't know until after I posted that we 2 LPARs on z/OS 2.2 on our existing z16. They have been there for almost a year now without any issues. We are going to upgrade the z/OS 2.1 systems before they are migrated to the new z16 later this year. And hope to also upgrade the 2.2 systems. And maintenance for some of the 2.3 & 2.4 systems. Our 2.5 & 3.1 already have the z16 FIXCAT maintenance. I do believe you that the 2.1 won't work at all, but I still hoping to test one in the next few weeks; just to see what happens. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 2.1 & 2.2 on z16?
I know z/OS 2.1 and 2.2 are not supported release of z/OS. I also know that the z16 spec sheet states that z/OS 2.3 is the oldest release of z/OS supported. But the z16 spec sheet has a 2022 date when z/OS 2.3 was the oldest supported release. I don't think IBM would list a release of z/OS for any hardware that is not a supported release of z/OS. I need to know if we can run a z/OS 2.1 or 2.2 LPAR on a z16? If you have done so, did you have any issues? If you tried and it didn't, please share. Thank you, Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IZPCA
Getting it configured and the lookup tables properly setup, can be a challenge if doing it on your own. 21st Century will assist new users of IZPCA with those tasks. It requires a good amount of time up front. The use of Cognos server reports, is nice. Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IZPCA
I have some, we have and worked with TDS a bit. Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dataset Alias - determine if used
Working on a client system that has some unusual datasets alias defined for some z/OS system datasets. Other than the Scream method, is there any way to determine if the aliases are being used? Anything in RACF or SMF or any other option? More crazy than unusual, they some how lost their z/OS DLIB datasets so the crested alias for SYS1.AMODGEN and SYS1.AMACLIB to SYS1.MODGEN and SYS1.MACLIB. Those are the crazy examples but I am more concerned about the ones like alias SYS1.SISP* pointing to ISP.SISP*. Thanks Rebecca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Dataset Alias - determine if used
Thank you for you reply and Collin's as well. The AMODGEN and AMACLIB are not my major concern because with the upgrade, real and current datasets will be created. Those were just the 2 that created a WTH moment for me and internal scream. I am more concerned about the alias like SYS1.SISP* that are related to ISP.SISP*. The ISP datasets are not the only ones. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Dataset Alias - determine if used
I have done that. That is how I found out about the aliases. Tomorrow I am going to test on our lpar and see if SMF 14/15 will show the use of the dataset Alias. I need to know what is using them, if anything because I am going to upgrade their z/OS and want them gone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Dataset Alias - determine if used
Thank you, you got pass my blind spot. I could at least take the ISP datasets and create actual SYS1 datasets and then check RACF. There are too many to take that approach for all of them. Since I am testing on system with supported z/OS I going to open case to ask IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Dataset Alias - determine if used
IBM replied that my only option was searching JCL and PROCLIB datasets. I am going to test the create dataset and putting it in warning mode. Thanks everyone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Dataset Alias - determine if used
Thank you for your suggestion. Will pick Scream method or an exit. This particular system already has way too many (mostly for silly cute things) exits. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
