Re: Unable to complete IPL - message IOS120D
Thanks for all your replies. I did start JES2 with 'WARM,NOREQ' and I did a $S to make sure. I made sure I could do JES2 Commands - and did a $dspool, and it showed 98.4% full - I seem to have lots of SMTP jobs in my output - so I purged some randomly, and got the level down to 90%, and then things started. I don't know why there are so many SMTP job outputs, and if they are big, or we have a small test SPOOL. When I get onto TSO, then I can investigate more. Nigel -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: VS: Soft Capping
Ted's right. I've just seen a case where a customer screwed up performance by setting the cap too low. And that WASN'T the first time I'd seen it. Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTOC size
Bill, Mate, you have to update your disk drive knowledge a bit. It's been a long time since a single 56664 track would fit on 3.5 inch disk. If you look at the current crop of 300GB 15K RPM the maximum transfer rate of the disk is 1441Mb/sec. At 4ms per rotation, that would mean largest track size can be estimated as ((4/1000)*1441)=5.764Mb. That's about 720KB per zone 0 track: nearly a full CKD CYL in a single track. However the sustained data rate is 72-123MB/sec, which is still 30 times faster than a SLED. The speed depends on which zone the data is coming from - inside tracks vs outside tracks. Also consider that pre-fetch in Disk Arrays is in parallel from multiple spindles, to the point where in most cases the backend pre-fetch can stay ahead of a single threaded sequential read. I think it is a long time since backups operated as single track IO. With the prevalence of half track blocks and default five buffers for SAM-E even the much maligned IEBGENER will read 2.5 tracks in a chained SSCH. I usually see DFSMSdss Dumps using OPT(4) which operates at 1CYL per I/O. Just to verify my point, the 377MB/sec for a port was actually 16 ports doing sequential IO from 1024 disk drives for an aggregate 6032MB/sec. We drove this with 64 FX4 channels fanned into 16 Ports. That's 6MB/sec/spindle with 100% sequential cache hit (meaning pre-fetch stayed ahead of Host reads). For the naysayers, these were not little datasets living in cache. These were 2048 datasets of 4001 CYLs each read front to back. That's why I think that 50MB/sec is a good, conservative, working number for most backup products. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Friday, February 08, 2008 2:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] VTOC size In a message dated 2/8/2008 3:45:21 P.M. Central Standard Time, [EMAIL PROTECTED] writes: On FICON it would be reasonable to expect to get 50MB/sec to and from your Disk and tape drives. ... So 54,000MB at 50MB/sec is 1080 seconds, or 18 minutes. I may be wrong, but I think backup/archive/retrieval/migrate products that are operating on a whole volume level do each track serially, so a backup of a really huge volume would be limited by the slowest part of the I/O path which I believe will be the rotation speed of the disks. No matter how big the controller's cache is, sooner or later a backup of an entire really huge volume is going to slow down to match the track rotational speed. The SLED 3390 rotated at 70 RPS, which at 57K per track yielded about 4MB/second. RAID disks rotate a lot faster than the 3390 did, but I think it's on the order of twice the RPS rather than 10 to 20 times as fast. I would expect that a controller could not cram more than 10MB per second into that 50MB FICON channel unless the backup product is doing some kind of multitasking or similar operation whereby it can do multiple large-scale reads at the same time. There's no other way to break the rotation barrier. Do backup products work like that yet? 54000 MB at 10MB/second = 5400 seconds = 90 minutes. Bill Fairchild Rocket Software **Biggest Grammy Award surprises of all time on AOL Music. (http://music.aol.com/grammys/pictures/never-won-a- grammy?NCID=aolcmp00300025 48) -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: JES2 NJE question: SNA(CTC) vs. TCPIP
Is there any reason to consider using TCPIP NJE instead of the old-fashioned VTAM NJE? The reason we use TCPIP instead of VTAM is that we don't have VTAM connectivity between all of our systems. NJE/TCPIP is pretty easy to set up and works well with the exception of some known glitches that are being addressed (e.g. automatic restart when a connection drops). I suspect in your case it comes down to: 1. Do you want to play with NJE/TCPIP? 2. How long will your VTAM network remain in place? 3. Do you need NJE connectivity to anyplace outside of your VTAM network? If you just want to experiment, the definitions can be easily removed when you have finished. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
New MFNetDisk free tutorial.
HI, I create a new tutorial and I upload it in http://www.megaupload.com/?d=OOQ8DFD3 The current version of MFNetDisk is the best version so far. This version has significant improvement in the performance (minimal CPU MF utilization) and stabilization. I used for the video, version 10 from 9 Jan 2008. The tutorial was created in one shoot. No editing and no manipulate the video. What you see is what you get. See for yourself what the product can do for you. I also in processing to put the video in YouTube. I hope I will succeed with this mission, I will let you know. Thanks, Shai -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: VTOC size
In a message dated 2/9/2008 5:34:12 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Mate, you have to update your disk drive knowledge a bit. It's been a long time since a single 56664 track would fit on 3.5 inch disk. ... largest track size can be estimated as ... nearly a full CKD CYL in a single track. You're right. I was assuming that one RAID track holds only one emulated 3390 track. in most cases the backend pre-fetch can stay ahead of a single threaded sequential read. And having unlimited CCW prefetch now as an option in the LPAR helps get multiple tracks' data into central storage faster than single threading. I think it is a long time since backups operated as single track IO. I didn't mean to imply they only read one track per I/O. I meant they read the volume sequentially. They can chain up 1,000 tracks per I/O request if they want and if they have enough real storage. But they still go through the whole volume sequentially. The first such I/O reads tracks 0-999 while maybe a second buffer is reading in tracks 1000-1999. When 0-999 are written to tape, tracks 2000-2999 start being read (if BUFNO is only 2). Etc. Multiple tracks per I/O, but still reading sequentially through the volume with only one process (task) that may be doing multiple simultaneous channel programs (as in SAME's BUFNO1). With BUFNO=huge you would not to have multiple tasks copying different parts of the volume simultaneously. At one cylinder per BUFNO, you could get 100 such I/Os running together with a mere 150MB of real storage tied up (75 for DASD in and another 75 for tape out). That's not very much real these days. A shop with really huge volumes is also likely to have a really huge amount of central storage. Bill Fairchild Rocket Software **Biggest Grammy Award surprises of all time on AOL Music. (http://music.aol.com/grammys/pictures/never-won-a-grammy?NCID=aolcmp00300025 48) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GETMSG RC=4 after going from z/0S 1.7 from 1.4
REXX execs in TSO batch issuing operator commands and reading the
returned messages have started failing to get the messages most but not
all of the time now that we have gone to z/OS 1.7. For instance:
15 *-* SAY 'TIME: 'TIME()
TIME: 16:31:23
TIME: 16:31:23
16 *-* CONSPROF SOLDISPLAY(NO) SOLNUM(199) /* NO NESC. FOR
GETMSG */
CONSPROF SOLDISPLAY(NO) SOLNUM(199)
17 *-* CONSOLE ACTIVATE /* GET INTO CONSOLE
MODE */
CONSOLE ACTIVATE
18 *-* CONSOLE SYSCMD(D U,TAPE,ALLOC) CART('DUDASD')
CONSOLE SYSCMD(D U,TAPE,ALLOC) CART('DUDASD')
19 *-* GETCODE = GETMSG('MSG.','SOL','DUDASD',,99)
4
Up until z/OS 1.7, the GETCODE return code would always be zero even
with the wait time coded as 5 instead of the 99 seconds I have specified
here. The SYSLOG shows
16:31:23.95 CCFTLS 0290 D U,TAPE,ALLOC
16:31:23.97 CCFTLS 0090 IEE455I UNIT STATUS NO DEVICES WITH
REQUESTED ATTRIBUTES
16:31:24.00 JOB01650 0290 IEE455I UNIT STATUS NO DEVICES WITH
REQUESTED ATTRIBUTES
Does anyone have an idea of how to remedy this?
Tom Sipusic
--
For IBM-MAIN subscribe / signoff / archive access instructions,
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 help on running clist in batch mode in z/os system
That is because you are executing the CLIST under batch ISPF (ISPSTART), not just under batch TSO. It is not the CLIST (or REXX EXEC) RC that determines the job step completion code in this environment, but the RC from ISPF. Check the ISPF documentation. To alter the ISPF return code you need to use VPUT to save the desired ISPF return code into variable ZISPFRC in the SHARED pool before terminating the CLIST, as in SET ZISPFRC = 4 ISPEXEC VPUT (ZISPFRC) SHARED sri wrote: When run this job I am getting rc 20 in the clist output. Though job completed with cond code of 00. This clist reading flat file and erasing the ispf table member and recrestes in the isptabl library. It used to work fine in os/390. Atlast we upgraded the os to Z/os 1.8. //JOBCARD //EFT01050 EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(0,LT) //ISPPROF DD DISP=SHR,DSN=TEST.XTXT.ISPFPROF //SYSPROC DD DISP=SHR,DSN=Y166.CLIST //ISPPLIB DD DISP=SHR,DSN=SYS2.XTXT.ISPFPLIB.SMT //ISPMLIB DD DISP=SHR,DSN=SYS2.XTXT.ISPFMLIB.SMT //ISPSLIB DD DISP=SHR,DSN=SYS2.XTXT.ISPFSLIB.SMT //ISPTLIB DD DISP=SHR,DSN=SYS2.XTXT.ISPFTLIB.SMT // DD DISP=SHR,DSN=XTX.DIALOG.ISPTLIB //ISPTABL DD DISP=SHR,DSN=XTX.DIALOG.ISPTLIB //ISPLOG DD DUMMY,BLKSIZE=0 //SYSTSPRT DD SYSOUT=* //SYSUDUMP DD SYSOUT=I //SYSTSIN DD * ISPSTART CMD(%ERSTABL) /* SAMPLE of THE CLIST IS PROC 0 DEBUG CONTROL LIST CONLIST SYMLIST MSG END(DEND) ISPEXEC TBERASE TESTTABL LIBRARY(ISPTABL) SET RC = LASTCC IF (RC NE 0) THEN DO WRITE ** WRITE * TBERASE RETURN CODE: RC WRITE ** DEND END IN SDSF READY %ERSTABL ** * TBERASE RETURN CODE: 20 ** READY END IF YOU EXECUTE THIS CLIST TSO EX 'PDS(ERSTABL)' it works fine. So can anyone tell me why is this is happening in bacth mode. Thanks Ravi -- Joel C. Ewing, Fort Smith, AR[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: Wheeler Postings (Was: How does ATTACH pass address of ECB to child?)
In [EMAIL PROTECTED], on 01/22/2008 at 04:12 PM, Van Dalsen, Herbie [EMAIL PROTECTED] said: I should not ask the question, but do they exist or is it a 'virus' inside IBM-MAIN? Google for Wheeler Scheduler. Yes, I find the long URL lists and the repetitive OT paragraphs to be frustrating, but I also find that they provide a wealth of interesting historical data. I hope that they keep posting for a long time. -- 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: Data Erasure Products
In [EMAIL PROTECTED], on 02/08/2008 at 09:36 AM, R.S. [EMAIL PROTECTED] said: Don't you think, the magic numbers of the rewrites comes from voodoo (or black magic) rather than from technological reasons ? No. Any disk taken (stolen) from DASD array contains part of gazillion-elements-puzzle. Without any overwrite. If you overwrite the data, The question in dispute is what it takes to successfully overwrite the data. Believing that you've overwritten them isn't good enough. -- 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
IBMLink down Sev 1 ticket 34623947
Attempts to use IBMLINK Web get Error Internal server error An internal server error occurred while processing your request. Please try again or report the problem to IBMLink customer support. After waiting about 12 minutes finally got to the help desk staff then another wait since they thought everything was fine. They found that they also could not get in and Sev 1 ticket 34623947 was already open since 12:48pm EST no ETA for uptime. I pointed out the recorded message was not updated from Friday or +7 hours into an outage. They are going to update it now. I don't believe this suggests that the communication problems we have complained about or the technical problems are getting better. Since I am not going to have someone paged for research and a PMR update I am out of luck tonight. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... 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
