Re: Numeric TSO Userids
Gee, who in the first place decided to use numeric userids, possibly supported by ACF2, but not by the rest of MVS? Sounds like allowing Syncsort options and then return to DFSORT, or allow PDSFAST options and then return to IEBCOPY or... If you did already prefix the userid with an Alpha character, can't you definitely change the userid to that prefixed value? It won't make any difference for the datasets, only the users have to get used to their 'new' userid, which they already know from their datasets? Kees. "Mark Wilson" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Cross Posted to RACF-L and re posted to IBM Main > > Could anybody offer any ideas at all in this area? > > Regards > > Mark > > > ** > > Hi, > > I am in the middle of migrating a customer from ACF2 to RACF and have > encountered a problem. > > ACF2 supports the use of fully numeric TSO Userids. > > The customer has an exit in place that forces all dataset allocations to be > prefixed with a Alpha character, getting around the dataset issues. > > However, if I migrate them to RACF, TSO does NOT support a fully numeric > Userid. > > I know this is not supported by IBM, but does anyone have any ideas (TSO > exit?), that I can use to support fully numeric TSO Userids. > > The customer does not what to change the RACF Userids to start with an alpha > character for business/application reasons. > > Any help gratefully received. > > Regards, > > Mark > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/VM Evaluation Edition Now Available
Yes, that's my understanding also, it's an HMC + z10 technical feature issue related to loading (and reloading) speed. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
> I checked on the z800 that we use for most of our system test > dump reading, and SCCBSAIX is set, so it is probably > the case that all IBM z/Architecture processors set SCCBSAIX. > However, I prefer to stick with the architecturally > correct algorithm. Thanks - easy enough to stick a check in. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
IBM Mainframe Discussion List wrote on 07/23/2008 01:58:31 AM: > Jim, is it safe to assume SCCBSAIX is always valid ???. Has agreed with > SCCBSAI on the couple of systems I looked at. > > Maybe Mark Z could add a couple of lines to IPLINFO (if not already there; > been a while since I pulled a new version). > > Shane ... > > > However, if you use SYS1.MACLIB(IHASCCB) to > > map the area pointed to by CVTSCPIN (CVT+340), then > > SCCBSAI (or if it is zero, use SCCBSAIX) allows you to compute > > the increment size. I checked on the z800 that we use for most of our system test dump reading, and SCCBSAIX is set, so it is probably the case that all IBM z/Architecture processors set SCCBSAIX. However, I prefer to stick with the architecturally correct algorithm. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Numeric TSO Userids
All, >From the research I have done I agree with Walt in that it¹s a TSO restriction. If you logon (Full screen mode) and enter a numeric Userid you get the not valid message, press F1 and there is the message from TSO. Hence, my thinking I may be able to get at the field in a TSO EXIT and bypass the numeric check. The fact that ACF2 supports it means it can be done and from what I am seeing there are no issues with MVS commands, INTRDR, etc. Looks like I go back to the manuals to see if I can figure this out. Mark On 23/07/2008 03:00, "Walt Farrell" <[EMAIL PROTECTED]> wrote: > On 7/22/2008 6:15 PM, Barry Schrager wrote: >> > I agree -- HASP has nothing to do with this. The 7 character limit was >> > imposed because submitted jobs had the Userid as the first 7 characters >> > and had to attach another character/digit to make the submitted jobname >> > unique. >> > >> > It never occurred to us that you might have 7 digit Userids when we >> > created ACF2. That, it works, is a surprise to me. I guess that by >> > bypassing UADS, nobody checks -- but RACF obviously does. >> > > Interesting, Barry. RACF doesn't check, and fully supports numeric user > IDs. It has to be a TSO/E restriction, and I'm pretty sure that the > standard TSO/E logon command parsing (and full-screen validation) will > reject a numeric user ID, so I always figured it was done with logon > exits and/or replacement of the logon command when another security > product does allow it. > > -- > Walt Farrell, CISSP > IBM STSM, z/OS Security Design > > > > ___ Mark Wilson Mobile: +44 (0) 7768 617006 Email: [EMAIL PROTECTED] Chairman GSE Large Systems Working Group. Large Systems Web Site is: http://lsx.gse.org.uk/ ___ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
Jim, is it safe to assume SCCBSAIX is always valid ???. Has agreed with SCCBSAI on the couple of systems I looked at. Maybe Mark Z could add a couple of lines to IPLINFO (if not already there; been a while since I pulled a new version). Shane ... > However, if you use SYS1.MACLIB(IHASCCB) to > map the area pointed to by CVTSCPIN (CVT+340), then > SCCBSAI (or if it is zero, use SCCBSAIX) allows you to compute > the increment size. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dump management
>That is a minor benefit. Not to me, it isn't. To me this is a HUGE benefit. I am the one who is supposed to figure out why 'automation didn't work' during system shutdown, especially when the operator forced down Jes2 after he couldn't see the jobs/stcs that hadn't come down *before* JES. Or when they say 'automation didn't terminate'. Try to find out why when there is no syslog, no automation log, no joblog (the thing is started sub=mstr) They are especially fond of saying 'the system doesn't come down' on the monoplexes (where we didn't have operlog) until I got so fed up that I forced the setup of operlog even on the monoplexes. >The big benefit is having all the logs for the sysplex >combined in one place when trying to diagnose a problem. *That* is considered a big drawback here! When I established operlog here, I got temporary update access to all ISPF profiles for the company to change the default log a in SDSF to log s to not 'irritate everybody'. I admit that I go to syslog, too, when I have to check for a problem that I know is limited to one system, mostly when that system doesn't output a lot of lines. Scrolling past all the stuff from other systems that output a lot is tiresom. (And yes, I know about operlog viewer...) The thing that I really hate is that it also takes just about forever when I look into syslog - log s (even on the same system). Barbara -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/VM Evaluation Edition Now Available
2008-07-22 Wayne Driscoll <[EMAIL PROTECTED]> wrote: > Now I realize that IBM has valid reasons for the limitation, but in my > opinion, point 2 "You can run it on any System z10 machine" is more of a > lowlight than a highlight. Another example of IBM making things available > at a low or no cost, but only to customers that have already spent millions > of dollars. Well I am not a lawyer, etc. etc. but as far as I can see the licence agreement doesn't say you must run it on a z10 only. Perhaps there is a genuine technical limitation, e.g. it uses some of the new instructions or a new HMC interface, or maybe it specifically tests for the right machine. Or maybe not. The only requirement I see in the licence is that the machine must correctly implement the 64-bit z instruction set, or words to that effect. The z10 would seem to be more of an example of such than a requirement. There is a requirement that if you run it on IFLs it be used only to run Linux and its supporting applications. No big opportunity to resurrect CMS application development on the cheap here... Did I mention that I'm not a lawyer, or that treating my interpretation as anything beyond speculation would be foolish? Tony H. I read the licence, but I didn't inha^Hdownload. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/VM Evaluation Edition Now Available
Here is a quote from a post on the VM List from Les Geer of z/VM Development: "Why z10 only, it takes advantage of new support between the HMC and LPAR which allows the load to be ~10 minutes as opposed to hours." Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll Sent: Tuesday, July 22, 2008 10:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/VM Evaluation Edition Now Available If I recall correctly, it had do with a change in the HMC appliance to allow an LPAR to "own" the DVD-RAM device. Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, July 22, 2008 9:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/VM Evaluation Edition Now Available Wayne Driscoll wrote: > Now I realize that IBM has valid reasons for the limitation ... What are the valid reasons? Why not z9 as well? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/VM Evaluation Edition Now Available
If I recall correctly, it had do with a change in the HMC appliance to allow an LPAR to "own" the DVD-RAM device. Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, July 22, 2008 9:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/VM Evaluation Edition Now Available Wayne Driscoll wrote: > Now I realize that IBM has valid reasons for the limitation ... What are the valid reasons? Why not z9 as well? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/VM Evaluation Edition Now Available
>> Now I realize that IBM has valid reasons for the limitation ... >What are the valid reasons? Why not z9 as well? It should be available for any supported processor that runs the OS! IBM always comes up short on this kind of stuff! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/VM Evaluation Edition Now Available
Wayne Driscoll wrote: Now I realize that IBM has valid reasons for the limitation ... What are the valid reasons? Why not z9 as well? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/VM Evaluation Edition Now Available
Now I realize that IBM has valid reasons for the limitation, but in my opinion, point 2 "You can run it on any System z10 machine" is more of a lowlight than a highlight. Another example of IBM making things available at a low or no cost, but only to customers that have already spent millions of dollars. Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples Sent: Tuesday, July 22, 2008 8:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: z/VM Evaluation Edition Now Available IBM has posted details and the download for the z/VM 5.3 Evaluation Edition here: http://www.vm.ibm.com/eval/ Here are the highlights: 1. You can download z/VM 5.3 EE at no charge. 2. You can run it on any System z10 machine.. 3. There's no capacity cap, and you can run it on either/both CPs and IFLs, on any number of machines. 4. You're licensed for 90 days, but there's no "time bomb" that would cause z/VM EE to stop. 5. No support -- you cannot open PMRs, etc. -- nor can you apply PTFs. (It's not for production use.). 6. It's got a fairly rich set of z/VM options included (e.g. the Performance Toolkit). If you download z/VM, you'll need to burn it to a DVD-RAM disc, so make sure you can do that on your PC. Many DVD burners support DVD-RAM discs, but not all. If yours doesn't, fortunately DVD-RAM burners are cheap and plentiful. Anyway, for those of you who'd like to give z/VM a try -- for running Linux or any other mainframe operating system -- you're good to go. The files are available for download now. Enjoy. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/VM Evaluation Edition Now Available
IBM has posted details and the download for the z/VM 5.3 Evaluation Edition here: http://www.vm.ibm.com/eval/ Here are the highlights: 1. You can download z/VM 5.3 EE at no charge. 2. You can run it on any System z10 machine.. 3. There's no capacity cap, and you can run it on either/both CPs and IFLs, on any number of machines. 4. You're licensed for 90 days, but there's no "time bomb" that would cause z/VM EE to stop. 5. No support -- you cannot open PMRs, etc. -- nor can you apply PTFs. (It's not for production use.). 6. It's got a fairly rich set of z/VM options included (e.g. the Performance Toolkit). If you download z/VM, you'll need to burn it to a DVD-RAM disc, so make sure you can do that on your PC. Many DVD burners support DVD-RAM discs, but not all. If yours doesn't, fortunately DVD-RAM burners are cheap and plentiful. Anyway, for those of you who'd like to give z/VM a try -- for running Linux or any other mainframe operating system -- you're good to go. The files are available for download now. Enjoy. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to change the ISPF code page?
On Tue, 22 Jul 2008 17:23:04 -0400, Gerhard Postpischil <[EMAIL PROTECTED]> wrote: >... >> The square brackets that display correctly are x'AD' and x'BD'. ... >They're both wrong Mine are x'BA' and x'BB', and they work >wonderfully. >... Use of characters in a codepage work wonderfully within that codepage. Amazing how that works. :-) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to change the ISPF code page?
Patrick O'Keefe wrote: While that is a reasonable assumption, I think I'm innocent this time. It's in the default keyboard map ... as downloaded to my PC by our wonderful corporate software distribution system. This is a seriously ammended (mostly pruned) PComm 5.5 They may helped us out by giving us a non-standard default keyboard map. They're nice that way. If you go into the keyboard utility and change the base value for the [ and ] keys from whatever they are now to '[' and ']' respectively (including the surrounding apostrophes), it should work no matter what code page you use. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Numeric TSO Userids
-Original Message- From: RACF Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thompson, Steve Sent: Tuesday, July 22, 2008 4:56 PM To: [EMAIL PROTECTED] Subject: Re: Numeric TSO Userids If TSS could do it, then why couldn't it be done in a RACF environment? ISPF shouldn't choke on this, after all, as the original poster said, they already prefix the "TSOID" with a letter, which would give a max HLQ of 8 characters. Sorry, I had Top Secret running around in my head this afternoon. I meant ACF2 as the original poster was saying. Long day. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Numeric TSO Userids
-Original Message- From: RACF Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Doc Farmer Sent: Tuesday, July 22, 2008 2:14 PM To: [EMAIL PROTECTED] Subject: Re: FW: Numeric TSO Userids As Bender of Futurama might say, "We're Boned!" Sorry, the Wonderful Wizards of HASP decided that a TSO User ID in RACF must be only 7 characters in length and must start with an alpha character only. I think you're gonna have some fun renaming all those old IDs (and all those old Datasets) to the new format. I doubt you'd have an exit that could work that wouldn't also screw up your other operations, so get ready to do some bulk renaming. If TSS could do it, then why couldn't it be done in a RACF environment? ISPF shouldn't choke on this, after all, as the original poster said, they already prefix the "TSOID" with a letter, which would give a max HLQ of 8 characters. The Submit Exit and INTRDR may need a little tweaking. I'd think that the thing to do is bring up a NON-TSS system with RACF (standalone). Your first problem is going to be the TSO PREFIX PROFILE(nn) because it is going to give you this: IKJ56710I INVALID USERID, 1234567 Once you get that to work, you can set your prefix to your TSS ID (all numbers) and see what falls out next. What one might do, if TopSecret is installed with SMPE is look at the ++USERMODS and what they apply to. That will give you some ideas of what you will need to handle. If it is an IEBCOPY install, look to see what it requires to be installed that happens to have "IBM" owned program (CSECT/MODULE) names. You just might be able to pull off the same things TSS does to allow numeric TSO IDs. Or you may be able to prove to your management that this will require a migration of TSO IDs, or stay on TSS (probably justifying the license/maint fees for TSS to CA). Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to change the ISPF code page?
Patrick O'Keefe wrote: The square brackets that display correctly are x'AD' and x'BD'. The square brackets from PComm are x'B0' and x'6A'. They're both wrong Mine are x'BA' and x'BB', and they work wonderfully. When IBM introduced the 327x, they should have used the codes assigned to the TN train for common values, but that was too much work for them? Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete PAGESPACE in other catalog
Ding ding ding! We have a winner. Of course this bypasses the check that prevents deleting an active page dataset. Be vewy vewy careful! heheheheheheheh //STEP01 EXEC PGM=IDCAMS //SYSOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //DISK1DD UNIT=3390,VOL=SER=H5PAG1,DISP=SHR //SYSINDD * DELETE PAGE.AQH2.PLPA - PAGESPACE - FILE(DISK1) - CATALOG(SYS1.ZOS17.MCAT) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
Thanks Bob. You are a voice I trust and I almost decided to go forward. But, I'm a coward and it's not hard to goback, so that is what I decided to do. I opened an ETR asking if I would be supported if I went forward, no answer yet. In the meantime I still have a dozen PARMLIB members to review and merge with my current set-up :) Thank you to Lizette, Alan and the others. I learn a good part of my job from this forum. Thanks to all of you. > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Bob Rutledge > Sent: Tuesday, July 22, 2008 9:51 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Some insight on 1.9 install > > Gibney, Dave wrote: > > > >Yahbut, I did run the 835 successful PTFs with the 1.7 system against > > the 1.9 target? Is NUCLEUS (which failed) my only worry? > > Seems like. See the thread around > http://bama.ua.edu/cgi-bin/wa?A2=ind0801&L=ibm-main&D=0&I=1&X=-&P=91155 > > Bob > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete PAGESPACE in other catalog
You do if the dataset is not accessible through the standard catalog search order. And certain commands require it. On Tue, 22 Jul 2008 20:21:21 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>//DISK1DD UNIT=3390,VOL=SER=H5PAG1,DISP=SHR > >You do not need to statically allocate DISK DD's to IDCAMS steps. >- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete PAGESPACE in other catalog
>//DISK1DD UNIT=3390,VOL=SER=H5PAG1,DISP=SHR You do not need to statically allocate DISK DD's to IDCAMS steps. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to change the ISPF code page?
On Tue, 22 Jul 2008 11:51:00 -0700, Edward Jaffe <[EMAIL PROTECTED]> wrote: >... >Ummm The default United States keyboard mapping in PCOMM does not >define square brackets ... >... >You must have defined them yourself -- to the wrong values! >... While that is a reasonable assumption, I think I'm innocent this time. It's in the default keyboard map ... as downloaded to my PC by our wonderful corporate software distribution system. This is a seriously ammended (mostly pruned) PComm 5.5 They may helped us out by giving us a non-standard default keyboard map. They're nice that way. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Numeric TSO Userids
Saw your main in RACF-L as well. The answer is TSO logon exit. Have the user be aware to his numeric id, not more then six chars and prefix a character or assign another UID. I have a similar problem at a customer here who converted from VSE to MVS. Not a big problem., but I would keep a sync. Between the userid and the numeric value in RACF. Perhaps an other class that can hold a numeric value and a field that holds the userid. Itschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wilson Sent: Tuesday, July 22, 2008 9:03 PM To: IBM-MAIN@BAMA.UA.EDU Subject: FW: Numeric TSO Userids Cross Posted to RACF-L and re posted to IBM Main Could anybody offer any ideas at all in this area? Regards Mark ** Hi, I am in the middle of migrating a customer from ACF2 to RACF and have encountered a problem. ACF2 supports the use of fully numeric TSO Userids. The customer has an exit in place that forces all dataset allocations to be prefixed with a Alpha character, getting around the dataset issues. However, if I migrate them to RACF, TSO does NOT support a fully numeric Userid. I know this is not supported by IBM, but does anyone have any ideas (TSO exit?), that I can use to support fully numeric TSO Userids. The customer does not what to change the RACF Userids to start with an alpha character for business/application reasons. Any help gratefully received. Regards, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ NOD32 3280 (20080718) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Numeric TSO Userids
| Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Wilson Sent: Tuesday, July 22, 2008 9:03 PM To: IBM-MAIN@BAMA.UA.EDU Subject: FW: Numeric TSO Userids Cross Posted to RACF-L and re posted to IBM Main Could anybody offer any ideas at all in this area? Regards Mark ** Hi, I am in the middle of migrating a customer from ACF2 to RACF and have encountered a problem. ACF2 supports the use of fully numeric TSO Userids. The customer has an exit in place that forces all dataset allocations to be prefixed with a Alpha character, getting around the dataset issues. However, if I migrate them to RACF, TSO does NOT support a fully numeric Userid. I know this is not supported by IBM, but does anyone have any ideas (TSO exit?), that I can use to support fully numeric TSO Userids. The customer does not what to change the RACF Userids to start with an alpha character for business/application reasons. Any help gratefully received. Regards, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ NOD32 3280 (20080718) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete PAGESPACE in other catalog
On Tue, 22 Jul 2008 13:55:38 -0500, McKown, John <[EMAIL PROTECTED]> wrote: Close, but no cigar. //STEP01 EXEC PGM=IDCAMS //SYSOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //DISK1DD UNIT=3390,VOL=SER=H5PAG1,DISP=SHR //SYSINDD * DELETE PAGE.AQH2.PLPA - PAGESPACE - FILE(DISK1) - CATALOG(SYS1.ZOS17.MCAT) >> -Original Message- >> From: IBM Mainframe Discussion List >> [mailto:[EMAIL PROTECTED] On Behalf Of Pat Mihalec >> Sent: Tuesday, July 22, 2008 1:51 PM >> To: IBM-MAIN@BAMA.UA.EDU >> Subject: Re: Delete PAGESPACE in other catalog >> >> Here is some JCL I have used in the past >> //IDCAMS EXEC PGM=IDCAMS >> //STEPCAT DD DSN=CATALOG.MASTER.VCATT28,DISP=SHR >> //SYSPRINT DD SYSOUT=* >> //SYSINDD * >> DELETE - >> PAGE.TEST.COMMON - >> PAGESPACE - >> PURGE - >> CATALOG(CATALOG.MASTER.VCATT28) >> >> Pat Mihalec > >H no more STEPCAT allowed! > >My page datasets are all named PAGE.&SYSNAME.stuff. I use MultiLevel >aliases so that I can do a DEFINE alias so that PAGE.&SYSNAME in this >system's master catalog points to &SYSNAME's master catalog. > >Another possibility is to simply create the PAGESPACE in the current >system's master catalog. Then, just do a DEFINE PAGESPACE ... RECATALOG >CAT(other.mastercat) . One nice thing is that a PAGESPACE can be defined >in multiple catalogs at the same time. > >-- >John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FW: Numeric TSO Userids
Cross Posted to RACF-L and re posted to IBM Main Could anybody offer any ideas at all in this area? Regards Mark ** Hi, I am in the middle of migrating a customer from ACF2 to RACF and have encountered a problem. ACF2 supports the use of fully numeric TSO Userids. The customer has an exit in place that forces all dataset allocations to be prefixed with a Alpha character, getting around the dataset issues. However, if I migrate them to RACF, TSO does NOT support a fully numeric Userid. I know this is not supported by IBM, but does anyone have any ideas (TSO exit?), that I can use to support fully numeric TSO Userids. The customer does not what to change the RACF Userids to start with an alpha character for business/application reasons. Any help gratefully received. Regards, Mark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to change the ISPF code page?
In a message dated 7/22/2008 1:54:49 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: It figures. The characters got "munged" by email. Corrections are noted below: >> Probably a code page problem? **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete PAGESPACE in other catalog
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Pat Mihalec > Sent: Tuesday, July 22, 2008 1:51 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Delete PAGESPACE in other catalog > > Here is some JCL I have used in the past > //IDCAMS EXEC PGM=IDCAMS > //STEPCAT DD DSN=CATALOG.MASTER.VCATT28,DISP=SHR > //SYSPRINT DD SYSOUT=* > //SYSINDD * > DELETE - > PAGE.TEST.COMMON - > PAGESPACE - > PURGE - > CATALOG(CATALOG.MASTER.VCATT28) > > Pat Mihalec H no more STEPCAT allowed! My page datasets are all named PAGE.&SYSNAME.stuff. I use MultiLevel aliases so that I can do a DEFINE alias so that PAGE.&SYSNAME in this system's master catalog points to &SYSNAME's master catalog. Another possibility is to simply create the PAGESPACE in the current system's master catalog. Then, just do a DEFINE PAGESPACE ... RECATALOG CAT(other.mastercat) . One nice thing is that a PAGESPACE can be defined in multiple catalogs at the same time. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to change the ISPF code page?
Edward Jaffe wrote:
It figures. The characters got "munged" by email. Corrections are noted
below:
The left bracket key is defined as:
Base: ',' <-- This is supposed to be the NOT symbol (like a backwards
L rotated left 90 degrees)
Shift: '{'
Ctrl: [ESC]
Alt: [pass]
AltGr: [dead]
CtrlShift: [pass]
The right bracket key is defined as:
Base: '&' <-- This is supposed to be a broken vertical bar
Shift: '}'
Ctrl: [GS]
Alt: [pass]
AltGr: [dead]
CtrlShift: [pass]
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete PAGESPACE in other catalog
Here is some JCL I have used in the past //IDCAMS EXEC PGM=IDCAMS //STEPCAT DD DSN=CATALOG.MASTER.VCATT28,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSINDD * DELETE - PAGE.TEST.COMMON - PAGESPACE - PURGE - CATALOG(CATALOG.MASTER.VCATT28) Pat Mihalec Rush University Medical Center Senior System Programmer (312) 942-8386 [EMAIL PROTECTED] John Mattson <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/22/2008 01:46 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Delete PAGESPACE in other catalog zOS 1.9 IDCAMS manual has a fine example of how to deFINE a pagespace in another system's Master catalog. Excellent DEFINE ALIAS (NAME(SYS2) RELATE(MASTCAT.SYSTEM2)) DEFINE PAGESPACE (NAME(SYS2.PAGE2) CYLINDERS(10) VOLUMES(VSER05) ALTER SYS2.PAGE2 NEWNAME(SYS1.PAGE2) CATALOG(MASTCAT.SYSTEM2) ALTER SYS2.PAGE2.DATA NEWNAME(SYS1.PAGE2.DATA) CATALOG(MASTCAT.SYSTEM2) But how to deLETE one of these in another system's master catalog? I have tried to DEFINE ALIAS, DELETE PAGESPACE with CAT(, tried ALTER the pagespace to an SSA aliwas like SYS2 in the example above, but no luck. Anyone know this trick? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to change the ISPF code page?
Patrick O'Keefe wrote:
I'm using PComm with "Session parameters - Host Code-Page" set to
1047. It was probably mentioned somewhere in this thread, but I
don't know if that specification effects both keyboard mapping and
display or just display.
The square brackets that display correctly are x'AD' and x'BD'.
The square brackets from PComm are x'B0' and x'6A'.
Ummm The default United States keyboard mapping in PCOMM does not
define square brackets ...
The left bracket key is defined as:
Base: ','
Shift: '{'
Ctrl: [ESC]
Alt: [pass]
AltGr: [dead]
CtrlShift: [pass]
The right bracket key is defined as:
Base: '&'
Shift: '}'
Ctrl: [GS]
Alt: [pass]
AltGr: [dead]
CtrlShift: [pass]
You must have defined them yourself -- to the wrong values!
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Delete PAGESPACE in other catalog
zOS 1.9 IDCAMS manual has a fine example of how to deFINE a pagespace in another system's Master catalog. Excellent DEFINE ALIAS (NAME(SYS2) RELATE(MASTCAT.SYSTEM2)) DEFINE PAGESPACE (NAME(SYS2.PAGE2) CYLINDERS(10) VOLUMES(VSER05) ALTER SYS2.PAGE2 NEWNAME(SYS1.PAGE2) CATALOG(MASTCAT.SYSTEM2) ALTER SYS2.PAGE2.DATA NEWNAME(SYS1.PAGE2.DATA) CATALOG(MASTCAT.SYSTEM2) But how to deLETE one of these in another system's master catalog? I have tried to DEFINE ALIAS, DELETE PAGESPACE with CAT(, tried ALTER the pagespace to an SSA aliwas like SYS2 in the example above, but no luck. Anyone know this trick? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to change the ISPF code page?
On Mon, 14 Jul 2008 11:32:39 -0400, Gerhard Postpischil <[EMAIL PROTECTED]> wrote: >... >I sympathize, having just worked through some bracket >incompatibilities with special software, but what would the >keyboard look like? Eight shift keys or worse ? >... Speaking of bracket incompatabilites, ... Maybe this was already mentioned inthe thread, but I've been verifying effects of the changes to "Terminal type" by looking at the output from man commands issued from an ISHELL panel (in addition to viewing the macros mentioned). Square brackets look great there. But not so the square brackets I enter from my keyboard. I'm using PComm with "Session parameters - Host Code-Page" set to 1047. It was probably mentioned somewhere in this thread, but I don't know if that specification effects both keyboard mapping and display or just display. The square brackets that display correctly are x'AD' and x'BD'. The square brackets from PComm are x'B0' and x'6A'. I know I can change the keyboard mapping. Is that what others have done, or is there some other more standard technique? Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting problem with CONSOLE ACTIVATE
That's what I'd call "Clustered Departures". :-) Sorry folks That's got to be the most NERDY joke in history. :-) Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM's 2Q2008 Earnings
Hopefully you didn't miss out Abel Gance's "La Roue". :-) Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting problem with CONSOLE ACTIVATE
Bingo. I saw the S13E but it did not penetrate my brain bone. Everything else looks like a good fit and the fix is not on. Thanks!!! -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Brian Peterson Sent: Tuesday, July 22, 2008 11:57 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Interesting problem with CONSOLE ACTIVATE Does this batch job reference a PDSE? Perhaps OA22344 describes this problem. Brian On Tue, 22 Jul 2008 11:37:29 -0500, Hal Merritt wrote: > For many, many moons, we have a large number of productions jobs kick >off at about the same time. The first step is scheduler administration, >and the second step executes IKJEFT1B, which calls a REXX exec (see >below). > >The command executed is a JES purge: $P O JOB(xxyyzz),HOURS<12 > >(Please don't ask why we do the purge. It makes perfect >business/technical sense to us. A REXX is used so that the command can >be scheduled, routed, and managed.) > >Just lately, that step has been randomly failing and then hanging >between the CONSOLD ACTIVATE and CONSOLE DEACTIVATE. The hanging job >then 'sits' on the console causing other jobs with that same ID to fail. > >The only symptom I see is the following message: > >IEC999I IFG0TC0A,IGWFARC0,jobname,stepname > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Branch Entry Catalog
Who calls Branch Entry Catalog (as opposed to issuing SVC 26)? /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM's 2Q2008 Earnings
Roger Bolan wrote: If you didn't get the reference, you really need to rent this movie: Animal House.:-) I started from the beginning. Now just seen Metropolis and Dr. Caligari -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
Dave, With regrests, I think it would be better to go back to the beginning of your base SERVERPAC and then reinstall the maint with the correct JOBLIB/STEPLIB. I am not sure if a REDO on all of the fixes would work as well. (Yes I did have to regress my SMPE libraries to the beginning and rerun the APPLY. I had the same number of PTFs that got regressed) I think it is safer to go back to the base serverpac and then go forward. Of course I did a FDR Dump of all of my serverpac libraries before doing maint, so it was an easy process to regress them. Lizette > > Thank you, of course I should have done that. What I get for doing >one of these only every two or three years. And I missed it in the PSP >and/or migration doc. > My next question is: Since I did get 835 PTFs on (all that didn't >involve NUCLEUS), can I go forward, or should I start over one more >time? Or restore from back up to the pre APPLY state and run again. Or >SMP/E restore? > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >> Behalf Of Lizette Koehler >> Sent: Tuesday, July 22, 2008 4:46 AM >> To: IBM-MAIN@BAMA.UA.EDU >> Subject: Re: Some insight on 1.9 install >> >> I ran into that one. You MUST run your SMPE Assembles pointing to the >z/OS >> V1.9 ASSEMBLER AND BINDER libraries. They need to be JOBLIB or >STEPLIB in >> your SMPE libraries. This is documented in the z/OS V1.9 PSP bucket >> >> Otherwise the IPL blows up. >> >> Lizette >> >> >> > >> >I'll probably open an ETR in the morning, but I hope for some >> > thoughts here. My Serverpac order is now several months old. So, I >> > uploaded a report and ordered maintenance to current level. After >some >> > work with excludes, I get an APPLY CHECK with rc=0. >> > >> > So, I run the APPLY and I get several (more than a dozen) like >this: >> > >> > >> > >> > UA36789 HBB7740 GIM23911E 56 LINK-EDIT PROCESSING FAILED FOR >> > MODULE ITTTL IN LMOD IEANUC01 IN THE NUCLEUS >> > >> > LIBRARY. THE RETURN CODE WAS >12. >> > THE SEQUENCE NUMBER WAS 000522. THE SYSPRINT >> > >> > FILE WAS SMP00111. >> > >> > >> > >> > >> > Messages as above, all the other PTFs (anything that doesn't touch >> > NUCLEUS) go on clean. What am I missing? >> > >> > >> > >> > As you might imagine, I'm a little reluctant to good forward with >> > potential nucleus problems. >> > >> > >> > >> > Running on a 1.7 driving system. Damn, should I be using the 1.9 >> > MIGLIB? >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
All of the issues will be indicated in the SMPOUT DD. Anything that shows "system utility failure" (or something similar) will need to be fixed. About the only thing that should remain after the last run (once all issues have been fixed) are unresolved error holds. <> > >My next question is: Since I did get 835 PTFs on (all that didn't > involve NUCLEUS), can I go forward, or should I start over one more > time? Or restore from back up to the pre APPLY state and run again. Or > SMP/E restore? > > > Just rerun the apply, fixing problems until a clean run is achieved. > Each run will remember what the previous runs accomplished, and only > attempt to apply the stuff previously in error. Yahbut, I did run the 835 successful PTFs with the 1.7 system against the 1.9 target? Is NUCLEUS (which failed) my only worry? <> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting problem with CONSOLE ACTIVATE
Does this batch job reference a PDSE? Perhaps OA22344 describes this problem. Brian On Tue, 22 Jul 2008 11:37:29 -0500, Hal Merritt wrote: > For many, many moons, we have a large number of productions jobs kick >off at about the same time. The first step is scheduler administration, >and the second step executes IKJEFT1B, which calls a REXX exec (see >below). > >The command executed is a JES purge: $P O JOB(xxyyzz),HOURS<12 > >(Please don't ask why we do the purge. It makes perfect >business/technical sense to us. A REXX is used so that the command can >be scheduled, routed, and managed.) > >Just lately, that step has been randomly failing and then hanging >between the CONSOLD ACTIVATE and CONSOLE DEACTIVATE. The hanging job >then 'sits' on the console causing other jobs with that same ID to fail. > >The only symptom I see is the following message: > >IEC999I IFG0TC0A,IGWFARC0,jobname,stepname > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
Gibney, Dave wrote: Yahbut, I did run the 835 successful PTFs with the 1.7 system against the 1.9 target? Is NUCLEUS (which failed) my only worry? Seems like. See the thread around http://bama.ua.edu/cgi-bin/wa?A2=ind0801&L=ibm-main&D=0&I=1&X=-&P=91155 Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Interesting problem with CONSOLE ACTIVATE
On Tue, 22 Jul 2008 11:37:29 -0500, Hal Merritt <[EMAIL PROTECTED]> wrote: > > > >The only symptom I see is the following message: > > > >IEC999I IFG0TC0A,IGWFARC0,jobname,stepname > > > >The FM implies I should be looking for the debris field of a system 0C1, >but I don't' see anything. > Have you checked LOGREC from that time period? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Interesting problem with CONSOLE ACTIVATE
For many, many moons, we have a large number of productions jobs kick
off at about the same time. The first step is scheduler administration,
and the second step executes IKJEFT1B, which calls a REXX exec (see
below).
The command executed is a JES purge: $P O JOB(xxyyzz),HOURS<12
(Please don't ask why we do the purge. It makes perfect
business/technical sense to us. A REXX is used so that the command can
be scheduled, routed, and managed.)
Just lately, that step has been randomly failing and then hanging
between the CONSOLD ACTIVATE and CONSOLE DEACTIVATE. The hanging job
then 'sits' on the console causing other jobs with that same ID to fail.
The only symptom I see is the following message:
IEC999I IFG0TC0A,IGWFARC0,jobname,stepname
The FM implies I should be looking for the debris field of a system 0C1,
but I don't' see anything.
We expect failures when more than one job attempts to concurrently
activate the console, but the hang is something new.
Any clues?
Thanks!!
/**REXX/
/* ISSUE COMMANDS FROM BATCH */
/* USED INSTEAD OF INSTREAM COMMANDS SO THAT THE */
/* BATCH JOB CAN BE ROUTED TO A DESIRED LPAR*/
/**/
TRACE OFF
PARSE ARG SYSCMD
"CONSOLE ACTIVATE"
"CONSOLE SYSCMD("SYSCMD")"
SAY "COMMAND EXECUTED=" SYSCMD
"CONSOLE DEACTIVATE"
"CONSPROF SOLDISP(YES)"
EXIT
NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Confusion
I actaully brought up the new z/OS V1.9 system in our shared plex (5 lpars) with everybody sharing. So I used all of our current files (ACDS CDS, HSM Files, CF files, and so on). The first IPL was perfect, I had no issues. Only gotcha is that you need to do all your SMS work from the higher level operating system once it touches your SMS data sets. But I had no issue doing the software upgrade and then just IPL'ing the system into the plex the first time. Of course I made sure all the toleration maint between z/OS V1.7 and V1.9 was in place. I even did a fall back from 1.9 to 1.7 without issue. To recap, 1) Laid down the Software installation for Serverpac 2) Build the new SYSRES and OMVS data sets 3) IPL'd into the plex using all the current data sets for JES2, HSM, SMS, and so on. The IPL was done from the BASE serverpac level, I have no problems to report doing that. Lizette > > >> Ready to IPL our test 1.9 and the SMS question came up. Is the version as > >> laid down by the build process enough to bring up the system? My boss is >> concerned since we're in a shared DASD world. >> >My z/OS guys would bring it up for the first time in the sandbox and have >me active a real configuration quickly thereafter. If you want to be sure >you have something valid before the ipl, you could do a SETSMS >SAVEACDS(your.new.acds.dsn) to put your SMS configuration in the new acds >dataset. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
> -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Staller, Allan > Sent: Tuesday, July 22, 2008 9:06 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Some insight on 1.9 install > > >My next question is: Since I did get 835 PTFs on (all that didn't > involve NUCLEUS), can I go forward, or should I start over one more > time? Or restore from back up to the pre APPLY state and run again. Or > SMP/E restore? > > > Just rerun the apply, fixing problems until a clean run is achieved. > Each run will remember what the previous runs accomplished, and only > attempt to apply the stuff previously in error. Yahbut, I did run the 835 successful PTFs with the 1.7 system against the 1.9 target? Is NUCLEUS (which failed) my only worry? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
That WASN'T my assumption... My assumption was that anyone WITH a CF had it well above CFLEVEL=1. As to WHAT the minimum level is I don't know. Rich Fochtman wrote: > Bad assumption. I'm stuck working part-time in a Basic Sysplex shop of > three images: PROD, TEST and SANDBOX. CF is not even being considered, > mainly due to politics in the office. All three images running in > separate LPARs on a 6-engine z9 processor. Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Confusion
Will you be using one Commds dataset or two? From: Daniel McLaughlin [mailto:[EMAIL PROTECTED] Sent: Tue 7/22/2008 11:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: SMS Confusion Ready to IPL our test 1.9 and the SMS question came up. Is the version as laid down by the build process enough to bring up the system? My boss is concerned since we're in a shared DASD world. TIA... If you wish to respond offline, that is cool, too. (SMS Rookie) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
My next question is: Since I did get 835 PTFs on (all that didn't involve NUCLEUS), can I go forward, or should I start over one more time? Or restore from back up to the pre APPLY state and run again. Or SMP/E restore? Just rerun the apply, fixing problems until a clean run is achieved. Each run will remember what the previous runs accomplished, and only attempt to apply the stuff previously in error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Confusion
Daniel, > Ready to IPL our test 1.9 and the SMS question came up. Is the version as > laid down by the build process enough to bring up the system? My boss is > concerned since we're in a shared DASD world. > My z/OS guys would bring it up for the first time in the sandbox and have me active a real configuration quickly thereafter. If you want to be sure you have something valid before the ipl, you could do a SETSMS SAVEACDS(your.new.acds.dsn) to put your SMS configuration in the new acds dataset. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
Thank you, of course I should have done that. What I get for doing one of these only every two or three years. And I missed it in the PSP and/or migration doc. My next question is: Since I did get 835 PTFs on (all that didn't involve NUCLEUS), can I go forward, or should I start over one more time? Or restore from back up to the pre APPLY state and run again. Or SMP/E restore? > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Lizette Koehler > Sent: Tuesday, July 22, 2008 4:46 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Some insight on 1.9 install > > I ran into that one. You MUST run your SMPE Assembles pointing to the z/OS > V1.9 ASSEMBLER AND BINDER libraries. They need to be JOBLIB or STEPLIB in > your SMPE libraries. This is documented in the z/OS V1.9 PSP bucket > > Otherwise the IPL blows up. > > Lizette > > > > > >I'll probably open an ETR in the morning, but I hope for some > > thoughts here. My Serverpac order is now several months old. So, I > > uploaded a report and ordered maintenance to current level. After some > > work with excludes, I get an APPLY CHECK with rc=0. > > > > So, I run the APPLY and I get several (more than a dozen) like this: > > > > > > > > UA36789 HBB7740 GIM23911E 56 LINK-EDIT PROCESSING FAILED FOR > > MODULE ITTTL IN LMOD IEANUC01 IN THE NUCLEUS > > > > LIBRARY. THE RETURN CODE WAS 12. > > THE SEQUENCE NUMBER WAS 000522. THE SYSPRINT > > > > FILE WAS SMP00111. > > > > > > > > > > Messages as above, all the other PTFs (anything that doesn't touch > > NUCLEUS) go on clean. What am I missing? > > > > > > > > As you might imagine, I'm a little reluctant to good forward with > > potential nucleus problems. > > > > > > > > Running on a 1.7 driving system. Damn, should I be using the 1.9 > > MIGLIB? > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMS Confusion
Ready to IPL our test 1.9 and the SMS question came up. Is the version as laid down by the build process enough to bring up the system? My boss is concerned since we're in a shared DASD world. TIA... If you wish to respond offline, that is cool, too. (SMS Rookie) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
--- I'm wondering whether to do the same regarding Parallel Sysplex manuals.They refer to eg CFLEVEL1 which I kinda think all customers will have by now. :-) Bad assumption. I'm stuck working part-time in a Basic Sysplex shop of three images: PROD, TEST and SANDBOX. CF is not even being considered, mainly due to politics in the office. All three images running in separate LPARs on a 6-engine z9 processor. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
In a message dated 7/22/2008 10:11:47 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: No, it's quit since we used 3081s, 3090s and IBM publications for landfill >> We had a gas fired 'burner' for many years. There were rumors that 3rd shift used it for ribs to go with the watermelon storage under the raised floor. Anyway one day the reburner died and the 200 car parking lot was covered in fine ash. I wasn't in on the details, but the EPA compliance office made them shut it down since we didn't have the $$$ to upgrade. **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dump management
I used to have a boss that kept lots of CICS dumps on spool. We had 2 3390 M3s for our spool. The day after she left, our spool went from about 60% full to around 20% full after I purged all of the CICS dumps. I think the oldest dump she had was about 2 years old. Her desk and table were also piled with dumps. Once or twice when I asked her where something was, she always found it right away. I don't know why she kept them, because she rarely did anything with them. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
No, it's quit since we used 3081s, 3090s and IBM publications for landfill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tracing USS IP flows
Sorry There was supposed to be a [2] following the name of the "man of steel". Chris Mason On Tue, 22 Jul 2008 07:16:54 -0500, Chris Mason <[EMAIL PROTECTED]> wrote: >Ian > >... and "before" was when you used VTAM obviously and probably >understood "USS" to mean "Unformatted System Services".[1] > >The fact that you hark back to the good old days may indicate that you retain >the entirely reasonable expectation that, if data can find its way from A to B, >it should jolly well be able to find its way back from B to A - a "given" in >the >connection-oriented SNA world. > >Regrettably, thanks, I was told, to Iosef Vissarionovich Dzhugashvili, aka >Stalin and his propensity for aiming WMD at the US, the network invented to >cater for the mass destruction of communication facilities which could result >from a launch of these weapons, IP is connectionless. > >This is all a massively verbose way to hint that your problem may be simply >that the outbound route works but the inbound route does not. Thus, before >you go to all the trouble of tracing anything in the old "VTAM buffer" way, you >might like to try the traceroute command at the B node in order to find out >where the routing definitions are "broken". > >I hope you'll be able to say "I'll drink to that!" > >Chris Mason > >[1] I see my preference for this usage has attracted some notoriety; regular >contributor Timothy has used it as an example of the proper use of the list! > >[2] In a reassignment/redesign of the library at an education centre where I >used to work into a sort-of "internet cafe" without the coffee, a blank space >was left between two doors with busy corridors on two sides. It seemed >obvious to me - but not the local management - that it was the ideal location >for a bust of the person most responsible for inspiring the Internet. > >Chris Mason > >On Mon, 21 Jul 2008 23:49:31 +0100, Ian S. Worthington ><[EMAIL PROTECTED]> wrote: > >>I've been asked to look at some problems communicating with an application >>running under USS from a z/linux system. >> >>Symptoms seem to be that the input's arriving and being processed, but the >>reply message isn't making it back. >> >>What's the best way of tracing ip comms under uss? When I used to do this >>before it was get a vtam buffer trace, but I'm not sure if there's a better >>way under uss. >> >>Suggestions welcome. >> >> >>ian >>... >> >>Ian S. Worthington, MBCS. >> >>me: http://isw.me.uk/ >>photos: http://gallery.isw.me.uk/ >> >>Dulce et decorum est pro patria mori, sed dulcius pro patria vivere, et >>dulcissimus pro patria biber. Ergo, bibiamo pro salute patriae. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
I spend all of my time reading IBM-Main. --- [EMAIL PROTECTED] wrote: From: "Gray, Larry - Larry A" <[EMAIL PROTECTED]> To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.9 System Commands Memory Reconfiguration Issue Date: Tue, 22 Jul 2008 09:41:40 -0400 How could you have free time. Shouldn't you be out shoring up your sinking data center? Larry Gray Large Systems Engineering Lowe's Companies 336-658-7944 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Brian Kenny Sent: Tuesday, July 22, 2008 9:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.9 System Commands Memory Reconfiguration Issue Recently, June 2008, with time on my hands and no real life, I got tired so seeing references in the EREP reference (copyright Mar 2006) to the 3081 and 3090s. So summoning up righteous indignation I sent off an email to the address in back of the manual - [EMAIL PROTECTED], never really expecting a response. Surprise, about a week later I received an email from IBM thanking me for my input and a promise that the manuals would be changed with the next release. Thankfully my workload has increased and I am no longer spending my time in search of nits to pick. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
How could you have free time. Shouldn't you be out shoring up your sinking data center? Larry Gray Large Systems Engineering Lowe's Companies 336-658-7944 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Brian Kenny Sent: Tuesday, July 22, 2008 9:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.9 System Commands Memory Reconfiguration Issue Recently, June 2008, with time on my hands and no real life, I got tired so seeing references in the EREP reference (copyright Mar 2006) to the 3081 and 3090s. So summoning up righteous indignation I sent off an email to the address in back of the manual - [EMAIL PROTECTED], never really expecting a response. Surprise, about a week later I received an email from IBM thanking me for my input and a promise that the manuals would be changed with the next release. Thankfully my workload has increased and I am no longer spending my time in search of nits to pick. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
I'm wondering whether to do the same regarding Parallel Sysplex manuals. They refer to eg CFLEVEL1 which I kinda think all customers will have by now. :-) Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] From: Brian Kenny <[EMAIL PROTECTED]> To: IBM-MAIN@BAMA.UA.EDU Date: 22/07/2008 14:15 Subject: Re: z/OS 1.9 System Commands Memory Reconfiguration Issue Recently, June 2008, with time on my hands and no real life, I got tired so seeing references in the EREP reference (copyright Mar 2006) to the 3081 and 3090s. So summoning up righteous indignation I sent off an email to the address in back of the manual - [EMAIL PROTECTED], never really expecting a response. Surprise, about a week later I received an email from IBM thanking me for my input and a promise that the manuals would be changed with the next release. Thankfully my workload has increased and I am no longer spending my time in search of nits to pick. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dump management
On Tue, 22 Jul 2008 14:13:27 +0200, Barbara Nitz <[EMAIL PROTECTED]> wrote: > I have been unable so far to convince the powers that be that operlog is much >better as it definitely shows more (everythings after a $pjes2 during shutdown), >so no one really cares about operlog. > That is a minor benefit. The big benefit is having all the logs for the sysplex combined in one place when trying to diagnose a problem. There is still a 9 system sysplex here that doesn't use it because they couldn't afford the extra CF activity in their DB2 data sharing environment. But that decision goes back to 9672 CFs. I don't think it would have been an issue with the z900-100 CFs and it certainly wouldn't be an issue today with z9 CFs. Just haven't gotten around to it yet. Anyway... trying to look back at problems in that sysplex can be a real PITA to say the least if you don't know what system to start looking on. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 System Commands Memory Reconfiguration Issue
Recently, June 2008, with time on my hands and no real life, I got tired so seeing references in the EREP reference (copyright Mar 2006) to the 3081 and 3090s. So summoning up righteous indignation I sent off an email to the address in back of the manual - [EMAIL PROTECTED], never really expecting a response. Surprise, about a week later I received an email from IBM thanking me for my input and a promise that the manuals would be changed with the next release. Thankfully my workload has increased and I am no longer spending my time in search of nits to pick. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dump management
On Tue, 22 Jul 2008 04:17:11 -0500, Bruce Hewson <[EMAIL PROTECTED]> wrote: >I keep dumps for 6 months, as I recall reading that is how long >DAE "remembers" an SVC dump occurred... > Sort of. DAE ignores entries that haven't been updated in 180 days. Sounds like a good reason to use 6 months. Although I've never had to go back to one older than the 30 days we keep them in my 6 years here. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSO/ISPF Screen Swap
On Mon, 21 Jul 2008 22:07:21 -0500, Hardee, Charles H <[EMAIL PROTECTED]> wrote: >Actually, everything I do I try to do in REXX. >Unfortunately, some things are still in CLIST and >beyond my control to change, else changed they would be. > Just like any programming language, there really is no good reason to rewrite just for the sake of doing so. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Example of what a very small JCL Interpreter can do to your installation.
On Mon, Jul 21, 2008 at 3:18 PM, McKown, John <[EMAIL PROTECTED]> wrote: > I agree, in part. I tried to use DisplayWrite/370. . But the > main problem, as usual, is management. The mainframe has been around a > long time. We have a lot of policies and procedures. Some of which are > good and necessary. Some of which make no sense (to me). At least around > here, in the past, the Windows environment could change quickly to > demands. Why? Because they were allowed to. There was little change > control. There was almost no review of what was going on. Now that > management here is implementing this, two things have happened: (1) the > "cowboys" has gone on to "greener pastures" where they are allowed to > "get work done, not fill out paper" and (2) change has slowed down to > almost mainframe-likeness. > > John McKown And in some cases even slower Last year we created a *new* mainframe application because the distributed platform guys could not commit to the project's delivery dates (which were legislation-driven and could not be changed). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tracing USS IP flows
On Mon, 2008-07-21 at 23:49 +0100, Ian S. Worthington wrote: > What's the best way of tracing ip comms under uss? TDSLink is useful. It has a builtin web interface and produces a log file in sniffer format. Dead simple to install, and free. TDS (the company) has been acquired and their product renamed to "ServicePilot NBA for z/OS". It can be had at: http://www.servicepilot.com/download1/ -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OPERLOG IEAMDBLG and z/OS V1.9
>But even so, there is no reason that should cause you to lose operlog data. >Did the systems shut >down clean? Up until this morning, I would have said that yes, if there was a normal shutdown, operlog should not have lost records, not even when you're not using staging data sets. This morning I learned that even a system that is not connected to operlog, will not write to operlog etc can definitely have a connection to the operlog logstream/structure, and what's worse, can offload log stream data that during later IPL can cause the logstream to have lost records. How? Have one system in the plex that does NOT use operlog and that has it's own SMS/catalog structure that does NOT know the HLQ used for offloading operlog. Then use SDSF and use LOG O. You will be told 'Log not active', but the system nonetheless connects to the log stream and shows the operlog such as it is written to from other systems! You won't see anythign from your 'own' system, but if you don't leave operlog in sdsf until the *other* system is IPL'd, then yours is going to offload. Regards, Barbara NItz -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tracing USS IP flows
Ian ... and "before" was when you used VTAM obviously and probably understood "USS" to mean "Unformatted System Services".[1] The fact that you hark back to the good old days may indicate that you retain the entirely reasonable expectation that, if data can find its way from A to B, it should jolly well be able to find its way back from B to A - a "given" in the connection-oriented SNA world. Regrettably, thanks, I was told, to Iosef Vissarionovich Dzhugashvili, aka Stalin and his propensity for aiming WMD at the US, the network invented to cater for the mass destruction of communication facilities which could result from a launch of these weapons, IP is connectionless. This is all a massively verbose way to hint that your problem may be simply that the outbound route works but the inbound route does not. Thus, before you go to all the trouble of tracing anything in the old "VTAM buffer" way, you might like to try the traceroute command at the B node in order to find out where the routing definitions are "broken". I hope you'll be able to say "I'll drink to that!" Chris Mason [1] I see my preference for this usage has attracted some notoriety; regular contributor Timothy has used it as an example of the proper use of the list! [2] In a reassignment/redesign of the library at an education centre where I used to work into a sort-of "internet cafe" without the coffee, a blank space was left between two doors with busy corridors on two sides. It seemed obvious to me - but not the local management - that it was the ideal location for a bust of the person most responsible for inspiring the Internet. Chris Mason On Mon, 21 Jul 2008 23:49:31 +0100, Ian S. Worthington <[EMAIL PROTECTED]> wrote: >I've been asked to look at some problems communicating with an application >running under USS from a z/linux system. > >Symptoms seem to be that the input's arriving and being processed, but the >reply message isn't making it back. > >What's the best way of tracing ip comms under uss? When I used to do this >before it was get a vtam buffer trace, but I'm not sure if there's a better >way under uss. > >Suggestions welcome. > > >ian >... > >Ian S. Worthington, MBCS. > >me: http://isw.me.uk/ >photos: http://gallery.isw.me.uk/ > >Dulce et decorum est pro patria mori, sed dulcius pro patria vivere, et >dulcissimus pro patria biber. Ergo, bibiamo pro salute patriae. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dump management
> How old is the oldest dump you recall having to go back to? That was the one occurance, and since all dumps get filtered through me, anyway, I *knew* there was a saved one that was about 3 weeks old. Anyway, it took me long enough to get a consistent erep saving set up here, so that I can get back with erep records a while (15 months). As for dumps, it is usually that they weren't even written or suppressed by DAE when we need one. >I'm curious; are you using an automated process to get SYSLOG to tape? Syslog gets assigned a class that is written to our default archive system that also archives all joblogs and assorted other files, so in production and in theory, I can go back ten years finding syslogs. I have been unable so far to convince the powers that be that operlog is much better as it definitely shows more (everythings after a $pjes2 during shutdown), so no one really cares about operlog. Regards, Barbara Nitz -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
I ran into that one. You MUST run your SMPE Assembles pointing to the z/OS V1.9 ASSEMBLER AND BINDER libraries. They need to be JOBLIB or STEPLIB in your SMPE libraries. This is documented in the z/OS V1.9 PSP bucket Otherwise the IPL blows up. Lizette > >I'll probably open an ETR in the morning, but I hope for some > thoughts here. My Serverpac order is now several months old. So, I > uploaded a report and ordered maintenance to current level. After some > work with excludes, I get an APPLY CHECK with rc=0. > > So, I run the APPLY and I get several (more than a dozen) like this: > > > > UA36789 HBB7740 GIM23911E 56 LINK-EDIT PROCESSING FAILED FOR > MODULE ITTTL IN LMOD IEANUC01 IN THE NUCLEUS > > LIBRARY. THE RETURN CODE WAS 12. > THE SEQUENCE NUMBER WAS 000522. THE SYSPRINT > > FILE WAS SMP00111. > > > > > Messages as above, all the other PTFs (anything that doesn't touch > NUCLEUS) go on clean. What am I missing? > > > > As you might imagine, I'm a little reluctant to good forward with > potential nucleus problems. > > > > Running on a 1.7 driving system. Damn, should I be using the 1.9 > MIGLIB? > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Using COBOL to create a DSNTYPE=LARGE dataset
On Tue, 22 Jul 2008 11:45:36 +0200, Itschak Mugzach <[EMAIL PROTECTED]> wrote: >No, but I would look into the manual for second opinion ;-) > >ITschak Info Apar II14094 Bruno Sugliani zxnetconsult(at)free(dot)fr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dyamic FTP Control Cards
>There is an Input file which contains all the server details, In the job these >server can be passed as symbolic parameters and then the control card for You could split the server information into several members in a PDS and allocated the latter to the //NETRC DD, specifying the member name as a JCL variable. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Using COBOL to create a DSNTYPE=LARGE dataset
No, but I would look into the manual for second opinion ;-) ITschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of גדי בן אבי Sent: Tuesday, July 22, 2008 11:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Using COBOL to create a DSNTYPE=LARGE dataset Hi, After I changed BLOCKTOKENSIZE to NOREQUIRE, the job ran fine. Does anyone know of problems with changing BLOCKTOKENSIZE to NOREQUIRE? Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Itschak Mugzach Sent: Tuesday, July 22, 2008 11:59 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Using COBOL to create a DSNTYPE=LARGE dataset Hello Gadi, What is the value of BLOCKTOKENSIZE in IGDSMS member of parmlib? Itschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: | Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of גדי בן אבי Sent: Tuesday, July 22, 2008 10:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Using COBOL to create a DSNTYPE=LARGE dataset Hi, We are starting to use datasets defined as DSNTYPE=LARGE. When we use a COBOL program to create a LARGE file we get abend s213-15 on module IFG0196J. We are using a very old version of COBOL (VS COBOL II v1.3.2). We are using z/OS v1.7. Is there any way to make this work? TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ NOD32 3280 (20080718) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ NOD32 3280 (20080718) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Using COBOL to create a DSNTYPE=LARGE dataset
Yes, it's a regular DD with DSNTYPE=LARGE. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Tuesday, July 22, 2008 12:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Using COBOL to create a DSNTYPE=LARGE dataset גדי בן אבי wrote: > Hi, > > We are starting to use datasets defined as DSNTYPE=LARGE. > > When we use a COBOL program to create a LARGE file we get abend s213-15 on > module IFG0196J. > > We are using a very old version of COBOL (VS COBOL II v1.3.2). > > We are using z/OS v1.7. > > Is there any way to make this work? 1. How do you use COBOL to create dataset? Is it regular DD with DISP=(NEW,something)? 2. Why don't you use extended format PS? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorcw KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Using COBOL to create a DSNTYPE=LARGE dataset
Hi, After I changed BLOCKTOKENSIZE to NOREQUIRE, the job ran fine. Does anyone know of problems with changing BLOCKTOKENSIZE to NOREQUIRE? Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Itschak Mugzach Sent: Tuesday, July 22, 2008 11:59 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Using COBOL to create a DSNTYPE=LARGE dataset Hello Gadi, What is the value of BLOCKTOKENSIZE in IGDSMS member of parmlib? Itschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: | Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of גדי בן אבי Sent: Tuesday, July 22, 2008 10:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Using COBOL to create a DSNTYPE=LARGE dataset Hi, We are starting to use datasets defined as DSNTYPE=LARGE. When we use a COBOL program to create a LARGE file we get abend s213-15 on module IFG0196J. We are using a very old version of COBOL (VS COBOL II v1.3.2). We are using z/OS v1.7. Is there any way to make this work? TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ NOD32 3280 (20080718) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Using COBOL to create a DSNTYPE=LARGE dataset
גדי בן אבי wrote: Hi, We are starting to use datasets defined as DSNTYPE=LARGE. When we use a COBOL program to create a LARGE file we get abend s213-15 on module IFG0196J. We are using a very old version of COBOL (VS COBOL II v1.3.2). We are using z/OS v1.7. Is there any way to make this work? 1. How do you use COBOL to create dataset? Is it regular DD with DISP=(NEW,something)? 2. Why don't you use extended format PS? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorcw KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dump management
I keep dumps for 6 months, as I recall reading that is how long DAE "remembers" an SVC dump occurred... Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Using COBOL to create a DSNTYPE=LARGE dataset
Hello Gadi, What is the value of BLOCKTOKENSIZE in IGDSMS member of parmlib? Itschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of גדי בן אבי Sent: Tuesday, July 22, 2008 10:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Using COBOL to create a DSNTYPE=LARGE dataset Hi, We are starting to use datasets defined as DSNTYPE=LARGE. When we use a COBOL program to create a LARGE file we get abend s213-15 on module IFG0196J. We are using a very old version of COBOL (VS COBOL II v1.3.2). We are using z/OS v1.7. Is there any way to make this work? TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ NOD32 3280 (20080718) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Using COBOL to create a DSNTYPE=LARGE dataset
Hi, We are starting to use datasets defined as DSNTYPE=LARGE. When we use a COBOL program to create a LARGE file we get abend s213-15 on module IFG0196J. We are using a very old version of COBOL (VS COBOL II v1.3.2). We are using z/OS v1.7. Is there any way to make this work? TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
It is not directory space on the NUCLEUS perhaps? UA36789 has been superceeded by UA40674. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Tuesday, July 22, 2008 9:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Some insight on 1.9 install I'll probably open an ETR in the morning, but I hope for some thoughts here. My Serverpac order is now several months old. So, I uploaded a report and ordered maintenance to current level. After some work with excludes, I get an APPLY CHECK with rc=0. So, I run the APPLY and I get several (more than a dozen) like this: UA36789 HBB7740 GIM23911E 56 LINK-EDIT PROCESSING FAILED FOR MODULE ITTTL IN LMOD IEANUC01 IN THE NUCLEUS LIBRARY. THE RETURN CODE WAS 12. THE SEQUENCE NUMBER WAS 000522. THE SYSPRINT FILE WAS SMP00111. Messages as above, all the other PTFs (anything that doesn't touch NUCLEUS) go on clean. What am I missing? As you might imagine, I'm a little reluctant to good forward with potential nucleus problems. Running on a 1.7 driving system. Damn, should I be using the 1.9 MIGLIB? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Standard Bank email Disclaimer and confidentiality note This e-mail, its attachments and any rights attaching hereto are, unless the content clearly indicates otherwise, the property of Standard Bank Group Limited and its subsidiaries. It is confidential, private and intended for only the addressee. Should you not be the addressee and receive this e-mail by mistake, kindly notify the sender, and delete this e-mail immediately. Do not disclose or use it in any way. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of Standard Bank Group. Standard Bank Group accepts no liability for any loss or damages howsoever incurred, or suffered, resulting, or arising, from the use of this email or its attachments. Standard Bank Group does not warrant the integrity of this e-mail nor that it is free of errors, viruses, interception or interference. Licensed divisions of the Standard Bank Group are authorised financial services providers in terms of the Financial Advisory and Intermediary Services Act, No 37 of 2002 (FAIS). For information about the Standard Bank Group visit our website http://www.standardbank.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Some insight on 1.9 install
Have a look at the SMPE SYSPROINT output, probebly locatged on JES spool. It holds the Binder output. Try finding the mod or lmod. ITschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Tuesday, July 22, 2008 9:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Some insight on 1.9 install I'll probably open an ETR in the morning, but I hope for some thoughts here. My Serverpac order is now several months old. So, I uploaded a report and ordered maintenance to current level. After some work with excludes, I get an APPLY CHECK with rc=0. So, I run the APPLY and I get several (more than a dozen) like this: UA36789 HBB7740 GIM23911E 56 LINK-EDIT PROCESSING FAILED FOR MODULE ITTTL IN LMOD IEANUC01 IN THE NUCLEUS LIBRARY. THE RETURN CODE WAS 12. THE SEQUENCE NUMBER WAS 000522. THE SYSPRINT FILE WAS SMP00111. Messages as above, all the other PTFs (anything that doesn't touch NUCLEUS) go on clean. What am I missing? As you might imagine, I'm a little reluctant to good forward with potential nucleus problems. Running on a 1.7 driving system. Damn, should I be using the 1.9 MIGLIB? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ NOD32 3280 (20080718) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Some insight on 1.9 install
I'll probably open an ETR in the morning, but I hope for some thoughts here. My Serverpac order is now several months old. So, I uploaded a report and ordered maintenance to current level. After some work with excludes, I get an APPLY CHECK with rc=0. So, I run the APPLY and I get several (more than a dozen) like this: UA36789 HBB7740 GIM23911E 56 LINK-EDIT PROCESSING FAILED FOR MODULE ITTTL IN LMOD IEANUC01 IN THE NUCLEUS LIBRARY. THE RETURN CODE WAS 12. THE SEQUENCE NUMBER WAS 000522. THE SYSPRINT FILE WAS SMP00111. Messages as above, all the other PTFs (anything that doesn't touch NUCLEUS) go on clean. What am I missing? As you might imagine, I'm a little reluctant to good forward with potential nucleus problems. Running on a 1.7 driving system. Damn, should I be using the 1.9 MIGLIB? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
