Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
Charles Finding out which SMF subsystems are defined in SMFPRMxx is also something to consider as SYS.IEFU83 and SYS.IEFU83 can point to different module lists and your software may have to install its exit to every SMF subsystem. I am surprised that IFAQUERY has not been enhanced to return extra SMF related information like this. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: 24 April 2014 23:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())? Thanks. I can obviously find it in showmvs -- just thought I would ask. Charles Composed on a mobile: please excuse my brevity Rob Scott rsc...@rocketsoftware.com wrote: The SMF SST control block is not a GUPI nor is documented anywhere that I am aware of. The code in SHOWZOS is using either reverse-engineered DSECTs or something left over from the pre-OCO days. On 24 Apr 2014, at 17:40, Charles Mills charl...@mcn.org wrote: It is indeed there: SYS TYPE(0,4-7,14-15,18,21,26,30,36,41-42,50,60-90,94,100-103,109-116,118 -20 EXITS(IEFU29,IEFUTL,IEFUJI,IEFUSO,IEFUJP,IEFUSI,IEFUJV,IEFACTRT,IEFU8 5,I OMVS TYPE(0,4-7,14-15,18,21,26,30,36,41-42,50,60-90,94,100-103,109-116,118-20 EXITS(IEFU85,IEFU84,IEFU83) STC TYPE(0,30,41-42,50,60-83,88-89,100-103,109-110,115-120) etc. Somewhere around line 8250 of SHOWZOS Gilbert pulls it (not surprisingly) out of the SMCA and associated tables. SSTEXTAB. Anyone know where the SMF Selection Control Table is documented? I don't see it in my MVS Data Areas, but I suppose I am looking in the wrong place. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, April 24, 2014 11:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())? Excellent thought. I shall look into that. Thanks, Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Thursday, April 24, 2014 11:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())? ShowMvs can so I think you can also (source is available for ShowMvs) On 24.04.2014 16:42, Charles Mills wrote: Is there any way for an (authorized) program to determine whether SYS(EXITS(IEFU8n)) has been specified? That is, whether IEFU8n (where 'n' is 3, 4 or 5) is active. Note that z/OS allows a module to be added to an exit even though the exit is not active and the module will never receive a single call. I am looking for whether the EXIT is active and will be called by z/OS, not whether or not module X has been installed on the exit. I am hoping for a conventional z/OS macro type answer, not issue /D SMF,O from Rexx and parse the results. I am looking at bit EXAAEDEFINED in the CSVDYNEX answer area mapping DSECT CSVEXAA. Does this provide the information I am looking for? Does something else? - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF PanExit question
In cace9d90ab02da4f8de4c45db43ba3452a4d927...@phxccrprd03.adprod.bmc.com, on 04/24/2014 at 05:45 AM, Dyck, Lionel lionel_d...@bmc.com said: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,EXITDATA,MSG=PEX001) )END Is that legal without the commas? Shouldn't it be PANEXIT ((Field1, Field2, Field3, zuser),REXX,PANEXIT,EXITDATA,MSG=PEX001) -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
In 20140424213615.6004883.18431.8...@yahoo.ca, on 04/24/2014 at 05:36 PM, Ted MacNEIL eamacn...@yahoo.ca said: Early compiler writers used the term for languages that used 'call by name' sub-routines (such as FORTRAN) when something like an expression was passed. That's not call by name. Thunks were invented for ALGOL 60, which did have call by name. A typical example is an integartion routine where one of the parameters is the integrand expression. Every time that the subroutine uses that parameter it re-evaluates the integrand. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF PanExit question
It worked without commas :-) -- Lionel B. Dyck BMC Software Product Development Lead, Common Install and Services 10431 Morado Circle, Building 5, Austin, Texas 78759 Office Phone: 512-340-6031 (extension x26031) E-Mail: lionel_d...@bmc.com Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are. - John Wooden -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, April 24, 2014 7:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF PanExit question In cace9d90ab02da4f8de4c45db43ba3452a4d927...@phxccrprd03.adprod.bmc.com, on 04/24/2014 at 05:45 AM, Dyck, Lionel lionel_d...@bmc.com said: )PROC PANEXIT ((Field1 Field2 Field3 zuser),REXX,PANEXIT,EXITDATA,MSG=PEX001) )END Is that legal without the commas? Shouldn't it be PANEXIT ((Field1, Field2, Field3, zuser),REXX,PANEXIT,EXITDATA,MSG=PEX001) -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Development Clueless about COBOL DEV activities
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John Gilmore [ snip ] COBOL 5.2 is a very large step forward in performance; . . . [ snip ] I've not yet seen the IBM Announcement for [Enterprise] COBOL 5.2. Would you kindly furnish a pointer to it? Thanks, -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Development Clueless about COBOL DEV activities
John [Chase], Your implicit point is well taken: 'COBOL 5.2' should of course have been 'COBOL 5.1'. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automate Flash Copy : DS8800
Of course there is also DSCLI and the TSO utilities Whats the TSO utility name that would help me in Controlling TPCR flash initiation ? On Mon, Nov 4, 2013 at 6:50 PM, Scott Chapman sachap...@aep.com wrote: If you're talking about just flashing datasets or volumes for local purposes (not involving replication), then that's a different (and simpler) story. But because you mention TPCR, my presumption is that you're talking about a DR replication scenario. By automate I take you to mean that you want a flash to be initiated in response to either a certain time or a certain event, other than replication breaking itself. E.G. you want to schedule an I2 to H2 flash at 3:05 am tomorrow for part of your DR testing so you don't have to get up and click the button yourself. As far as I can tell, there's no way to do that. Of course there is also DSCLI and the TSO utilities. I'm certain that there are DSCLI command(s) to initiate the flash--in theory you can do everything from DSCLI without TPCR. But the nomenclature for the volume sets is apparently different between DSCLI and TPCR. And a simple single click in TPCR may end up being multiple DSCLI commands. But DSCLI is probably where I'd start looking. Scott Chapman On Sat, 2 Nov 2013 23:11:45 +0530, Jake anderson justmainfra...@gmail.com wrote: Hello All, Is there an opportunity to automate the flash copy in DS8800 using Tivoli storage productivity center for replication ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GRS RESMIL setting on CPU consumption
Anthony, If you have DB2 in that plex, I would think twice (or thrice) about increasing the resmil value, as DB2 does heavy enqueue activity. I remember one presentation (I think it was at share or maybe another conference), where someone from IBM GRS presented the following item: Company A implemented GRS Star and opened a ticket with ibm as a db2 application, that normally ran 9 hours, ran in just a few minutes, so they were sure something had gone wrong. Working with ibm, they went through testing, first back on GRS RING and the default of RESMIL=10. Result: the application ran 9 hours IBM had them change to RESMIL(1) (or maybe 0) and the elapsed time dropped to 90 minutes Change to GRS Star, and the application ran in 9 minutes. Just an example of the impact of the RESMIL setting (and even of what GRS Star can give (yes it does require the Coupling Facility). Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SLES Starter System for System z 11 SP3 f00 disk full
Has anyone encountered the f00 disk being full in step 8o of the starter-system-guide? ACCESS 151 G Ready; T=0.01/0.01 11:21:50 VMARC UNPACK NOV151 VMARC G * * A DMSERD107S Disk A(F00) is full Unexpected error during output. RC=13. Ready(00013); T=2.27/2.49 11:22:16 MDISK 0191 3390 0001 0005 LN0631 MR MDISK 019F 3390 0006 0050 LN0631 MR MDISK 0150 3390 0056 3283 LN0631 MR MDISK 0151 3390 0001 3338 LN0632 MR MDISK 0F00 3390 0001 3338 LN0633 MR LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL NOVF00 F00 A R/W 3338 3390 40967 600832-99 8 600840 NOV151 151 G R/W 3338 3390 40961 438639-73 162201 600840 MNT190 190 S R/O 207 3390 4096 694 18268-49 18992 37260 MNT19E 19E Y/S R/O 500 3390 4096 1125 29764-33 60236 9 TCM592 120 Z R/O 140 3390 4096 867 13823-55 11377 25200 Ready; T=0.01/0.01 11:37:00 LVL 0 - A F00 600840 BLKS 3390 R/W 99% FILE 1 OF 7 INVMARC EXEC A1 F 80 23 1 4/24/14 11:04 CMSDDR EXEC A2 V 72134 2 5/22/01 11:20 VMARCMODULE A1 V 13456 3 4 5/19/02 18:26 DDR2CMSX HELPCMS A1 V 79139 2 5/22/01 11:14 DDR2CMSX MODULE A2 V 65535 5 33 5/21/01 10:13 NOV150 DISKIMG A1 V 49152 90091 542474 11/07/13 10:23 VMARCCMSUT1 A1 V 49152 8486 56513 4/24/14 11:22 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Post Sent: Wednesday, April 09, 2014 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SLES Starter System for System z 11 SP3 has been released Cross-posted to Linux-390, IBMVM, and IBM-Main. It's rather long overdue, but we finally managed to the the Starter System for SLES11 SP3 out the door. For those that don't know what it is, you can read about it at https://www.suse.com/startersystem/ For those that want to download it, there is a download link (to the left of the image of the z12EC), or you can go directly to https://download.suse.com/Download?buildid=l5_UjT5Nvmk~ . The Starter System is free for download; customers with a valid subscription or eval activation code are entitled for their respective support level. Note that the addition of support for the Starter System is new. The installation process is largely unchanged, but I recommend you read guide thats among the files you can download. You'll need a no-cost Novell Customer Center account to access it. (I've never experienced any unwanted spam from having min, so that shouldn't be a worry.) If you don't have one already, you can go to https://www.novell.com/center to get one. Thanks, Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
I see the descriptions of the XPLINK and XPLINK-64 conventions in that manual, but nothing about those conventions would prevent calls to programs with other linkage conventions or address modes, IMHO without much trouble at all. The code to implement a call to a 31-bit program will obviously cost CPU cycles to move the arguments below the bar, and perhaps more to set up a non-XPLINK DSA and stack (assuming a call to an LE-enabled module), but none of that is impossible. It's only a question of knowingly bearing the cost of those extra linkage steps and some enclave-initialization-time cost to proactively set up a 31-bit DSA and stack for those inter-linkage-convention calls. I also saw in section 2.3.2.2.2 Stack Overflow in the XPLINK-64 area this statement: The stack floor is the lowest usable address of the current stack area. In the lower storage addresses, it is preceded by a store-protected guard area used to detect stack overflows. The guard area in XPLINK-64 is 1M, the minimum allocation size, so they are using the hardware store-protect mechanism to detect stack overflow. Seems wasteful of CPU cycles to me, since PIC exception processing is so much more expensive than one prolog instruction to test the available space in the stack frame, but I guess with above-the-bar storage being so plentiful they are trading prolog CPU cycles for far more expensive stack-extension cycles, with the implied assumption that stack extension will be far less common than below the bar. It obviously argues that they expect you to allocate far more stack than you think you may ever need to avoid stack extension costs. I share your opinion that the LE people have gotten this wrong. The only excuse I can imagine is that it makes true exception processing too difficult to implement, FSVO difficult. The only other explanation would seem to be we don't care about legacy code any more, which is a bit scary. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, April 24, 2014 4:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enterprise COBOL v5.1 and RDz v9.x On Thu, 24 Apr 2014 10:33:50 -0400, Farley, Peter x23353 wrote: PMFJI here, but it is my impression (please correct me if I am wrong) that XPLINK is the z/OS analog of the calling mechanism developed in Germany for z/Linux from the kernel on up to user space. I don't know about that. XPLINK was introduced with OS/390 2.10 The LE Concepts Guide has this in its glossary: quote Extra Performance Linkage (XPLINK). Extra Performance Linkage (XPLINK) is an enhanced linkage between programs that can significantly improve the performance of your C and C++ programs. The primary goal of XPLINK is to make subroutine calls as fast and efficient as possible by removing all nonessential instructions from the main program path. The XPLINK run-time option controls the initialization of the XPLINK environment. /quote Yes, it's fast, but it provides no call backtrace (i.e., no register saveareas) unless specifically requested at compile time. Yes, it does, but it does it differently. The XPLINK save areas are documented in the LE Vendor Interfaces manual. Not all registers are necessarily saved, but register 7, the return address with XPLINK, is always saved. Fast? Well, you can pass a few parameters in registers. And it doesn't do a GETMAIN for a save area in the code for every program entry. And it doesn't check the stack to see if there is sufficient room in the stack every time. Instead, it relies upon a Program Interruption Code 4 if it tries to store the caller's registers outside of the stack. I don't remember how they ensure that a PIC 4 occurs with XPLINK, rather than overlaying something. With XPLINK-64, the stack is above the bar and a guard area is allocated. This causes its own issues. For example, if an XPLINK-64 program wants to call a program that uses standard linkage, even a standard program like GET or PUT, it needs to allocate a save area below the bar for its save area. Actually, LE uses a stack with standard linkage too, so it doesn't need the GETMAIN either, but it tests the stack to see if there is sufficient space available. If not, more stack is acquired. In XPLINK, the same kind of thing is done, but it is triggered by the PIC 4. If I am a Cobol programmer, I might want to write a program that is called to look up something in a table that resides above the bar. The limitations on interoperability mean that it is more difficult to do that and the small performance improvement that would be available in an environment that is all XPLINK-64 becomes a bigger performance penalty each time the program is called. LE would have me recompile the entire system to run XPLINK-64. And if my system uses subroutines that are also used by other systems, maybe I should recompile all of them as well. The LE people
Beyond the EC12
Has anyone heard any good rumors about what will be coming out next year as the latest and greatest model? z296? Ec14? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
Answering my own question for the benefit of future searchers.
Yes, CSVDYNEX LIST may be used to answer this question, and Yes, the
relevant bit is EXAAEDEFINED. FWIW, I think all of the information in this
regard that SHOWMVS obtains from non-GUPI interfaces may be obtained in this
manner in a supported fashion.
There is one annoying gotcha IMHO with CSVDYNEX LIST. I inferred from the
documentation that the answer returned was in the format
{header, EXAAE, module, module, ...}
Instead, the results are in the format
{header, module, module, ..., EXAAE}
What that means is that if you do not provide an answer area long enough to
hold ALL of the member entries, you will not get the EXAAE (which in my case
is all that I am interested in). How many member areas might there be? There
appears to be no limit. Yes, you can issue CSVDYNEX LIST twice, once to find
out how much storage you need, and once with enough storage. I only need
this information to put out an optional warning, so I made the executive
decision that if 20 member entries was not enough, the customer was just
going to have to live without the warning.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, April 24, 2014 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Any way to programmatically determine state of SMFPRMxx
SYS(EXITS())?
Is there any way for an (authorized) program to determine whether
SYS(EXITS(IEFU8n)) has been specified? That is, whether IEFU8n (where 'n' is
3, 4 or 5) is active.
Note that z/OS allows a module to be added to an exit even though the exit
is not active and the module will never receive a single call. I am looking
for whether the EXIT is active and will be called by z/OS, not whether or
not module X has been installed on the exit.
I am hoping for a conventional z/OS macro type answer, not issue /D SMF,O
from Rexx and parse the results.
I am looking at bit EXAAEDEFINED in the CSVDYNEX answer area mapping DSECT
CSVEXAA. Does this provide the information I am looking for? Does something
else?
Thanks,
Charles
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
On 4/25/2014 8:09 AM, Klein, Kenneth E wrote: Has anyone heard any good rumors about what will be coming out next year as the latest and greatest model? z296? Ec14? You bring up an interest point to contemplate as IBM eventually considers official names for its 13th-generation machine (if and when such a thing is produced). Is there still enough superstition about the number '13' that they will avoid using it and come up with something completely different? Or will they stick with EC13/BC13? For the record, I consider it unlikely that they will leap ahead to '14' and be out-of-sync forever more. I also believe the chances close to 'nil' that they will reduce from 120 cores on EC12 back down to 96 for the next generation, making any name ending in '96' not worthy of consideration. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
The z196/z114 names were just plain confusing, so yeah, I'd assume they wouldn't do that. If they were going to have an aberration, they should have done that for 13. Let's see, z10EC/BC, zEC12/zBC12...maybe z1EC3/z1BC3 to hide the 13?! On Fri, Apr 25, 2014 at 11:47 AM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 4/25/2014 8:09 AM, Klein, Kenneth E wrote: Has anyone heard any good rumors about what will be coming out next year as the latest and greatest model? z296? Ec14? You bring up an interest point to contemplate as IBM eventually considers official names for its 13th-generation machine (if and when such a thing is produced). Is there still enough superstition about the number '13' that they will avoid using it and come up with something completely different? Or will they stick with EC13/BC13? For the record, I consider it unlikely that they will leap ahead to '14' and be out-of-sync forever more. I also believe the chances close to 'nil' that they will reduce from 120 cores on EC12 back down to 96 for the next generation, making any name ending in '96' not worthy of consideration. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SLES Starter System for System z 11 SP3 f00 disk full
On 4/25/2014 at 10:30 AM, Le Blanc, Frank flebl...@bu.edu wrote: Has anyone encountered the f00 disk being full in step 8o of the starter-system-guide? ACCESS 151 G Ready; T=0.01/0.01 11:21:50 VMARC UNPACK NOV151 VMARC G * * A DMSERD107S Disk A(F00) is full Unexpected error during output. RC=13. Ready(00013); T=2.27/2.49 11:22:16 It appears there's a step missing. After step 8l there should be this: ERASE NOV150 DISKIMG A (TYPE to free up the space for the 151 disk to be unpacked. I'll report the omission internally. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
Or you can consider the EC10/EC12 as ECyy so at this point the next EC would be EC14 if it were to come out this year. Just my $0.01 to add to the discussion -- Lionel B. Dyck BMC Software Product Development Lead, Common Install and Services 10431 Morado Circle, Building 5, Austin, Texas 78759 Office Phone: 512-340-6031 (extension x26031) E-Mail: lionel_d...@bmc.com Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are. - John Wooden -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of zMan Sent: Friday, April 25, 2014 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beyond the EC12 The z196/z114 names were just plain confusing, so yeah, I'd assume they wouldn't do that. If they were going to have an aberration, they should have done that for 13. Let's see, z10EC/BC, zEC12/zBC12...maybe z1EC3/z1BC3 to hide the 13?! On Fri, Apr 25, 2014 at 11:47 AM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 4/25/2014 8:09 AM, Klein, Kenneth E wrote: Has anyone heard any good rumors about what will be coming out next year as the latest and greatest model? z296? Ec14? You bring up an interest point to contemplate as IBM eventually considers official names for its 13th-generation machine (if and when such a thing is produced). Is there still enough superstition about the number '13' that they will avoid using it and come up with something completely different? Or will they stick with EC13/BC13? For the record, I consider it unlikely that they will leap ahead to '14' and be out-of-sync forever more. I also believe the chances close to 'nil' that they will reduce from 120 cores on EC12 back down to 96 for the next generation, making any name ending in '96' not worthy of consideration. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
I don't remember where I heard this, or even I really did hear this, but immediately, Next jumped to the front of my brain. zNext - NextZ. It could be real, it could just a hallucination. On Fri, Apr 25, 2014 at 1:17 PM, Dyck, Lionel lionel_d...@bmc.com wrote: Or you can consider the EC10/EC12 as ECyy so at this point the next EC would be EC14 if it were to come out this year. Just my $0.01 to add to the discussion -- Lionel B. Dyck BMC Software Product Development Lead, Common Install and Services 10431 Morado Circle, Building 5, Austin, Texas 78759 Office Phone: 512-340-6031 (extension x26031) E-Mail: lionel_d...@bmc.com Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are. - John Wooden -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of zMan Sent: Friday, April 25, 2014 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beyond the EC12 The z196/z114 names were just plain confusing, so yeah, I'd assume they wouldn't do that. If they were going to have an aberration, they should have done that for 13. Let's see, z10EC/BC, zEC12/zBC12...maybe z1EC3/z1BC3 to hide the 13?! On Fri, Apr 25, 2014 at 11:47 AM, Ed Jaffe edja...@phoenixsoftware.com wrote: On 4/25/2014 8:09 AM, Klein, Kenneth E wrote: Has anyone heard any good rumors about what will be coming out next year as the latest and greatest model? z296? Ec14? You bring up an interest point to contemplate as IBM eventually considers official names for its 13th-generation machine (if and when such a thing is produced). Is there still enough superstition about the number '13' that they will avoid using it and come up with something completely different? Or will they stick with EC13/BC13? For the record, I consider it unlikely that they will leap ahead to '14' and be out-of-sync forever more. I also believe the chances close to 'nil' that they will reduce from 120 cores on EC12 back down to 96 for the next generation, making any name ending in '96' not worthy of consideration. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Development Clueless about COBOL DEV activities
Which utility? http://www-03.ibm.com/software/products/en/migration -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
Maybe they'll resurrect Future System. :-) -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of zMan Sent: Friday, April 25, 2014 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beyond the EC12 The z196/z114 names were just plain confusing, so yeah, I'd assume they wouldn't do that. If they were going to have an aberration, they should have done that for 13. Let's see, z10EC/BC, zEC12/zBC12...maybe z1EC3/z1BC3 to hide the 13?! On Fri, Apr 25, 2014 at 11:47 AM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 4/25/2014 8:09 AM, Klein, Kenneth E wrote: Has anyone heard any good rumors about what will be coming out next year as the latest and greatest model? z296? Ec14? You bring up an interest point to contemplate as IBM eventually considers official names for its 13th-generation machine (if and when such a thing is produced). Is there still enough superstition about the number '13' that they will avoid using it and come up with something completely different? Or will they stick with EC13/BC13? For the record, I consider it unlikely that they will leap ahead to '14' and be out-of-sync forever more. I also believe the chances close to 'nil' that they will reduce from 120 cores on EC12 back down to 96 for the next generation, making any name ending in '96' not worthy of consideration. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
If the superstition about 13 was considered, why did they come out with z/OS 1.13? :) Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Friday, April 25, 2014 11:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beyond the EC12 On 4/25/2014 8:09 AM, Klein, Kenneth E wrote: Has anyone heard any good rumors about what will be coming out next year as the latest and greatest model? z296? Ec14? You bring up an interest point to contemplate as IBM eventually considers official names for its 13th-generation machine (if and when such a thing is produced). Is there still enough superstition about the number '13' that they will avoid using it and come up with something completely different? Or will they stick with EC13/BC13? For the record, I consider it unlikely that they will leap ahead to '14' and be out-of-sync forever more. I also believe the chances close to 'nil' that they will reduce from 120 cores on EC12 back down to 96 for the next generation, making any name ending in '96' not worthy of consideration. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
It's always referred to as zNext until the formal announcement and final name is released. CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 740 5459 (tel) | ken.porow...@cit.com This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, “CIT”), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sent from or received at this email address. -Original Message- Mark Pace Sent: Friday, April 25, 2014 1:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Beyond the EC12 I don't remember where I heard this, or even I really did hear this, but immediately, Next jumped to the front of my brain. zNext - NextZ. It could be real, it could just a hallucination. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
Around here, people are betting on EC14 or EC15. We don't understand where the name z196 came from, but didn't z9's come out in 2009, z10's in 2010, EC12's in 2012... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ken Porowski Sent: Friday, April 25, 2014 1:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beyond the EC12 It's always referred to as zNext until the formal announcement and final name is released. CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 740 5459 (tel) | ken.porow...@cit.com This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, “CIT”), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sent from or received at this email address. -Original Message- Mark Pace Sent: Friday, April 25, 2014 1:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Beyond the EC12 I don't remember where I heard this, or even I really did hear this, but immediately, Next jumped to the front of my brain. zNext - NextZ. It could be real, it could just a hallucination. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information in this transmission may contain proprietary and non-public information of BBT or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
My bet: BHV3B4 Reason: completely unrelated to the predecessor, Of course B4 is number of procesors in hex, 3 could be understood as third generation (z196 - 1 was first generation), V is for Virtualization, finally BH stand for absolutely nothing. -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
Ah, thanks, I was sure I had heard it before. On Fri, Apr 25, 2014 at 1:54 PM, Ken Porowski ken.porow...@cit.com wrote: It's always referred to as zNext until the formal announcement and final name is released. CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 740 5459 (tel) | ken.porow...@cit.com This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, “CIT”), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sent from or received at this email address. -Original Message- Mark Pace Sent: Friday, April 25, 2014 1:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Beyond the EC12 I don't remember where I heard this, or even I really did hear this, but immediately, Next jumped to the front of my brain. zNext - NextZ. It could be real, it could just a hallucination. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())?
Funny, I was just looking at that. Thanks. I am real aware of SYS(EXITS()) versus SUBSYS(XXX,EXITS()). My product now warns if it is told to monitor subsystem XXX but SUBSYS(XXX,EXITS(IEFU83/4/5)) has not been specified. But it does not know if there is also a subsystem YYY that it has not been told about. Looking at SHOWZOS I can see how to do it from SMCA-SST, but as you said, GUPI it ain't. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: Friday, April 25, 2014 5:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Any way to programmatically determine state of SMFPRMxx SYS(EXITS())? Charles Finding out which SMF subsystems are defined in SMFPRMxx is also something to consider as SYS.IEFU83 and SYS.IEFU83 can point to different module lists and your software may have to install its exit to every SMF subsystem. I am surprised that IFAQUERY has not been enhanced to return extra SMF related information like this. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
And if IBM has disclosed anything to ISVs, the NDAs undoubtedly prohibit disclosing even that fact publicly. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Shannon Sent: Friday, April 25, 2014 1:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beyond the EC12 We don't understand where the name z196 came from Z196 = 1st generation 96 cores. It was a silly name. IBM has been very tight-lipped about the next machine. No models have been mentioned. No availability dates have been given. No features have been discussed. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
On 4/25/2014 10:57 AM, DiBianca, Robert wrote: Around here, people are betting on EC14 or EC15. We don't understand where the name z196 came from, but didn't z9's come out in 2009, z10's in 2010, EC12's in 2012... I realize time flies, but the IBM Danu z9-109 EC 2094 (9th generation processor) was announced in July 2005 and available in the third quarter of that year. The IBM z10 EC 2097 (10th generation) was first available in 1Q 2008. The IBM z196 zEnterprise 2817 (11th generation) was first available in 3Q 2010. The IBM zEnterprise EC12 2827 (12th generation) was first available in 3Q 2012. Bob Shannon has already answered the question about what z196 means. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
That's because we haven't ANNOUNCED anything. :-) TGIF :-) Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Bob Shannon bshan...@rocketsoftware.com To: IBM-MAIN@listserv.ua.edu Date: 25/04/2014 19:28 Subject:Re: Beyond the EC12 Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu We don't understand where the name z196 came from Z196 = 1st generation 96 cores. It was a silly name. IBM has been very tight-lipped about the next machine. No models have been mentioned. No availability dates have been given. No features have been discussed. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
I can neither confirm nor deny that I know anything at all. On Fri, Apr 25, 2014 at 2:41 PM, Chase, John jch...@ussco.com wrote: And if IBM has disclosed anything to ISVs, the NDAs undoubtedly prohibit disclosing even that fact publicly. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Shannon Sent: Friday, April 25, 2014 1:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beyond the EC12 We don't understand where the name z196 came from Z196 = 1st generation 96 cores. It was a silly name. IBM has been very tight-lipped about the next machine. No models have been mentioned. No availability dates have been given. No features have been discussed. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ISPF Log error
Since moving my sandbox LPARs to z/OS 1.13, I have been getting this error message frequently. So for, I just pressed the Enter key and continued. It finally irritated me enough to ask if others have this experience. It is possible it is due to the way I have the these two LPARs sharing disk and catalogs and stuff without any GRS protection. ISPF Log error ISPF will continue without log data set *** Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
It's all about what we don't know that we don't know. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Mark Pace pacemainl...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 04/25/2014 11:59 AM Subject:Re: Beyond the EC12 Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I can neither confirm nor deny that I know anything at all. On Fri, Apr 25, 2014 at 2:41 PM, Chase, John jch...@ussco.com wrote: And if IBM has disclosed anything to ISVs, the NDAs undoubtedly prohibit disclosing even that fact publicly. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bob Shannon Sent: Friday, April 25, 2014 1:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beyond the EC12 We don't understand where the name z196 came from Z196 = 1st generation 96 cores. It was a silly name. IBM has been very tight-lipped about the next machine. No models have been mentioned. No availability dates have been given. No features have been discussed. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Relationship of Resolve to ServiceLink?
Looking at software renewals, and I was asked about several. This stumped me. I read the Getting Started Guide to Technical Support Services for IBM zSeries Software at http://www-935.ibm.com/services/us/its/pdf/swxcel.pdf. It is a whopping 2 paragraphs, and no detail. The description on IBM's web site under IBM Products and Services ( https://www-304.ibm.com/shop/americas/webapp/wcs/stores/servlet/default/CategoryDisplay?catalogId=-840storeId=1langId=-1dualCurrId=73categoryId=2364419go= ) is just as useful. If all I have is z/OS on my hardware, what does Resolve provide me that my ServiceLink money does not? Cheers,,,Steve Steven F. Conway, CISSP Hosting Services Division, Cloud Technology and Hosting Office, AO-DTS-CTHO-HSD z/OS Systems Support Phone: 703-295-1926 Mobile: 703-402-2650 steve_con...@ao.uscourts.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Log error
True dat. Bad idea. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@LISTSERV.UA.EDU, Date: 04/25/2014 12:36 PM Subject:ISPF Log error Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Since moving my sandbox LPARs to z/OS 1.13, I have been getting this error message frequently. So for, I just pressed the Enter key and continued. It finally irritated me enough to ask if others have this experience. It is possible it is due to the way I have the these two LPARs sharing disk and catalogs and stuff without any GRS protection. ISPF Log error ISPF will continue without log data set *** Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
My suspicion is: ZFH3FF-z/Fog Horn 3rd Gen 255 processors and will be end of line for Z. To be sup'd by VCN4FFF-Virtual Cumulo nimbus 4th gen 1023 engines. Well it is Friday! In a message dated 4/25/2014 1:25:07 P.M. Central Daylight Time, r.skoru...@bremultibank.com.pl writes: My bet: BHV3B4 Reason: completely unrelated to the predecessor, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Log error
It may be a bad idea. And actually I agree. But, my z9-L03 capped at 16 MSU doesn't have an ICF or any resources to fire up GRS in ring mode, let alone star. Since I am the only user in one sandbox and one of two sysprogs in the other, we get by. :) The message does not occur with z/OS 1.11 with the same mix of monoplexes. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Friday, April 25, 2014 12:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Log error True dat. Bad idea. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@LISTSERV.UA.EDU, Date: 04/25/2014 12:36 PM Subject:ISPF Log error Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Since moving my sandbox LPARs to z/OS 1.13, I have been getting this error message frequently. So for, I just pressed the Enter key and continued. It finally irritated me enough to ask if others have this experience. It is possible it is due to the way I have the these two LPARs sharing disk and catalogs and stuff without any GRS protection. ISPF Log error ISPF will continue without log data set *** Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
W dniu 2014-04-25 20:41, Chase, John pisze: And if IBM has disclosed anything to ISVs, the NDAs undoubtedly prohibit disclosing even that fact publicly. ISV may not know the names, just because they don't need to know names. They need to know technical details of zNEXT. BTW: Let's guess: 1. How many CP's will be available in zNEXT? 2. How many MIPS per CP? 3. How many BOOKs, if any? 4. New I/O cards/ports? 5. How much memory? My bets: 1. ~120 (without SAPs, spares) 2. 50% more than EC12. 3. 4 BOOKs, different number of cores per BOOK - as today. 4. FICON 16Gbps, two-port 10GbEth, maybe 40GbEth? 5. 1.5 TB per book, 6 TB per CPC -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Log error
Dave, Do you have 'Profile Sharing' turned on? IIRC that was new with 1.13. In addition to allowing safe sharing of ISPPROF between systems, it also provides: 1.3.3.2 Temporary data set names The ISPF Configuration utility provides an option to specify an additional qualifier for ISPF temporary data sets, including Log, List and temporary control and work data sets. The use of this qualifier also includes trace data sets from ISPVCALL, ISPDPTRC and ISPFTTRC. When Profile Sharing has been enabled and no value has been specified for the additional qualifier, a value of ISPSEQ is used, where SEQ is a system symbolic variable that has the same value as defined by the ISPF dialog variable ZSEQ. Dana On Fri, 25 Apr 2014 19:35:56 +, Gibney, Dave gib...@wsu.edu wrote: Since moving my sandbox LPARs to z/OS 1.13, I have been getting this error message frequently. So for, I just pressed the Enter key and continued. It finally irritated me enough to ask if others have this experience. It is possible it is due to the way I have the these two LPARs sharing disk and catalogs and stuff without any GRS protection. ISPF Log error ISPF will continue without log data set *** Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of Resolve to ServiceLink?
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Conway Sent: Friday, April 25, 2014 2:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Relationship of Resolve to ServiceLink? Looking at software renewals, and I was asked about several. This stumped me. I read the Getting Started Guide to Technical Support Services for IBM zSeries Software at http://www- 935.ibm.com/services/us/its/pdf/swxcel.pdf. It is a whopping 2 paragraphs, and no detail. The description on IBM's web site under IBM Products and Services ( https://www- 304.ibm.com/shop/americas/webapp/wcs/stores/servlet/default/CategoryDisplay?catalogId=- 840storeId=1langId=-1dualCurrId=73categoryId=2364419go= ) is just as useful. If all I have is z/OS on my hardware, what does Resolve provide me that my ServiceLink money does not? IIRC, Resolve includes what used to be known as TechQA while Servicelink does not. -jc- Cheers,,,Steve Steven F. Conway, CISSP Hosting Services Division, Cloud Technology and Hosting Office, AO-DTS-CTHO-HSD z/OS Systems Support Phone: 703-295-1926 Mobile: 703-402-2650 steve_con...@ao.uscourts.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Log error
Thanks, I will look at that setting. I don't remember doing anything with that when I installed 1.13, so I bet that is it. And might not be an issue in my two other LPARs (Development and Production) where the Catalogs and stuff aren't as broadly shared. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dana Mitchell Sent: Friday, April 25, 2014 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Log error Dave, Do you have 'Profile Sharing' turned on? IIRC that was new with 1.13. In addition to allowing safe sharing of ISPPROF between systems, it also provides: 1.3.3.2 Temporary data set names The ISPF Configuration utility provides an option to specify an additional qualifier for ISPF temporary data sets, including Log, List and temporary control and work data sets. The use of this qualifier also includes trace data sets from ISPVCALL, ISPDPTRC and ISPFTTRC. When Profile Sharing has been enabled and no value has been specified for the additional qualifier, a value of ISPSEQ is used, where SEQ is a system symbolic variable that has the same value as defined by the ISPF dialog variable ZSEQ. Dana On Fri, 25 Apr 2014 19:35:56 +, Gibney, Dave gib...@wsu.edu wrote: Since moving my sandbox LPARs to z/OS 1.13, I have been getting this error message frequently. So for, I just pressed the Enter key and continued. It finally irritated me enough to ask if others have this experience. It is possible it is due to the way I have the these two LPARs sharing disk and catalogs and stuff without any GRS protection. ISPF Log error ISPF will continue without log data set *** Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Relationship of Resolve to ServiceLink?
Thanks, John. Found a SHARE presentation that shows Resolve is one of the Electronic Support offerings. I didn't even know that, having nothing to do with the contracts. Since I was asked the question without seeing the contract, guess I need to see what all we're actually paying for. Steven F. Conway, CISSP Hosting Services Division, Cloud Technology and Hosting Office, AO-DTS-CTHO-HSD z/OS Systems Support Phone: 703-295-1926 Mobile: 703-402-2650 steve_con...@ao.uscourts.gov From: Chase, John jch...@ussco.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 04/25/2014 03:59 PM Subject:Re: Relationship of Resolve to ServiceLink? Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Conway Sent: Friday, April 25, 2014 2:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Relationship of Resolve to ServiceLink? Looking at software renewals, and I was asked about several. This stumped me. I read the Getting Started Guide to Technical Support Services for IBM zSeries Software at http://www- 935.ibm.com/services/us/its/pdf/swxcel.pdf. It is a whopping 2 paragraphs, and no detail. The description on IBM's web site under IBM Products and Services ( https://www- 304.ibm.com/shop/americas/webapp/wcs/stores/servlet/default/CategoryDisplay?catalogId=- 840storeId=1langId=-1dualCurrId=73categoryId=2364419go= ) is just as useful. If all I have is z/OS on my hardware, what does Resolve provide me that my ServiceLink money does not? IIRC, Resolve includes what used to be known as TechQA while Servicelink does not. -jc- Cheers,,,Steve Steven F. Conway, CISSP Hosting Services Division, Cloud Technology and Hosting Office, AO-DTS-CTHO-HSD z/OS Systems Support Phone: 703-295-1926 Mobile: 703-402-2650 steve_con...@ao.uscourts.gov -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF Log error
;-) Sorry for the snarky comeback. I got carried away with my current fav 'true dat'. I logged on to two different sysplex members. They use GRS, but I don't think that's your problem. Here's what I see: useird.$SYSX0.SPFLOGn.LIST on SYSX0 userid.$SYSX1.SPFLOGn.LIST on SYSX1 That is, my two sysplex members use different DSNs for log (and other) data sets. Each one has SYSCLONE built into the name, so there could never be a conflict. That protects against any possible conflict whether concurrent use or ISPF level difference. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@LISTSERV.UA.EDU, Date: 04/25/2014 01:03 PM Subject:Re: ISPF Log error Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Thanks, I will look at that setting. I don't remember doing anything with that when I installed 1.13, so I bet that is it. And might not be an issue in my two other LPARs (Development and Production) where the Catalogs and stuff aren't as broadly shared. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dana Mitchell Sent: Friday, April 25, 2014 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Log error Dave, Do you have 'Profile Sharing' turned on? IIRC that was new with 1.13. In addition to allowing safe sharing of ISPPROF between systems, it also provides: 1.3.3.2 Temporary data set names The ISPF Configuration utility provides an option to specify an additional qualifier for ISPF temporary data sets, including Log, List and temporary control and work data sets. The use of this qualifier also includes trace data sets from ISPVCALL, ISPDPTRC and ISPFTTRC. When Profile Sharing has been enabled and no value has been specified for the additional qualifier, a value of ISPSEQ is used, where SEQ is a system symbolic variable that has the same value as defined by the ISPF dialog variable ZSEQ. Dana On Fri, 25 Apr 2014 19:35:56 +, Gibney, Dave gib...@wsu.edu wrote: Since moving my sandbox LPARs to z/OS 1.13, I have been getting this error message frequently. So for, I just pressed the Enter key and continued. It finally irritated me enough to ask if others have this experience. It is possible it is due to the way I have the these two LPARs sharing disk and catalogs and stuff without any GRS protection. ISPF Log error ISPF will continue without log data set *** Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
In 985915eee6984740ae93f8495c624c6c232c1e0...@jscpcwexmaa1.bsg.ad.adp.com, on 04/25/2014 at 10:59 AM, Farley, Peter x23353 peter.far...@broadridge.com said: Seems wasteful of CPU cycles to me, How often do you expect to hit the guard page? An explicit test for stack overflow costs you at every call, and that can add up to more overhead than an infrequent program exception. I would hope that IBM did some measurements bfore deciding on the guard-page strategy. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
On 25 April 2014 14:41, Chase, John jch...@ussco.com wrote: And if IBM has disclosed anything to ISVs, the NDAs undoubtedly prohibit disclosing even that fact publicly. I've seen lots of NDA technical material over the years, but in my experience IBM has *never* disclosed any branding info to ISVs before announcement. The NDAs refer to zNEXT right to the end. Of course I'm a technical guy, and there may well be other ISV marketing people who see other stuff, but marketing is IBM's core, and not something I imagine they disclose to much of anyone. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond the EC12
Well sure. It's need to know. If the next mainframe is going to have 96-bit word support and a Load Inverted instruction, this is information that may be of benefit to an ISV and, given a couple of months' lead time, allow them to offer Day One support. But whether it is going to be called the z1396 or the 360-2014 hardly matters. Well, I suppose an ISV might need a week's lead time to draft a press release and/or prepare a Web page announcing the Day One support, but that's about it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Friday, April 25, 2014 6:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Beyond the EC12 On 25 April 2014 14:41, Chase, John jch...@ussco.com wrote: And if IBM has disclosed anything to ISVs, the NDAs undoubtedly prohibit disclosing even that fact publicly. I've seen lots of NDA technical material over the years, but in my experience IBM has *never* disclosed any branding info to ISVs before announcement. The NDAs refer to zNEXT right to the end. Of course I'm a technical guy, and there may well be other ISV marketing people who see other stuff, but marketing is IBM's core, and not something I imagine they disclose to much of anyone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
Everything is relative. Certainly some 31-bit code is easy to thunk to, but it's not just arguments that need to go below the bar, it's any control blocks those arguments point to and any control blocks those control blocks point to, etc. You also need to handle call-backs from 31-bit code, exceptions thrown from same, etc. As for stack extensions, there isn't a lot of code that would go deeper than one megabyte and that's the minimum allocation size for 64-bit. There's a bunch of tuning knobs for this stuff if you do have such an application. In article 985915eee6984740ae93f8495c624c6c232c1e0...@jscpcwexmaa1.bsg.ad.adp.com you wrote: I see the descriptions of the XPLINK and XPLINK-64 conventions in that manual, but nothing about those conventions would prevent calls to programs with other linkage conventions or address modes, IMHO without much trouble at all. The code to implement a call to a 31-bit program will obviously cost CPU cycles to move the arguments below the bar, and perhaps more to set up a non-XPLINK DSA and stack (assuming a call to an LE-enabled module), but none of that is impossible. It's only a question of knowingly bearing the cost of those extra linkage steps and some enclave-initialization-time cost to proactively set up a 31-bit DSA and stack for those inter-linkage-convention calls. I also saw in section 2.3.2.2.2 Stack Overflow in the XPLINK-64 area this statement: The stack floor is the lowest usable address of the current stack area. In the lower storage addresses, it is preceded by a store-protected guard area used to detect stack overflows. The guard area in XPLINK-64 is 1M, the minimum allocation size, so they are using the hardware store-protect mechanism to detect stack overflow. Seems wasteful of CPU cycles to me, since PIC exception processing is so much more expensive than one prolog instruction to test the available space in the stack frame, but I guess with above-the-bar storage being so plentiful they are trading prolog CPU cycles for far more expensive stack-extension cycles, with the implied assumption that stack extension will be far less common than below the bar. It obviously argues that they expect you to allocate far more stack than you think you may ever need to avoid stack extension costs. I share your opinion that the LE people have gotten this wrong. The only excuse I can imagine is that it makes true exception processing too difficult to implement, FSVO difficult. The only other explanation would seem to be we don't care about legacy code any more, which is a bit scary. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, April 24, 2014 4:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enterprise COBOL v5.1 and RDz v9.x On Thu, 24 Apr 2014 10:33:50 -0400, Farley, Peter x23353 wrote: PMFJI here, but it is my impression (please correct me if I am wrong) that XPLINK is the z/OS analog of the calling mechanism developed in Germany for z/Linux from the kernel on up to user space. I don't know about that. XPLINK was introduced with OS/390 2.10 The LE Concepts Guide has this in its glossary: quote Extra Performance Linkage (XPLINK). Extra Performance Linkage (XPLINK) is an enhanced linkage between programs that can significantly improve the performance of your C and C++ programs. The primary goal of XPLINK is to make subroutine calls as fast and efficient as possible by removing all nonessential instructions from the main program path. The XPLINK run-time option controls the initialization of the XPLINK environment. /quote Yes, it's fast, but it provides no call backtrace (i.e., no register saveareas) unless specifically requested at compile time. Yes, it does, but it does it differently. The XPLINK save areas are documented in the LE Vendor Interfaces manual. Not all registers are necessarily saved, but register 7, the return address with XPLINK, is always saved. Fast? Well, you can pass a few parameters in registers. And it doesn't do a GETMAIN for a save area in the code for every program entry. And it doesn't check the stack to see if there is sufficient room in the stack every time. Instead, it relies upon a Program Interruption Code 4 if it tries to store the caller's registers outside of the stack. I don't remember how they ensure that a PIC 4 occurs with XPLINK, rather than overlaying something. With XPLINK-64, the stack is above the bar and a guard area is allocated. This causes its own issues. For example, if an XPLINK-64 program wants to call a program that uses standard linkage, even a standard program like GET or PUT, it needs to allocate a save area below the bar for its save area. Actually, LE uses a stack with standard linkage too, so it doesn't need the GETMAIN either, but it tests the stack to see if there is
Re: Beyond the EC12
I've heard rumors that the names are often not determined until shortly before release anyway, after some not-so-fun marketing meetings... On Fri, Apr 25, 2014 at 6:14 PM, Tony Harminc t...@harminc.net wrote: On 25 April 2014 14:41, Chase, John jch...@ussco.com wrote: And if IBM has disclosed anything to ISVs, the NDAs undoubtedly prohibit disclosing even that fact publicly. I've seen lots of NDA technical material over the years, but in my experience IBM has *never* disclosed any branding info to ISVs before announcement. The NDAs refer to zNEXT right to the end. Of course I'm a technical guy, and there may well be other ISV marketing people who see other stuff, but marketing is IBM's core, and not something I imagine they disclose to much of anyone. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
On Fri, Apr 25, 2014 at 9:59 AM, Farley, Peter x23353 peter.far...@broadridge.com wrote: I see the descriptions of the XPLINK and XPLINK-64 conventions in that manual, but nothing about those conventions would prevent calls to programs with other linkage conventions or address modes, IMHO without much trouble at all. The code to implement a call to a 31-bit program will obviously cost CPU cycles to move the arguments below the bar, and perhaps more to set up a non-XPLINK DSA and stack (assuming a call to an LE-enabled module), but none of that is impossible. It's only a question of knowingly bearing the cost of those extra linkage steps and some enclave-initialization-time cost to proactively set up a 31-bit DSA and stack for those inter-linkage-convention calls. I also saw in section 2.3.2.2.2 Stack Overflow in the XPLINK-64 area this statement: The stack floor is the lowest usable address of the current stack area. In the lower storage addresses, it is preceded by a store-protected guard area used to detect stack overflows. The guard area in XPLINK-64 is 1M, the minimum allocation size, so they are using the hardware store-protect mechanism to detect stack overflow. Seems wasteful of CPU cycles to me, since PIC exception processing is so much more expensive than one prolog instruction to test the available space in the stack frame, but I guess with above-the-bar storage being so plentiful they are trading prolog CPU cycles for far more expensive stack-extension cycles, with the implied assumption that stack extension will be far less common than below the bar. It obviously argues that they expect you to allocate far more stack than you think you may ever need to avoid stack extension costs. Java has the area above the 2GB line. If the top of that is store protected, you could place the stack right above the protected Java area. deleted Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
