Re: Sequential Data Striping

Ron, I have decided to use/setup data striping - guaranteed space with volume count allocation. However I noticed when I allocate the QSAM file and checked the file attribute, it says striped count = 1, but with the total number of striped equal to what is specified in the volume count of the data

Re: TIOT filling up: too many dynamic concatenations

>Remember, z/OS emulates UNIX -- a CAT/READ/de-allocate is still >just as expensive. > >It may quack like a duck; walk like a duck; it is an emulated duck. There is no such thing as allocation and deallocation in UNIX, incluiding z/OS UNIX. The z/OS UNIX kernel, more specifically, the physical

Re: TIOT filling up: too many dynamic concatenations

>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. If this hasn't chang

SVCDUMP capture phase statistics.....

..and how to interpret them. Yesterday connect:direct took another of those abend0c4 that Sterling always tells us 'they're all fixed'. They're all from ISTAICPT in SRB mode... And of course they always occur in production where there is extremely high load (both CPU and workload) The problem

Re: TIOT filling up: too many dynamic concatenations

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin > Sent: Wednesday, April 09, 2008 7:47 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: TIOT filling up: too many dynamic concatenations > > > On Wed, 9 Apr 2008 19:13:19 -0400,

Re: Onboard Timer

Hi Hal, As Alan indicated, its the feature is called: Server Time Protocol ( STP ). There are two IBM Redbooks, one titled: Server Time Protocol Implementation Guide ( SG24-7281 ) and the other titled: Server Time Protocol Planning Guide ( SG24-7280 ). Both of these books have been recently (

Re: TIOT filling up: too many dynamic concatenations

>How would the performance of a scheme that "allocates, opens, reads, closes, >and unallocates each file sequentially" (or concatenated, which still does >most of the same work) compare with allocating a single POSIX pipe and using BPX1* system calls to copy the various NFS files into it? My gu

Re: TIOT filling up: too many dynamic concatenations

On Wed, 9 Apr 2008 19:13:19 -0400, Jim Mulder wrote: > > Is it necessary to concatenate all of the files? Could you >restructure the program so that it allocates, opens, reads, closes, >and unallocates each file sequentially? If the purpose is simply >to read and process all of the records in al

Re: TIOT filling up: too many dynamic concatenations

On Wed, 9 Apr 2008 17:52:47 -0500, Paul Gilmartin <[EMAIL PROTECTED]> wrote: > >But this provokes an interesting question: If (as I believe) HFS >data sets are dynamically allocated in the OMVS address space >(that's what's cited when I try to delete one), isn't OMVS at >extreme hazard of impactin

Re: TIOT filling up: too many dynamic concatenations

IBM Mainframe Discussion List wrote on 04/09/2008 02:16:58 PM: > 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 int

Re: TIOT filling up: too many dynamic concatenations

On Wed, 9 Apr 2008 16:15:26 -0500, McKown, John wrote: >> -Original Message- >> [mailto:[EMAIL PROTECTED] On Behalf Of Traylor, Terry >> Sent: Wednesday, April 09, 2008 4:11 PM >> >> The dataclass Dynamic Volume Count (DVC) is (DSN DD + DVC amount) for >> each dataset allocated. If the DV

Re: z/OS-MVS Control Block Layout - Offsets

Michael Stack wrote: At 05:01 PM 4/9/2008 -0300, you wrote: In <[EMAIL PROTECTED]>, on 04/08/2008 at 09:00 AM, Stan Weyman <[EMAIL PROTECTED]> said: Does anyone have a text, PDF or whatever file that shows the MVS control block layout, offset, fields, relation to other control blocks, et

Re: z/OS-MVS Control Block Layout - Offsets

At 05:01 PM 4/9/2008 -0300, you wrote: >In <[EMAIL PROTECTED]>, on 04/08/2008 > at 09:00 AM, Stan Weyman <[EMAIL PROTECTED]> said: > >>Does anyone have a text, PDF or whatever file that shows the MVS >>control block layout, offset, fields, relation to other control blocks, >>etc that is som

Re: z/OS-MVS Control Block Layout - Offsets

In <[EMAIL PROTECTED]>, on 04/08/2008 at 09:00 AM, Stan Weyman <[EMAIL PROTECTED]> said: >Does anyone have a text, PDF or whatever file that shows the MVS >control block layout, offset, fields, relation to other control blocks, >etc that is somewhat current? There was a pointer diagram i

Re: Web Interfaces (was: Broken LISTSERV)

In <[EMAIL PROTECTED]>, on 04/09/2008 at 11:46 AM, Paul Gilmartin <[EMAIL PROTECTED]> said: >Right. Even as the web interface isn't IBMLink. I'm not sure in that case; they may have done substantial rewriting. FWIW, I prefer the 3270 version. -- Shmuel (Seymour J.) Metz, SysProg and

Re: TIOT filling up: too many dynamic concatenations

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Traylor, Terry > Sent: Wednesday, April 09, 2008 4:11 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: TIOT filling up: too many dynamic concatenations > > > The dataclass Dynamic Volume Count

Re: TIOT filling up: too many dynamic concatenations

The dataclass Dynamic Volume Count (DVC) is (DSN DD + DVC amount) for each dataset allocated. If the DVC is 20, the that would equate to 21 DDs in TIOT times however many datasets allocated. Terry Traylor -- For IBM-MAIN subsc

Re: Onboard Timer

Are you referring to Server Time Protocol? There are two red books discussing it. You also need a $$$ microcode feature turned on. Alan Subject: Onboard Timer Once upon a time, there was talk of how the sysplex timer was to be replaced by some timer application that ran on the HMC. The require

Onboard Timer

Once upon a time, there was talk of how the sysplex timer was to be replaced by some timer application that ran on the HMC. The requirements were a certain level of microcode on a z/9 box and z/os 1.7. I think we are there, and would like to look at the feature. Anyone done this? Anyone

Re: z/OS 1.4->1.7 gotchas

>going to goal mode with WLM. I must be misunderstanding your context. COMPAT Mode hasn't been supported since either 1.2 or 1.3. We had to convert going from 2.10 to 1.4. - Too busy driving to stop for gas! -- For IBM-MAIN subs

Re: z/OS 1.4->1.7 gotchas

I just did this last year and as others have said the JES changes were a biggie, as well as going to goal mode with WLM. The other issue was the console rewrite and some of our RACF rules and the subsystems. The ever increasing size of the ROOT keeps amazing me. In general, it's relatively pain

Re: CF pricing [was: SPFEDIT does a RESERVE!?!]

>CFL It's not called a CFL, either. It's called an ICF (Internal Coupling Facility) - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with t

Re: z/OS 1.4->1.7 gotchas

>But I seem to recall a firmware refresh fixing this - Config OSA off/on. I >don't recall needing a POR to change this parameter. POR shouldn't be required, at all. Like the old IRMA cards, the microcode is loaded everytime the card is refreshed. - Too busy driving to stop for gas! ---

Re: SPFEDIT does a RESERVE!?! A<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

What is all the cr*p after !?!. I use a BlackBerry, and this doesn't show up with mine. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with t

Re: CF pricing [was: SPFEDIT does a RESERVE!?!]

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews > Sent: Wednesday, April 09, 2008 3:03 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: CF pricing [was: SPFEDIT does a RESERVE!?!] > > > On Wed, 2008-04-09 at 14:02 -0500, McKown, J

Re: SPFEDIT does a RESERVE!?! A<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Scott Rowe > Sent: Wednesday, April 09, 2008 3:15 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: SPFEDIT does a RESERVE!?! > A<63986815-1207766168-cardhu_decombobulator_blackberry.rim.net > [

Re: z/OS 1.4->1.7 gotchas

On Wed, 9 Apr 2008 11:11:12 -0300, Shmuel Metz (Seymour J.) wrote: >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

Re: SPFEDIT does a RESERVE!?! A<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

John, did you even consider running an ICF on your CPs? I don't know if you have any excess capacity, but it is an option. They don't advise using shared CPs for ICFs in a true data sharing environment, but if all you are using it for is GRS* it can work, and might allow you to convert all res

Re: TIOT filling up: too many dynamic concatenations

On Wed, 9 Apr 2008 14:54:53 -0500, McKown, John wrote: > >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 pi

Re: Dynamic PER Traps

Chase, John wrote: How quickly does the first of a pair of SLIP IF traps "arm" the second one? AFAIK, it happens synchronously with respect to the first one. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL P

CF pricing [was: SPFEDIT does a RESERVE!?!]

On Wed, 2008-04-09 at 14:02 -0500, McKown, John wrote: > No coupling facility, so basic sysplex. XCF signalling via a ESCON CTC. > That's all I have. The CF was nixed due to cost. Sigh. That CF is 1/4 of a z10 chip, already delivered to you and sitting idle. It could have been positioned and mar

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

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 th

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 i

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

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

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

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

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

Re: OA22578 NEW FUNCTION (GRS) migrate GRSRNL=EXCLUDE environment to full RNLs without requiring a sysplex-wide outage

This was discussed at a vendor disclosure. Now that it's public knowledge, I'm just curious about who will actually use it. Before responding, be sure to read all of the caveats. Bob Shannon Rocket Software -- For IBM-MAIN subs

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

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

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? --

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 PROTEC

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

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 thi

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! --

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(

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

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 mess

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 maximu

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 a

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 >

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 ... 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:[EMA

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 i

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

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

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 diffe

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 ar

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 assem

Re: How to format the current linkage stack for a SLIP dump taken in SRB mode?

IBM Mainframe Discussion List 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 pr

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 maxi

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-576&ad=634581&asrc=EM_NLN_3449818&uid=1900046 When I saw

Re: Faxing from the mainframe

We tried once upon a time at a previous employer to install OM/MVS as VM was being retired. After a couple of months a product was procured that was used with some sort of CICS hooks instead. I was had an OV/VM farm of over 5,000 customers. It was a dream for the time. Then the chickens got inv

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 DYNA

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

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

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

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 ---

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 loc

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

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 mess

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 04/09/2008 12:16 PM Please respond to IBM Mainframe Discu

Re: Faxing from the mainframe

When I was at P&H 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 ri

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, ear

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

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

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

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 s

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

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 unre

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 DS

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 re

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

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 documen

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

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-AGG

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 workloa

Re: Modify DSCB information

what about Expiry date of dataset ? Can it be changed ? -- 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. --

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 wh

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 > > > > There's nothing

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 S

Re: Sequential Data Striping

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 tur

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: "

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

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 upgr

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-

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 followi

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 Expansion

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 ma

  1   2   >