Re: Opinions? Subset input with DFSORT before processing in REXX?
I would, definitely. You can do some Wonderful Things with DFSORT/ICETOOL these days. The SPLICE operator is particularly wonderful for RACF database unloads as you can join up base userid records with their segments, so you can then handle single records at a time in a report instead of having to go doing subsequent reads for the segments. I love Frank Yaeger. He's a God! ;-) Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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: Huh?? (Was: APPC no longer support on zos/1.9)
Phew! That's a relief..! I'll stop frantically searching through the release notes and migration guides now then. I think I just had a minor heart attack.. :-) Brian -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Edward Jaffe Sent: 21 May 2008 15:35 To: IBM-MAIN@BAMA.UA.EDU Subject: Huh?? (Was: APPC no longer support on zos/1.9) Tommy Tsui wrote: any shop have migration plan on APPC application ? or use FTP instead of APPC? The subject of this thread is like a misleading headline in a partisan newspaper. APPC (LU 6.2) and all other SNA protocols are fully supported by z/OS 1.9. - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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.4-1.7 gotchas
Ok.. We hit this problem late last year on an IBM z9BC. I supppose the PMR is still out there on the database if anyone's got access to it. I just dug out our internal problem log for the morning's events and looked through the timeline. Our IBM support engineer first took the device offline on all LPARs, and that did not resolve the problem. We then IPL'd each LPAR; again, that did not resolve the problem. We then did a POR of the box, and the devices were then available. This is the email they (IBM) sent me: Here is the information about the problem. This a known problem and there is a microcode fix available for your machine. The intent of this TDR is to provide information to determine if Segmentation Offload is enabled, and how to disable it. Symptoms: OSA Card will lock up. Check for Segmentation Offload being active: From the z/OS console on each Image, enter D TCPIP,procname,NETSTAT,DEV. If Segmentation offload is functioning, you will see SEGMENTATIONOFFLOAD: YES for the OSA. If this specific line is not displayed, segmentation offload is not available. at this level or previously disabled There is not a NO option for SEGMENTATIONOFFLOAD. Its either YES, or not displayed. There are two ways to disable segmentation offload. The maintenance level on the system determines which one must be used If your customer has applied PK21685 or PK26905, it must be done via the configuration file. 1) If the PTFs are not applied, use the following procedure: Update the TCPIP PROFILE to comment out the START statements for the affected OSA devices. Issue the following commands every time TCPIP is restarted: MODIFY tcpipprocname,NOSEGOFFLOAD (then for each OSA) VARY TCPIP,tcpipjobname,START,osa_device_name (tcpipjobname is optional on this command in a single stack environment) If the MODIFY command is rejected with a EZZ3250I THE MODIFY COMMAND IS NOT SUPPORTED message, Then either: The system does not support Segmentation Offload. Only z/OS 1.7 and above or z/OS 1.6 with the PK02490 PTFs applied have this support, earlier systems do not have any concern with this problem. The PTFs for PK21685 have been applied, thus the following method needs to be used instead. 2) If the PTFs are applied, add the NOSEGMENTATIONOFFLOAD keyword to the GLOBALCONFIG statement in the TCPIP PROFILE. For further help with these commands, contact software support. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Scott Rowe Sent: 09 April 2008 20:40 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.4-1.7 gotchas ??? AFIAK there is no fix, microcode or otherwise, for the segmentation offload problem. I think the default has since been changed been changed to off. Also, it did not affect old OSA cards, it affects ALL OSA Express cards. There was also no need to POR, or even IPL, to recover the card, all that is needed is to configure it offline to ALL LPARs, and then back on. - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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 sites on Google Maps
I used to work at Hursley and noticed the A3090 coincidence as well. It's merely a consequence of the numbering system for UK mainland roads based on the primary trunk roads going more or less radially outwards from London; A1 going North, A2 going Southeast, A3 going southwest, A4 west, and A5 and A6 going northwest. Intermediate roads get a number derived from the proximity to their nearest major trunk road. I stayed in a lot of hotels in the Winchester area whilst working at Hursley, and couldn't help but notice that at least two of them had their toilet facilities serviced and cleaned by a company called CICS.. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Rob Scott Sent: 10 April 2008 12:35 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IBM sites on Google Maps I live 2 miles from IBM Hursley and drive along the A3090 all the time. It made me smile when I first saw the road signs - but according to my wife that is because I am a sad sad geek who really should get out more. - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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.4-1.7 gotchas
Sorry, should have made that clearer - by 'device' I meant the actual OSA itself, not the MVS devices. We did CONFIG CHP(xx),OFFLINE on all LPARs that it was defined to. You got me doubting myself for a moment there though, so I just pulled back our archived SYSLOGs for that day, and they clearly show we did take the channel off and on again with no success. Anyway, I guess that's just a mystery then. Bri - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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.4-1.7 gotchas
One that got us was the TCPIP profile default for the SEGMENTATIONOFFLOAD changed from NO to YES. This attempts to offload some of the TCPIP packet handling from the processor to the OSA card. If you have an old(ish - ours was from 2006/2007) version of the OSA Express/Express2 card, it will lock up under certain high workload conditions, and all IP traffic to and from the machine will stop. The only resolution is a full Power-on Reset - an IPL is not enough. There is a microcode fix for the OSA, however the workaround is to explicitly specify NOSEGMENTATIONOFFLOAD on a GLOBALCONFIG statement in your TCPIP profile, on all LPARs that run a TCPIP stack. It's a known problem apparently. We thought we'd been quite thorough in our prep too, but we missed it. Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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: Clock Change
I keep my z9BC's HMC on GMT all the time (I would probably do that even if I was in New Zealand or Australia, regardless of being in the UK). I don't recall it adjusting time last March or last October, but then I probably wasn't paying particular attention anyway. I don't IPL for time changes any more, I just use a Netview timer event (or even the ops) to issue a SET TIMEZONE=E.01.00 to change to BST in March and a SET RESET to go back to GMT in October. If we have to IPL for some reason, we just manually issue the appropriate command if necessary, but I've almost finished a Netview startup Rexx exec to determine if it should be BST or not and absolve us of that particular chore as well. Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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: Clock Change
We don't have any databases, no. It's several years now since I was at a DB2 shop but I think that it doesn't actually use timestamps on the logs anyway, it uses its own sequencing independent of a time source, if I remember correctly. To be honest, in this day and age, I'd have to question whether I wanted a db that would require a one-hour outage just because the clocks changed anyway, if you see what I mean. Our main problem is that most of our work runs overnight and on one particular LPAR is very tightly organised into scheduling 'windows'. Our OPC setup runs on local time - I'm not an OPC expert so I don't know off the top of my head if that can be changed, and never bothered enough to look it up - but what happens at when you jump forward an hour is that any jobs that should have been submitted in the interim will immediately be submitted, so there's the potential for additional resource contention, or maybe missed files if dependent files haven't been created yet. So we delay it a couple of hours on that LPAR, for when it's more convenient. There's a PCI compliance issue to consider as well, which I can't seem to get a sensible answer out of any of the auditors on, that states that all servers must be set to use similar time sources or kept reasonably synchronised with each other (for log comparisons etc). Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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
Import Connect:Direct self-signed certificate into RACF?
Hi folks Has anyone managed to successfully import into RACF a self-signed server certificate generated by Sterling Commerce's Windows-based Certificate Wizard? I've been sent one by one of our customers; they use it on their Windows-based C:D server, apparently quite successfully on their other C:D sessions from that server. However I can't import the certificate into RACF as a Certificate Signing Authority (CERTAUTH) as it issues message: IRRD126I The certificate contains either a key usage or basic constraint extension indicating that it may not be used as a Certificate Authority certificate. The certificate is not added. This seems fairly reasonable since the attributes of the certificate only specify HANDSHAKE and DATAENCRYPT (not CERTAUTH), however, this is the standard for a self-signed server certificate coming out of the Certificate Wizard - in fact you can neither add nor remove attributes in this case. I've tried importing it as a personal certificate for our C:D server, and it accepts that. I've tried putting it in the keyring as USAGE(PERSONAL), and USAGE(CERTAUTH) but either way C:D fails to negotiate the session, instead issuing message: CSPA202E SSL handshake failure, reason=GSK_ERR_SELF_SIGNED I've had a call open for some time now with Sterling's support and although they're being very attentive and helpful, we're not managing to fix this, and the suggestion now is that we need to find out why RACF is not accepting the certificate, since Windows seems quite happy to do so. Hopefully someone out there has done this (Windows C:D - z/OS C:D) successfully and can tell me where I'm going wrong? Cheers Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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: Import Connect:Direct self-signed certificate into RACF?
Hi Wolfgang
I used the following (real names changed)
RACDCERT -
ID(CDTASK) -
ADD('SSCROOT.CER') -
TRUST -
WITHLABEL('My WindowsCD Partner')
RACDCERT -
ID(CDTASK) -
CONNECT(ID(CDTASK) LABEL('My WindowsCD Partner') -
RING(CDKEYR) USAGE(CERTAUTH))
racdcert id(CDTASK) listring(*) produces the following output:
Certificate Label Name Cert Owner USAGE DEFAULT
---
My CD Server ID(CDTASK) PERSONAL YES
My Signing CA CERTAUTH CERTAUTH NO
My WindowsCD Partner ID(CDTASK) CERTAUTH NO
I've also tried adding 'My WindowsCD Partner' to the keyring as
USAGE(PERSONAL), with no success.
Brian
-
Email sent from www.virginmedia.com/email
Virus-checked using McAfee(R) Software and scanned for spam
--
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
