CHPID online requires 10-15 min after upgrade to z9

Hi all, Is there anyone try "CF CHP(XX),ONLINE" a FIOCN channel requires 10-15 mins after migrated to z9. Any shop has met before ?? any solution? Any comment will be appreciated Tommy -- For IBM-MAIN subscribe / signoff / arch

Re: New System Build (Part II)

On Fri, 4 Jan 2008 16:49:24 -0600, Tom Marchant wrote: >On Fri, 4 Jan 2008 16:23:23 -0600, Alan Altmark wrote: >> >> (I am >>mystified by tapeless mainframes. How does one take a stand-alone dump? > >DASD Perhaps in z/OS, but in z/VM, a stand-alone dump is written to tape, not dasd. A C

Re: Graphics is reason mainframe is losing was (fwd) Re: Java is becoming the new Cobol

On Jan 5, 2008, at 7:53 PM, Clark F Morris wrote: The following on comp.lang.cobol should give us some food for thought although the mainframe is now being used as a web server. Clark Morris On Sat, 05 Jan 2008 11:22:26 -0600, in comp.lang.cobol Scott <[EMAIL PROTECTED]> wrote: Howard Brazee

Re: z/OS and VM Control Blocks

> 4) What is the proper way to get the CVT time zone? What is obsolete > and what is the way to do it nowadays? Lindy, I received this REXX code from the TSO-REXX mailing list a few weeks ago... /* Courtesy Lionel B Dyck <[EMAIL PROTECTED]>, via the TSO-REX mailing list */ /* ===

Graphics is reason mainframe is losing was (fwd) Re: Java is becoming the new Cobol

The following on comp.lang.cobol should give us some food for thought although the mainframe is now being used as a web server. Clark Morris On Sat, 05 Jan 2008 11:22:26 -0600, in comp.lang.cobol Scott <[EMAIL PROTECTED]> wrote: >Howard Brazee <[EMAIL PROTECTED]> wrote in >news:[EMAIL PROTECTED]

Re: Common Dataspace

Hi Jim, based on the discussion I raised a share requirement to automaticly anchor a CADS to the *MASTER*. Regards Roland > > CADS were not part of the original data space design in >SP3.1.0. They were a quick add-on in SP3.1.3, and as such, >inherited the property that every data space i

Re: z/OS + TSO + ISPF versus z/VM + CMS + ISPF

IBM Mainframe Discussion List wrote on 01/05/2008 05:32:16 PM: > "This invention describes a method that can be used to display panels from > an ISPF panel library using an XEDIT macro written with the REXX language > under IBM's VM operating system." > > This has got to be a hoax, surely? Ap

Re: SMP/E and why not.

On Sat, 5 Jan 2008 17:53:13 -0600, Patrick O'Keefe wrote: > > If you don't mind having incredibly convoluted RESTORE >processes, don't ACCEPT anything except the FUNCTION. There is an >obvious trade off between ACCEPT and RESTORE. > >Perhaps it would be a good enhancement to SMP (SMP/E2?

Re: how to cut down RACF auth & run rexx under diff auth

On 5 Jan 2008 14:44:21 -0800, in bit.listserv.ibm-main (Message-ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (Aman Naqvi) wrote: We have two security operations teams who are defined in RACF with the group-Special attribute and hold CLAUTH on a class to define profiles. The issue is that we ne

Re: JCL parms

On Sat, 5 Jan 2008 19:44:19 -0400, Clark Morris wrote: >On 4 Jan 2008 13:50:22 -0800, in bit.listserv.ibm-main you wrote: > >>Gil, >>We're strictly talking _JCL_-_PARM_ parameters here, where there does exist >>a 100-byte length limit imposed by JCL syntax rules. >>Passing parameter values from on

Re: SMP/E and why not.

On Sat, 5 Jan 2008 14:49:54 -0600, Paul Gilmartin <[EMAIL PROTECTED]> wrote: >... >There are complications. It's a BAD limitation of SMP/E's RESTORE >that it can restore to no level earlier than the last ACCEPT (and >often to no level later than that). The otherwise generally inferior >VMFMERGE

Re: JCL parms

On 4 Jan 2008 13:50:22 -0800, in bit.listserv.ibm-main you wrote: >Gil, >We're strictly talking _JCL_-_PARM_ parameters here, where there does exist >a 100-byte length limit imposed by JCL syntax rules. >Passing parameter values from one called _program_ to another called >_program_ is a complete

Re: z/OS and VM Control Blocks

Hi Lindy, I suggest you download SHOWzOS from the www.cbttape.org. It doesn't provide all the requested functions but maybe a good starting point You might also look at the delivered SDSF-Source code. Roland >I'm only curious. How many times do things like this come up? > >1) I want to calc

Re: z/OS and VM Control Blocks

In a message dated 1/5/2008 3:09:46 P.M. Central Standard Time, [EMAIL PROTECTED] writes: It was only a question! (-: I certainly didn't mean to upset the status quo. ((--:: >> Don't know what the status quo is. Tuning is an art form suffered by pressures of cost benefit and business requ

how to cut down RACF auth & run rexx under diff auth

Dear all, We have two security operations teams who are defined in RACF with the group-Special attribute and hold CLAUTH on a class to define profiles. The issue is that we need to cut down their access. The task is to only provide these teams access through Panels/REXX and to cut off their

Re: z/OS + TSO + ISPF versus z/VM + CMS + ISPF

On Sat, 5 Jan 2008 14:46:40 -0600, Mike Baldwin wrote: >Here is an interesting IBM patent in this area: >United States Patent 5724559 >Method for displaying ISPF panels in a VM non-ISPF environment ... >http://www.patentstorm.us/patents/5724559-claims.html "This invention describes a method that c

Re: iSCSI v FICON

>>> On Sat, Jan 5, 2008 at 2:31 PM, in message <[EMAIL PROTECTED]>, "R.S." <[EMAIL PROTECTED]> wrote: -snip- > Since mainframe does not support iSCSI, there is no reason to compare > what is cheaper/better/etc. Sure there is. Just to be clear, z/OS !== "mainframe." Linux on the mainframe doe

Re: z/OS and VM Control Blocks

The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Lindy Mayfield) writes: > It was only a question! (-: I certainly didn't mean to upset the status > quo. ((--:: recent post from how i tried to h

Re: my free mainframe product

HI, > You know many people who backup PC hard drives? To what? And some kind of synchronized backup so when multiple restores need to be done the application still works. I can restore multiple backups in the same time. using Multi threading. The data can be in the net or in the same Hard disk.

Re: z/OS and VM Control Blocks

It was only a question! (-: I certainly didn't mean to upset the status quo. ((--:: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell Sent: 5. tammikuuta 2008 22:58 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS and VM Control Blocks

Re: z/OS and VM Control Blocks

In a message dated 1/5/2008 1:48:03 P.M. Central Standard Time, [EMAIL PROTECTED] writes: The 4 volume Control Blocks has much of this information. It isn't easy reading. >>Guess the other option is to check out somebody who's been there before. Dr Merrill's MXG product and book(s) try to

Re: SMP/E and why not.

On Sat, 5 Jan 2008 14:36:37 -0600, Patrick O'Keefe wrote: >On Fri, 4 Jan 2008 22:58:33 -0800, shai hess wrote: > >>... >>Imagine how easy it to return to your old load library in case of error and >>not pray that SMP/E with the APPLY/RESTORE/ACCEPT/RECEIVE/REJECT will work >>fine for you. >>... >

z/OS + TSO + ISPF versus z/VM + CMS + ISPF

On Thu, 3 Jan 2008 17:52:10 -0700, Steve Comstock <[EMAIL PROTECTED]> wrote: >>> Raymond Noal wrote: ...- Will z/OS, TSO ISPF panels and dialogs work under the z/VM, CMS ISPF program product? Is there any degree of compatibility between the two ISPF products? Is there any migration/

Re: SMP/E and why not.

On Fri, 4 Jan 2008 22:58:33 -0800, shai hess <[EMAIL PROTECTED]> wrote: >... >Imagine how easy it to return to your old load library in case of error and >not pray that SMP/E with the APPLY/RESTORE/ACCEPT/RECEIVE/REJECT will work >fine for you. >... That is a hollow argument. If backing out the

Re: JCL parms

On Sat, 5 Jan 2008 15:47:33 -, Phil Payne wrote: > >One thing it did was a GETMAIN for the parm length and a move - and there was >at that time a >solid recommendation to do that. > Ah, but it was for the PARM length, not for 100 characters, so your macro was prepared to handle a CALL with a l

Re: Curiousity question: the processing of DD DUMMY.

On Wed, 2 Jan 2008 21:06:54 -0500, Shmuel Metz (Seymour J.) wrote: > >Off the top of my head, I'd say that it's broken as designed. Another case >of IBM's MVS, OMVS and Unix people not talking to each other, assuming >that you have verified the difference in behavior. > Do you consider the followin

JCL parms

Tom and Rick's comments about moving the PARM. There was once a reason, but I've forgotten it. One of the first things I did when I learnt to write Assembler macros was to write my own initialisation and termination macros, making more use of the save area chain conventions than IBM's equivalen

Re: z/OS and VM Control Blocks

Thank you. While I appreciate people telling me that I can find the info in the Data Areas docs, what usually happens is that I look through them for a few hours and then when I give up either search for some source code that has it or ask on a list. -Original Message- From: IBM Mainfra

z/OS and VM Control Blocks

We have interesting technologies available. It would be relatively trivial to devise an XML Schema that would support fields by name, with attributes including the control block in which they resided, their offsets, means of access of the control block, field characteristics, etc. It's the sort

Re: z/OS and VM Control Blocks

On Sat, 5 Jan 2008 20:14:56 +0100 Lindy Mayfield <[EMAIL PROTECTED]> wrote: :>I'm only curious. How many times do things like this come up? :> :>1) I want to calculate the total CPU time for an address space. Which :>control blocks do I look in for that? :>2) I found the TIOT which lists the DD

IBM Hardware Group in Big Restructuring

Parrots and perches. Once I see a senior manager without a box target I'll start to believe it. IBM's legal challenge to PSI has frozen PSI's business. IBM _may_ have intended to run PSI's money out, but after the third financing round and Microsoft's entry any such hope will have vapourized -

Re: z/OS and VM Control Blocks

Lindy,

Re: JCL procedure parameters

On Sat, 5 Jan 2008 11:03:01 -0600, Kenneth E Tomiak wrote: >SDSF can be run as a separate step or can be called from your program. >Below is a step that will capture the JESJCL output. You then get to read it >and parse it. On the system I can access right now I am not authorized to get >the inter

Re: iSCSI v FICON

Barry Jones wrote: Thanks RS. I thought that if I asked that question FIRST, then I wouldn't receive any replies to the other questions. But, I'm also interested in learning the answers to those questions. Barry, It reminds me the following interview: Are your married? Y/N Your wife's name: .

z/OS and VM Control Blocks

I'm only curious. How many times do things like this come up? 1) I want to calculate the total CPU time for an address space. Which control blocks do I look in for that? 2) I found the TIOT which lists the DD names, but where can I get the datasets allocated to those DD names? 3) How do I know i

Re: my free mainframe product

On Wed, 2 Jan 2008 22:16:04 -0800, shai hess <[EMAIL PROTECTED]> wrote: > Yes, if you need local 3390 it is faster to use directly connect >FICON/ESCON real 3390. Using TCP with MFNetDIsk is a feature which nobody >have and I really do not like to be one of a many OEM which use the real >3390 and

Re: JCL procedure parameters

Internal text may not be pretty but once you decipher the format of it, you have something easy to use compared to the free format JCL is going to be in. SDSF can be run as a separate step or can be called from your program. Below is a step that will capture the JESJCL output. You then get to re

Re: ghost dataset from non-existent catalog on work volume

Not too long ago there was a thread about using apostrophes in JCL around a data set name and circumventing the normal standards we expect for a DSN. With the right parameters, you can now allocate and delete VSAM clusters using just JCL. If this is how it was created, then DISP= (OLD,DELETE),DS

Re: Joys setting up RESOLVER

Each manual has both a comment form you can print then mail and an email address where you can send comments. In my experience, some component owners are hard to accept criticism or do some extra work. Some respond quickly, others may take months to respond, as fixing documentation is not a hig

Re: Anyone using SUN/STK CDRT ( maybe CVDT ) product

Glenn, According to our tape expert We actually had run into this issue and have created workarounds. We do mark all production MVC's lost and read only prior to test so they roll into CDRT as such. Also, we have an unload job that we run to unload the VTV's from the MVC's. This was all built b

Re: JCL parms

On Sat, 5 Jan 2008 09:16:22 -0600, Rick Fochtman wrote: > >Maybe a front-end process or that creates a long PARM string from >control statements? > Sure. Provided that symbol substitution within those control statements is supported. And provided that those control statements with substitutable s

Re: JCL parms

- No, only the one that is coded. If you have PARM=" " coded, it works as always. If you code NEWPARM="" they Getmain an area for something larger like 256 bytes and everything else works the same. That way you could have a controlled implementation without muck

Re: JCL parms

-- No! For compatibility, it should be exactly the venerable format produced by the CALL macro, etc. I'd have no problem with a different keyword for longer PARMs, provided that keyword also tolerated shorter PARMs. And I'd have little problem with

Re: JCL parms

Have you any real data to support your "just about all"? I have never encountered a problem invoking programs (including IBM products) from Rexx ATTCHMVS (assembler CALL would be the same) with PARM>100 chars. Any program which would fail as you suggest with

Re: JCL parms

--- I'd be overjoyed if IBM would admit to the possibility of a parm string up to 32,767 bytes, and design parm-driven software with that in mind. And allow JCL to accept a parm of that length. Changes to code would be minimal, since it already uses

Re: IBM Hardware Group in Big Restructuring

On Jan 4 Sam Knutson remarked: >Surprised no one had commented on this Relative to IBM's reorganization, as reported in: > I saw the article. Was especially interested in the remark that: - IBM gets most of its busi

Re: JCL parms

On 4 Jan 2008 18:19:58 -0800, [EMAIL PROTECTED] (Bill Wilkie) wrote: >No, only the one that is coded. If you have PARM=" " coded, it works as >always. If you code NEWPARM="" they Getmain an area for something larger like >256 bytes and everything else works the same. That way you could have a >

Re: JCL parms

On 4 Jan 2008 14:41:32 -0800, [EMAIL PROTECTED] (Steve Comstock) wrote: >> It's been over 30 years since I was a COBOL programmer, but I'm sure that I >> never moved the parm that was supplied in the JCL. Yes, I wrote quite a few >> programs that would accept a parm. The parm area was always c

Re: Batch Tuning

Barry, Very true, but for best results make sure as many concurrent readers as possible are submitted at the same time, and make sure they can run at the same velocity. Otherwise Jobs that are swapped or slowed because a lower DP will fall too far behind the lead job and you'll end up with very li

Re: iSCSI v FICON

Barry, z/OS does not support iSCSI. Your system need to support iSCSI IO first. It may be possible to use iSCSI with a software iSCSI driver from Linux on z/VM. Check with better minds than mine. iSCSI may be easier than FCP to deploy in LAN environments with low IO demands, and very good for re

Re: SMP/E and why not.

Dave Salt wrote: At the risk of being flamed (both for agreeing with what Radoslaw wrote above and also for mentioning a product I'm involved with), I have to say that SimpList works the same way. It checks dependencies at runtime, and to me this offers many advantages over using SMP/E. T