Re: APF authorization failure with DB2
Vivian wrote: On May 22, 2:31 pm, pauls2...@yahoo.com wrote: When we run in straight batch PGM=MyPgm, it works. When we run using IKJEFT01 with a call, it works. When we run it as a DB2 job (IKJEFT01 with Run), it fails S047. But, all of our DB2 libs are also APF authorized and in the linklist. By all I mean SDSNLINK, SDSNEXIT, SDSNLOAD, SDXRRESL. So, I'm perplexed. Is DSN in your TSO Authorized commands table? Yes, it is. We put it in the authorized commands and the authorized programs, just in case... No change. Might try establishing DB2 connectivity by having your program call DB2 CAF (Call Attachment Facility) from your program rather than using DB2 DSN interface under batch TSO. That way you can again invoke your program directly from JCL and at least get the added complication of IKJEFT01 batch TSO and DB2 DSN out of the picture. If you need a different DB2 subsystem for testing, you can still have that passed to your program as a parameter to control the CAF call. Can't recall ever using CAF from an authorized program, but at least there shouldn't be any confusion about getting your program invoked as authorized and running as authorized up to the actual CAF call. Converting batch DB2 to use CAF instead of the DSN interface has the added benefit that SMF job step stats will now reflect the real executed program and not be disguised as just another execution of IKJEFT01. JC Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Enterprise COBOL for z/OS V4
Richards, Robert B. pisze: That is only true if you are paying full cap. Enterprise COBOL is a Variable Workload License Charge (VWLC) product. You only pay for what you use if you are doing sub-capacity pricing. Plus, if you are careful to restrict the lpars that you allow compiler execution on, more money can be saved. Not true. Previous version was also paid by LPAR. The only difference could be that v4 produces SMF89 and then do not need NOSMF89 entry. However subcapacity pricing is available for COBOL V3. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Submitting a Marketing REQUEST (was: BLOCK CONTAINS
Ed, And yet, IBM is hiring 1,300 people in Dubuque Iowa. I'm sure they will hire some who got laid off in other areas of the country, but it is a good sign. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Ed Gould ps2...@yahoo.com Excellent question. Although you might end up getting told to call the 1-800 IBM number. Chuckle they wouldn't know it if it cut their head in half. IBM really screwed the customer over when they got rid of the people x many years ago. I am happy to be far far far away from that IBM mess. If people ask me if IBM is a good investment, I tell them to run run run away as fast as you can as sometime soon it is going to belly up. If they have any business left it will probably be in INDIA. If they are doing short term its a 50-50 gamble as far as I can see. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OAM 3995 objects
Over a year ago one of our DBA's converted us from OAM and the 3995 to remote DB2 objects on DASD on a non-mainframe server platform (as the whole point of the 3995 was long-term archival on random access media cheaper than mainframe DASD). Our case might have been simpler than yours in that our only OAM archive and user of the 3995 was accessed through a single in-house subroutine and 3995 updates were only done weekly. I don't know all the details, but I'm pretty sure he had to write his own program to pull objects from OAM and the 3995 and store them on the new platform; but by retaining some of the old naming conventions and modifying the common access subroutine, the move was almost transparent to the applications using the archive (except for elimination of the weekly 3995 drive and/or cherry picker failures and extended periods of unavailability!). I can remember no another hardware device that was the source of so many night calls, or that I was happier to see depart. As this application was the only user of OAM, we were able to turn off that as well. Six months after the departure of the 3995, our snack vendor replaced our simple gravity-feed drink vending machines with improved vending machines with a cherry-picker extraction mechanism, a single point of failure like the 3995 that breaks at least once a month. Go figure! Joel C Ewing, Data-Tronics Corp., Fort Smith, AR Joel M Ivey wrote: We're in need of migrating our transitioned objects to a better-performing platform than the 3995. Unfortunately OAM doesn't support transitioning objects to (non-DB2) dasd. Our other option is our VTS. Are there any shops that have migrated all their 3995 objects to another platform in order to get rid of the 3995 altogether? Thanks, Joel USC Columiba, SC ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Migrate at close
David, If you are using DFSMShsm duplex tapes for ML2 do you really need to have a third copy as a DFSMShsm backup? Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, May 20, 2009 5:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Migrate at close Lizzette, If the OP migrates to ML2 immediately at EOJ, then there is no HSM Backup taken. The only option for a backup copy in this case is ABARs, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler [stars...@mindspring.com] Sent: Wednesday, May 20, 2009 8:39 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Migrate at close Just so I have a clearer understanding - Is this to create a backup or DR file for offsite? Could you use a management class that would move it to ML2 a little later? Does it need to be immediate? Could you have a second management class that you could use occasionally that would migrate to ML2? Is this because you do not always want to migrate to ML2 but only occasionally? Thanks. Lizette In some cases , it would be nice to migrate a dataset to ML2, as soon as it has been writen and closed. Can I achive this ? Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ups batteries draining, can't switch to generators
While YMMV, out experience has been that any utility power failure lasting more than 5-15 seconds is a solid failure and the outage will invariably be an hour or more while the utility company locates and fixes the problem. This means that unless you have an extraordinary UPS, or functional generators able to recharge the UPS, you are going down -- The only issue is when or how. Given the choice, a controlled shutdown from which restart is almost guaranteed is infinitely better than gambling the potential of adding hours of downtime and potential data loss from an abrupt termination for the questionable benefit of staying up for a few minutes longer. One of issues sounds like a management problem. Placing the power to make a shutdown decision solely in the hands of a duty manager who is not 100% available obviously doesn't work for decisions requiring a 10 minute or better response time. The other issue is that you must have automation support in place to minimize the z/OS shutdown time and documented emergency shutdown procedure that are required reading for whoever may have to effect the shutdown. We have documented procedures for emergency system and hardware shutdown and z/OS automated procedures (using Netview automation and CBT freebie program NETINIT/NETSTOP) to take down online and batch systems and DB2 as quickly as possible. These are the same procedures used for normal IPL shutdown, so they are tested regularly. Normally Operations would consult with whoever is on call in Technical Services (and someone is always available) and we would advise whether to initiate a system shutdown or do it ourselves if on site; but if communication is impossible within the allowed time frame, that decision must be made by the ranking Operator on site. Our procedures also document a quick and dirty shutdown method if there is reason to believe the remaining UPS time is at best only one or two minutes instead of the typical 15+ minutes - namely, QUIESCE z/OS, SYSTEM RESET the production LPAR, and power down the processor and other hardware ASAP. There is greater risk of logical damage - DB2 threads in a questionable state and possibly a need to recover some specific tables from archive logs -- but doing a controlled hardware shutdown should at least eliminate any hardware issues on restart. Joel C Ewing Kelly Bert Manning wrote: Please don't laugh. I work with applications on a non-sysplex and non-xrf, supported, z/OS where there have been 3 cases of UPS batteries draining flat, followed by uncontrolled server crashes, in the past 17 years. They all happened in October and November, gale season (Cue background music with the Gales of November line by Gordon Lightfoot) After the first one the data center operator said that they would consider giving operators authority to shut down OS/390 if they were unable to make immediate contact with the Duty Manager after discovering that UPS batteries were draining during a power failure and that generator power was not available or failed after starting. Four weeks later a carbon copy crash occurred, inspriring a promise that operators would start draining CICS and IMS message queues and stopping and rolling back BMPs and DB2 online jobs, while there was still power in batteries. Roll forward to this decade, power off during gale season, generators start, but one fails and goes offline, followed by other mayhem in the power hardware. Back on batteries for 22 minutes, until they drain and the z server crashes. Current operator says what promise to shut everything down cleanly before the batteries drain?. Is 22 minutes an unreasonable time figure for purging IMS messaqe queues, bringing down CICS regions, draining initiators, and abending and rolling back online IMS and DB2 jobs to the last checkpoint, swapping logs, writing and dismounting log backups and turning off power before sudden power loss starts to play mayhem with disk and other hardware? Oh did I mention, the 2 CPU single processor was only about 30% busy at the time, the Sunday weekly low CPU use period. We had a different sort of power outage after the first of the 2 crashes last decade. Somebody working for one of the potential bidders used a metal tape measure in an attempt to measure clearance around the power cable entrance to the building. The resulting demonstration of how much power moves through the space around a high voltage cable destroyed several 3380 clone drives, in addition to crashing all the OS/390 processors. I earned my DBA pay that day. Bottom line, what should happen when UPS batteries start to drain and there is no prospect of reliable, high quality, utility power being restored quickly? Leave it up and roll the dice about losing work in progress and log data (head crashes and cache controller microcode bugs) or shut it down cleanly? -- For IBM-MAIN subscribe
Re: Migrate at close
Ron Hawkins pisze: David, If you are using DFSMShsm duplex tapes for ML2 do you really need to have a third copy as a DFSMShsm backup? Human error. Even duplex copy can be deleted by mistake. Backup requires another action. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Migrate at close
Hi Ron, At DR I have the capability to Recall migrated datasets as well as Recover any that might be mistakenly deleted. To be completely safe, Yes, I believe both ML2 and Backups should be duplexed. Tape is cheap, recreating data if possible is not. Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins [ron.hawkins1...@sbcglobal.net] Sent: Saturday, May 23, 2009 11:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Migrate at close David, If you are using DFSMShsm duplex tapes for ML2 do you really need to have a third copy as a DFSMShsm backup? Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of O'Brien, David W. (NIH/CIT) [C] Sent: Wednesday, May 20, 2009 5:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Migrate at close Lizzette, If the OP migrates to ML2 immediately at EOJ, then there is no HSM Backup taken. The only option for a backup copy in this case is ABARs, Dave O'Brien NIH Contractor From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler [stars...@mindspring.com] Sent: Wednesday, May 20, 2009 8:39 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Migrate at close Just so I have a clearer understanding - Is this to create a backup or DR file for offsite? Could you use a management class that would move it to ML2 a little later? Does it need to be immediate? Could you have a second management class that you could use occasionally that would migrate to ML2? Is this because you do not always want to migrate to ML2 but only occasionally? Thanks. Lizette In some cases , it would be nice to migrate a dataset to ML2, as soon as it has been writen and closed. Can I achive this ? Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLOCK CONTAINS
Paul Gilmartin wrote: On Fri, 15 May 2009 09:27:42 -0400, Thompson, Steve wrote: Welcome to the MVS world. In the MVS world, we are not device dependant, nor are we data definition locked/blocked. We generally don't have to recompile our programs, change the DTF contents (DCB in MVS), etc. just because the file attributes change (xSAM to VSAM is the exception). Huh??? If we are not device dependant, why is there such intense trepidation and resistance to the mere suggestion of a device with a novel geometry such as more bytes per track or more tracks per cylinder? It doesn't appear that you and I have been living in the same MVS world. -- gil It would be a rarity for application programs themselves to be device dependent in the z/OS world, but once you start dealing with instances of data used by those programs on DASD the dependency creeps back in in both obvious and subtle ways, in both the physical representation of the data and in the JCL which references or allocates that data set. I think it would be fair to say that a systems programmer who has to design and implement a migration strategy and deal with effects that are more often than not performance and resource usage issues would see many more issues with DASD architecture migration than an applications programmer. Just changing the number of cylinders per device, complicates DASD migration strategies and may require JCL adjustments to optimize allocations when the typical free space per volume or size of typical free space extents changes. If you change the capacity of a track or cylinder, then all JCL, IDCAMS, or TSO dataset space allocations in those units are obviously suspect. A change in track size raises issues in both block size and number of blocks per track that in general defy a completely automated solution and require some analysis to resolve. Even with an ordinary sequential dataset, there is no guarantee that all access is via standard (QSAM) access methods with no use of pointers dependent in some way on track geometry. And even if all access is QSAM, do you leave the block size alone and risk performance issues, or re-optimize block size and risk having to adjust JCL REGION sizes to allow for larger buffers? Data set types that are known to be direct access, and which may contain internal relative track pointers cannot be copied without some internal modification. Changes in track size or tracks per cylinder have especially subtle side effects when dealing with VSAM KSDS files. VSAM Control Area (CA) size is tied to the physical cylinder architecture, optimum index CI-size is tied to the number of Data CIs per CA, which in turn is tied to both track size and cylinder size. Failure to adjust a sub-optimum Index CI size when copying a KSDS to a new architecture could seriously degrade CA space utilization and increase total dataset space requirements, but automatically adjusting Index CI size for online files could have adverse side effects on manually defined LSR buffer pools in the online regions that access these KSDS files. So again, any attempt to automatically migrate such files to a new architecture carries risks. Having been through several architecture conversions in the past -- 3330 3350 3380(various models) 3390(various models) -- there is no doubt that (1)it can be done (but any old code with datasets that are tied to one architecture with no source or no support is a definite problem!), (2) a migration that changes the track/cylinder architecture takes more person hours to do correctly, (3) and having two different architectures in house during a transition is more complicated to manage. All things being equal, I would much rather not use my scarce time dealing with DASD architecture migration. Joel C Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLOCK CONTAINS
All things being equal, I would much rather not use my scarce time dealing with DASD architecture migration. Having gone from 3330 -- 3350 -- 3380 -- 3390 (emulation mode) -- 3390 (native), I agree 100%! IBM promised, years ago, to not change the geometry again. Better the devil you know; I have other things to waste my time on. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLOCK CONTAINS
On Sat, 23 May 2009 19:12:19 +, Ted MacNEIL wrote: All things being equal, I would much rather not use my scarce time dealing with DASD architecture migration. Having gone from 3330 -- 3350 -- 3380 -- 3390 (emulation mode) -- 3390 (native), I agree 100%! IBM promised, years ago, to not change the geometry again. Better the devil you know; I have other things to waste my time on. - Too busy driving to stop for gas! You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Would you be willing to go so far as to side with me and say that we fundamentally disagree with Mr. Thompson? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLOCK CONTAINS
You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Not at all. There are at least two device types -- tape and disk. And, I can convert to either without re-compiling. That is device independent. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Configuring APPN using Hipersockets
John I'm glad you managed to get it all working. You obviously don't need it but, for completeness for the archives, I may as well air the IP considerations for Enterprise Extender: 1. Clearly you need to define a static VIPA, the IP address given in the XCA GROUP statement. DEVICE device_name VIRTUAL 0 LINK link_name VIRTUAL 0 device_name HOME ... aaa.aaa.aaa.aaa link_name ... 2. Usual descriptions of the IP requirements for Enterprise Extender say that you need to establish a same host interface. DEVICE IUTSAMEH device_name MPCPTP LINK link_name MPCPTP IUTSAMEH HOME ... bbb.bbb.bbb.bbb link_name ... BSDROUTINGPARMS TRUE ... link_name mtu cost_metric subnet_mask 0 ... ENDBSDROUTINGPARMS either as above or as a side-effect of specifying IPCONFIG ... DYNAMICXCF bbb.bbb.bbb.bbb/num_mask_bits cost_metric ... However, some doubt has been thrown on this requirement by a recent thread Duplicate Home Addresses for VIPA and EE - Problem? running in February and March of this year in the IBMTCP-L list.[1] Since you probably defined the DYNAMICXCF parameter of the IPCONFIG statement, you get your IUTSAMEH interface defined for you at no extra cost in terms of definition activity. 3. You will be using UDP ports 12000 to 12004. There have been recent discussions over whether or not you really need to specify entries in the PORT statement list when you do not actually need to protect your installation from people running socket programs without reference to the authority supposedly managing Communications Server (CS) IP. Nevertheless it is good documentation practice - at least - to define your server ports in the PORT statement list. Of course if you need to specify additional parameters such as the BIND parameter, you will need to define an entry in the PORT statement list: PORT ... 12000 UDP NET 12001 UDP NET 12002 UDP NET 12003 UDP NET 12004 UDP NET ... alternatively PORTRANGE ... 12000 5 UDP NET where I have assumed that NET is the name of the started task procedure for VTAM. Note that IBM has taken care to reserve port numbers 12000 to 12004 with the appropriate authority http://www.iana.org/assignments/port-numbers quote entextxid 12000/tcp IBM Enterprise Extender SNA XID Exchange entextxid 12000/udp IBM Enterprise Extender SNA XID Exchange entextnetwk 12001/tcp IBM Enterprise Extender SNA COS Network Priority entextnetwk 12001/udp IBM Enterprise Extender SNA COS Network Priority entexthigh 12002/tcp IBM Enterprise Extender SNA COS High Priority entexthigh 12002/udp IBM Enterprise Extender SNA COS High Priority entextmed 12003/tcp IBM Enterprise Extender SNA COS Medium Priority entextmed 12003/udp IBM Enterprise Extender SNA COS Medium Priority entextlow 12004/tcp IBM Enterprise Extender SNA COS Low Priority entextlow 12004/udp IBM Enterprise Extender SNA COS Low Priority /quote Just in case IBM might feel inspired in the future to have a flavour of Enterprise Extender which uses TCP as the transport protocol, the same ports are reserved with TCP. However there are some products which have used at least port 12000 without reference to the standards body. SHADOW DIRECT is one and there may be others lurking out there. If you are already unfortunately committed to one of these products - as well as marking them 0, assuming that's the lowest mark, the next chance you have to give them an evaluation - you should be able to avoid the unnecessary difficulty by means of the BIND parameter which would allow you to specify the Enterprise Extender static VIPA - assuming you have dedicated that static VIPA for use with Enterprise Extender. 4. The last IP topic is to establish routing to your partner. This can be either by static routing or dynamic routing using OMPROUTE. A route over HiperSockets interfaces should be quite straightforward. For more complicated configurations it is CS IP business-as-usual. - Chris Mason [1] You can review posts in the IBMTCP-L list here: http://www2.marist.edu/htbin/wlvindex?IBMTCP-L On Wed, 20 May 2009 12:18:49 -0700, John Au john...@paccar.com wrote: Chris, Thanks a million. Your examples helped. We now see the APPN connection being made between the LPARs. Regards, John -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Mason Sent: Tuesday, May 19, 2009 12:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Configuring APPN using Hipersockets John Here's some samples to get you started taken from some definitions I set up for a customer last year: Sample Enterprise Extender Major Node - VBUILD TYPE=XCA name PORT MEDIUM=HPRIP, enterprise extender * HPREELIV=YES, HPR liveness reduction for EE * IPPORT=12000,first of 5 IP port numbers * IPRESOLV=0, no resolver
Re: BLOCK CONTAINS
Ted MacNEIL pisze: You seem to be agreeing with Steve Thompson that In the MVS world, we are not device dependant, only insofar as there is only one type of device. A weak assertion indeed. Not at all. There are at least two device types -- tape and disk. And, I can convert to either without re-compiling. That is device independent. IMHO more definitions of the independence can be formulated. For me it is track size in SMS. As long you use track size as physical paramter of the disk you are device dependent. When you think about it as just some chunk of disk space (maybe even FBA) then you are independent. BTW: When we compare MVS to other systems in this context it is good to know what they understand as device dependency. IMHO no need for recompilation is not independency. My $0.02 -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ups batteries draining, can't switch to generators
Why not simply fix the problems in the power systems, and test them regularly? If this had been the case in the last 3 places I have worked, I would have been escorted off the premises, and my stuff thrown out after me. Doug snip Kelly Bert Manning wrote: Please don't laugh. I work with applications on a non-sysplex and non-xrf, supported, z/OS where there have been 3 cases of UPS batteries draining flat, followed by uncontrolled server crashes, in the past 17 years. They all happened in October and November, gale season (Cue background music with the Gales of November line by Gordon Lightfoot) After the first one the data center operator said that they would consider giving operators authority to shut down OS/390 if they were unable to make immediate contact with the Duty Manager after discovering that UPS batteries were draining during a power failure and that generator power was not available or failed after starting. Four weeks later a carbon copy crash occurred, inspriring a promise that operators would start draining CICS and IMS message queues and stopping and rolling back BMPs and DB2 online jobs, while there was still power in batteries. Roll forward to this decade, power off during gale season, generators start, but one fails and goes offline, followed by other mayhem in the power hardware. Back on batteries for 22 minutes, until they drain and the z server crashes. Current operator says what promise to shut everything down cleanly before the batteries drain?. Is 22 minutes an unreasonable time figure for purging IMS messaqe queues, bringing down CICS regions, draining initiators, and abending and rolling back online IMS and DB2 jobs to the last checkpoint, swapping logs, writing and dismounting log backups and turning off power before sudden power loss starts to play mayhem with disk and other hardware? Oh did I mention, the 2 CPU single processor was only about 30% busy at the time, the Sunday weekly low CPU use period. We had a different sort of power outage after the first of the 2 crashes last decade. Somebody working for one of the potential bidders used a metal tape measure in an attempt to measure clearance around the power cable entrance to the building. The resulting demonstration of how much power moves through the space around a high voltage cable destroyed several 3380 clone drives, in addition to crashing all the OS/390 processors. I earned my DBA pay that day. Bottom line, what should happen when UPS batteries start to drain and there is no prospect of reliable, high quality, utility power being restored quickly? Leave it up and roll the dice about losing work in progress and log data (head crashes and cache controller microcode bugs) or shut it down cleanly? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ups batteries draining, can't switch to generators
Hi All, I have a couple of points to make on this topic: 1) For all the well documented (and well taken) information about the importance of shutting down a system orderly and cleanly, I find it hard to remember when - in my experience - the system ever had problems coming back up after a hard crash (I worked in OPS for 10+ yrs.). Maybe back in the 308x days, but 3090+ ?? The hardware was pretty resilient, as I remember. I'm not saying that I recommend anything other than a clean shutdown, but 2) Kelly's post harken's me back to an old pet peev and that is; Operations *used* to have good, knowledgable people who could make decisions without calling 5 people to tell them what to do! I saw, firsthand, the dumbing down of OPS and it disturbed me greatly. I had mgmt come into Operations where I worked that *never* wanted to be at fault... that was truly their #1 priority. They achieved this through never making a darn decision on their own... never sticking their neck out no matter what the situation. I remember one time where I restarted the master catalog to resolve a problem; as called for by the manual (ok... I think I could have gotten away with a lesser evil), but my point is that my mgmt thought I was nuts (and just lucky). Maybe so, but as long as we put zombies who won't take action based on knowledge and experience (and who are - most importantly - empowered to do so), then more money must be spent on hardware, systems and automation that will take the place of that. Just my thoughts... All the best, Scott T. Harder Kelly Bert Manning wrote: Please don't laugh. I work with applications on a non-sysplex and non-xrf, supported, z/OS where there have been 3 cases of UPS batteries draining flat, followed by uncontrolled server crashes, in the past 17 years. They all happened in October and November, gale season (Cue background music with the Gales of November line by Gordon Lightfoot) After the first one the data center operator said that they would consider giving operators authority to shut down OS/390 if they were unable to make immediate contact with the Duty Manager after discovering that UPS batteries were draining during a power failure and that generator power was not available or failed after starting. Four weeks later a carbon copy crash occurred, inspriring a promise that operators would start draining CICS and IMS message queues and stopping and rolling back BMPs and DB2 online jobs, while there was still power in batteries. Roll forward to this decade, power off during gale season, generators start, but one fails and goes offline, followed by other mayhem in the power hardware. Back on batteries for 22 minutes, until they drain and the z server crashes. Current operator says what promise to shut everything down cleanly before the batteries drain?. Is 22 minutes an unreasonable time figure for purging IMS messaqe queues, bringing down CICS regions, draining initiators, and abending and rolling back online IMS and DB2 jobs to the last checkpoint, swapping logs, writing and dismounting log backups and turning off power before sudden power loss starts to play mayhem with disk and other hardware? Oh did I mention, the 2 CPU single processor was only about 30% busy at the time, the Sunday weekly low CPU use period. We had a different sort of power outage after the first of the 2 crashes last decade. Somebody working for one of the potential bidders used a metal tape measure in an attempt to measure clearance around the power cable entrance to the building. The resulting demonstration of how much power moves through the space around a high voltage cable destroyed several 3380 clone drives, in addition to crashing all the OS/390 processors. I earned my DBA pay that day. Bottom line, what should happen when UPS batteries start to drain and there is no prospect of reliable, high quality, utility power being restored quickly? Leave it up and roll the dice about losing work in progress and log data (head crashes and cache controller microcode bugs) or shut it down cleanly? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- All the best, Scott T. Harder -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ups batteries draining, can't switch to generators
Sorry should have said restarted the CATALOG address space. On 5/23/09, Scott T. Harder scottyt.har...@gmail.com wrote: Hi All, I have a couple of points to make on this topic: 1) For all the well documented (and well taken) information about the importance of shutting down a system orderly and cleanly, I find it hard to remember when - in my experience - the system ever had problems coming back up after a hard crash (I worked in OPS for 10+ yrs.). Maybe back in the 308x days, but 3090+ ?? The hardware was pretty resilient, as I remember. I'm not saying that I recommend anything other than a clean shutdown, but 2) Kelly's post harken's me back to an old pet peev and that is; Operations *used* to have good, knowledgable people who could make decisions without calling 5 people to tell them what to do! I saw, firsthand, the dumbing down of OPS and it disturbed me greatly. I had mgmt come into Operations where I worked that *never* wanted to be at fault... that was truly their #1 priority. They achieved this through never making a darn decision on their own... never sticking their neck out no matter what the situation. I remember one time where I restarted the master catalog to resolve a problem; as called for by the manual (ok... I think I could have gotten away with a lesser evil), but my point is that my mgmt thought I was nuts (and just lucky). Maybe so, but as long as we put zombies who won't take action based on knowledge and experience (and who are - most importantly - empowered to do so), then more money must be spent on hardware, systems and automation that will take the place of that. Just my thoughts... All the best, Scott T. Harder Kelly Bert Manning wrote: Please don't laugh. I work with applications on a non-sysplex and non-xrf, supported, z/OS where there have been 3 cases of UPS batteries draining flat, followed by uncontrolled server crashes, in the past 17 years. They all happened in October and November, gale season (Cue background music with the Gales of November line by Gordon Lightfoot) After the first one the data center operator said that they would consider giving operators authority to shut down OS/390 if they were unable to make immediate contact with the Duty Manager after discovering that UPS batteries were draining during a power failure and that generator power was not available or failed after starting. Four weeks later a carbon copy crash occurred, inspriring a promise that operators would start draining CICS and IMS message queues and stopping and rolling back BMPs and DB2 online jobs, while there was still power in batteries. Roll forward to this decade, power off during gale season, generators start, but one fails and goes offline, followed by other mayhem in the power hardware. Back on batteries for 22 minutes, until they drain and the z server crashes. Current operator says what promise to shut everything down cleanly before the batteries drain?. Is 22 minutes an unreasonable time figure for purging IMS messaqe queues, bringing down CICS regions, draining initiators, and abending and rolling back online IMS and DB2 jobs to the last checkpoint, swapping logs, writing and dismounting log backups and turning off power before sudden power loss starts to play mayhem with disk and other hardware? Oh did I mention, the 2 CPU single processor was only about 30% busy at the time, the Sunday weekly low CPU use period. We had a different sort of power outage after the first of the 2 crashes last decade. Somebody working for one of the potential bidders used a metal tape measure in an attempt to measure clearance around the power cable entrance to the building. The resulting demonstration of how much power moves through the space around a high voltage cable destroyed several 3380 clone drives, in addition to crashing all the OS/390 processors. I earned my DBA pay that day. Bottom line, what should happen when UPS batteries start to drain and there is no prospect of reliable, high quality, utility power being restored quickly? Leave it up and roll the dice about losing work in progress and log data (head crashes and cache controller microcode bugs) or shut it down cleanly? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- All the best, Scott T. Harder -- All the best, Scott T. Harder -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLOCK CONTAINS
At 20:24 -0300 on 05/18/2009, Clark Morris wrote about Re: BLOCK CONTAINS: On 18 May 2009 13:35:40 -0700, in bit.listserv.ibm-main you wrote: Ah! NOBLOCK had F/80/80 whereas BLOCK1 had FB/80/80. BLOCK0 still had FB/80/27920. But it is still interesting, to me, that BLOCK CONTAINS 1 and no BLOCK CONTAINS at all can still create an optimally block dataset with little effort in the JCL and no program changes. This is weird because the normal merge is DCB overrides JCL and JCL overrides data set label (DSCB or tape label). The code to distinguish between BLKSIZE=0 in JCL and BLKSIZE not supplied must be interesting to say the least. If I get energetic, I'll check the COBOL Programmers Guide. Talk about ways to confuse the applications programmers and subtle ways to screw up. JCL BLKSIZE=0 gives SDB, no BLKSIZE gives 0. By the time the merge happens the FD has generates a DCB with F/80/80 for no Block Contains, FB/80/80 for Block Contains 1, and FB/80/0 for Block Contains 0 (thus only the last has a Blksize that can be filled in by the Merge). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLOCK CONTAINS
At 16:07 -0500 on 05/18/2009, Paul Gilmartin wrote about Re: BLOCK CONTAINS: On Mon, 18 May 2009 18:18:20 +0200, Gilbert Saint-Flour wrote: On Monday 18 May 2009 18:04, Paul Gilmartin wrote: What a stupid necessity that programmers have to code BLOCK CONTAINS 0 ! What happens if the programmer pre-allocates the data set? It's still a stupid necessity, but it might help in dealing with situations where recompilation is impractical. Well, pre-allocation is not very compatible with HSM, GDG, and a few other I believe I understand the concern with GDG. (Actually, my understanding of GDG is so rudimentary I'm not qualified to doubt the concern.) GDG will get the blocksize from the DCB= clause, a DCB=DSN reference, or a DSCB with the DSNAME (without the .GVyy suffix) on the volume where the Catalog lives (or has this last last source become no longer relevant). Thus this information is always there for the predefined file. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP and SMS (and DYNALLOC)
Hi Greg, No joy, I'm afraid. Set it up as documented, but get the same error. I think I'm getting bit by this statement in the doc. ---snip--- Volumes in dummy storage groups cannot be used when performing volume allocations. For example, the following DD statement, where DUMMY1 is a volume in a dummy storage group, does not work: //DD1 DD VOL=SER=DUMMY1,UNIT=SYSDA,DISP=SHR ---snip--- It appears that this applies to LOCSITE VOL= in the FTP client as well. Thanks! BobL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Greg Shirey Sent: Friday, May 22, 2009 3:53 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FTP and SMS (and DYNALLOC) I believe this is one the situations where a dummy storage group would be useful. I couldn't find an example in the Implementing System-Managed Storage manual, but found the definition: A type of storage group that contains the serial numbers of volumes no longer connected to a system. Dummy storage groups allow existing JCL to function without having to be changed. HTH, Greg -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ups batteries draining, can't switch to generators
I saw, firsthand, the dumbing down of OPS and it disturbed me greatly. When I started in this business, working as an operator was almost a requirement before becoming a SYSPROG. I had mgmt come into Operations where I worked that *never* wanted to be at fault... that was truly their #1 priority. BTDT. GTTS. But, my management (at the time) still gave them the call of if/which changes would be implemented. And, which changes to back out. And, when I complained, they just said I didn't understand, having never been in the trenches. I said, I have the scars to prove it. Remember when you could do a $PQ and blow everything away (before $PQ,ALL was introduced and $PQ was an error). I did that, once. They achieved this through never making a darn decision on their own... never sticking their neck out no matter what the situation. I've worked for many financial and government organisations. That is the prevalent attitude in many departments, not just Computer Ops. The problem becomes, eventually a decision will be made, due to the erosion of the situation, and you can only postpone for so long. By the way, I think you have the wrong third letter in 'darn'. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP and SMS (and DYNALLOC)
No joy, I'm afraid. Set it up as documented, but get the same error. I think I'm getting bit by this statement in the doc. I haven't really been following this thread, so please forgive me as I ask for clarification. Are you saying that if an FTP outfile is allocated, under z/OS, that DFSMS does not intercede? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ups batteries draining, can't switch to generators
On 5/23/09, Ted MacNEIL eamacn...@yahoo.ca wrote: When I started in this business, working as an operator was almost a requirement before becoming a SYSPROG. Absolutely. BTDT. GTTS. ;-) But, my management (at the time) still gave them the call of if/which changes would be implemented. And, which changes to back out. Yup. Warrented, I think, though. And, when I complained, they just said I didn't understand, having never been in the trenches. Wrong. I said, I have the scars to prove it. Remember when you could do a $PQ and blow everything away (before $PQ,ALL was introduced and $PQ was an error). I did that, once. What about just a $P? One day, everything came to a screaching halt and nobody could figure it out. Turned out, a Print Room Op had indadvertently entered $P and the whole system drained. ;-) They achieved this through never making a darn decision on their own... never sticking their neck out no matter what the situation. I've worked for many financial and government organisations. That is the prevalent attitude in many departments, not just Computer Ops. The problem becomes, eventually a decision will be made, due to the erosion of the situation, and you can only postpone for so long. Too much time wasted. People on the front lines need to be empowered to make decisions and they need to be well-paid, knowledgable professionals. By the way, I think you have the wrong third letter in 'darn'. You bet! ;-) - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- All the best, Scott T. Harder -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP and SMS (and DYNALLOC)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Saturday, May 23, 2009 7:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FTP and SMS (and DYNALLOC) No joy, I'm afraid. Set it up as documented, but get the same error. I think I'm getting bit by this statement in the doc. I haven't really been following this thread, so please forgive me as I ask for clarification. Are you saying that if an FTP outfile is allocated, under z/OS, that DFSMS does not intercede? - Hi Ted, More or less, I guess. FTP client on z/OS 1.9, pulling data from a squatty box. Relevant parms are: LOCSITE UNIT=SYSDA VOL=SYST01 Get whatever.distributed.file 'PFDT.TSREL.OPPLZDCK.PULLOUT.SUN' SYST01 doesn't exist, but my SMS ACS routines point PFDT.** to a particular SG. The get fails with: PFDT.TSREL.OPPLZDCK.PULLOUT.SUN is on a direct access volume that is not mounted and Noautomount is specified. Std Return Code = 16000, Error Code = 00018 Putting SYST01 in a DUMMY SG doesn't work, same error. Doc sort of implies that it won't work. I clipped a volume to SYST01 and it works fine. I was trying to get this to work without changing the ftp client control cards. Thanks! BobL -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP and SMS (and DYNALLOC)
I just read that in detail again. The automount lead me to consider if you're really in the HFS file system when you di the get. Try a whatever the print local directory command is after the locsite and before the get. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lester, Bob Sent: Saturday, May 23, 2009 7:43 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FTP and SMS (and DYNALLOC) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Saturday, May 23, 2009 7:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FTP and SMS (and DYNALLOC) No joy, I'm afraid. Set it up as documented, but get the same error. I think I'm getting bit by this statement in the doc. I haven't really been following this thread, so please forgive me as I ask for clarification. Are you saying that if an FTP outfile is allocated, under z/OS, that DFSMS does not intercede? - Hi Ted, More or less, I guess. FTP client on z/OS 1.9, pulling data from a squatty box. Relevant parms are: LOCSITE UNIT=SYSDA VOL=SYST01 Get whatever.distributed.file 'PFDT.TSREL.OPPLZDCK.PULLOUT.SUN' SYST01 doesn't exist, but my SMS ACS routines point PFDT.** to a particular SG. The get fails with: PFDT.TSREL.OPPLZDCK.PULLOUT.SUN is on a direct access volume that is not mounted and Noautomount is specified. Std Return Code = 16000, Error Code = 00018 Putting SYST01 in a DUMMY SG doesn't work, same error. Doc sort of implies that it won't work. I clipped a volume to SYST01 and it works fine. I was trying to get this to work without changing the ftp client control cards. Thanks! BobL -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
