Re: How to format the current linkage stack for a SLIP dump taken in SRB mode?
Barbara Nitz wrote: First, as Ed pointed out, an SSRB will only be generated when the SRB has to wait for something like a lock or get willingly suspended. The reason Tom has only seen ssrbs in his dumps may well be that they're scheduled with the local lock (or some other lock) held, and that isn't available when the srb is supposed to get dispatched. In that case, without having executed a single instruction, it gets suspended with an SSRB. I repeat: There aren't necessarily SSRBs for *every* SRB. And as far as I know, an SRB does not get automatically suspended just because the PER hardware detects a hit. Binyamin says that he cannot find the SRB anymore. Here's my guess what happened: [analysis snipped] SRBs were never intended to be heavy duty work units. Compared to what most developers are used to with TCBs, their flexibility, recoverability, resiliency and overall capabilities are sorely lacking -- as is the quality of point-in-time and trace diagnostic information captured for/about them. IBM's decision to allow only enclave SRBs to run on zIIPs is the primary reason so many developers are working with SRBs lately. In some very important ways, our bullet proof platform is regressing. The more SRB mode code that is written, the more fragile z/OS becomes. And, based on what (little) I know about development plans at other software companies, things will only get worse from here ... On the bright side, people developing brand new SRB-mode infrastructures get lots of hands-on practice with taking SADUMPs and IPLing their systems. What fun! :-) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sort order for Generic processing
Okay, My first choice was originally to sort the generics last, and since it's good enough for RACF, it's good enough for me. I wrote a little routine to test the processing out and found that my sort routine can sort between 2 and 1,000 entries fast enough that I can't tell the difference between sorting and not sorting the array. So I guess there is no reason to limit the array to 1,000 entries. Thank you very much for your opinions on this, it was driving me nuts with not being able to decide one way or the other. Thanks again, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to check if a job has run?
As I previously indicated, the code I have doesn't need to go after every step, it just goes at the end of the JOB. The output (JOB step CC's ) gets emailed to wherever you want. You could use IEFACTRT exit as was indicated, the overhead is trivial (zero if you decide not to do anything) if you decide not to do anything, and if you wanted to use a JES exit the overhead again is trivial. Brian -- 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
SRBs and sadump, was: Re: How to format the current linkage stack for a SLIP dump taken in SRB mode
Ed, On the bright side, people developing brand new SRB-mode infrastructures get lots of hands-on practice with taking SADUMPs and IPLing their systems. What fun! :-) You mean we have to expect more questions about sadumps on ibm-main? :-) The type that says 'the necessary data are not in the sadump' ? Who gets to analyze this nice type of dumps? (After all, you don't have to think about timing issues when looking at them, right? Nothing can change anymore once the sadump has been started...) Barbara -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Need Certification exam info on Mainframe Sysprog/RACF
Thanks Mirtha! Valuable Information. Regards, Mani -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mirtha Quattrochi Sent: Tuesday, April 08, 2008 7:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Need Certification exam info on Mainframe Sysprog/RACF Mani: you can check the following from IBM website: http://www-03.ibm.com/certify/mastery_tests/ovrZ01.shtml http://www-03.ibm.com/certify/certs/21002102.shtml Regards, Mirtha. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Sivakumar, Manikandan Sent: April 8, 2008 6:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Need Certification exam info on Mainframe Sysprog/RACF Greetings ! I would appreciate if your provide information on any Mainframe System programming/RACF certification currently available. Thank you all. Regards, Mani The information contained in this transmission may contain privileged and confidential information and is intended only for the use of the person(s) named above. If you are not the intended recipient, any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you received this email in error, please contact the sender immediately by reply e-mail and destroy all copies of the original message. This email is not intended as an offer or solicitation for the purchase or sale of any financial instruments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z800 to z9 migration
I don't know whethe SAPR covers it or not, but I'd like to remind about cyrptography. If you use ICSF and crypto features, be prepared for big change. Depending on your system level you could have to download new ICSF FMID. You won't find it in any set of PSP bucket or other sources covering migration to z/999 or z9. Crypto is out of scope. BTDT. -- 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.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to format the current linkage stack for a SLIP dump taken in SRB mode?
On Wed, 9 Apr 2008 01:15:59 -0400 Craddock, Chris [EMAIL PROTECTED] wrote: :Barbara Nitz writes a nicely detailed summary snipped : In that case no amount of summ format will get you the exact linkage :stack : formatted automatically, as far as I know (unless the SRB abended and :SRB- : to-task percolation was done, I think). :Linkage stacks get used and reused with such high frequency that :formatting a linkage stack that is not actively in use and/or whose user :is not currently suspended is a futile exercise. SLIP absolutely should SUMLIST the linkage stack for the current UOW. Is a requirement required? -- 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: How to format the current linkage stack for a SLIP dump taken in SRB mode?
On Wed, 9 Apr 2008 07:07:32 +0200 Barbara Nitz [EMAIL PROTECTED] wrote: :First, as Ed pointed out, an SSRB will only be generated when the SRB has to wait for something like a lock or get willingly suspended. The reason Tom has only seen ssrbs in his dumps may well be that they're scheduled with the local lock (or some other lock) held, and that isn't available when the srb is supposed to get dispatched. In that case, without having executed a single instruction, it gets suspended with an SSRB. :I repeat: There aren't necessarily SSRBs for *every* SRB. And as far as I know, an SRB does not get automatically suspended just because the PER hardware detects a hit. :Binyamin says that he cannot find the SRB anymore. Here's my guess what happened: Not at all. There is no SRB to find as the SRB block only exists while it is on a queue. Once dispatched it is simply data. The registers are consistent with the point of the trap. :That SRB was running on a processor when the slip hit. The PER interrupt basically only saves the summary information from that *somewhere*. By the time slip got around to scheduling the actual dump request, that SRB had already run to completion and wasn't 'current' anymore, as in it wasn't in any dispatching queue with it's original storage freed and gone as far as MVS is concerned. In that case it will not be shown via summ format which 'only' formats (towards the top) S/SRBs from the global queues, then below the ASCB of the address space S/SRBs from the (address space) local queues. The dump nevertheless will show (from the summary data as captured somewhere when the trap hit) what the storage looked like at the point the trap hit. (Here status cpu registers is your friend.) I certainly would hope that the system automatically SUMLISTs the linkage stacks. Does the SLIP SL operand support indirect address off of control registers? :In that case no amount of summ format will get you the exact linkage stack formatted automatically, as far as I know (unless the SRB abended and SRB-to-task percolation was done, I think). Actually, CBF of the CR15 value did format it. -- 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: How to format the current linkage stack for a SLIP dump taken in SRB mode?
Binyamin, Not at all. There is no SRB to find as the SRB block only exists while it is on a queue. Once dispatched it is simply data. The registers are consistent with the point of the trap. I believe that I said that. My explanation wasn't really for you, it was more for those that kept telling you to look for an SSRB. Actually, CBF of the CR15 value did format it. And that was NOT done via summary format command *automatically*, but by actually typing in an address and provide IPCS a clue how to format it. I certainly would hope that the system automatically SUMLISTs the linkage stacks. It does, doesn't it? You were able to cbf it. Is the content inconsistent with what you hoped to see? What prompts the ongoing enquiry after Jim provided the command? Does the SLIP SL operand support indirect address off of control registers? No clue. Your guess looking at the slip command is as good as mine. Barbara Nitz -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VS: z/OS-MVS Control Block Layout - Offsets
A dream of mine was to start a shared documentation project someplace like sourceforge so anyone could contribute. Or maybe an MVS control block wiki. That idea was shot down straight away. (-: -Alkuperäinen viesti- Lähettäjä: IBM Mainframe Discussion List puolesta: Rob Scott Lähetetty: ti 8.4.2008 18:26 Vastaanottaja: IBM-MAIN@BAMA.UA.EDU Aihe: Re: z/OS-MVS Control Block Layout - Offsets Pipe dream of mine was to produce a z/OS version in Visio and hand it out free with MXI G2 licenses - maybe someday... Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Modify DSCB information
Is it possible to change the DSCB information of allocated dataset through some utility ? Like changing Primary / Secondary quantity ? Expiry Date etc. JAcky -- 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: Modify DSCB information
Jacky, It depends on what you want to change and the reason for the change. Is this to prevent space abends or some other reason? If the items are controlled by DFSMS (Storclas, Mgmtclass, etc.) you can use the ISMF panels to alter a data set. If it is things in a LISTCAT you can see if IDCAMS can help. Depending on how the data set is allocated at the time, some things may work and some may not. As for space allocation, for VSAM use IDCAMS (so long as the correct SHAREOPTIONS are in use), for NONVSAM you will need to have control over the data set. Products like the old STOPX37 would intercept allocation process and add volumes or increase space to prevent (or reduce) SX37 Abends. Lizette Is it possible to change the DSCB information of allocated dataset through some utility ? Like changing Primary / Secondary quantity ? Expiry Date etc. -- 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: Modify DSCB information
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Wednesday, April 09, 2008 7:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Modify DSCB information Jacky, It depends on what you want to change and the reason for the change. Is this to prevent space abends or some other reason? If the items are controlled by DFSMS (Storclas, Mgmtclass, etc.) you can use the ISMF panels to alter a data set. If it is things in a LISTCAT you can see if IDCAMS can help. Depending on how the data set is allocated at the time, some things may work and some may not. As for space allocation, for VSAM use IDCAMS (so long as the correct SHAREOPTIONS are in use), for NONVSAM you will need to have control over the data set. Products like the old STOPX37 would intercept allocation process and add volumes or increase space to prevent (or reduce) SX37 Abends. Lizette Is it possible to change the DSCB information of allocated dataset through some utility ? Like changing Primary / Secondary quantity ? Expiry Date etc. -- 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: Modify DSCB information
There is an old program on the CBT Tape (DMOD) that can change many F1 DSCB attributes. I don't know if anyone has updated it for SMS. I last used this Program in the early 90's. HTH, snip Is it possible to change the DSCB information of allocated dataset through some utility ? Like changing Primary / Secondary quantity ? /snip -- 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: Modify DSCB information
- Original Message - From: Jacky Bright [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, April 09, 2008 8:28 AM Subject: Modify DSCB information Is it possible to change the DSCB information of allocated dataset through some utility ? Like changing Primary / Secondary quantity ? CDSCB at www.cbttape.org. -- 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
undertones of ??
I have been reading thru the thread with Shai Hess. I would ask group at large to be somewhat tempered in their responses. I am perceiving a mean-spirited undertone to some of the responses. Please allow for the mistakes of those that are at least attempting to understand and engender technologies that cross platforms and include Z. Thanks for reading, Rob Schramm -- 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: (fwd) Re: Is IT becoming extinct?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Arellanes Sent: Wednesday, April 09, 2008 12:21 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: (fwd) Re: Is IT becoming extinct? I gotta ask this, hope you don't mind. Why is the code generation for fullword binary so weird? Try TRUNC(OPT), you will get: LH2,14(0,10) PGMLIT AT +10 A 2,0(0,8)MYDATA ST2,0(0,8)MYDATA See the COBOL Performance Tuning paper at http://www- 306.ibm.com/software/awdtools/cobol/library/ for more info on the TRUNC compiler option, as well as the performance implications of using the various suboptions of TRUNC. Rick Arellanes (IBM COBOL Development and Performance) Thanks. COBOL really confuses me at times. I'm going to double check what our TRUNC option is. On my 3.4.1 compile, I guess since I used a literal, I got the code: LA5,1(0,0) A 5,0(0,2)MYDATA ST5,0(0,2)MYDATA -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sequential Data Striping
On Tue, 2008-04-08 at 19:40 +, Ted MacNEIL wrote:
FILTLIST EXTCLASS INCLUDE('SMSCOMP','SMSEXT')
Why do you put the SMS prefix in the class names?
We already know they are SMS constructs.
I've got a *really* simple setup here, a single Iceberg on a system
small enough that many of you folks would use it to initialize tapes.
Not bleeding edge, and not with a huge staff. Our entire systems staff
is me (and I do some IDMS stuff too).
Test entries excluded, I've only got two data classes: NONSMS and
SMSxxx. We're mostly SMS-managed nowadays, but I took my time walking
applications and users over, inch by inch, bit by bit. Having SMS in
the class names was meaningful to me at the time, and because nobody
else sees them it's no big deal. It's not like I have a namespace
issue, so I leave well enough alone.
Hey, you *did* ask!
--
David Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL)
Hi, I am getting this error submitting a job. The job is a simple logrec format and previously worked. How could we go over this? Thanks fabio D'Alfonso -- 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: Modify DSCB information
what about Expiry date of dataset ? Can it be changed ? JAcky On 4/9/08, Pinnacle [EMAIL PROTECTED] wrote: - Original Message - From: Jacky Bright [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, April 09, 2008 8:28 AM Subject: Modify DSCB information Is it possible to change the DSCB information of allocated dataset through some utility ? Like changing Primary / Secondary quantity ? CDSCB at www.cbttape.org. -- 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: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL)
Ah, we would need a little bit more than that to answer your question. Perhaps the JCL job log? On Wed Apr 9 15:20 , Fabio D'Alfonso [EMAIL PROTECTED] sent: Hi, I am getting this error submitting a job. The job is a simple logrec format and previously worked. How could we go over this? Thanks fabio D'Alfonso -- 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
SPFEDIT does a RESERVE!?!
This came as a shock to me. We just went to a basic sysplex, splitting a single image into two images. We just had a lockup occur between the two images. This was caused because SPFEDIT does a RESERVE on the volume during a save operation. OK, mea culpa, for not reading every word of all the manuals where it is mentioned. The problem came up due to a package called Data Accelerator, which does on-the-fly compression of VSAM and non-VSAM files. What appears to have happened is that a TSO user does a SAVE on one system. Coincidentally just a bit after this (I think) Data Accelerator on the other system attempts a RESERVE on its control file, which happens to be on the same volume. This hangs Data Accelerator on the second system. But, part of the SAVE operation on the first system invokes Data Accelerator to see if the file is compressed, requiring access to the control file which the second system has hung up on. Now both systems are hung up in Data Accelerator. This eventually hangs up every OPEN and CLOSE on both systems until I figure out what is going on (about 5 minutes once I'm informed of a problem). The resolution: Put SPFEDIT in the conversion RNL. Also, put BMCBCSS in the reserve conversion RNL as well. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL)
Looking at the SYS1.LOGREC should be in uppercase Edouard A. Myers Acting Manager of Technical Services Office of the Chief Technology Officer DC Government 222 Massachusetts Ave, NW, Suite 200 Washington, DC 20001 Phone : 202-727-4017 Fax: 202-727-3880 Email: [EMAIL PROTECTED] Website: http://www.octo.dc.gov -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Fabio D'Alfonso Sent: Wednesday, April 09, 2008 9:57 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL) Hi this is the job //STEP1EXEC PGM=IFCDIP00 //SERERDS DD DSN=sys1.logrec, // DISP=SHR on console there is a IEFC452I JOB NOT RUN Best Regards Fabio D'Alfonso Ah, we would need a little bit more than that to answer your question. Perhaps the JCL job log? On Wed Apr 9 15:20 , Fabio D'Alfonso [EMAIL PROTECTED] sent: Hi, I am getting this error submitting a job. The job is a simple logrec format and previously worked. How could we go over this? Thanks fabio D'Alfonso -- 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 -- 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: Modify DSCB information
On Wed, 9 Apr 2008 13:28:13 +0100 Jacky Bright [EMAIL PROTECTED] wrote: :Is it possible to change the DSCB information of allocated dataset through :some utility ? Like changing Primary / Secondary quantity ? :Expiry Date etc. Well, there is always AMASPZAP against the VTOC. But there are many that will change if you specify them in the JCL and open for output. -- 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: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL)
If that is the EXACT JCL you submitted, the lower case characters in the DSN would cause a JCL error. Try converting them to upper case and resubmitting. On Wed Apr 9 15:57 , Fabio D'Alfonso [EMAIL PROTECTED] sent: Hi this is the job //STEP1EXEC PGM=IFCDIP00 //SERERDS DD DSN=sys1.logrec, // DISP=SHR on console there is a IEFC452I JOB NOT RUN Best Regards Fabio D'Alfonso Ah, we would need a little bit more than that to answer your question. Perhaps the JCL job log? On Wed Apr 9 15:20 , Fabio D'Alfonso [EMAIL PROTECTED] sent: Hi, I am getting this error submitting a job. The job is a simple logrec format and previously worked. How could we go over this? Thanks fabio D'Alfonso -- 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 -- 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: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL) [EMAIL PROTECTED]
But nothing changed . On Wed, 9 Apr 2008 10:00:33 -0400 Rob Scott [EMAIL PROTECTED] wrote: :Try using uppercase for the dataset name :-Original Message- :From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Fabio D'Alfonso :Sent: 09 April 2008 14:57 :To: IBM-MAIN@BAMA.UA.EDU :Subject: Re: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL) :Hi this is the job ://STEP1EXEC PGM=IFCDIP00 ://SERERDS DD DSN=sys1.logrec, :// DISP=SHR :on console there is a IEFC452I JOB NOT RUN : Ah, we would need a little bit more than that to answer your question. : Perhaps the JCL job log? : On Wed Apr 9 15:20 , Fabio D'Alfonso : [EMAIL PROTECTED] : sent: :Hi, :I am getting this error submitting a job. :The job is a simple logrec format and previously worked. :How could we go over this? -- 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: SPFEDIT does a RESERVE!?!
John If you haven't seen it already, ISPF enqueues are mentioned explicitly in the z/OS MVS Planning : GRS manual - there are cases where exclusion RNL is warranted and it also explains how SPFEDIT lives with SYSDSN. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: 09 April 2008 14:59 To: IBM-MAIN@BAMA.UA.EDU Subject: SPFEDIT does a RESERVE!?! This came as a shock to me. We just went to a basic sysplex, splitting a single image into two images. We just had a lockup occur between the two images. This was caused because SPFEDIT does a RESERVE on the volume during a save operation. OK, mea culpa, for not reading every word of all the manuals where it is mentioned. The problem came up due to a package called Data Accelerator, which does on-the-fly compression of VSAM and non-VSAM files. What appears to have happened is that a TSO user does a SAVE on one system. Coincidentally just a bit after this (I think) Data Accelerator on the other system attempts a RESERVE on its control file, which happens to be on the same volume. This hangs Data Accelerator on the second system. But, part of the SAVE operation on the first system invokes Data Accelerator to see if the file is compressed, requiring access to the control file which the second system has hung up on. Now both systems are hung up in Data Accelerator. This eventually hangs up every OPEN and CLOSE on both systems until I figure out what is going on (about 5 minutes once I'm informed of a problem). The resolution: Put SPFEDIT in the conversion RNL. Also, put BMCBCSS in the reserve conversion RNL as well. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM announcements
I was thinking more along the lines of a local (z/OS based web) interface instead of the current ISPF dialogs. Ken -Original Message- Shane Ken Porowski wrote: Does this mean that things like ServerPac dialogs are going the way of the web? Gawd I hope not. It took about 6 years to get Link2000 to the AP region. And how many complaints about the (web) IBMLink have there been in the last couple of years ???. Ugh. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM announcements
Ken Porowski wrote: I was thinking more along the lines of a local (z/OS based web) interface instead of the current ISPF dialogs. Ken Exactly! -Original Message- Shane Ken Porowski wrote: Does this mean that things like ServerPac dialogs are going the way of the web? Gawd I hope not. It took about 6 years to get Link2000 to the AP region. And how many complaints about the (web) IBMLink have there been in the last couple of years ???. Ugh. Shane ... Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == call or email to receive a free sample student handout == -- 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: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL)
On Wed, 2008-04-09 at 15:20 +0200, Fabio D'Alfonso wrote: The job is a simple logrec format and previously worked. On Wed, 2008-04-09 at 15:57 +0200, Fabio D'Alfonso wrote: //STEP1EXEC PGM=IFCDIP00 //SERERDS DD DSN=sys1.logrec, // DISP=SHR This job previously worked with a lowercase dsname? Curious. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL)
It's easy enough to have an exit convert all JCL lines to upper case. Maybe their shop did that. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews Sent: Wednesday, April 09, 2008 8:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL) On Wed, 2008-04-09 at 15:20 +0200, Fabio D'Alfonso wrote: The job is a simple logrec format and previously worked. On Wed, 2008-04-09 at 15:57 +0200, Fabio D'Alfonso wrote: //STEP1EXEC PGM=IFCDIP00 //SERERDS DD DSN=sys1.logrec, // DISP=SHR This job previously worked with a lowercase dsname? Curious. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM announcements
On Wed, 2008-04-09 at 10:09 -0400, Ken Porowski wrote: I was thinking more along the lines of a local (z/OS based web) interface instead of the current ISPF dialogs. A poorly designed (web) interface is a poorly designed interface. What gives you faith it will be any better designed just because it remains within a LAN ???. My sceptosity level remains elevated until disproved. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SPFEDIT does a RESERVE!?!
Welcome to the wonderful world of shared DASD. You ain't seen nutin' yet :-) Such reserves and enqueues abound. That's the only way you can keep multiple updaters from corrupting data. It also changes things. For example, in a shared DASD environment, you might find that Data Accelerator might actually degrade performance to an unacceptable level. From your description, every open is serialized across the sysplex and includes a enqueue/reserve that has a good potential for waiting on the other LPAR. Why not simply convert all reserves? One reason is that reserve is fast and cheap. An enqueue involves a negotiation with all interested parties over a commutations Link. Can be v e r y s l o w. By the way, the term to use is 'deadly embrace'. Just wait till you see the long chains: A waiting on B waiting on C waiting on D waiting on A. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, April 09, 2008 8:59 AM To: IBM-MAIN@BAMA.UA.EDU Subject: SPFEDIT does a RESERVE!?! This came as a shock to me. We just went to a basic sysplex, splitting a single image into two images. We just had a lockup occur between the two images. This was caused because SPFEDIT does a RESERVE on the volume during a save operation. OK, mea culpa, for not reading every word of all the manuals where it is mentioned. The problem came up due to a package called Data Accelerator, which does on-the-fly compression of VSAM and non-VSAM files. What appears to have happened is that a TSO user does a SAVE on one system. Coincidentally just a bit after this (I think) Data Accelerator on the other system attempts a RESERVE on its control file, which happens to be on the same volume. This hangs Data Accelerator on the second system. But, part of the SAVE operation on the first system invokes Data Accelerator to see if the file is compressed, requiring access to the control file which the second system has hung up on. Now both systems are hung up in Data Accelerator. This eventually hangs up every OPEN and CLOSE on both systems until I figure out what is going on (about 5 minutes once I'm informed of a problem). The resolution: Put SPFEDIT in the conversion RNL. Also, put BMCBCSS in the reserve conversion RNL as well. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JOB00045 $HASP165 IBMUSERB ENDED AT N1 - JCL ERROR CN(INTERNAL)
If you post the jcl with error messages it would help. Basically you go to the JES Messages section and find the reason for the JCL error. JCL does a decent job of telling you why you got the error. The JES Messages is the third Data set on SPOOL. First is JOBLOG, Second is JCL with Expansions, then third the JES Messages. Lizette Hi, I am getting this error submitting a job. The job is a simple logrec format and previously worked. How could we go over this? -- 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: (fwd) Re: Is IT becoming extinct?
Hmmm, are we comparing languages a little bit here? When I was an undergraduate student at Ga. Tech (many years ago) the school computer was a Burroughs 5500. When I went back for my Masters in Computer Science that machine was the Computer Science Department's play toy. It was an interesting machine since it had plug-n-play before plug-n-play. You'd create a small gen with necessary devices like the card reader and punch. Then when you IPL'd the system would just look around to determine what other devices were attached to it. The language used was ALGOL. In fact the operating system itself was written in ALGOL. I always felt that it was a very powerful language and was sorry it didn't catch on better. Tom Kelman Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, April 08, 2008 3:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: (fwd) Re: Is IT becoming extinct? PL/1 is the UnCOBOL When I was a UofW student in the mid-1970's, they offered a PL/I course, but (for some reason) it was a non-credit course for Math/CS students. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: Modify DSCB information
Jacky, If you have SimpList installed you can select a data set from any object list or DSLIST using 'I' for Information. All of the data set attributes are displayed, including things like SMS attributes and expiry date (etc). Any of the displayed attributes can be changed by simply tabbing down and entering new values. For example, you can change the DSORG, primary/secondary allocation, number of directory blocks, record length, blocksize, expiry date (etc). HTH, Dave SaltSee the new SimpList(tm) rollover image at: http://www.mackinney.com/products/SIM/simplist.htmDate: Wed, 9 Apr 2008 14:03:41 +0100 From: [EMAIL PROTECTED] Subject: Re: Modify DSCB information To: IBM-MAIN@BAMA.UA.EDU what about Expiry date of dataset ? Can it be changed ? JAcky On 4/9/08, Pinnacle [EMAIL PROTECTED] wrote: - Original Message - From: Jacky Bright [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, April 09, 2008 8:28 AM Subject: Modify DSCB informationIs it possible to change the DSCB information of allocated dataset through some utility ? Like changing Primary / Secondary quantity ? CDSCB at www.cbttape.org. -- 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 _ Turn every day into $1000. Learn more at SignInAndWIN.ca http://g.msn.ca/ca55/213 -- 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
Problem with CA-1
Hi Everyone, We are having a problem with CA-1 which CA believes is not a CA problem. We are trying to upgrade from v11 to v11.5. When we implement the v11.5 we have the following problems. The first is a problem with multiple files on a tape. When it complete the 4th file, we get the following error. The exact JCL works file on our system once we back out the new version of CA-1. This appears to maybe be some type of option that allows it to stack more than 4 files on a tape, but haven't been able to track it down. IEC205I TAPE,JBACKSM1,SMFD16,FILESEQ=0004, COMPLETE VOLUME LIST, 818 DSN=JCC1.BACKUP.SMFD16.G1181V00,VOLS=J00414,TOTALBLOCKS=38033 -JBACKSM1 SMFD16 00 41255 151K.03.032.7 469K 0 0 0 0 0 -JBACKSM1 B4BOMB IEFPROC FLUSH 0 0.00.00 .0 0 0 0 0 0 0 IEC999I IFG019CA,JBACKSM1,SMFD17 IEF196I TMSSMF06W END OF DSNB CHAIN REACHED TMSSMF06W END OF DSNB CHAIN REACHED IEF196I TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 -JBACKSM1 SMFD17 08 58 15.00.00 .4 2414 0 0 0 0 0 The next problem we had was where the job called for a scratch tape, the scratch tape was mounted (see the tape inquiry info below says it's a scratch tape) M00605 VOLSER=M00605 VOLSER=M00605 DSN=MEP001.BACKUP.MO75FC.CYC8072 EXPDT=2008/093 ACCT=HEXZEROS SMSMC=BLANKSFLAG1=44=(CLO,SCR) HOOKID=FE= FLAG2=40=(OUT) CTLGCNT=000 BATCHID=54=TMSSCR FLAG3=00 FLAG5=00 USERID=TMSUSER FLAG4=00 DSN17=UP.M147FC.CYC8072 LJOB=MEP001CC LDATE=2008/073 LPGM=ADRDSSU LUNIT=057A LTIME=0649 CJOB=MEP001CC CDATE=2008/073 CPGM=ADRDSSU CUNIT=057A CTIME=0446 CSTEP=DUMP1CDDNAME=TAPE01 BLKCNT=00 ROBTY=00 COMPRES=078 LABEL=SL DEN=3590 TRTCH=256TROBID=000 TRERRC=0 RECFM=ULRECL=00 BLKSIZE=00EDMID=BLANKS TWERRC=0 NUMDSNB= 1STDSNB=000 LSTDSNB=000 ACTVOL= PRERRC=0 1STVOL=NEXTVOL= PREVVOL= VOLSEQ=0002 PWERRC=0 COUNT=00209VENDOR=BLANKSBTHDATE=2007/115 VOLPERC=024 TRERRI=0 USECLN=00201 CLNCNT=013 DATECLN=2008/072 FILPERC=002 TWERRI=1 OUTCODE=BLANKS SLOT=000 OUTDATE=ZEROS CPUID=JCC1 PRERRI=0 AUTIME=0427AUCODE=00AUDATE=2008/093 AUFLAG1=00 PWERRI=0 *** SCRATCH TAPE *** INQUIRY COMPLETE Here is the error we got: MO14FC.CYC8093 IEC151I A13-08,IFG0195B,MEP001CO,DUMP1,TAPE16,0570,M00605,MEP001.BACKUP. M102FC.CYC8093 IEF196I TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE IEF196I TMSSMF30I VOL=M00605, FSEQ=0001, IEF196I DSN=MEP001.BACKUP.MO00FC.CYC8093 TMSSMF30I VOL=M00605, FSEQ=0001, DSN=MEP001.BACKUP.MO00FC.CYC8093 -MEP001CO DUMP108597276.00.001.7 The error message says: 08The requested file sequence number is less than that of the first file on the SL or AL tape during an open to the start of the file. Probable user error. Check the file sequence number and volume serial numbers. We have verified this was not a user error. For some reason it appears that the new CA-1 was reading the old tape label even though it was a scratch tape. (we do not reinit the tapes before putting them in scratch status) Does anyone know if we missed some options somewhere that is causing this? Both these problems go away when we go back to the old version. Thanks, Mary Mary J. Yukus IT Specialist - Lead Systems Programmer HQ US Military Entrance Processing Command J6/MIT-System Support Branch 2834 Green Bay Road North Chicago, IL 60064-3057 Work: 847-688-3680 x7274 Work Cell: 224-627-6017 DSN: 792-7274 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problem with CA-1
Problem # 2 is VOLSEQ=0002 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Yukus, Mary J CIV USMEPCOM Sent: Wednesday, April 09, 2008 11:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Problem with CA-1 Hi Everyone, We are having a problem with CA-1 which CA believes is not a CA problem. We are trying to upgrade from v11 to v11.5. When we implement the v11.5 we have the following problems. The first is a problem with multiple files on a tape. When it complete the 4th file, we get the following error. The exact JCL works file on our system once we back out the new version of CA-1. This appears to maybe be some type of option that allows it to stack more than 4 files on a tape, but haven't been able to track it down. IEC205I TAPE,JBACKSM1,SMFD16,FILESEQ=0004, COMPLETE VOLUME LIST, 818 DSN=JCC1.BACKUP.SMFD16.G1181V00,VOLS=J00414,TOTALBLOCKS=38033 -JBACKSM1 SMFD16 00 41255 151K.03.032.7 469K 0 0 0 0 0 -JBACKSM1 B4BOMB IEFPROC FLUSH 0 0.00.00 .0 0 0 0 0 0 0 IEC999I IFG019CA,JBACKSM1,SMFD17 IEF196I TMSSMF06W END OF DSNB CHAIN REACHED TMSSMF06W END OF DSNB CHAIN REACHED IEF196I TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 -JBACKSM1 SMFD17 08 58 15.00.00 .4 2414 0 0 0 0 0 The next problem we had was where the job called for a scratch tape, the scratch tape was mounted (see the tape inquiry info below says it's a scratch tape) M00605 VOLSER=M00605 VOLSER=M00605 DSN=MEP001.BACKUP.MO75FC.CYC8072 EXPDT=2008/093 ACCT=HEXZEROS SMSMC=BLANKSFLAG1=44=(CLO,SCR) HOOKID=FE= FLAG2=40=(OUT) CTLGCNT=000 BATCHID=54=TMSSCR FLAG3=00 FLAG5=00 USERID=TMSUSER FLAG4=00 DSN17=UP.M147FC.CYC8072 LJOB=MEP001CC LDATE=2008/073 LPGM=ADRDSSU LUNIT=057A LTIME=0649 CJOB=MEP001CC CDATE=2008/073 CPGM=ADRDSSU CUNIT=057A CTIME=0446 CSTEP=DUMP1CDDNAME=TAPE01 BLKCNT=00 ROBTY=00 COMPRES=078 LABEL=SL DEN=3590 TRTCH=256TROBID=000 TRERRC=0 RECFM=ULRECL=00 BLKSIZE=00EDMID=BLANKS TWERRC=0 NUMDSNB= 1STDSNB=000 LSTDSNB=000 ACTVOL= PRERRC=0 1STVOL=NEXTVOL= PREVVOL= VOLSEQ=0002 PWERRC=0 COUNT=00209VENDOR=BLANKSBTHDATE=2007/115 VOLPERC=024 TRERRI=0 USECLN=00201 CLNCNT=013 DATECLN=2008/072 FILPERC=002 TWERRI=1 OUTCODE=BLANKS SLOT=000 OUTDATE=ZEROS CPUID=JCC1 PRERRI=0 AUTIME=0427AUCODE=00AUDATE=2008/093 AUFLAG1=00 PWERRI=0 *** SCRATCH TAPE *** INQUIRY COMPLETE Here is the error we got: MO14FC.CYC8093 IEC151I A13-08,IFG0195B,MEP001CO,DUMP1,TAPE16,0570,M00605,MEP001.BACKUP. M102FC.CYC8093 IEF196I TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE IEF196I TMSSMF30I VOL=M00605, FSEQ=0001, IEF196I DSN=MEP001.BACKUP.MO00FC.CYC8093 TMSSMF30I VOL=M00605, FSEQ=0001, DSN=MEP001.BACKUP.MO00FC.CYC8093 -MEP001CO DUMP108597276.00.001.7 The error message says: 08The requested file sequence number is less than that of the first file on the SL or AL tape during an open to the start of the file. Probable user error. Check the file sequence number and volume serial numbers. We have verified this was not a user error. For some reason it appears that the new CA-1 was reading the old tape label even though it was a scratch tape. (we do not reinit the tapes before putting them in scratch status) Does anyone know if we missed some options somewhere that is causing this? Both these problems go away when we go back to the old version. Thanks, Mary Mary J. Yukus IT Specialist - Lead Systems Programmer HQ US Military Entrance Processing Command J6/MIT-System Support Branch 2834 Green Bay Road North Chicago, IL 60064-3057 Work: 847-688-3680 x7274 Work Cell: 224-627-6017 DSN: 792-7274 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problem with CA-1
Since this is a scratch tape, it should ignore this. The old version of CA-1 does. VOLSEQ 1 doesn't exist any longer either since it also was a scratch tape. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Campbell Jay Sent: Wednesday, April 09, 2008 10:15 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Problem with CA-1 Problem # 2 is VOLSEQ=0002 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Yukus, Mary J CIV USMEPCOM Sent: Wednesday, April 09, 2008 11:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Problem with CA-1 Hi Everyone, We are having a problem with CA-1 which CA believes is not a CA problem. We are trying to upgrade from v11 to v11.5. When we implement the v11.5 we have the following problems. The first is a problem with multiple files on a tape. When it complete the 4th file, we get the following error. The exact JCL works file on our system once we back out the new version of CA-1. This appears to maybe be some type of option that allows it to stack more than 4 files on a tape, but haven't been able to track it down. IEC205I TAPE,JBACKSM1,SMFD16,FILESEQ=0004, COMPLETE VOLUME LIST, 818 DSN=JCC1.BACKUP.SMFD16.G1181V00,VOLS=J00414,TOTALBLOCKS=38033 -JBACKSM1 SMFD16 00 41255 151K.03.032.7 469K 0 0 0 0 0 -JBACKSM1 B4BOMB IEFPROC FLUSH 0 0.00.00 .0 0 0 0 0 0 0 IEC999I IFG019CA,JBACKSM1,SMFD17 IEF196I TMSSMF06W END OF DSNB CHAIN REACHED TMSSMF06W END OF DSNB CHAIN REACHED IEF196I TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 -JBACKSM1 SMFD17 08 58 15.00.00 .4 2414 0 0 0 0 0 The next problem we had was where the job called for a scratch tape, the scratch tape was mounted (see the tape inquiry info below says it's a scratch tape) M00605 VOLSER=M00605 VOLSER=M00605 DSN=MEP001.BACKUP.MO75FC.CYC8072 EXPDT=2008/093 ACCT=HEXZEROS SMSMC=BLANKSFLAG1=44=(CLO,SCR) HOOKID=FE= FLAG2=40=(OUT) CTLGCNT=000 BATCHID=54=TMSSCR FLAG3=00 FLAG5=00 USERID=TMSUSER FLAG4=00 DSN17=UP.M147FC.CYC8072 LJOB=MEP001CC LDATE=2008/073 LPGM=ADRDSSU LUNIT=057A LTIME=0649 CJOB=MEP001CC CDATE=2008/073 CPGM=ADRDSSU CUNIT=057A CTIME=0446 CSTEP=DUMP1CDDNAME=TAPE01 BLKCNT=00 ROBTY=00 COMPRES=078 LABEL=SL DEN=3590 TRTCH=256TROBID=000 TRERRC=0 RECFM=ULRECL=00 BLKSIZE=00EDMID=BLANKS TWERRC=0 NUMDSNB= 1STDSNB=000 LSTDSNB=000 ACTVOL= PRERRC=0 1STVOL=NEXTVOL= PREVVOL= VOLSEQ=0002 PWERRC=0 COUNT=00209VENDOR=BLANKSBTHDATE=2007/115 VOLPERC=024 TRERRI=0 USECLN=00201 CLNCNT=013 DATECLN=2008/072 FILPERC=002 TWERRI=1 OUTCODE=BLANKS SLOT=000 OUTDATE=ZEROS CPUID=JCC1 PRERRI=0 AUTIME=0427AUCODE=00AUDATE=2008/093 AUFLAG1=00 PWERRI=0 *** SCRATCH TAPE *** INQUIRY COMPLETE Here is the error we got: MO14FC.CYC8093 IEC151I A13-08,IFG0195B,MEP001CO,DUMP1,TAPE16,0570,M00605,MEP001.BACKUP. M102FC.CYC8093 IEF196I TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE IEF196I TMSSMF30I VOL=M00605, FSEQ=0001, IEF196I DSN=MEP001.BACKUP.MO00FC.CYC8093 TMSSMF30I VOL=M00605, FSEQ=0001, DSN=MEP001.BACKUP.MO00FC.CYC8093 -MEP001CO DUMP108597276.00.001.7 The error message says: 08The requested file sequence number is less than that of the first file on the SL or AL tape during an open to the start of the file. Probable user error. Check the file sequence number and volume serial numbers. We have verified this was not a user error. For some reason it appears that the new CA-1 was reading the old tape label even though it was a scratch tape. (we do not reinit the tapes before putting them in scratch status) Does anyone know if we missed some options somewhere that is causing this? Both these problems go away when we go back to the old version. Thanks, Mary Mary J. Yukus IT Specialist - Lead Systems Programmer HQ US Military Entrance Processing Command J6/MIT-System Support Branch 2834 Green Bay Road North Chicago, IL 60064-3057 Work: 847-688-3680 x7274 Work Cell: 224-627-6017 DSN: 792-7274 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive
Re: Problem with CA-1
Thanks Tom, I'll forward this on to my CA-1 person. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pinnacle Sent: Wednesday, April 09, 2008 10:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Problem with CA-1 - Original Message - From: Yukus, Mary J CIV USMEPCOM [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, April 09, 2008 11:04 AM Subject: Problem with CA-1 Hi Everyone, We are having a problem with CA-1 which CA believes is not a CA problem. We are trying to upgrade from v11 to v11.5. When we implement the v11.5 we have the following problems. The first is a problem with multiple files on a tape. When it complete the 4th file, we get the following error. The exact JCL works file on our system once we back out the new version of CA-1. This appears to maybe be some type of option that allows it to stack more than 4 files on a tape, but haven't been able to track it down. IEC205I TAPE,JBACKSM1,SMFD16,FILESEQ=0004, COMPLETE VOLUME LIST, 818 DSN=JCC1.BACKUP.SMFD16.G1181V00,VOLS=J00414,TOTALBLOCKS=38033 -JBACKSM1 SMFD16 00 41255 151K.03.032.7 469K 0 0 0 0 0 -JBACKSM1 B4BOMB IEFPROC FLUSH 0 0.00.00 .0 0 0 0 0 0 0 IEC999I IFG019CA,JBACKSM1,SMFD17 IEF196I TMSSMF06W END OF DSNB CHAIN REACHED TMSSMF06W END OF DSNB CHAIN REACHED IEF196I TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 -JBACKSM1 SMFD17 08 58 15.00.00 .4 2414 0 0 0 0 0 snip Mary, The first thing I would do is run TMSPTRS at V11 and at V11R5 to see if you have pointer issues. After that, I would work with Russ Witt at CA, and then the O/C/E folks at IBM if necessary, to figure out the problem. If you haven't talked to Russ yet, you should request him. Regards, Tom Conley -- 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: Problem with CA-1
- Original Message - From: Yukus, Mary J CIV USMEPCOM [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, April 09, 2008 11:04 AM Subject: Problem with CA-1 Hi Everyone, We are having a problem with CA-1 which CA believes is not a CA problem. We are trying to upgrade from v11 to v11.5. When we implement the v11.5 we have the following problems. The first is a problem with multiple files on a tape. When it complete the 4th file, we get the following error. The exact JCL works file on our system once we back out the new version of CA-1. This appears to maybe be some type of option that allows it to stack more than 4 files on a tape, but haven't been able to track it down. IEC205I TAPE,JBACKSM1,SMFD16,FILESEQ=0004, COMPLETE VOLUME LIST, 818 DSN=JCC1.BACKUP.SMFD16.G1181V00,VOLS=J00414,TOTALBLOCKS=38033 -JBACKSM1 SMFD16 00 41255 151K.03.032.7 469K 0 0 0 0 0 -JBACKSM1 B4BOMB IEFPROC FLUSH 0 0.00.00 .0 0 0 0 0 0 0 IEC999I IFG019CA,JBACKSM1,SMFD17 IEF196I TMSSMF06W END OF DSNB CHAIN REACHED TMSSMF06W END OF DSNB CHAIN REACHED IEF196I TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 -JBACKSM1 SMFD17 08 58 15.00.00 .4 2414 0 0 0 0 0 snip Mary, The first thing I would do is run TMSPTRS at V11 and at V11R5 to see if you have pointer issues. After that, I would work with Russ Witt at CA, and then the O/C/E folks at IBM if necessary, to figure out the problem. If you haven't talked to Russ yet, you should request him. Regards, Tom Conley -- 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: Sequential Data Striping
---snip- There's nothing wrong with stripes over stripes. I've referred to this as braiding in the past. With a good pre-fetch algorithm the storage uses the parallelism of the striped arrays to feed the cache in large block requests from many disks, and in turn the RAID-0 dataset can feed the sequential read process by pre-fetching from many concurrent volumes and paths. Braiding is a good thing. It is heavily used in UNIX land, Not so common on Windows, and unfortunately (for some unknown reason) strangely rare in MVS. --unsnip At the risk of sounding obtuse, I have to ask the question: why is striping even an issue today? Given the architecture of modern DASD-like storage systems and the advent of Dynamic PAV, the hardware and operating system facilities SEEM to address all of the performance considerations that might seem to mitigate in favor of striping. -- 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: Sequential Data Striping
Rick Fochtman wrote: [...] At the risk of sounding obtuse, I have to ask the question: why is striping even an issue today? A the risk of... - because of performance reasons. Even on new shining DASD arrays it gives performance increase. BTDT. Good planning is harder than in very old days of SLEDs. You have to care about how MVS volumes are emulated on physical RAID groups. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sequential Data Striping
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Wednesday, April 09, 2008 10:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Sequential Data Striping ---snip- There's nothing wrong with stripes over stripes. I've referred to this as braiding in the past. With a good pre-fetch algorithm the storage uses the parallelism of the striped arrays to feed the cache in large block requests from many disks, and in turn the RAID-0 dataset can feed the sequential read process by pre-fetching from many concurrent volumes and paths. Braiding is a good thing. It is heavily used in UNIX land, Not so common on Windows, and unfortunately (for some unknown reason) strangely rare in MVS. --unsnip At the risk of sounding obtuse, I have to ask the question: why is striping even an issue today? Given the architecture of modern DASD-like storage systems and the advent of Dynamic PAV, the hardware and operating system facilities SEEM to address all of the performance considerations that might seem to mitigate in favor of striping. -- There is one left. Even if the data is physically striped on the DASD, when you read an unstriped, in z/OS's view, disk dataset, you do a single I/O operation. If you use z/OS striping, you do multiple I/Os (one to each stripe), which hopefully means that you wait less for the I/O operation. The same on a write. I.e. the amount of data concurrently transferred is greater. Of course, if you have my luck, each stripe (z/OS DASD volume) will end up being on the same physical back end DASD and nothing will be prefetched in cache either. If it weren't for bad luck, I'd have no luck at all. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problem with CA-1
That second issue sounds like an intercept is missing and CA-1 isn't getting control to subvert the VOLSEQ. We have plenty of chains that run over 7,000 dsnbs long created every week, I did nothing for 11.5 to enable that, it should work out of the box. My wag is that there is something wrong when you ipl with the new 11.5, old CA90 running downlevel L052INIT or something. That's just very bizarre behaviour for CA-1. Jeff Williams Operating Systems Support -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Yukus, Mary J CIV USMEPCOM Sent: April 9, 2008 11:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Problem with CA-1 Since this is a scratch tape, it should ignore this. The old version of CA-1 does. VOLSEQ 1 doesn't exist any longer either since it also was a scratch tape. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Campbell Jay Sent: Wednesday, April 09, 2008 10:15 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Problem with CA-1 Problem # 2 is VOLSEQ=0002 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Yukus, Mary J CIV USMEPCOM Sent: Wednesday, April 09, 2008 11:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Problem with CA-1 Hi Everyone, We are having a problem with CA-1 which CA believes is not a CA problem. We are trying to upgrade from v11 to v11.5. When we implement the v11.5 we have the following problems. The first is a problem with multiple files on a tape. When it complete the 4th file, we get the following error. The exact JCL works file on our system once we back out the new version of CA-1. This appears to maybe be some type of option that allows it to stack more than 4 files on a tape, but haven't been able to track it down. IEC205I TAPE,JBACKSM1,SMFD16,FILESEQ=0004, COMPLETE VOLUME LIST, 818 DSN=JCC1.BACKUP.SMFD16.G1181V00,VOLS=J00414,TOTALBLOCKS=38033 -JBACKSM1 SMFD16 00 41255 151K.03.032.7 469K 0 0 0 0 0 -JBACKSM1 B4BOMB IEFPROC FLUSH 0 0.00.00 .0 0 0 0 0 0 0 IEC999I IFG019CA,JBACKSM1,SMFD17 IEF196I TMSSMF06W END OF DSNB CHAIN REACHED TMSSMF06W END OF DSNB CHAIN REACHED IEF196I TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 -JBACKSM1 SMFD17 08 58 15.00.00 .4 2414 0 0 0 0 0 The next problem we had was where the job called for a scratch tape, the scratch tape was mounted (see the tape inquiry info below says it's a scratch tape) M00605 VOLSER=M00605 VOLSER=M00605 DSN=MEP001.BACKUP.MO75FC.CYC8072 EXPDT=2008/093 ACCT=HEXZEROS SMSMC=BLANKSFLAG1=44=(CLO,SCR) HOOKID=FE= FLAG2=40=(OUT) CTLGCNT=000 BATCHID=54=TMSSCR FLAG3=00 FLAG5=00 USERID=TMSUSER FLAG4=00 DSN17=UP.M147FC.CYC8072 LJOB=MEP001CC LDATE=2008/073 LPGM=ADRDSSU LUNIT=057A LTIME=0649 CJOB=MEP001CC CDATE=2008/073 CPGM=ADRDSSU CUNIT=057A CTIME=0446 CSTEP=DUMP1CDDNAME=TAPE01 BLKCNT=00 ROBTY=00 COMPRES=078 LABEL=SL DEN=3590 TRTCH=256TROBID=000 TRERRC=0 RECFM=ULRECL=00 BLKSIZE=00EDMID=BLANKS TWERRC=0 NUMDSNB= 1STDSNB=000 LSTDSNB=000 ACTVOL= PRERRC=0 1STVOL=NEXTVOL= PREVVOL= VOLSEQ=0002 PWERRC=0 COUNT=00209VENDOR=BLANKSBTHDATE=2007/115 VOLPERC=024 TRERRI=0 USECLN=00201 CLNCNT=013 DATECLN=2008/072 FILPERC=002 TWERRI=1 OUTCODE=BLANKS SLOT=000 OUTDATE=ZEROS CPUID=JCC1 PRERRI=0 AUTIME=0427AUCODE=00AUDATE=2008/093 AUFLAG1=00 PWERRI=0 *** SCRATCH TAPE *** INQUIRY COMPLETE Here is the error we got: MO14FC.CYC8093 IEC151I A13-08,IFG0195B,MEP001CO,DUMP1,TAPE16,0570,M00605,MEP001.BACKUP. M102FC.CYC8093 IEF196I TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE IEF196I TMSSMF30I VOL=M00605, FSEQ=0001, IEF196I DSN=MEP001.BACKUP.MO00FC.CYC8093 TMSSMF30I VOL=M00605, FSEQ=0001, DSN=MEP001.BACKUP.MO00FC.CYC8093 -MEP001CO DUMP108597276.00.001.7 The error message says: 08The requested file sequence number is less than that of the first file on the SL or AL tape during an open to the start of the file. Probable user error. Check the file sequence number and volume serial numbers. We have verified this was not a user error. For some reason it appears that the new CA-1 was reading the old tape label even though it was a scratch tape. (we do not reinit the tapes before putting them in scratch status) Does anyone know if we missed some options somewhere that is causing this? Both these problems go away when we go back to the old version. Thanks, Mary Mary
Re: Modify DSCB information
snip what about Expiry date of dataset ? Can it be changed ? unsnip-- Yes. I THINK CDSCB can do it, but it's been a long time since I used it so I'm not really sure. You can always use AMASPZAP to make changes. -- 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: Sequential Data Striping
On Tue, 2008-04-08 at 07:17 -0700, Ron Hawkins wrote: The Iceberg's sequential pre-fetch performance was not one of its finest moments. If you are seeing disconnect time of 10ms or more for your sequential IO then restricting your work to 8 stripes may not be the best thing for your workload. 1-3ms seems typical, with the current snapshot showing a max of 4.2. A larger number of stripes and corresponding BUFNO changes would increase the IO transfer and cache miss overlap. Cache miss overlap -- hadn't thought about that, good catch. I'm leery of striping things indiscriminately; there's a cost involved with allocating additional extents for multivolume datasets. F CATALOG,REPORT,PERFORMANCE on my system reports DADSM scratch time of 139ms, which I (without any direct evidence) attribute to SVAA's dynamic space reclaim function. Maybe one of these days I'll turn that off and see if interval space management improves DADSM scratch any. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sequential Data Striping
I'm confused. If a program is reading or writing a dataset sequentially, then it does so one I/O (block) at a time. If another program is concurrently reading, then it will be doing I/O's more or less concurrently and the likelihood of cache hits rise. If you are writing, you write only one block at a time. With 'fast write', the operation ends once the block is in the device cache. What happens physically is not that relevant. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, April 09, 2008 10:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Sequential Data Striping There is one left. Even if the data is physically striped on the DASD, when you read an unstriped, in z/OS's view, disk dataset, you do a single I/O operation. If you use z/OS striping, you do multiple I/Os (one to each stripe), which hopefully means that you wait less for the I/O operation. The same on a write. I.e. the amount of data concurrently transferred is greater. Of course, if you have my luck, each stripe (z/OS DASD volume) will end up being on the same physical back end DASD and nothing will be prefetched in cache either. If it weren't for bad luck, I'd have no luck at all. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM announcements
I never said it would be better, I was just wondering if that was going to be the direction for what used to be done in ISPF dialogs. Things like ServerPac, Health Checker, Omegamon installer. If history serves as any lesson, most attempts at any type of installation dialog usually fails (CA-AGGRAVATOR anyone?) as well as most other OEM installers. Give me an install lib and a list of jobs to run and I'll be just fine thank you. The exception at this point appears to be the ServerPac dialogs which actually appear to work nicely and properly the way they are. Altering them to use a web interface may work but why bother? Ken -Original Message- Shane On Wed, 2008-04-09 at 10:09 -0400, Ken Porowski wrote: I was thinking more along the lines of a local (z/OS based web) interface instead of the current ISPF dialogs. A poorly designed (web) interface is a poorly designed interface. What gives you faith it will be any better designed just because it remains within a LAN ???. My sceptosity level remains elevated until disproved. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS 1.4-1.7 gotchas
I may be drafted to do a 1.4 to 1.7 migration. I'm concerned both about any gotchas in the migration itself and about anything that might impede a later migration to a supported[1] release. There are two LPAR's in a sysplex and a third LPAR in a monplex. Is there anything critical that the documentation and PSP don't tell you, or that they get wrong? [1] 1.7 is still supported, but not for long. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Duplicate temporary dataset names
In [EMAIL PROTECTED], on 04/07/2008 at 03:44 PM, Myers, Edouard (OCTO) [EMAIL PROTECTED] said: It should be in upper case Why? It would still be invalid. He needs to remove it entirely. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Problem with CA-1
Did you copy the TMC onto this system for testing? How did you copy it? I have seem weird DSNB chaining problems using TMSCOPY to backup and restore for testing and would use an IEBGENER copy anyday. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Yukus, Mary J CIV USMEPCOM Sent: 09 April 2008 16:04 To: IBM-MAIN@BAMA.UA.EDU Subject: Problem with CA-1 Hi Everyone, We are having a problem with CA-1 which CA believes is not a CA problem. We are trying to upgrade from v11 to v11.5. When we implement the v11.5 we have the following problems. The first is a problem with multiple files on a tape. When it complete the 4th file, we get the following error. The exact JCL works file on our system once we back out the new version of CA-1. This appears to maybe be some type of option that allows it to stack more than 4 files on a tape, but haven't been able to track it down. IEC205I TAPE,JBACKSM1,SMFD16,FILESEQ=0004, COMPLETE VOLUME LIST, 818 DSN=JCC1.BACKUP.SMFD16.G1181V00,VOLS=J00414,TOTALBLOCKS=38033 -JBACKSM1 SMFD16 00 41255 151K.03.032.7 469K 0 0 0 0 0 -JBACKSM1 B4BOMB IEFPROC FLUSH 0 0.00.00 .0 0 0 0 0 0 0 IEC999I IFG019CA,JBACKSM1,SMFD17 IEF196I TMSSMF06W END OF DSNB CHAIN REACHED TMSSMF06W END OF DSNB CHAIN REACHED IEF196I TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 TMSSMF30I VOL=J00414, FSEQ=0005, DSN=JCC1.BACKUP.SMFD17.G1181V00 -JBACKSM1 SMFD17 08 58 15.00.00 .4 2414 0 0 0 0 0 The next problem we had was where the job called for a scratch tape, the scratch tape was mounted (see the tape inquiry info below says it's a scratch tape) M00605 VOLSER=M00605 VOLSER=M00605 DSN=MEP001.BACKUP.MO75FC.CYC8072 EXPDT=2008/093 ACCT=HEXZEROS SMSMC=BLANKSFLAG1=44=(CLO,SCR) HOOKID=FE= FLAG2=40=(OUT) CTLGCNT=000 BATCHID=54=TMSSCR FLAG3=00 FLAG5=00 USERID=TMSUSER FLAG4=00 DSN17=UP.M147FC.CYC8072 LJOB=MEP001CC LDATE=2008/073 LPGM=ADRDSSU LUNIT=057A LTIME=0649 CJOB=MEP001CC CDATE=2008/073 CPGM=ADRDSSU CUNIT=057A CTIME=0446 CSTEP=DUMP1CDDNAME=TAPE01 BLKCNT=00 ROBTY=00 COMPRES=078 LABEL=SL DEN=3590 TRTCH=256TROBID=000 TRERRC=0 RECFM=ULRECL=00 BLKSIZE=00EDMID=BLANKS TWERRC=0 NUMDSNB= 1STDSNB=000 LSTDSNB=000 ACTVOL= PRERRC=0 1STVOL=NEXTVOL= PREVVOL= VOLSEQ=0002 PWERRC=0 COUNT=00209VENDOR=BLANKSBTHDATE=2007/115 VOLPERC=024 TRERRI=0 USECLN=00201 CLNCNT=013 DATECLN=2008/072 FILPERC=002 TWERRI=1 OUTCODE=BLANKS SLOT=000 OUTDATE=ZEROS CPUID=JCC1 PRERRI=0 AUTIME=0427AUCODE=00AUDATE=2008/093 AUFLAG1=00 PWERRI=0 *** SCRATCH TAPE *** INQUIRY COMPLETE Here is the error we got: MO14FC.CYC8093 IEC151I A13-08,IFG0195B,MEP001CO,DUMP1,TAPE16,0570,M00605,MEP001.BACKUP. M102FC.CYC8093 IEF196I TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE TMSSMF14W VOLSEQ NOT 1 FOR FIRST FILE IEF196I TMSSMF30I VOL=M00605, FSEQ=0001, IEF196I DSN=MEP001.BACKUP.MO00FC.CYC8093 TMSSMF30I VOL=M00605, FSEQ=0001, DSN=MEP001.BACKUP.MO00FC.CYC8093 -MEP001CO DUMP108597276.00.001.7 The error message says: 08The requested file sequence number is less than that of the first file on the SL or AL tape during an open to the start of the file. Probable user error. Check the file sequence number and volume serial numbers. We have verified this was not a user error. For some reason it appears that the new CA-1 was reading the old tape label even though it was a scratch tape. (we do not reinit the tapes before putting them in scratch status) Does anyone know if we missed some options somewhere that is causing this? Both these problems go away when we go back to the old version. Thanks, Mary Mary J. Yukus IT Specialist - Lead Systems Programmer HQ US Military Entrance Processing Command J6/MIT-System Support Branch 2834 Green Bay Road North Chicago, IL 60064-3057 Work: 847-688-3680 x7274 Work Cell: 224-627-6017 DSN: 792-7274 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html No virus found in this incoming message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.9/1364 - Release Date: 07/04/2008 18:38 No virus found in this outgoing message. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.9/1364 - Release Date: 07/04/2008 18:38 -- For
Re: Faxing from the mainframe
In [EMAIL PROTECTED], on 04/08/2008 at 02:02 PM, Timothy Sipples [EMAIL PROTECTED] said: Perhaps it's more precise to say that OV/MVS is, by far, the closest current match to PROFS. Is that fair? Is OV/VM dead? If not, it's the closest available to PROFS. OV/MVS was a hodgepodge of unrelated components bolted together. I'd be interested in comments from prior or current OV/MVS users as to how they view it. BTDTGTS. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Modify DSCB information
In [EMAIL PROTECTED], on 04/09/2008 at 01:28 PM, Jacky Bright [EMAIL PROTECTED] said: Is it possible to change the DSCB information of allocated dataset through some utility ? OPEN will merge some fields from your DD back to the DSCB. That's often useful, but sometimes somebody changes something that they shouldn't have. Like changing Primary / Secondary quantity ? You can change secondary; the system does not record the primary size. Note that your first extent may be smaller than the primary size, and that there is no way to tell how many extents the system initially allocated to satisfy the primary requirement. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Duplicate temporary dataset names
In [EMAIL PROTECTED], on 04/07/2008 at 02:27 PM, Mark Zelden [EMAIL PROTECTED] said: The problem is not with the poster, It's the poster that tried to actually run the bad JCL. He needs to know how to fix the JCL, which I told him. Fixing the web site is a more difficult problem. it is with LISTSERV's web interface. Broken web sites are endemic :-( Just to prove it I'm rarely sceptical about claims that a web site is broken; I might be sceptical about claims that it is not ;-) FWIW, there are sites that are much more badly broken. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Broken LISTSERV (was: Duplicate temporary dataset names)
In [EMAIL PROTECTED], on 04/07/2008 at 10:41 AM, Paul Gilmartin [EMAIL PROTECTED] said: Yours is fine. Apparently you posted via E-mail (I'm guessing because your Date: header indicates MDT, not CDT). I posted via the WWW interface, so that narrows the suspect list. The web interface is not LISTSERV, any more than bit.listserv.ibm-main is IBM-MAIN. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Broken LISTSERV (was: Duplicate temporary dataset names)
In [EMAIL PROTECTED], on 04/07/2008 at 06:41 AM, Steve Comstock [EMAIL PROTECTED] said: [Now I'll wait to see how this comes through on the actual message, just to verify.] It came through just fine. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: SPFEDIT does a RESERVE!?!
On Wed, 9 Apr 2008 10:09:04 -0400, Rob Scott wrote: If you haven't seen it already, ISPF enqueues are mentioned explicitly in the z/OS MVS Planning : GRS manual - there are cases where exclusion RNL is warranted and it also explains how SPFEDIT lives with SYSDSN. And, more important, earlier I found in one of the ISPF manuals an explanation of how ISPF thrives without exclusive ENQs on SYSDSN. This is a technique I earnestly wish would be embraced by other z/OS components, particularly the C Run Time Library. -- gil -- 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: Faxing from the mainframe
When I was at PH Mining, we had OV/MVS for several years. We got it when there were very few PCs in the company. Most people who had PCs, and did emails or document writing on the mainframe didn't like OV/MVS. It was much more cumbersome to use than a PC. When most people had PCs, we got rid of OV/MVS. I don't remember when though. I know the OV/MVS email system was not connected to the internet. There was a project to allow people to send from OV/MVS to people within the company who had Groupwise, and vice versa, but that project was never completed. Eric Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: OV/MVS was a hodgepodge of unrelated components bolted together. I'd be interested in comments from prior or current OV/MVS users as to how they view it. BTDTGTS. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html -- Eric Bielefeld Systems Programmer Aviva USA Des Moines, Iowa 515-645-5153 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.4-1.7 gotchas
One that we ran into was a COBOL RM31 program calling an assembler RM24 program. Had to change the LE370 options ALL31 to OFF and HEAP to ANYWHERE. Shmuel Metz (Seymour J.) [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 04/09/2008 12:16 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject z/OS 1.4-1.7 gotchas I may be drafted to do a 1.4 to 1.7 migration. I'm concerned both about any gotchas in the migration itself and about anything that might impede a later migration to a supported[1] release. There are two LPAR's in a sysplex and a third LPAR in a monplex. Is there anything critical that the documentation and PSP don't tell you, or that they get wrong? [1] 1.7 is still supported, but not for long. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Modify DSCB information
In [EMAIL PROTECTED], on 04/09/2008 at 07:43 AM, Staller, Allan [EMAIL PROTECTED] said: There is an old program on the CBT Tape (DMOD) that can change many F1 DSCB attributes. I don't know if anyone has updated it for SMS. Aren't the SMS attributes carried in the NVR rather than the DSCB1? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM announcements
In [EMAIL PROTECTED], on 04/09/2008 at 10:09 AM, Ken Porowski [EMAIL PROTECTED] said: I was thinking more along the lines of a local (z/OS based web) interface instead of the current ISPF dialogs. I'm sure that Shane was as well, and that he is concerned about the track record of such replacement interfaces. I believe that he is right to be concerned. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Problem with CA-1
Mary, I am aware of the first problem (the level-1 tech asked me to look at the issue). She is going to ask for some additional information (for example, you have the SYSPRINT for the DFDSS step that is failing coded as DD DUMMY, and we would like to see if DFDSS is putting out any error messages. I was not aware of the second issue, so please open an issue with CA-1 support. I can tell you that the first question we will ask is to see the joblog and/or JCL for the failing job. My guess is that they have LABEL=2 specified and are trying to stack a dataset onto a scratch tape. Feel free to contact me directly. Russell Witt L2 Support Manager [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sequential Data Striping
Hal, What operating system are you using? The z/OS I use reads multiple blocks per start sub-channel so that blocks are pre-fetched into buffers ahead of the program request. For sequential caching algorithms, in HDS anyway, having two jobs reading the same dataset does not mean the trailing job will get cache hits. That implies that sequential IO is walking the cache - this is very bad. Sequential reads are assigned a pre-fetch area in cache that is re-used by the sequential pre-fetch algorithm. This prevents cache walking, but it also means that most sequential read processes are doing their own pre-fetch reads from disk. Even if they are reading from the same volume or dataset. There are some exceptions to this when there are two sequences of sequential reads in the same general area, but this is an extraordinary situation. For chained writes, a similar explanation except it is the parity generation and destage process that are optimized when sequential writes are detected. Note that detection can be through a bit setting in the channel command, or access pattern detection. I don't think you are really doing sequential IO one block at a time, except perhaps for VSAM using default BUFSP. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Wednesday, April 09, 2008 9:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] Sequential Data Striping I'm confused. If a program is reading or writing a dataset sequentially, then it does so one I/O (block) at a time. If another program is concurrently reading, then it will be doing I/O's more or less concurrently and the likelihood of cache hits rise. If you are writing, you write only one block at a time. With 'fast write', the operation ends once the block is in the device cache. What happens physically is not that relevant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.4-1.7 gotchas
One that got us was the TCPIP profile default for the SEGMENTATIONOFFLOAD changed from NO to YES. This attempts to offload some of the TCPIP packet handling from the processor to the OSA card. If you have an old(ish - ours was from 2006/2007) version of the OSA Express/Express2 card, it will lock up under certain high workload conditions, and all IP traffic to and from the machine will stop. The only resolution is a full Power-on Reset - an IPL is not enough. There is a microcode fix for the OSA, however the workaround is to explicitly specify NOSEGMENTATIONOFFLOAD on a GLOBALCONFIG statement in your TCPIP profile, on all LPARs that run a TCPIP stack. It's a known problem apparently. We thought we'd been quite thorough in our prep too, but we missed it. Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Web Interfaces (was: Broken LISTSERV)
On Wed, 9 Apr 2008 11:02:59 -0300, Shmuel Metz (Seymour J.) wrote: The web interface is not LISTSERV, any more than bit.listserv.ibm-main is IBM-MAIN. Right. Even as the web interface isn't IBMLink. But the distinction blurs when one tries to use it. -- gil -- 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: Sequential Data Striping
Dave, 1-3ms disconnect time is pretty good for sequential IO on Iceberg. Early Iceberg and RVAs I came across were typically 20-50ms disconnect time during batch - I had the first ICEBERG in ASIA. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews Sent: Wednesday, April 09, 2008 8:49 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] Sequential Data Striping On Tue, 2008-04-08 at 07:17 -0700, Ron Hawkins wrote: The Iceberg's sequential pre-fetch performance was not one of its finest moments. If you are seeing disconnect time of 10ms or more for your sequential IO then restricting your work to 8 stripes may not be the best thing for your workload. 1-3ms seems typical, with the current snapshot showing a max of 4.2. A larger number of stripes and corresponding BUFNO changes would increase the IO transfer and cache miss overlap. Cache miss overlap -- hadn't thought about that, good catch. I'm leery of striping things indiscriminately; there's a cost involved with allocating additional extents for multivolume datasets. F CATALOG,REPORT,PERFORMANCE on my system reports DADSM scratch time of 139ms, which I (without any direct evidence) attribute to SVAA's dynamic space reclaim function. Maybe one of these days I'll turn that off and see if interval space management improves DADSM scratch any. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- 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: Sequential Data Striping
Rick, While the arrays have all this parallelism built in so that sequential IO is pre-fetched concurrently from many disks into the cache (on some RAID designs), the effectiveness is somewhat discounted when this massively parallel data stream from disk to cache is transferred one SSCH at a time on one channel at a time from cache to host. While PAV provides a degree of parallelism at the volume and dataset level, it does not provide any parallelism at requesting program level. Using wide striping with striped datasets (RAID-0) means that the buffers can be processing reads and writes to many volumes in parallel across many channels. In simple terms, a four way striped dataset can be processed up to four times faster than an un-striped dataset. The other advantage of striping, especially wide striping, is prevention or mitigation of hot spots. Even with PAV we have all seen how the reporting phase of batch processing can bog down when the new master file is suddenly hammered by 25 reporting programs. There are a few ways to relieve this such as IO avoidance with DLF, or creating clone datasets with FCV2 or similar. Another way is to stripe the dataset so that the IO is spread across many volumes, paths, and usually more disk drives. This is the whole logic behind LDEV Striping (HDS parlance). Array Groups with 4 disk drives, RAID-5 and 10, do not handle hot spots as well as Array Groups with 8 disk drives. LDEV striping allows volumes to be striped over 16 or 32 disk, which in turn reduce skew and soften the hot spots that create sibling pend. The same logic applies to striped datasets. RAID-0 datasets for random activity need no explanation - it is just better than sliced bread. Ron At the risk of sounding obtuse, I have to ask the question: why is striping even an issue today? Given the architecture of modern DASD-like storage systems and the advent of Dynamic PAV, the hardware and operating system facilities SEEM to address all of the performance considerations that might seem to mitigate in favor of striping. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to format the current linkage stack for a SLIP dump taken in SRB mode?
On Wed, 9 Apr 2008 11:24:09 +0200 Barbara Nitz [EMAIL PROTECTED] wrote: :Not at all. There is no SRB to find as the SRB block only exists while it is on a queue. Once dispatched it is simply data. :The registers are consistent with the point of the trap. :I believe that I said that. My explanation wasn't really for you, it was more for those that kept telling you to look for an SSRB. Sorry. :Actually, CBF of the CR15 value did format it. :And that was NOT done via summary format command *automatically*, but by actually typing in an address and provide IPCS a clue how to format it. Yes. :I certainly would hope that the system automatically SUMLISTs the linkage :stacks. :It does, doesn't it? You were able to cbf it. Is the content inconsistent with what you hoped to see? What prompts the ongoing enquiry after Jim provided the command? It appears to be accurate. :Does the SLIP SL operand support indirect address off of control :registers? :No clue. Your guess looking at the slip command is as good as mine. Not as of 1.8 -- 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
TIOT filling up: too many dynamic concatenations
Anyone, I have a mainframe assembler application which is invoking Unix system services to get the names of all of the files in an NFS-mounted folder. The application dynamically allocates and logically concatenates these files into one giant dataset, then uses QSAM macros to read it. The DYNALLOC calls work this way: first, I dynamically allocate the first file in the folder with DDNAME MYFILE. Then the program enters a loop, performing these steps for each remaining file in the folder: 1) Dynamically allocate the file, asking the system to provide the DDNAME (I observe that these are getting the ddnames SYS1, SYS2, etc). 2) Dynamically concatenate MYFILE with the SYSx dataset just allocated (with the permanently allocated attribute on). This works beautifully; when I exit the loop, I can OPEN and GET all the records successfully from MYFILE. The problem is that I have reached a practical limit of approximately 540 files in the folder, because when I reach that point, I get a dynamic concatenation ABEND due to the TIOT filling up. I am told that our TIOT size is the default of 32K, which would allow for a maximum of 1,635 DDs in a job step. It would seem, however, that something in my allocation/concatenation loop is preventing me from reaching that number of files. There are only a handful of other DDs allocated to the step (e.g., STEPLIB, etc). If I were able to handle up to 750 (or perhaps 1,000) files at a time, it would be of immense help. At the moment, our only option seems to be to split up the files into multiple folders of 500 files each. Do I have any other options? Thanks so much. David -- 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
False Advertising
Many of you will probably receive the email from one of the MF sites which will contain the reference to this article. http://serverspecs.blogs.techtarget.com/2008/04/04/why-there-should-probably-be-no-windows-in-the-data-center/?track=NL-576ad=634581asrc=EM_NLN_3449818uid=1900046 When I saw the title, Why There Should Probably Be No Windows in the Data Center, it piqued my interest. ;) As I mention in the subject, it turned out to be false advertising. -- 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: TIOT filling up: too many dynamic concatenations
David Eisenberg wrote: The problem is that I have reached a practical limit of approximately 540 files in the folder, because when I reach that point, I get a dynamic concatenation ABEND due to the TIOT filling up. I am told that our TIOT size is the default of 32K, which would allow for a maximum of 1,635 DDs in a job step. It would seem, however, that something in my allocation/concatenation loop is preventing me from reaching that number of files. There are only a handful of other DDs allocated to the step (e.g., STEPLIB, etc). Which abend code? Is there no dump? A dump will show you what's in the TIOT. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Eisenberg Sent: Wednesday, April 09, 2008 1:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: TIOT filling up: too many dynamic concatenations Anyone, I have a mainframe assembler application which is invoking Unix system services to get the names of all of the files in an NFS-mounted folder. The application dynamically allocates and logically concatenates these files into one giant dataset, then uses QSAM macros to read it. [snip] If I were able to handle up to 750 (or perhaps 1,000) files at a time, it would be of immense help. At the moment, our only option seems to be to split up the files into multiple folders of 500 files each. Do I have any other options? Thanks so much. David Why do you concatenate them that way? Why not just find/open/process each independently? Or if you prefer, find all of them, then in a loop (allocate, open, process, deallocate) each individually? Yes, it is a bit more difficult to program, but it is infinitely scalable. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
Ed, Field S99ERROR (after the dynamic concatenation request to DYNALLOC) is coming back with a value of X'0238': Space unavailable in task input output table (TIOT). The manual says that the application should Reduce the total number of allocated DDs and devices. Deallocate data sets that are not needed simultaneously. The only way I've found to reduce the total number of allocated DDs is to reduce the number of files in the folder. I can't deallocate any of the component allocations once they've been concatenated. I did use IDF to step through and watch the TIOT grow. With each new concatenation call, there is an entry which keeps growing in size until the TIOT fills up. I think that what I need to know is if I'm missing some approach/technique that can get around what is probably a legitimate limitation. David -- 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: SPFEDIT does a RESERVE!?!
Why not simply convert all reserves? One reason is that reserve is fast and cheap. An enqueue involves a negotiation with all interested parties over a commutations Link. Can be v e r y s l o w. I've been converting them for years. With GRS*, fast coupling links, and today's DASD, the difference is not noticable. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
Yes, it is a bit more difficult to program, but it is infinitely scalable. Of course, you are correct. I took this approach because I have inherited a pre-existing application that used to read a single mainframe dataset. It's only recently that the capability to read multiple files via NFS was made necessary. My approach worked very nicely until very recently. If I have to modify the application to work the way you've suggested, then of course, I will. David -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.4-1.7 gotchas
Were unable to do any SPUFI commands due to RACF authorization. This fixed that. //STEP1 EXEC PGM=IKJEFT01,DYNAMNBR=20 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * SETROPTS GENERIC(DSNR) RDEFINE DSNR ** UACC(READ) Can be done in advance on z/OS 1.4 Don't forget JES2 $ACTIVATE command on z/OS 1.4 -- 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: TIOT filling up: too many dynamic concatenations
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Eisenberg Sent: Wednesday, April 09, 2008 1:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: TIOT filling up: too many dynamic concatenations Anyone, I have a mainframe assembler application which is invoking Unix system services to get the names of all of the files in an NFS-mounted folder. The application dynamically allocates and logically concatenates these files into one giant dataset, then uses QSAM macros to read it. The DYNALLOC calls work this way: first, I dynamically allocate the first file in the folder with DDNAME MYFILE. Then the program enters a loop, performing these steps for each remaining file in the folder: 1) Dynamically allocate the file, asking the system to provide the DDNAME (I observe that these are getting the ddnames SYS1, SYS2, etc). 2) Dynamically concatenate MYFILE with the SYSx dataset just allocated (with the permanently allocated attribute on). This works beautifully; when I exit the loop, I can OPEN and GET all the records successfully from MYFILE. The problem is that I have reached a practical limit of approximately 540 files in the folder, because when I reach that point, I get a dynamic concatenation ABEND due to the TIOT filling up. I am told that our TIOT size is the default of 32K, which would allow for a maximum of 1,635 DDs in a job step. It would seem, however, that something in my allocation/concatenation loop is preventing me from reaching that number of files. There are only a handful of other DDs allocated to the step (e.g., STEPLIB, etc). If I were able to handle up to 750 (or perhaps 1,000) files at a time, it would be of immense help. At the moment, our only option seems to be to split up the files into multiple folders of 500 files each. Do I have any other options? Thanks so much. snip Try putting DYNAMNBR=1024 on your EXEC card. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Modify DSCB information
On Wed, 9 Apr 2008 10:48:10 -0400, Dave Salt [EMAIL PROTECTED] wrote: If you have SimpList installed you can ... snip You forgot the shameless plugtag. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to format the current linkage stack for a SLIP dump taken in SRB mode?
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 04/09/2008 04:20:11 AM: I certainly would hope that the system automatically SUMLISTs the linkage stacks. Does the SLIP SL operand support indirect address off of control registers? The linkage stack should be in the SUMDUMP. VERBX SUMDUMP provides a list of the areas that are in the SUMDUMP. SLIP does not support indirect addressing from a control register. 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: SPFEDIT does a RESERVE!?!
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Wednesday, April 09, 2008 1:36 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SPFEDIT does a RESERVE!?! Why not simply convert all reserves? One reason is that reserve is fast and cheap. An enqueue involves a negotiation with all interested parties over a commutations Link. Can be v e r y s l o w. I've been converting them for years. With GRS*, fast coupling links, and today's DASD, the difference is not noticable. - No coupling facility, so basic sysplex. XCF signalling via a ESCON CTC. That's all I have. The CF was nixed due to cost. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
OA22578 NEW FUNCTION (GRS) migrate GRSRNL=EXCLUDE environment to full RNLs without requiring a sysplex-wide outage
Interesting APAR OA22578 NEW FUNCTION (GRS) http://publibz.boulder.ibm.com/zoslib/pdf/OA22578.pdf PTF List: Release 73J : UA40237 available 08/04/09 (1000 ) Release 730 : UA40235 available 08/04/09 (1000 ) Release 74J : UA40238 available 08/04/09 (1000 ) Release 740 : UA40236 available 08/04/09 (1000 ) * USERS AFFECTED: All users of hbb7730 and up in a Parallel* * Sysplex and GRS STAR environment * * PROBLEM DESCRIPTION: See problem summary.* * RECOMMENDATION: * Installations that desire to switch from GRSRNL=EXCLUDE to standard RNLs must schedule a sysplex-wide outage in order to perform the migration. GRSRNL=EXCLUDE is a special mode where GRS excludes most SYSTEMS (global) level ENQs to SYSTEM (local) level scope. PROBLEM CONCLUSION: TEMPORARY FIX: COMMENTS: This SPE contains function which provides a migration path from a GRSRNL=EXCLUDE environment to full RNLs without requiring a sysplex-wide outage for certain environments. It will require that only one STAR mode system remains in the sysplex before the function can be used. This function is disabled by default and a DIAGxx setting will be required to enable it. Specifics on enabling this function can be obtained from the IBM Washington Systems Center by sending Nat Stevenson an email at [EMAIL PROTECTED] Please consider these questions prior to contacting the Washington Systems Center: * Are you sharing any resources (DASD) outside of the sysplex? * Do you have a need to perform this migration without a sysplex-wide outage? Extensive planning is required before making any changes to the Resource Name Lists (RNLs) as any errors in their configuration can lead to deadlocks or data integrity errors. Consult the manuals of installed applications for details on how to configure their ENQs. Note that once migrating to the specified RNLs, the only way to move back to GRSRNL=EXCLUDE is a sysplex-wide outage. Additionally note that there is no FORCE option for changing from the specified RNLs to another set of RNLs therefore long held resources could delay such a change indefinitely requiring cancellation of jobs or even a sysplex-wide outage to complete. Consult the GRS Planning Guide for more information on this function. Documentation updates for this APAR can be found in http://publibz.boulder.ibm.com/zoslib/pdf/OA22578.pdf This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic 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
Re: TIOT filling up: too many dynamic concatenations
Hi Ed: Maybe not the best solution but you can increase the size of the TIOT in the ALLOCxx parmlib member in the z/OS MVS Initialization and Tuning Reference _http://publibz.boulder.ibm.com/epubs/pdf/iea2e261.pdf_ (http://publibz.boulder.ibm.com/epubs/pdf/iea2e261.pdf) page 73. The maximum size is 64K. Regards, Gene **Planning your summer road trip? Check out AOL Travel Guides. (http://travel.aol.com/travel-guide/united-states?ncid=aoltrv000316) -- 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: TIOT filling up: too many dynamic concatenations
Try putting DYNAMNBR=1024 on your EXEC card. Just tried it; no good. Same result as before. Thanks, though. David -- 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: TIOT filling up: too many dynamic concatenations
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Eisenberg Sent: Wednesday, April 09, 2008 1:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: TIOT filling up: too many dynamic concatenations Yes, it is a bit more difficult to program, but it is infinitely scalable. Of course, you are correct. I took this approach because I have inherited a pre-existing application that used to read a single mainframe dataset. It's only recently that the capability to read multiple files via NFS was made necessary. My approach worked very nicely until very recently. If I have to modify the application to work the way you've suggested, then of course, I will. David Ah. That makes sense. I hate changing code. Hum, you could use the UNIX cat program to catenate all the files together into a single file somewhere, then read that. In a shell script, I'd do something like: #!/bin/sh cd /nfs/directory/to/scan cat * ~/all.files process ~/all.files You didn't say what language you are writing in. But you can dynamically invoke the /bin/cat program from almost anything via the BPXWUNIX subroutine. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Modify DSCB information
I usually put the Shameless plug tag if the solution being offered is a bit of a stretch from what the person is asking for. But in this case, the ability to change data set attributes is just one of the many time saving features SimpList offers . ;-) Dave Salt See the new SimpList(tm) rollover image at: http://www.mackinney.com/products/SIM/simplist.htm Date: Wed, 9 Apr 2008 13:51:46 -0500 From: [EMAIL PROTECTED] Subject: Re: Modify DSCB information To: IBM-MAIN@BAMA.UA.EDU On Wed, 9 Apr 2008 10:48:10 -0400, Dave Salt wrote: If you have SimpList installed you can ... You forgot the tag. :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Turn every day into $1000. Learn more at SignInAndWIN.ca http://g.msn.ca/ca55/213 -- 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: SPFEDIT does a RESERVE!?!
No coupling facility, so basic sysplex. XCF signalling via a ESCON CTC. That's all I have. The CF was nixed due to cost. With two systems (which, iirc, you have), simple XCF signalling should be enough. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
You didn't say what language you are writing in. Mainframe assembler. Your suggestion would work, but then I would have to get into an argument with the network guys when I tell them that I need twice as much disk just so that I can do a physical concatenation of all of the files. I don't think I have a leg to stand on, given that there is a programmatic, scalable solution (i.e., processing each file on its own). I think that I might have to modify the appllication... David -- 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: TIOT filling up: too many dynamic concatenations
Try putting DYNAMNBR=1024 on your EXEC card. Just tried it; no good. Same result as before. That's because your TIOT size is still 32K. As somebody stated, the short term solution is to bump it up to 64K. The long term would be (imo) re-write the programme to open one file at a time. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OA22578 NEW FUNCTION (GRS) migrate GRSRNL=EXCLUDE environment to full RNLs without requiring a sysplex-wide outage
Release 73J Release 730 Release 74J Release 740 What releases of z/OS do these correspond to? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OA22578 NEW FUNCTION (GRS) migrate GRSRNL=EXCLUDE environment to full RNLs without requiring a sysplex-wide outage
Ted MacNEIL wrote: Release 73J Release 730 Release 74J Release 740 What releases of z/OS do these correspond to? z/OS 1.8 and 1.9. -- 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
Dynamic PER Traps
Hi, All, How quickly does the first of a pair of SLIP IF traps arm the second one? I have a situation wherein I may need to trap an IF in a common routine only when it's called from a specific location within a specific program. The route from the caller to the common routine goes thru some IBM OCO code, so I can't say with confidence how long it would take to get from the caller to the callee. TIA, -jc- -- 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: OA22578 NEW FUNCTION (GRS) migrate GRSRNL=EXCLUDE environment to full RNLs without requiring a sysplex-wide outage
1.8 and 1.9 (English **, Japanese **J) Subject: Re: OA22578 NEW FUNCTION (GRS) migrate GRSRNL=EXCLUDE environment to full RNLs without requiring a sysplex-wide outage Release 73J Release 730 Release 74J Release 740 What releases of z/OS do these correspond to? -- 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: OA22578 NEW FUNCTION (GRS) migrate GRSRNL=EXCLUDE environment to full RNLs without requiring a sysplex-wide outage
1.8 and 1.9 (English **, Japanese **J) Thanks. Being out of work for awhile can make you lose touch with small things. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.4-1.7 gotchas [EMAIL PROTECTED]
??? AFIAK there is no fix, microcode or otherwise, for the segmentation offload problem. I think the default has since been changed been changed to off. Also, it did not affect old OSA cards, it affects ALL OSA Express cards. There was also no need to POR, or even IPL, to recover the card, all that is needed is to configure it offline to ALL LPARs, and then back on. [EMAIL PROTECTED] 4/9/2008 12:46 PM One that got us was the TCPIP profile default for the SEGMENTATIONOFFLOAD changed from NO to YES. This attempts to offload some of the TCPIP packet handling from the processor to the OSA card. If you have an old(ish - ours was from 2006/2007) version of the OSA Express/Express2 card, it will lock up under certain high workload conditions, and all IP traffic to and from the machine will stop. The only resolution is a full Power-on Reset - an IPL is not enough. There is a microcode fix for the OSA, however the workaround is to explicitly specify NOSEGMENTATIONOFFLOAD on a GLOBALCONFIG statement in your TCPIP profile, on all LPARs that run a TCPIP stack. It's a known problem apparently. We thought we'd been quite thorough in our prep too, but we missed it. Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Note that my email domain has changed from jo-annstores.com to joann.com. Please update your address book and other records to reflect this change. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.4-1.7 gotchas
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Scott Rowe ??? AFIAK there is no fix, microcode or otherwise, for the segmentation offload problem. I think the default has since been changed been changed to off. Also, it did not affect old OSA cards, it affects ALL OSA Express cards. There was also no need to POR, or even IPL, to recover the card, all that is needed is to configure it offline to ALL LPARs, and then back on. I believe you're correct. We're waiting for the same fix which, last we heard, is due sometime in 2Q2008. -jc- -- 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: TIOT filling up: too many dynamic concatenations
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Eisenberg Sent: Wednesday, April 09, 2008 2:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: TIOT filling up: too many dynamic concatenations You didn't say what language you are writing in. Mainframe assembler. Your suggestion would work, but then I would have to get into an argument with the network guys when I tell them that I need twice as much disk just so that I can do a physical concatenation of all of the files. I don't think I have a leg to stand on, given that there is a programmatic, scalable solution (i.e., processing each file on its own). I think that I might have to modify the appllication... David I think that is the best idea. Hopefully it won't be too difficult. I can think of some other methods, but they are very UNIXy and weird. Such as creating a named pipe, fork()'ing then exec()'ing /bin/cat in the child to write to the pipe which is then read with QSAM in the parent. This would eliminate the second copy of the data. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
On Wed, 9 Apr 2008 13:16:58 -0500, David Eisenberg wrote: I have a mainframe assembler application which is invoking Unix system services to get the names of all of the files in an NFS-mounted folder. The application dynamically allocates and logically concatenates these files into one giant dataset, then uses QSAM macros to read it. ,,, Do I have any other options? Thanks so much. Create a named pipe (FIFO). Allocate that FIFO as input to your existing application. Run your directory scanner concurrently (fork(), spawn(), or ATTACH) with your existing program. As it encounters each file in the folder, it should copy it into the FIFO (Hmmm. Need to keep a descriptor of the FIFO open, not open it each time.) Only one allocation. Actually, you might call cat(1) with as many file arguments as you've mentioned, and pipe its output into your assembler program. Plan C: Take your question to MVS-OE. -- gil -- 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: SPFEDIT does a RESERVE!?!
On Wed, 9 Apr 2008 18:36:08 +, Ted MacNEIL [EMAIL PROTECTED] wrote: Why not simply convert all reserves? One reason is that reserve is fast and cheap. An enqueue involves a negotiation with all interested parties over a commutations Link. Can be v e r y s l o w. I've been converting them for years. With GRS*, fast coupling links, and today's DASD, the difference is not noticable. - John has no CFs. Not even sure if he has FICON CTCs. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problem with CA-1
On Wed, 9 Apr 2008 10:03:39 -0500, Yukus, Mary J CIV USMEPCOM [EMAIL PROTECTED] wrote: Hi Everyone, We are having a problem with CA-1 which CA believes is not a CA problem. We are trying to upgrade from v11 to v11.5. When we implement the v11.5 we have the following problems. The first is a problem with multiple files on a tape. When it complete the 4th file, we get the following error. The exact JCL works file on our system once we back out the new version of CA-1. snip We have verified this was not a user error. For some reason it appears that the new CA-1 was reading the old tape label even though it was a scratch tape. (we do not reinit the tapes before putting them in scratch status) Does anyone know if we missed some options somewhere that is causing this? Both these problems go away when we go back to the old version. We performed many 11.0 to 11.5 conversion and some from 5.2 to 11.5 and some from TLMS to CA-1 11.5. Had no problems with any of them. Did all the intercepts apply correctly in TMSINIT? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
