Re: Musings on a holiday weekend
Dunno if it was C++ for sure, but there was a lot of borrowing from some object-oriented programming language. Andy Wood wrote: On Mon, 3 Jul 2006 10:39:48 -0700, Steve Samson [EMAIL PROTECTED] wrote: Complexity? Blue sky? FS was the champion. From where I sat in FS Architecture in the 1973 time frame, it was appalling. PFCSKs full of themselves and full of the concepts of C++ were able to impose their vision of an object-oriented computer on the hardware design. C++ in 1973 ??? -- 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: USS (was: Re: Western Digital Loses ...)
Even component prefix is not always uniques. See IKJn messages. Some of them belongs to RACF. How do you know they belong to RACF? I admit IKJ messages sometimes appear where you wouldn't expect TSO routines to be involved. I guess that has historically grown. Anyway, no two different modules should issue the same numbered IKJ (or whatever) message. It need not to be unique. It is *strongly suggested*. It is *convenient*. But the system and systems programmers can surviver without full uniquity. Component prefixes need to be unique, otherwise a module of one component can inadvertantly be replaced by another module from another component, both residing in the same load library. Mainframe has a lot of such standards. For example: Sn libraries are target libraries (DDDEFs), while A libraries are distribution libraries. *Usually*. With a number of exceptions, like LINKLIB or LPALIB (no S). Many of them are exceptions because they existed before those rules arised. These again aren't component prefixes. It's a naming convention, and I agree, there very often are exceptions to conventions. Peter Hunkeler CREDIT SUISSE -- 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: VTS stacked tapes - not urgent
Hi All, We have resolved this problem by buying some more scratches. Management went out and bought some. Long debate here as to who is responsible for media management. Our Storage guy used to do it and no one else has taken it up since he has left. Any that is not what I need help here. Now with the SEV1 issue resolved, it was brought to my attention that we should look at .. ERROR CATEGORY SCRATCH COUNT: 183 Reading the redbook, it means there are 183 logical scratch volumes that have errors. How do I find out what they are? I believe the normal procedure is to eject the logical scratch volume? If not, please correct me. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Chiam, Susan Mee-Shia Sent: Monday, July 03, 2006 10:46 PM To: IBM-MAIN@BAMA.UA.EDU Subject: VTS stacked tapes - urgent help! Hi Listers, We have an urgent problem with our VTS. We have run out of Stacked tape for the VTS. We were told that we have to reduce the scratch volumes so reclaim scratch stacked volumes. Below is our library detail. What I want to find our urgently is to how to reclaim all some of the 8226 scratch volumes back into the scratch stacked volume count? I am trying to read the manual, but with your help, we need to resolve this problem urgently. Thanks. D SMS,LIB(XXVTS1),DETAIL CBR1110I OAM library status: 095 TAPE LIB DEVICETOT ONL AVL TOTAL EMPTY SCRTCH ON OP LIBRARY TYP TYPE DRV DRV DRV SLOTS SLOTS VOLS XXVTS1VL 3494-L10 64 60 47 2193141 8226 Y Y -- MEDIA SCRATCH SCRATCH SCRATCH TYPE COUNT THRESHOLD CATEGORY MEDIA2 8226 750 0002 -- OPERATIONAL STATE: AUTOMATED ERROR CATEGORY SCRATCH COUNT: 183 SCRATCH STACKED VOLUME COUNT: 1 PRIVATE STACKED VOLUME COUNT:1445 -- 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: USS (was: Re: Western Digital Loses ...)
Hunkeler Peter (KIUB 34) wrote: Even component prefix is not always uniques. See IKJn messages. Some of them belongs to RACF. How do you know they belong to RACF? See: SA22-7686-06 In fact they grown from TSO. It need not to be unique. It is *strongly suggested*. It is *convenient*. But the system and systems programmers can surviver without full uniquity. Component prefixes need to be unique, otherwise a module of one component can inadvertantly be replaced by another module from another component, both residing in the same load library. No. Component *names* need to be unique. Component prefixes *should* be unique to keep things simple. However I can imagine central repository of all component names. (SMPE/E ?) Mainframe has a lot of such standards. For example: Sn libraries are target libraries (DDDEFs), while A libraries are distribution libraries. *Usually*. With a number of exceptions, like LINKLIB or LPALIB (no S). Many of them are exceptions because they existed before those rules arised. These again aren't component prefixes. It's a naming convention, and I agree, there very often are exceptions to conventions. Component prefixes are conventions as well. Sometimes single component use several prefixes (ie. RACF: ICH and IRR), sometimes single prefix is shared (ANT different copy services). Usually prefix is 3-letter, but there are numerous exceptions as well. Disclaimer: I don't want to say we don't need standards. We need them. Standards, naming conventions provide order and simplification. However those rules are not strict. Regards -- Radoslaw Skorupka Lodz, Poland -- 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
COBOL ARITH(EXTEND) compiler option
I'm looking at the Enterprise COBOL Performance Tuning paper regarding the ARITH(EXTEND) compiler option which says - | *ARITH - EXTEND or COMPAT * | The ARITH compiler option allows you to control the maximum number of digits allowed for decimal | numbers (packed decimal, zoned decimal, and numeric-edited data items and numeric literals). With | ARITH(EXTEND), the maximum number of digits is 31; with ARITH(COMPAT), the maximum number | of digits is 18. However, ARITH(EXTEND) will cause some degradation in performance for all decimal | data types due to larger intermediate results. The amount of degradation that you experience depends directly | on the amount of decimal data that you use. | Performance considerations using ARITH: | On the average, ARITH(EXTEND) was 1% slower than ARITH(COMPAT), with a range of equiv- | alent to 38% slower. | (*COB PG: *pp 37, 41, 48-49, 95, 283-284, 557-566) Can anyone say what with a range of equivalent to 38% slower means. It doesn't make sense to me. I don't even think it's English. Jim McAlpine -- 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
HSM backup
Hi Listers, Can someone please point out what is wrong here for this job? All I am trying to backup dataset using HSM. Is there something either OPS or another team-mate has issued that is stopping HSM to backup to tape. READY PROFILE NOPREFIX READY HBACK 'aaa.KS' WAIT CHANGE ARC1001I aaa.KS BACKDS FAILED, RC=0058, REAS=0056 ARC1358I BACKUP FAILED FOR DATA SET ARC1062I 0001 DATA SETS PROCESSED FOR aaa.KS READY END ARC1358I BACKUP FAILED FOR DATA SET Explanation: A backup command was issued for a data set but was unsuccessful. The data set name and return code are given in message ARC1001I, as follows: 56Data set backup to TAPE is not allowed. -- 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
Wild branch tracing
Hello List,
z/OS 1.7 and the Z9 provide a wild branch value ('branch from' in the
SDWA). Does anyone know if this will be available for any previous z/OS.
A somewhat related question. When branch tracing is turned on (system
trace), are any of the relative branch instructions traced. The POPs seems
to indicate that relative instructions aren't traced.
Thanks
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: COBOL ARITH(EXTEND) compiler option
Jim McAlpine wrote: I'm looking at the Enterprise COBOL Performance Tuning paper regarding the ARITH(EXTEND) compiler option which says - | *ARITH - EXTEND or COMPAT * | The ARITH compiler option allows you to control the maximum number of digits allowed for decimal | numbers (packed decimal, zoned decimal, and numeric-edited data items and numeric literals). With | ARITH(EXTEND), the maximum number of digits is 31; with ARITH(COMPAT), the maximum number | of digits is 18. However, ARITH(EXTEND) will cause some degradation in performance for all decimal | data types due to larger intermediate results. The amount of degradation that you experience depends directly | on the amount of decimal data that you use. | Performance considerations using ARITH: | On the average, ARITH(EXTEND) was 1% slower than ARITH(COMPAT), with a range of equiv- | alent to 38% slower. | (*COB PG: *pp 37, 41, 48-49, 95, 283-284, 557-566) Can anyone say what with a range of equivalent to 38% slower means. It doesn't make sense to me. I don't even think it's English. I believe the interpretation is: The best case was some program ran at the same speed with ARITH(EXTEND) as with ARITH(COMPAT); in the worst case, some program ran 38% slower with ARITH(EXTEND) compared to running when compiled with ARITH(COMPAT). Kind regards, -Steve Comstock -- 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: HSM backup
Hi All, I found an article in IBMLINK regarding how to fix this problem. Problem is now resolved. For those who is interested, it is Item BDC31349. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chiam, Susan Mee-Shia Sent: Tuesday, 4 July 2006 8:16 PM To: IBM-MAIN@BAMA.UA.EDU Subject: HSM backup Hi Listers, Can someone please point out what is wrong here for this job? All I am trying to backup dataset using HSM. Is there something either OPS or another team-mate has issued that is stopping HSM to backup to tape. READY PROFILE NOPREFIX READY HBACK 'aaa.KS' WAIT CHANGE ARC1001I aaa.KS BACKDS FAILED, RC=0058, REAS=0056 ARC1358I BACKUP FAILED FOR DATA SET ARC1062I 0001 DATA SETS PROCESSED FOR aaa.KS READY END ARC1358I BACKUP FAILED FOR DATA SET Explanation: A backup command was issued for a data set but was unsuccessful. The data set name and return code are given in message ARC1001I, as follows: 56Data set backup to TAPE is not allowed. -- 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: Wild branch tracing
John Ticic wrote:
z/OS 1.7 and the Z9 provide a wild branch value ('branch from' in the
SDWA). Does anyone know if this will be available for any previous z/OS.
If it had been in their plan, I think IBM would have added SDWABEA to
z/OS 1.6 long before now.
A somewhat related question. When branch tracing is turned on (system
trace), are any of the relative branch instructions traced. The POPs seems
to indicate that relative instructions aren't traced.
Based branches aren't traced either. What you get are subroutine calls
made via BALR, BASR, BASSM, etc. Unfortunately, you also get mode
switches to/from 64-bit mode. (IMHO it was a poor design choice to not
separate the two.) You'd better have whopping big trace tables because,
with branch tracing enabled, RSM will chew up a significant portion of
it with all of their mode switching to/from 64-bit mode. A complete
64-bit RSM implementation will eventually do away with that craziness.
--
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
SCRT questions
Background: SCRTTOOL job takes a lot of time to complete. 1. What records are required by SCRT ? 2. Is it required to provide all the SMF records from all the LPARs ? I'm considering to exclude records from given LPAR(s) to save I/O. -- Radoslaw Skorupka Lodz, Poland -- 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: HSM CDS question
Have you audited your BCDS recently? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Perryman, Brian Sent: 03 July 2006 06:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: HSM CDS question Hi folks I have some datasets (a couple of hundred) that get included in a DCOLLECT BACKUPDATA output, but when I do an HSM LIST command for them, HSM denies all knowledge.. How can that happen? Thanks Brian This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- 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
Betr.: [IBM-MAIN] SCRT questions
1. SMF records type 70 and 89 2. Yes, all the 70's and 89's off all the lpars Nico Blekemolen Telegraaf Media ICT Amsterdam The Netherlands R.S. [EMAIL PROTECTED] Verzonden door: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 04-07-2006 15:52 Antwoord a.u.b. aan IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Aan IBM-MAIN@BAMA.UA.EDU Cc Onderwerp [IBM-MAIN] SCRT questions Background: SCRTTOOL job takes a lot of time to complete. 1. What records are required by SCRT ? 2. Is it required to provide all the SMF records from all the LPARs ? I'm considering to exclude records from given LPAR(s) to save I/O. -- Radoslaw Skorupka Lodz, Poland -- 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 De informatie in dit e-mailbericht en eventuele bijlagen is vertrouwelijk en is alleen bestemd voor de beoogde ontvanger(s). Indien u dit bericht ten onrechte heeft ontvangen, wordt u verzocht de verzender daarvan in kennis te stellen en het bericht te vernietigen. Het is niet toegestaan de hierin opgenomen informatie op welke wijze dan ook te gebruiken of openbaar te maken. The information contained in this e-mail, including possible attachments, is confidential and is solely for the use of the intended recipient(s). Should you have received this e-mail unintentionally you are then requested to inform the sender and to destroy the message. It is prohibited to use or disclose the information this message contains in whatsoever way. -- 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: avgrec/avgblk history ?
The track balance overhead depends on whether the access method chooses to write short blocks to fill track balances (what does QSAM do?). I have never heard any indication that QSAM writes short blocks in an attempt to fill tracks. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, July 03, 2006 8:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: avgrec/avgblk history ? On Mon, 3 Jul 2006 12:10:08 -0500, Tom Marchant [EMAIL PROTECTED] wrote: SPACE=(1,1024) means you want enough space to store 1024 blocks, assuming each block is 1 bytes. -- 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: Questions on Dedicated Processors
On Mon, 3 Jul 2006 16:35:16 -0500 David Day [EMAIL PROTECTED] wrote: :If anyone knows the answers to these questions, or can point me to the appropriate doc, I'd appreciate it. I read over the announcement regarding the zIIP for DB2 work, and have searched IBM's web site to no avail. But I'm not too good at navigating IBM's website. I always get a ton of useless hits, and probably give up before I should. :1. Does a dedicated processor have an entry in the PCCA? If so, is there some way to recognize the entry as one belonging to a dedicated processor? Only thing I can find in any doc is the data areas manual has something at offset 17c into the PCCA. I would think so. But I didn;' read the document. :2. The announcement I read states the zIIP does not process general interrupts. That makes sense since they want to dedicate the processor to specific work, so any type of general interrupt needing to be processed has to get handled on a general purpose processor. But the announcement also states the zIIP does not process IO, nor can it handle timer events. Is there more doc available anywhere on what is involved in this part of it? Simply disabling for those interrupts. Nothing magical there. As far as timer events - I would think that it would allow a CPU time limit, but who knows. :3. If an SQL statement should happen to abend at some point in it's processing, and I'm looking at a dump, will I see activity formatted in the trace table in the dump for the zIIP? I would think so. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: SCRT questions
Background: SCRTTOOL job takes a lot of time to complete. I extract just the records and the LPARs I need with IFASMFDP. Then I run SCRT. I have found this to be faster. 1. What records are required by SCRT ? Just 70 89 for the LPARs in question. 2. Is it required to provide all the SMF records from all the LPARs ? No, just the LPARs that are running products eligible for sub-capacity licensing. I have one machine that I only run for one (of two) LPAR. I'm considering to exclude records from given LPAR(s) to save I/O. That's what I do. Sent from my BlackBerry® wireless device -- 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: Betr.: [IBM-MAIN] SCRT questions
2. Yes, all the 70's and 89's off all the lpars No. Not if an LPAR has no candidates for sub-capacity licensing. Sent from my BlackBerry® wireless device -- 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: COBOL ARITH(EXTEND) compiler option
Thanks Steve. That makes sense now when you interpret it like that. Jim McAlpine On 7/4/06, Steve Comstock [EMAIL PROTECTED] wrote: Jim McAlpine wrote: I'm looking at the Enterprise COBOL Performance Tuning paper regarding the ARITH(EXTEND) compiler option which says - | *ARITH - EXTEND or COMPAT * | The ARITH compiler option allows you to control the maximum number of digits allowed for decimal | numbers (packed decimal, zoned decimal, and numeric-edited data items and numeric literals). With | ARITH(EXTEND), the maximum number of digits is 31; with ARITH(COMPAT), the maximum number | of digits is 18. However, ARITH(EXTEND) will cause some degradation in performance for all decimal | data types due to larger intermediate results. The amount of degradation that you experience depends directly | on the amount of decimal data that you use. | Performance considerations using ARITH: | On the average, ARITH(EXTEND) was 1% slower than ARITH(COMPAT), with a range of equiv- | alent to 38% slower. | (*COB PG: *pp 37, 41, 48-49, 95, 283-284, 557-566) Can anyone say what with a range of equivalent to 38% slower means. It doesn't make sense to me. I don't even think it's English. I believe the interpretation is: The best case was some program ran at the same speed with ARITH(EXTEND) as with ARITH(COMPAT); in the worst case, some program ran 38% slower with ARITH(EXTEND) compared to running when compiled with ARITH(COMPAT). Kind regards, -Steve Comstock -- 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
Using model DSCB
Over three decades ago it was realised ... I think I remember who realised it. And how he had to beg and plead to get a test job or two run on 350/50-1. Always was a sod for the manuals. Of course, it was a little while until we cottoned on to DS1LSTAR, and even longer until we got an approved way to reset it. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- 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
Subject: Re: SCRT questions
R.S. -- Removing LPARs is not allowed by the IBM Sub-capacity TsCs. From the Attachment for zSeries Workload License Charges Z125-6516 (in the US) 2) collect, and retain for a period of not less than six months, the SMF data records for all LPARs, by Machine, required by the Sub-Capacity Reporting Tool for each Reporting Period; IBM's sub-capacity pricing is not an *LPAR* level decision, it is a *machine* level decision. If a machine is using sub-capacity pricing then the SMF70 data and the SMF89 data from all LPARs must be presented to the IBM's Sub-Capacity Reporting Tool (SCRT). If you are using Sub-Capacity, then z/OS is using sub-capacity and the LPARs must be reported. Also VM LPARs running z/OS guests and z/TPF. The SCRT does report if LPARs are missing, as one MVS system's SMF70 data has some information about the other LPARs. If you strip off the SMF 70s and the SMF89s as suggested by Nico then I find the SCRT runs fast. The SMF70s and 89s are usually not too large. Most sites keep these in a DASD datasets. Best regards, Al -- Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.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
RES: Subject: Re: SCRT questions
RS, In your SMF daily process, you can generate a separate dataset only with SMF records 89 and 70 subtype 1 per LPAR. At the end of month, this dataset will be no more than 40 cyls. We do this way, and when SCRT report runs, it takes no longer than few seconds. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto Banco Bradesco S/A 4254/DPCD Alphaville Suporte Técnico - Software Básico Mainframes Tel: 55 11 4197-2021 Fax: 55 11 4197-2814 AVISO LEGAL BR Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. +**+ LEGAL ADVICE BR This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- 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: IOCP for 2 LPARs Questions.
Howard, Errr... do NOT IPL both systems at the same time leave on up just in case you need to fix something. Ed On Jul 4, 2006, at 8:29 AM, Howard Rifkind wrote: Bingo Matt. This just about did the trick, most everything was set up correctly except for the two OS configurations which I just created and loaded into a slot. Revised the SYS1.IPLPARMS and now waiting for an IPL to see if it all shakes out. Thanks - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. -- 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: IOCP for 2 LPARs Questions.
You should always provide a backout plan to get back to where you were. Don't replace the same IODF; don't use the same IPLPARM. Or at least copy the current IPLPARM to a previous name, if you want to keep the same name for Operation's sake. I know you've gotten a few different ways to do this. I prefer have the IODF contain all of the LPAR OS Definitions. This also allows you to name Consoles the same, and CTCs the same. That's another topic that I can send you a document on how to do that, if you'd like. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Tuesday, July 04, 2006 SYSN 11:23 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IOCP for 2 LPARs Questions. Howard, Errr... do NOT IPL both systems at the same time leave on up just in case you need to fix something. Ed On Jul 4, 2006, at 8:29 AM, Howard Rifkind wrote: Bingo Matt. This just about did the trick, most everything was set up correctly except for the two OS configurations which I just created and loaded into a slot. Revised the SYS1.IPLPARMS and now waiting for an IPL to see if it all shakes out. Thanks - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. -- 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
Maintenance philosophy wasRe: Need Urgent Help, Please
On 17 Jun 2006 07:06:12 -0700, in bit.listserv.ibm-main you wrote: It is worse than that. If you set up 'automatic update' then you may not even be aware that update is happening. I think that this illustrates the difference between the windoze mentality and the mainframe mentality ... The mainframe systems programmer generally comes to accept the (paraphrased) words of the 'hippocratic oath': First, do no harm ... . I think this also relates to an earlier thread about the caution with which mainframe folks approach new experiments (vs seat-of-the-pants windoze approach). While I own IBM stock and no Microsoft stock, The problems of Microsoft are in part due to the target ownership. The majority of home computers are owned and used by people who are using them as tools to get something done. They are not computer professionals and would have a hard time dealing with multiple copies of the operating environment. It only is within a relatively short time that enough disk space has been available to do such a thing and the setup could be interesting. The automatic install of fixes may be the best option for the majority of users since they have neither the time nor the inclination to read the description of the updates. The only thing I really dislike about their practice of trying to force automatic after you have selected notify or download and notify. I also resent the Genuine advantage fix which has the potential for fouling my system and gives me no advantage. Given the various maintenance philosophies available from the various Linux support organizations, the other IBM operating environments and Microsoft, an overall study of these methodologies should be done to see what improvements are worth carrying into the z/OS environment. One of the things that can be done to improve reliability in all of the environments is to add or improve the means of updating system parameters (PARMLIBs for z/OS, the registry for Windows *.*, etc.). While my experience is before the Health Checker, I am hopeful that this is a good first step. All of the environments need to be easier and safer to manage. Date:Fri, 16 Jun 2006 10:58:10 -0500- From:=?iso-8859-1?Q?Tim_Henness?= [EMAIL PROTECTED] Subject: Re: Need Urgent Help, Please On Thu, 15 Jun 2006 16:06:48 -0700, Gibney, Dave [EMAIL PROTECTED] wrote: As always, you're playing with fire if APPLYING to the live system datasets. You mean like Windoze does? Date:Fri, 16 Jun 2006 11:18:37 -0500 From:=?iso-8859-1?Q?Tom_Schmidt?= [EMAIL PROTECTED] Subject: Re: Need Urgent Help, Please On Fri, 16 Jun 2006 10:58:10 -0500, Tim Henness wrote: On Thu, 15 Jun 2006 16:06:48 -0700, Gibney, Dave wrote: As always, you're playing with fire if APPLYING to the live system datasets. You mean like Windoze does? Exactly!! Like Windoze *did* to my formerly working PC at home, in fact. (Now I get to reinstall since it won't boot due to the damage Windoze did to its SYSTEM/CONFIG directory.) It is a baad idea on pretty much any system that 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: IOCP for 2 LPARs Questions.
Done that, Yep, forgot to mention that we IPLed the Production first and left the Test lpar for last. Thanks. BTW it all worked and a big thanks to all for your help. Ed Gould [EMAIL PROTECTED] wrote: Howard, Errr... do NOT IPL both systems at the same time leave on up just in case you need to fix something. Ed On Jul 4, 2006, at 8:29 AM, Howard Rifkind wrote: Bingo Matt. This just about did the trick, most everything was set up correctly except for the two OS configurations which I just created and loaded into a slot. Revised the SYS1.IPLPARMS and now waiting for an IPL to see if it all shakes out. Thanks - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. -- 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 - Want to be your own boss? Learn how on Yahoo! Small Business. -- 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
MVS Commands
Is there any MVS command that will display what type of 3390 device (mod3 or mod9 etc) that is at a particular address. Thanks - Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta. -- 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: MVS Commands
DS P,unit# -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Tuesday, July 04, 2006 4:01 PM To: IBM-MAIN@BAMA.UA.EDU Subject: MVS Commands Is there any MVS command that will display what type of 3390 device (mod3 or mod9 etc) that is at a particular address. Thanks - Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta. -- 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: MVS Commands
Thanks Jay Campbell Jay [EMAIL PROTECTED] wrote: DS P,unit# -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Tuesday, July 04, 2006 4:01 PM To: IBM-MAIN@BAMA.UA.EDU Subject: MVS Commands Is there any MVS command that will display what type of 3390 device (mod3 or mod9 etc) that is at a particular address. Thanks - Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta. -- 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 - Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better. -- 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: MVS Commands
In a message dated 7/4/2006 3:01:29 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Is there any MVS command that will display what type of 3390 device (mod3 or mod9 etc) that is at a particular address. I like ===DS QD,,xxx,validate where is address xxx is for xxx devices ===DS QD,? gives the whole litany I think. -- 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
Help with TCB status
Hello everyone, I have an SRB that is scheduled to run in a target address space. The SRB attempts to determine the status (wait, active and ready) of all TCBs from job step down. The SRB holds the local lock before attempting to check the status. I'm trying to figure out a couple of things: 1) How can the SRB determine if the TCB is ready to execute (i.e. dispatchable)? 2) What other things besides the TCBACTIV bit, must be tested in order to know if a TCB is active?. I found an old post (cached on Google from IBM- MAIN dated 10Sep1999) that says the following... ...Don't assume anything about TCBACTIV. The entire picture of a task's dispatchability is incredibly volatile and (paraphrasing Alice) you have to look at several unbelievable things at once to get the full picture. Fortunately the dispatcher is the only guy who really needs to and he's twisted anyway ... Any help would be greatly appreciated. Thanks, Vic -- 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: MVS Commands
Thanks Ed. Ed Finnell [EMAIL PROTECTED] wrote: In a message dated 7/4/2006 3:01:29 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Is there any MVS command that will display what type of 3390 device (mod3 or mod9 etc) that is at a particular address. I like ===DS QD,,xxx,validate where is address xxx is for xxx devices ===DS QD,? gives the whole litany I think. -- 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 - Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better. -- 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: Help with TCB status
I have an SRB that is scheduled to run in a target address space. The SRB attempts to determine the status (wait, active and ready) of all TCBs from job step down. The SRB holds the local lock before attempting to check the status. I'm trying to figure out a couple of things: 1) How can the SRB determine if the TCB is ready to execute (i.e. dispatchable)? 2) What other things besides the TCBACTIV bit, must be tested in order to know if a TCB is active?. I found an old post (cached on Google from IBM- MAIN dated 10Sep1999) that says the following... ...Don't assume anything about TCBACTIV. The entire picture of a task's dispatchability is incredibly volatile and (paraphrasing Alice) you have to look at several unbelievable things at once to get the full picture. Fortunately the dispatcher is the only guy who really needs to and he's twisted anyway ... Unfortunately, it's like Einstein's cat. You can only know the state of the system by observing it and in making the observation you gain some information and lose other information. You literally cannot know for sure and there is no lock you can hold to prevent the state from changing on other cpus while you're dinking around. Even the dispatcher doesn't have that power. At best you can determine by sampling each of the cpus to see whether a TCB of interest is dispatched on that cpu at the time you looked - which is essentially tourist information because the state may have changed on the next clock cycle. If you were trying to make some sort of statistical determination (which is what certain monitoring products actually do btw) then you might get something of value, but if you wanted a deterministic answer then forget it. The comments you referenced (above) are correct. What is so important that you (think you) need to know about the dispatchability of ANY unit of work (TCB or SRB) other than your own? CC -- 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: Wild branch tracing
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/04/2006
09:13:33 AM:
z/OS 1.7 and the Z9 provide a wild branch value ('branch from' in the
SDWA). Does anyone know if this will be available for any previous z/OS.
It will not.
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: Wild branch tracing
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/04/2006 09:52:08 AM: Based branches aren't traced either. What you get are subroutine calls made via BALR, BASR, BASSM, etc. Unfortunately, you also get mode switches to/from 64-bit mode. (IMHO it was a poor design choice to not separate the two.) You'd better have whopping big trace tables because, with branch tracing enabled, RSM will chew up a significant portion of it with all of their mode switching to/from 64-bit mode. A complete 64-bit RSM implementation will eventually do away with that craziness. z/OS 1.8 RSM runs mainly in 64-bit addressing mode, so that should reduce the mode switching. Mode and Branch trace enabling may get separated in the next release after z/OS 1.8. 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
