LPAR MOBILITY
I'm am confused about one thing. IBM has created the Live Partition Mobility on system I, with the virtualization layer. Why this doesn't exit on Z machines, with an integrated flavor of Z/VM for example ? Does IBM has intent to have such feature one day ? I think this is nearly a 'revolution' and thought Z was at the top of technology... Am i the only Professional to ask this ? Thank's. Jean. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
It seems like JES error. JES is the one that add the "//SYSIN DD * GENERATED STATEMENT" before calling the MVS converter JES requires that the "*" will be separated by a comma or blank from the next JCL keyword Doron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
I think several flavors of GDPS cover this? LPM was released in 2007, the first GDPS was released in 1998. Not to mention Live Partition Mobility only works for planned outages. From what I understand, it cannot be used as a part of a DRP. _Jan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of IBMZOS Sent: donderdag 28 mei 2015 11:22 To: IBM-MAIN@LISTSERV.UA.EDU Subject: LPAR MOBILITY I'm am confused about one thing. IBM has created the Live Partition Mobility on system I, with the virtualization layer. Why this doesn't exit on Z machines, with an integrated flavor of Z/VM for example ? Does IBM has intent to have such feature one day ? I think this is nearly a 'revolution' and thought Z was at the top of technology... Am i the only Professional to ask this ? Thank's. Jean. -- 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: GENERATED STATEMENT!?
I missed the original of this. Is the original JCL for the job available? /steve From: Doron Geva To: IBM-MAIN@LISTSERV.UA.EDU Date: 2015-05-28 12:26 Subject:Re: GENERATED STATEMENT!? Sent by:IBM Mainframe Discussion List It seems like JES error. JES is the one that add the "//SYSIN DD * GENERATED STATEMENT" before calling the MVS converter JES requires that the "*" will be separated by a comma or blank from the next JCL keyword ?Doron? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Såvida annat inte anges ovan: / Unless stated otherwise above: IBM Svenska AB Organisationsnummer: 556026-6883 Adress: 164 92 Stockholm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
Thank's for the reply. No GDPS do not cover this specific area; it automate the IPL stop end start process, in approximatively 30 mn. With LPM on I series, the mobility of partition is in seconds !!! We use it on planned outages and it work very well. Z/OS is not the future ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
On Thu, 28 May 2015 13:51:26 +0200, Steve Coalbran wrote: >I missed the original of this. >Is the original JCL for the job available? > Yes. It's in the archives. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
GDPS does much more, it switches Dasd and applications on seconds. And have a look at Sysplex features and functions. You can switch without downtime. Does this look like a future already present? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of IBMZOS Sent: 28 May, 2015 14:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LPAR MOBILITY Thank's for the reply. No GDPS do not cover this specific area; it automate the IPL stop end start process, in approximatively 30 mn. With LPM on I series, the mobility of partition is in seconds !!! We use it on planned outages and it work very well. Z/OS is not the future ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
Clearly this is not the case: "JES requires that the "*" will be separated by a comma or blank from the next JCL keyword" I knew this because just today I discovered the SYMBOLS,EXPORT SYMLIST JCL functions. Well I have only been writing it for 40 years. I'm sure it wasn't there in OS/360 ?! :-/ //K248610S JOB (BSA0,P,B),'SYMBOLS TRY',CLASS=A,MSGCLASS=O, // NOTIFY=K248610,REGION=0M //* // EXPORT SYMLIST=(SYSIN) // SET LIB='K248610.MBM.JCL' // SET CPY=&LIB..COPY // SET DEL='(MOD,DELETE),SPACE=(TRK,0)' // SET SYSIN=' COPY I=I,O=O' //* //CLEANUP EXEC PGM=IEFBR14 //DELETE01 DD DISP=&DEL,DSN=&CPY //* //COPYLIB EXEC PGM=IEBCOPY //IDD DISP=SHR,DSN=&LIB //ODD DSN=&CPY, //DISP=(,CATLG,DELETE), //REFDD=*.I, //DCB=*.I, //SPACE=(TRK,(25,5,30),RLSE), //DSNTYPE=LIBRARY //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSINDD *,SYMBOLS=EXECSYS <=== COMMA FOLLOWS DD * &SYSIN // //* //E1 EXPORT SYMLIST=(JOBLIB) //S1 SET JOBLIB=&SYSUID..MBM.JCL //TSO EXEC PGM=IKJEFT1A,COND=(0,LE) //SYSTSPRT DD SYSOUT=* //SYSTSIN DD *,SYMBOLS=EXECSYS %JOBLIB &JOBLIB //* //* //* /Steve From: Doron Geva To: IBM-MAIN@LISTSERV.UA.EDU Date: 2015-05-28 12:26 Subject:Re: GENERATED STATEMENT!? Sent by:IBM Mainframe Discussion List It seems like JES error. JES is the one that add the "//SYSIN DD * GENERATED STATEMENT" before calling the MVS converter JES requires that the "*" will be separated by a comma or blank from the next JCL keyword ?Doron? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Såvida annat inte anges ovan: / Unless stated otherwise above: IBM Svenska AB Organisationsnummer: 556026-6883 Adress: 164 92 Stockholm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
On Thu, 28 May 2015 04:22:01 -0500, IBMZOS wrote: >I'm am confused about one thing. > >IBM has created the Live Partition Mobility on system I, with the >virtualization layer. > >Why this doesn't exit on Z machines, with an integrated flavor of Z/VM for >example ? > >Does IBM has intent to have such feature one day ? > >I think this is nearly a 'revolution' and thought Z was at the top of >technology... > >Am i the only Professional to ask this ? > >Thank's. Jean. > > Not z/OS guests, but z/Linux: from http://www.vm.ibm.com/ssi/ z/VM V6.2 release made available the Single System Image feature and Live Guest Relocation, which is the ability for a Linux guest to be moved from one z/VM system to another within the SSI cluster. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
Predictably stupid response. Where do I find the archives? /Steve :-/ From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Date: 2015-05-28 14:01 Subject:Re: GENERATED STATEMENT!? Sent by:IBM Mainframe Discussion List On Thu, 28 May 2015 13:51:26 +0200, Steve Coalbran wrote: >I missed the original of this. >Is the original JCL for the job available? > Yes. It's in the archives. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Såvida annat inte anges ovan: / Unless stated otherwise above: IBM Svenska AB Organisationsnummer: 556026-6883 Adress: 164 92 Stockholm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
Sorry but GDPS do not do this in seconds. it automate start / stop with approximatively 30 mn of interruption and do dasd swap in seconds (base swap of dasd). So the minimum interrupt time is 30mn-1hour when LPM do this **in seconds**. Sysplex do the job, but only in full parallel sysplex, which is very hard and long work. I would like to have ONE Click on my Z/OS lpar to move it on another CPU, as is on Iseries with LPM. The future is.. on Iseries :( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
Why ask the question if you already think you know what the answer is? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of IBMZOS Sent: 28 May, 2015 14:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LPAR MOBILITY Sorry but GDPS do not do this in seconds. it automate start / stop with approximatively 30 mn of interruption and do dasd swap in seconds (base swap of dasd). So the minimum interrupt time is 30mn-1hour when LPM do this **in seconds**. Sysplex do the job, but only in full parallel sysplex, which is very hard and long work. I would like to have ONE Click on my Z/OS lpar to move it on another CPU, as is on Iseries with LPM. The future is.. on Iseries :( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
Steve Coalbran wrote: >Predictably stupid response. Not stupid response! In fact, it is the only place. [1] >Where do I find the archives? Look in https://listserv.ua.edu/cgi-bin/wa?INDEX and scroll down for IBM-MAIN. Groete / Greetings Elardus Engelbrecht [1] - Google Groups also mirrors this, but discussions there are not mirrored back to the main IBM-MAIN site. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
You could do an internet search for IBMMAIN ARCHIVES Or use this URL https://listserv.ua.edu/archives/ibm-main.html Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Steve Coalbran > Sent: Thursday, May 28, 2015 5:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: GENERATED STATEMENT!? > > Predictably stupid response. > Where do I find the archives? > /Steve :-/ > > > > From: Paul Gilmartin <000433f07816-dmarc- > requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 2015-05-28 14:01 > Subject:Re: GENERATED STATEMENT!? > Sent by:IBM Mainframe Discussion List > > > > On Thu, 28 May 2015 13:51:26 +0200, Steve Coalbran wrote: > > >I missed the original of this. > >Is the original JCL for the job available? > > > Yes. It's in the archives. > > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
I'll disregard the idea that I have that you do not seem to be very knowledgeable with GDPS (or sysplexes for that matter) and its many modes that have been released this past decade and a half; LPM would only do what you describe if the image you're trying to move is healthy and running fine, not so much if your image is down/crashed (disaster situation). At that point you have to boot the image on your other machine, there is nothing for LPM to mirror to your other machine if your original image is not running. You will still encounter downtime in this situation. So the key is; LPM is only interesting for planned outages of your hardware. Also; while you're swapping with LPM, your applications will encounter slower response times, because LPM will have to synchronously copy working storage pages and disk frames when the OS requests them on the target machine. Your OS obviously has to wait while LPM satisfies the request, which might take a considerable amount of time on an electronics scale. So not only are you swapping fast when you could be swapping slow (planned downtime is that, planned, you should be planning, so a slow swap should be bearable), you're also inducing an impact on your business by slowing down your applications while you swap. Considering you have a sysplex architecture, you're free to do what you want. Slow and steady re-ipl an LPAR while its work is offloaded to your other LPARS in the sysplex (planned outage). Or instant swaps (if you went that far with GDPS) for disaster recovery, or considering how fast GDPS can be, business disaster prevention while a physical disaster is taking place. So when you acknowledge the limitations of LPM, that being when you can invoke it, and what it would entail in terms of response time impact, it becomes hard to come up with a case where you could actually use it. _Jan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of IBMZOS Sent: donderdag 28 mei 2015 2:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LPAR MOBILITY Sorry but GDPS do not do this in seconds. it automate start / stop with approximatively 30 mn of interruption and do dasd swap in seconds (base swap of dasd). So the minimum interrupt time is 30mn-1hour when LPM do this **in seconds**. Sysplex do the job, but only in full parallel sysplex, which is very hard and long work. I would like to have ONE Click on my Z/OS lpar to move it on another CPU, as is on Iseries with LPM. The future is.. on Iseries :( -- 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: LPAR MOBILITY
Sorry. i do not know all the solutions, but know what the GDPS and Hyperswap do. I'm confused to invest many hard work on Parallel Sysplex if one day, i can do LPM on Z with one clic. I think all the mainframe community would appreciate... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GENERATED STATEMENT!?
https://www.google.com/search?q=generated+statement+paul+gilmartin Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, May 28, 2015 5:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GENERATED STATEMENT!? Steve Coalbran wrote: >Predictably stupid response. Not stupid response! In fact, it is the only place. [1] >Where do I find the archives? Look in https://listserv.ua.edu/cgi-bin/wa?INDEX and scroll down for IBM-MAIN. Groete / Greetings Elardus Engelbrecht [1] - Google Groups also mirrors this, but discussions there are not mirrored back to the main IBM-MAIN site. -- 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: LPAR MOBILITY
Thank's Jan for detailed reply. Yes for the impact of LPM. We use it for planned outages, and work fine. I cannot do with my sysplex, because your reply is applicable to a Parallel sysplex, which is a HIGH step forward. From all the reply, i understand that Parallel Syplex is really the solution. Just curious if LPM or Live Guest Migration is announced one day on Z/OS, for planned outages... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
>z/VM V6.2 release made available the Single System Image feature and Live >Guest Relocation, which is the ability for a Linux guest to be moved from one >z/VM system to another within the SSI cluster. IBM is chasing smoke on this. On the way back from Boston Share, I dropped in to the VMWORLD in Frisco. Quite an eye opener. One of the speakers did a live migration of a running guest from the America to India. Real time in front of all of us. With IP monitors running. Pretty bloody impressive. As expected it knocked response times around during the move, but this was over a public switched network, not CTCs. Nearly two years ago. Sahne ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
Interesting, never thought someone would consider GDPS on anything but parallel sysplex. What would be the point? I could buy a Ferrari and remove the wheels.. But it wouldn't be much fun...and would be a very expensive chair. Seems more like the person is looking for parallel sysplex / sysplex-in-a-box plus automation. Rob Schramm On Thu, May 28, 2015, 9:01 AM IBMZOS < 00af65f10fb1-dmarc-requ...@listserv.ua.edu> wrote: > Thank's Jan for detailed reply. Yes for the impact of LPM. We use it for > planned outages, and work fine. I cannot do with my sysplex, because your > reply is applicable to a Parallel sysplex, which is a HIGH step forward. > From all the reply, i understand that Parallel Syplex is really the > solution. Just curious if LPM or Live Guest Migration is announced one day > on Z/OS, for planned outages... > > -- > 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: LPAR MOBILITY
1) What is the goal of the environment? 2) How much work needs to be processed? 3) How quickly do you need to get the environment back running after an unplanned outage vs a planned outage. 4) What is the cost for floor space, electricity, heating/cooling? 5) What are the licensing costs? 6) What is the ROI, TCO, - what are your goals? All platforms have their pros and cons. This does not mean one is superior to another, just different. For zSystems, work horses. You have huge data, a lot of processing power needed and quick responses. And you want to run more than one app at a time. You would not want to use it if you want to just run a little query of a 1000 rows. Excel would probably work fine on a PC. I have some data I would prefer to work in Excel but it is too much for the PC to handle, so I use the mainframe. If you need something that handles IO, huge programs, communicates with almost anything, then look towards zSystems. I worked at a shop that was Huge for zSystems. However, they also ran TPF for a specific application. The reason for TPF is it could IPL quickly. So their appl was not down for very long. With the work done on Parallel Sysplex, DB2 Data Sharing, CICS-Plex, IMS-Plex, the zSystems are up 24x7x365. With advances in SRDF, GDPS, XRC, Gridded Tape Systems, there can be an almost instantaneous roll over. Oh yeah, and there is that z/VM and z/Linux area as well. ;-D I can have a plex and take down an LPAR and my app and users may not even know it happened. I do not necessarily need to move anything, the system will take care of function shipping if it is setup. I would suggest before stating that one environment or another is better than another, try to determine what business problem you are trying to solve and then identify what is best for that business case. zSystems are geared for the future, mobile technology, security, availability, reliability, and I just love 'em. So I am very biased. But not so much not to look to other options when it is a valid business case. Just because one platform does one thing really well, does not make it a solution. Does IBM look at other ways of doing work - yes. Can they get it out quickly - sometimes. Once we can defeat the laws of physics and move huge quantities of data very quickly over very large distances, then I will be much happier. Now I can do it across town. I want to do it across the galaxy. Then the universe. One should always have goals. Just my two cents worth. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of IBMZOS > Sent: Thursday, May 28, 2015 5:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LPAR MOBILITY > > Sorry. i do not know all the solutions, but know what the GDPS and > Hyperswap do. I'm confused to invest many hard work on Parallel Sysplex if > one day, i can do LPM on Z with one clic. I think all the mainframe community > would appreciate... > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
"Sorry but GDPS do not do this in seconds." GDPS Active-Active in Active-Standby mode can do this in seconds for application workloads across two sysplexes at great distance. There are many flavours of GDPS for PPRC, XRC, Active-Active and possibly others I don’t know. Mike Wawiorko Please consider the environment before printing this e-mail -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of IBMZOS Sent: 28 May 2015 13:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LPAR MOBILITY Sorry but GDPS do not do this in seconds. it automate start / stop with approximatively 30 mn of interruption and do dasd swap in seconds (base swap of dasd). So the minimum interrupt time is 30mn-1hour when LPM do this **in seconds**. Sysplex do the job, but only in full parallel sysplex, which is very hard and long work. I would like to have ONE Click on my Z/OS lpar to move it on another CPU, as is on Iseries with LPM. The future is.. on Iseries :( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
As you said Rob. Interesting, since the "GDPS solution" was suggested by an IBM representative. :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
Well, I moved ISAUTH() unchanged to its own assembler module. No change in the error. I removed the IEABRCX DEFINE and bingo! It works. BTW, the RPTSTG(ON) output shows nothing unusual. I can post it if anyone thinks they would see something there. FWIW, here is the complete assembled code of the new ISAUTH. The addresses are of course different. CDSALEN is also a lot smaller because ISAUTH basically needs none of the work area used by some of the other functions. ***That's not the key difference -- the smaller CDSALEN still fails if IEABRCX DEFINE.*** Other than that, the only difference I can see relative to the old code is the base/displacement branches rather than branch relatives. (The EXTRN CEESTART is generated once per assembly by EDCPRLG. It's earlier in the listing in the big module.) I am *totally* mystified. Even if you posit a (HIGHLY unlikely!) bug in TESTAUTH or LE, I don't see how substituting two BRC's for BC's could expose it. 23 ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG 24+*** 0 0009825+IHB0002DS DSECT 26+ DSD 27+ DSCL(120+0) 00080 028+ ORG IHB0002DS 29+ DSCL(CDSALEN+8) 00098 0009830+ ORG 31+ DS0D 00090 32+IHB0002LG EQU *-IHB0002DS-8 0001C 000C033+CZAISAUT CSECT 34+*-- 35+ DS0H R:F 0001C 36+ USING *,15 47F0 F0400005C37+ISAUTH B IHB0002B branch ar 38+* PPA1 constant area 1439+ DCAL1(IHB0002N+4-*) offs CE40+ DCX'CE' . CEE A041+ DCX'A0' . CEE 1042+ DCAL1(0+0+16) . memb 0038 43+ DCAL4(IHB0002P) . A( 44+ DCAL4(0) . A( 0090 45+ DCAL4(IHB0002LG)to 0006 46+IHB0002N DCAL2(6) . leng C9E2C1E4E3C8 47+ DCC'ISAUTH' untr 48+*-- 49+ EXTRN CEESTART 50+*-- 51+* PPA2 constant area 52+IHB0002P DS0F forc 0353+ DCX'03' . memb 0054+ DCX'00' . memb 3355+ DCX'33' . plis 0056+ DCX'00' . CEE 57+ DCAL4(CEESTART) 58+ DCAL4(0)A( 0048 59+ DCAL4(IHB0002T) . A( 60+* 61+* Time stamp area 62+IHB0002T DS0F F2F0F1F5 63+ DCCL4'2015' . F0F5F2F8 64+ DCCL4'0528' . mmdd F0F9F1F5F0F0 65+ DCCL6'091500' . hhmm F0F1 66+ DCCL2'01' . vers F0F1F0F0 67+ DCCL4'0100' . rele 68+* 69+IHB0002B DS0H 70+*** 90EC D00CC71+ STM 14,12,12(13) . save 72+*** 5820 D04C0004C73+ L 2,76(,13) get 5800 F0100001074+ L 0,16(,15) size 1E02 75+ ALR 0,2 old 5500 C00CC76+ CL0,12(,12) chec 47D0 F05C0007877+ BNH *+10
Re: LPAR MOBILITY
Many thank's Lizette for your reply. I'm happy to see that the Parallel Sysplex is the solution we can continue to invest on. When IBM announce a 'Star Trek' solution we investigate on it. Don't hold it against me just to be curious what others do and what the future can Be. Thank's again. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
Yes that's right, and this imply a specific design of data infratructure, aka two copies of data, software replicated. Many thank's. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
FWIW, I can duplicate the problem with a call from a trivial C++ program.
Whether or not the program actually is authorized does not seem to make a
difference. Here's the entire program:
#ifdef __MVS__
// Same pragmas!
#pragma runopts(
STACK(64K,16K),ANYHEAP(192K,8K),HEAP(1024K),PLIST(HOST),POSIX(ON),TRAP(ON,NO
SPIE),NOEXECOPS )
#endif
#include
#include
extern "OS" {bool ISAUTH();}
int main(int argc, char* argv[])
{
printf("ISAUTH() test sandbox entered\n");
printf("Headed off to ISAUTH()\n");
bool isauth = ISAUTH();
printf("Back from ISAUTH(), isauth=%d\n", isauth);// make sure call
does not get optimized out
printf("Adios muchachos!\n");
return 0;
}
Output is
ISAUTH() test sandbox entered
Headed off to ISAUTH()
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4088 TO DATA SET: ...
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, May 28, 2015 6:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mysterious U4088-63 from RPTSTG(ON)
Well, I moved ISAUTH() unchanged to its own assembler module. No change in
the error. I removed the IEABRCX DEFINE and bingo! It works.
BTW, the RPTSTG(ON) output shows nothing unusual. I can post it if anyone
thinks they would see something there.
FWIW, here is the complete assembled code of the new ISAUTH. The addresses
are of course different. CDSALEN is also a lot smaller because ISAUTH
basically needs none of the work area used by some of the other functions.
***That's not the key difference -- the smaller CDSALEN still fails if
IEABRCX DEFINE.*** Other than that, the only difference I can see relative
to the old code is the base/displacement branches rather than branch
relatives. (The EXTRN CEESTART is generated once per assembly by EDCPRLG.
It's earlier in the listing in the big module.)
I am *totally* mystified. Even if you posit a (HIGHLY unlikely!) bug in
TESTAUTH or LE, I don't see how substituting two BRC's for BC's could expose
it.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEFC653I
The job: //ECHO JOB 505303JOB,'Paul Gilmartin', // MSGLEVEL=(1,1),REGION=0M //* //* Doc: Hack to display PARM in SYSPRINT //* //USERCOUTPUT JESDS=ALL,DEFAULT=YES, //* DEST=&SYSNAME..&SYSUID, // CLASS=R,PAGEDEF=V0648Z,CHARS=GT12 //* // SET ME='gil' //* //* Only to display PARM in error message. //A EXEC PGM=ASMA90, // PARM='''Bonnie&&Clyde''&&&ME' //SYSPRINT DD SYSOUT=(,) // Shows in JESJCL: //* Only to display PARM in error message. 4 //A EXEC PGM=ASMA90, // PARM='''Bonnie&&Clyde''&&&ME' IEFC653I SUBSTITUTION JCL - PGM=ASMA90,PARM='''Bonnie&&Clyde''&&gil' ... but in HLASM SYSPRINT: OPTIONS MESSAGES ** ASMA400W Error in invocation parameter - 'Bonnie&Clyde'&gil I believe the ASMA400W is correct and IEFC653I is incorrect. The PARM passed to the program should be not: ''Bonnie&&Clyde''&&gil but: 'Bonnie&Clyde'&gil ... because JCL substitution collapses double ampersands to single ampersands and double apostrophes to single apostrophes in the PARM actually passed to the executed program. IEFC653I should properly reflect this, even as HLASM does. I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
My only guess is: the branch in the Prolog to obtain New storage in the case when the current segment is too small must point to a special routine in the rptstg(on) case. And maybe this routine has a Problem if the branch is a BRC and no BC. But I cannot really imagine what sort of problem -Original Message- Date: Thu, 28 May 2015 15:33:41 +0200 Subject: Re: Mysterious U4088-63 from RPTSTG(ON) From: Charles Mills To: IBM-MAIN@LISTSERV.UA.EDU Well, I moved ISAUTH() unchanged to its own assembler module. No change in the error. I removed the IEABRCX DEFINE and bingo! It works. BTW, the RPTSTG(ON) output shows nothing unusual. I can post it if anyone thinks they would see something there. FWIW, here is the complete assembled code of the new ISAUTH. The addresses are of course different. CDSALEN is also a lot smaller because ISAUTH basically needs none of the work area used by some of the other functions. ***That's not the key difference -- the smaller CDSALEN still fails if IEABRCX DEFINE.*** Other than that, the only difference I can see relative to the old code is the base/displacement branches rather than branch relatives. (The EXTRN CEESTART is generated once per assembly by EDCPRLG. It's earlier in the listing in the big module.) I am *totally* mystified. Even if you posit a (HIGHLY unlikely!) bug in TESTAUTH or LE, I don't see how substituting two BRC's for BC's could expose it. 23 ISAUTH EDCPRLG DSALEN=CDSALEN,BASEREG 24+*** 0 0009825+IHB0002DS DSECT 26+ DSD 27+ DSCL(120+0) 00080 028+ ORG IHB0002DS 29+ DSCL(CDSALEN+8) 00098 0009830+ ORG 31+ DS0D 00090 32+IHB0002LG EQU *-IHB0002DS-8 0001C 000C033+CZAISAUT CSECT 34+*-- 35+ DS0H R:F 0001C 36+ USING *,15 47F0 F0400005C37+ISAUTH B IHB0002B branch ar 38+* PPA1 constant area 1439+ DCAL1(IHB0002N+4-*) offs CE40+ DCX'CE' . CEE A041+ DCX'A0' . CEE 1042+ DCAL1(0+0+16) . memb 0038 43+ DCAL4(IHB0002P) . A( 44+ DCAL4(0) . A( 0090 45+ DCAL4(IHB0002LG)to 0006 46+IHB0002N DCAL2(6) . leng C9E2C1E4E3C8 47+ DCC'ISAUTH' untr 48+*-- 49+ EXTRN CEESTART 50+*-- 51+* PPA2 constant area 52+IHB0002P DS0F forc 0353+ DCX'03' . memb 0054+ DCX'00' . memb 3355+ DCX'33' . plis 0056+ DCX'00' . CEE 57+ DCAL4(CEESTART) 58+ DCAL4(0)A( 0048 59+ DCAL4(IHB0002T) . A( 60+* 61+* Time stamp area 62+IHB0002T DS0F F2F0F1F5 63+ DCCL4'2015' . F0F5F2F8 64+ DCCL4'0528' . mmdd F0F9F1F5F0F0 65+ DCCL6'091500' . hhmm F0F1 66+ DCCL2'01' . vers F0F1F0F0 67+ DCCL4'0100' . rele 68+* 69+IHB0002B DS0H 70+*** 90EC D00C
Re: Mysterious U4088-63 from RPTSTG(ON)
Is it time to fire up a PMR?
On 28/05/2015 9:55 PM, Charles Mills wrote:
FWIW, I can duplicate the problem with a call from a trivial C++ program.
Whether or not the program actually is authorized does not seem to make a
difference. Here's the entire program:
#ifdef __MVS__
// Same pragmas!
#pragma runopts(
STACK(64K,16K),ANYHEAP(192K,8K),HEAP(1024K),PLIST(HOST),POSIX(ON),TRAP(ON,NO
SPIE),NOEXECOPS )
#endif
#include
#include
extern "OS" {bool ISAUTH();}
int main(int argc, char* argv[])
{
printf("ISAUTH() test sandbox entered\n");
printf("Headed off to ISAUTH()\n");
bool isauth = ISAUTH();
printf("Back from ISAUTH(), isauth=%d\n", isauth);// make sure call
does not get optimized out
printf("Adios muchachos!\n");
return 0;
}
Output is
ISAUTH() test sandbox entered
Headed off to ISAUTH()
CEE3798I ATTEMPTING TO TAKE A DUMP FOR ABEND U4088 TO DATA SET: ...
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, May 28, 2015 6:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mysterious U4088-63 from RPTSTG(ON)
Well, I moved ISAUTH() unchanged to its own assembler module. No change in
the error. I removed the IEABRCX DEFINE and bingo! It works.
BTW, the RPTSTG(ON) output shows nothing unusual. I can post it if anyone
thinks they would see something there.
FWIW, here is the complete assembled code of the new ISAUTH. The addresses
are of course different. CDSALEN is also a lot smaller because ISAUTH
basically needs none of the work area used by some of the other functions.
***That's not the key difference -- the smaller CDSALEN still fails if
IEABRCX DEFINE.*** Other than that, the only difference I can see relative
to the old code is the base/displacement branches rather than branch
relatives. (The EXTRN CEESTART is generated once per assembly by EDCPRLG.
It's earlier in the listing in the big module.)
I am *totally* mystified. Even if you posit a (HIGHLY unlikely!) bug in
TESTAUTH or LE, I don't see how substituting two BRC's for BC's could expose
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: GENERATED STATEMENT!?
Which job? This us a query scheduled frim a network pc. בתאריך 28 במאי 2015 14:51, "Steve Coalbran" כתב: > I missed the original of this. > Is the original JCL for the job available? > /steve > > > > From: Doron Geva > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 2015-05-28 12:26 > Subject:Re: GENERATED STATEMENT!? > Sent by:IBM Mainframe Discussion List > > > > It seems like JES error. > JES is the one that add the "//SYSIN DD * GENERATED > STATEMENT" before calling the MVS converter > JES requires that the "*" will be separated by a comma or blank from the > next JCL keyword > > ?Doron? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > Såvida annat inte anges ovan: / Unless stated otherwise above: > IBM Svenska AB > Organisationsnummer: 556026-6883 > Adress: 164 92 Stockholm > > -- > 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: Mysterious U4088-63 from RPTSTG(ON)
Sigh. Torture. BTW, if anyone wants to play with this I will be happy to send you the two source modules. 24 lines of C++ and 77 lines of assembler. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, May 28, 2015 7:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) Is it time to fire up a PMR? On 28/05/2015 9:55 PM, Charles Mills wrote: > FWIW, I can duplicate the problem with a call from a trivial C++ program. > Whether or not the program actually is authorized does not seem to > make a difference. Here's the entire program: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
Yeah, I suppose a routine could be looking at R14 minus 10 to see how it got there. Unlikely, and awful coding technique, but possible. But why only this one routine? If I comment out the call in the (large, real) C++ program, a subsequent call to another routine in the same source module works. I would assume C++ gets the stack at startup, not on the first external call. Interesting thought. I could add a call to a dummy do-nothing routine ahead of the ISAUTH call. But frankly, I am about out of patience with this problem. I have a fix now for the "real" problem, so perhaps I need to get back to my real job. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Thursday, May 28, 2015 7:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) My only guess is: the branch in the Prolog to obtain New storage in the case when the current segment is too small must point to a special routine in the rptstg(on) case. And maybe this routine has a Problem if the branch is a BRC and no BC. But I cannot really imagine what sort of problem -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
On Thu, 28 May 2015 13:20:53 +, Rob Schramm wrote: >Interesting, never thought someone would consider GDPS on anything but >parallel sysplex. Indeed. That's why it is called "Graphically Dispersed Parallel Sysplex". -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
List of all on-line volumes
Is there simple batch method to get a list of all on-line dasd volumes without actually coding the volumes in the JCL? I don't need it pretty, just something to ftp off-site for DR reasons where a script will use it to validate that all the active volumes are actually on one of the DR tapes. -- Tony Thigpen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Logjam hack?
https://weakdh.org/ (or GIYF). The articles mention man-in-the-middle vulnerability. Is anything immune to MITM? Even quantum? And I don't believe quantum is in practical use nowadays. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List of all on-line volumes
z/VSE or z/OS? I ask due to your email address having vse in it. I don't know VSE. On z/OS, I would run SDSF in batch and just do an operator command, and capture the SYSLOG. If you want to, there is an LSPACE command, for z/OS, on the CBT site in file 906 which you might like. If you are truly strange, you can down _my_ UNIX command examples which are in file 864. http://www.cbttape.org/cbtdowns.htm If you would like to look at my UNIX "lsdasd" command online, then you can gaze in wonder (or horror) at it at: https://github.com/JohnArchieMckown/utilities-1/blob/master/lsdasd.s It is LE enabled HLASM code. On Thu, May 28, 2015 at 11:07 AM, Tony Thigpen wrote: > Is there simple batch method to get a list of all on-line dasd volumes > without actually coding the volumes in the JCL? > > I don't need it pretty, just something to ftp off-site for DR reasons > where a script will use it to validate that all the active volumes are > actually on one of the DR tapes. > > -- > Tony Thigpen > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List of all on-line volumes
z/OS. (I am spending more and more time on the dark side lately.) :-) Tony Thigpen John McKown wrote on 05/28/2015 12:37 PM: z/VSE or z/OS? I ask due to your email address having vse in it. I don't know VSE. On z/OS, I would run SDSF in batch and just do an operator command, and capture the SYSLOG. If you want to, there is an LSPACE command, for z/OS, on the CBT site in file 906 which you might like. If you are truly strange, you can down _my_ UNIX command examples which are in file 864. http://www.cbttape.org/cbtdowns.htm If you would like to look at my UNIX "lsdasd" command online, then you can gaze in wonder (or horror) at it at: https://github.com/JohnArchieMckown/utilities-1/blob/master/lsdasd.s It is LE enabled HLASM code. On Thu, May 28, 2015 at 11:07 AM, Tony Thigpen wrote: Is there simple batch method to get a list of all on-line dasd volumes without actually coding the volumes in the JCL? I don't need it pretty, just something to ftp off-site for DR reasons where a script will use it to validate that all the active volumes are actually on one of the DR tapes. -- Tony Thigpen -- 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: Logjam hack?
On Thu, May 28, 2015 at 11:21 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > https://weakdh.org/ > > (or GIYF). The articles mention man-in-the-middle vulnerability. Is > anything immune to MITM? Even quantum? And I don't believe > quantum is in practical use nowadays. > The only thing that _I_ know of which cannot be gotten my MITM (at least not easily) is if you use a "one time pad" ( http://en.wikipedia.org/wiki/One-time_pad) where you distribute the "pads" physically (say via secured hand courier in a triple locked, milspec carrier). Or if, like in a SciFi novel, they develop the PGR communication chip which signals data over quantum entangled pairs. That simply cannot be intercepted. > > -- gil > > -- My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List of all on-line volumes
On Thu, May 28, 2015 at 11:40 AM, Tony Thigpen wrote: > z/OS. > (I am spending more and more time on the dark side lately.) :-) > > Tony Thigpen > > Just remember that there is more "dark matter" in the universe than there is "normal" matter. But, just like z/OS, it refuses to play nicely with others. Well, z/OS is nicer than MS-Windows. But that is like saying that a bugler is nicer than a serial killer. Penguinista and Proud! -- My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List of all on-line volumes
ISMF in batch is another option. Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Thursday, May 28, 2015 12:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: List of all on-line volumes z/OS. (I am spending more and more time on the dark side lately.) :-) Tony Thigpen John McKown wrote on 05/28/2015 12:37 PM: > z/VSE or z/OS? I ask due to your email address having vse in it. I don't > know VSE. > > On z/OS, I would run SDSF in batch and just do an operator command, and > capture the SYSLOG. > > If you want to, there is an LSPACE command, for z/OS, on the CBT site in > file 906 which you might like. If you are truly strange, you can down _my_ > UNIX command examples which are in file 864. > http://www.cbttape.org/cbtdowns.htm > If you would like to look at my UNIX "lsdasd" command online, then you can > gaze in wonder (or horror) at it at: > https://github.com/JohnArchieMckown/utilities-1/blob/master/lsdasd.s > It is LE enabled HLASM code. > > > On Thu, May 28, 2015 at 11:07 AM, Tony Thigpen wrote: > >> Is there simple batch method to get a list of all on-line dasd volumes >> without actually coding the volumes in the JCL? >> >> I don't need it pretty, just something to ftp off-site for DR reasons >> where a script will use it to validate that all the active volumes are >> actually on one of the DR tapes. >> >> -- >> Tony Thigpen >> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List of all on-line volumes
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, May 28, 2015 12:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: List of all on-line volumes On Thu, May 28, 2015 at 11:40 AM, Tony Thigpen wrote: > z/OS. > (I am spending more and more time on the dark side lately.) :-) > > Tony Thigpen > > Just remember that there is more "dark matter" in the universe than there is "normal" matter. But, just like z/OS, it refuses to play nicely with others. Well, z/OS is nicer than MS-Windows. But that is like saying that a bugler is nicer than a serial killer. Penguinista and Proud! -- My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- 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: List of all on-line volumes
On Thu, May 28, 2015 at 11:59 AM, van der Grijn, Bart (B) < bvandergr...@dow.com> wrote: > ISMF in batch is another option. > Bart > > Perhaps the easiest is IDCAMS DCOLLECT. Something like: //STEP002 EXEC PGM=IDCAMS, // REGION=0M //* //SYSPRINT DD SYSOUT=* //DCOUTDD DSN=&SYSUID..DCOUT, // DISP=(NEW,CATLG,DELETE), // SPACE=(TRK,(200,100),RLSE), // RECFM=VB,LRECL=932, // DSORG=PS //SYSINDD * DCOLLECT - OUTFILE(DCOUT) - VOLUMES( - * - ) /* -- My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List of all on-line volumes
OOPS, forgot a parameter. The NODATAINFO is needed or you will get a listing of all the data set information on the volumes as well. //STEP002 EXEC PGM=IDCAMS, // REGION=0M //* //SYSPRINT DD SYSOUT=* //DCOUTDD DSN=&SYSUID..DCOUT, // DISP=(NEW,CATLG,DELETE), // SPACE=(TRK,(200,100),RLSE), // RECFM=VB,LRECL=932, // DSORG=PS //SYSINDD * DCOLLECT - OUTFILE(DCOUT) - NODATAINFO - VOLUMES( - * - ) /* On Thu, May 28, 2015 at 12:15 PM, John McKown wrote: > On Thu, May 28, 2015 at 11:59 AM, van der Grijn, Bart (B) < > bvandergr...@dow.com> wrote: > >> ISMF in batch is another option. >> Bart >> >> > > Perhaps the easiest is IDCAMS DCOLLECT. Something like: > > //STEP002 EXEC PGM=IDCAMS, > // REGION=0M > //* > //SYSPRINT DD SYSOUT=* > //DCOUTDD DSN=&SYSUID..DCOUT, > // DISP=(NEW,CATLG,DELETE), > // SPACE=(TRK,(200,100),RLSE), > // RECFM=VB,LRECL=932, > // DSORG=PS > //SYSINDD * > DCOLLECT - >OUTFILE(DCOUT) - >VOLUMES( - >* - > ) > /* > > > -- > My sister opened a computer store in Hawaii. She sells C shells down by > the seashore. > > If someone tell you that nothing is impossible: > Ask him to dribble a football. > > He's about as useful as a wax frying pan. > > 10 to the 12th power microphones = 1 Megaphone > > Maranatha! <>< > John McKown > -- My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
GDPS has about as much to do with 'parallel sysplex' as TSO has to do with 'time sharing'. For us, GDPS automates disaster recovery. Before GDPS, we had to do a lot of manual procedures that GDPS performs without the need for fingers on a keyboard. Included in our DR environment is one monoplex LPAR that runs TPX. This LPAR has no need for sysplex resources but has to run in DR, which we view as business resumption after a catastrophic data center failure. RTO is important, but a few hours is far preferable to the alternative abyss. . . . 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 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Thursday, May 28, 2015 6:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LPAR MOBILITY Interesting, never thought someone would consider GDPS on anything but parallel sysplex. What would be the point? I could buy a Ferrari and remove the wheels.. But it wouldn't be much fun...and would be a very expensive chair. Seems more like the person is looking for parallel sysplex / sysplex-in-a-box plus automation. Rob Schramm On Thu, May 28, 2015, 9:01 AM IBMZOS < 00af65f10fb1-dmarc-requ...@listserv.ua.edu> wrote: > Thank's Jan for detailed reply. Yes for the impact of LPM. We use it > for planned outages, and work fine. I cannot do with my sysplex, > because your reply is applicable to a Parallel sysplex, which is a HIGH step > forward. > From all the reply, i understand that Parallel Syplex is really the > solution. Just curious if LPM or Live Guest Migration is announced one > day on Z/OS, for planned outages... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
But GDPS is not just a Disaster Recovery solution. It can "live" swap from data center to data center, within data centers. Are you saying that you are just a base sysplex using GDPS? Rob Schramm On Thu, May 28, 2015 at 1:55 PM J O Skip Robinson wrote: > GDPS has about as much to do with 'parallel sysplex' as TSO has to do with > 'time sharing'. For us, GDPS automates disaster recovery. Before GDPS, we > had to do a lot of manual procedures that GDPS performs without the need > for fingers on a keyboard. Included in our DR environment is one monoplex > LPAR that runs TPX. This LPAR has no need for sysplex resources but has to > run in DR, which we view as business resumption after a catastrophic data > center failure. RTO is important, but a few hours is far preferable to the > alternative abyss. > > . > . > . > 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 > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Rob Schramm > Sent: Thursday, May 28, 2015 6:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LPAR MOBILITY > > Interesting, never thought someone would consider GDPS on anything but > parallel sysplex. What would be the point? I could buy a Ferrari and > remove the wheels.. But it wouldn't be much fun...and would be a very > expensive chair. > > Seems more like the person is looking for parallel sysplex / > sysplex-in-a-box plus automation. > > Rob Schramm > > On Thu, May 28, 2015, 9:01 AM IBMZOS < > 00af65f10fb1-dmarc-requ...@listserv.ua.edu> wrote: > > > Thank's Jan for detailed reply. Yes for the impact of LPM. We use it > > for planned outages, and work fine. I cannot do with my sysplex, > > because your reply is applicable to a Parallel sysplex, which is a HIGH > step forward. > > From all the reply, i understand that Parallel Syplex is really the > > solution. Just curious if LPM or Live Guest Migration is announced one > > day on Z/OS, for planned outages... > > -- > 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: LPAR MOBILITY
On 5/28/2015 11:17 AM, Tom Marchant wrote: On Thu, 28 May 2015 13:20:53 +, Rob Schramm wrote: Interesting, never thought someone would consider GDPS on anything but parallel sysplex. Indeed. That's why it is called "Graphically Dispersed Parallel Sysplex". GDPS has been known to be graphic, as has been my language at times when working with it. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMPE MCS construction question re aliases
A question for you real SMPE jockeys out there (as opposed to a pretender like me): In creating SMPE MCS file commands for a load module that has an alias, do I need just one ++PROGRAM statement for the true module name, or do I need two (a la the way IEBCOPY deals with aliases), one for the true name and one for the alias name? (And my apologies if the question is not phrased properly -- see paragraph one.) Thanks! Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LISTDSI to indicate PDSE version 2
In z/OS 2.1 a PDSE can be allocated as type 1 or 2. The DSINFO service has been enhanced to set a variable (ZDSDSNV) that indicates if the PDSE is version 1 or 2. I've done some searching but much to my surprise I can't find a similar variable for LISTDSI. Does anyone know if such a variable exists? TIA! Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: List of all on-line volumes
Is it still called Naviquest? Several options to include PDS, DEVSERV(DS) console commands, List Backups from whatever you're using to create. To shorten the process I made a spread sheet that was in every turtle shell. Now we have a mirrored site out of state. In a message dated 5/28/2015 11:59:17 A.M. Central Daylight Time, bvandergr...@dow.com writes: ISMF in batch is another option. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
Not quite right. "Geographically Dispersed Parallel Sysplex" does the trick. --- *Lucas Rosalen* Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com * LinkedIn: http://br.linkedin.com/in/lrosalen Phone: +48 792 809 198 2015-05-28 15:35 GMT-03:00 Thomas Conley : > On 5/28/2015 11:17 AM, Tom Marchant wrote: > >> On Thu, 28 May 2015 13:20:53 +, Rob Schramm wrote: >> >> Interesting, never thought someone would consider GDPS on anything but >>> parallel sysplex. >>> >> >> Indeed. That's why it is called "Graphically Dispersed Parallel Sysplex". >> >> > GDPS has been known to be graphic, as has been my language at times when > working with it. > > Regards, > Tom Conley > > > -- > 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: (OT) Re: Question on 3270 Devices
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, May 22, 2015 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (OT) Re: Question on 3270 Devices On Fri, 22 May 2015 09:56:13 -0500, John McKown wrote: > >My sister opened a computer store in Hawaii. She sells C shells down by >the seashore. > I miss Mel Blanc. Suffering succotash. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE MCS construction question re aliases
Check your "SMP/e for z/OS: Reference" manual, Chapter 2.
" The ++PROGRAM MCS describes a program element (a pre-built load module or a
program object). It must immediately precede the load module or program object
when they are within the SYSMOD. Use the ++PROGRAM when you want to ship
executables as program parts. If you want to provide the object form of the
module, use the ++MOD MCS instead."
The name after "++PROGRAM(" is the "true module name" or Load module name.
Then in the "++PROGRAM" statement you can code, "ALIAS(" which will be the list
of alias names for the load module:
++PROGRAM(TRUEMO) ALIAS(THING1,THING2) .
So this would define the Load Module, TRUEMO with two aliases, THING1 & THING2.
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 Charles Mills
Sent: Thursday, May 28, 2015 2:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE MCS construction question re aliases
A question for you real SMPE jockeys out there (as opposed to a pretender like
me):
In creating SMPE MCS file commands for a load module that has an alias, do I
need just one ++PROGRAM statement for the true module name, or do I need two (a
la the way IEBCOPY deals with aliases), one for the true name and one for the
alias name?
(And my apologies if the question is not phrased properly -- see paragraph
one.)
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: SMPE MCS construction question re aliases
OK, great, thanks. I was looking in the "Standard Packaging Rules for z/OS
Products" and could not make sense out of what they were saying about
aliases.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Nims,Alva John (Al)
Sent: Thursday, May 28, 2015 12:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE MCS construction question re aliases
Check your "SMP/e for z/OS: Reference" manual, Chapter 2.
" The ++PROGRAM MCS describes a program element (a pre-built load module or
a program object). It must immediately precede the load module or program
object when they are within the SYSMOD. Use the ++PROGRAM when you want to
ship executables as program parts. If you want to provide the object form of
the module, use the ++MOD MCS instead."
The name after "++PROGRAM(" is the "true module name" or Load module name.
Then in the "++PROGRAM" statement you can code, "ALIAS(" which will be the
list of alias names for the load module:
++PROGRAM(TRUEMO) ALIAS(THING1,THING2) .
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE MCS construction question re aliases
On Thu, 28 May 2015 13:21:48 -0700, Charles Mills wrote: >OK, great, thanks. I was looking in the "Standard Packaging Rules for z/OS >Products" and could not make sense out of what they were saying about >aliases. > ++PROGRAM and other MCS are defined in SMP/E Reference; RECEIVE, APPLY, and ACCEPT in SMP/E Commands. And, perhaps worse, Packaging Rules tells a lot about tapes, but nothing (IIRC) about network delivery nor about CD/DVD. Are you planning to use GIMZIP (that's in Reference)? What delivery medium, network or physical (both?) And, AFAIK, IBM provides nothing for ISVs to support RECEIVE ORDER. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LISTDSI to indicate PDSE version 2
On 5/28/2015 2:47 PM, Dave Salt wrote: In z/OS 2.1 a PDSE can be allocated as type 1 or 2. The DSINFO service has been enhanced to set a variable (ZDSDSNV) that indicates if the PDSE is version 1 or 2. I've done some searching but much to my surprise I can't find a similar variable for LISTDSI. Does anyone know if such a variable exists? TIA! Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Dave, The short answer is no. The long answer is that I submitted a requirement for this and I've been working with IBM to see if we can make it happen for LISTDSI. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE MCS construction question re aliases
Geez. See the first paragraph in my OP. Yeah, a lot of tape in there. When IBM was asking here about software delivery not on tape I should have said "will you update the SMPE manuals also?" Yes, we use GIMZIP. And GIMSMP. And pax. All we are supporting currently for delivery is FTP from our server. We support FTP straight to the customer's mainframe, because a customer told me "if I have to use a PC to install it, it's not a real mainframe program." Okay, whatever. SMPE is in place. The only thing new was a load module with an alias that is critical to its operation. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 28, 2015 1:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMPE MCS construction question re aliases On Thu, 28 May 2015 13:21:48 -0700, Charles Mills wrote: >OK, great, thanks. I was looking in the "Standard Packaging Rules for >z/OS Products" and could not make sense out of what they were saying >about aliases. > ++PROGRAM and other MCS are defined in SMP/E Reference; RECEIVE, APPLY, and ACCEPT in SMP/E Commands. And, perhaps worse, Packaging Rules tells a lot about tapes, but nothing (IIRC) about network delivery nor about CD/DVD. Are you planning to use GIMZIP (that's in Reference)? What delivery medium, network or physical (both?) And, AFAIK, IBM provides nothing for ISVs to support RECEIVE ORDER. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE MCS construction question re aliases
On Thu, 28 May 2015 13:52:56 -0700, Charles Mills wrote: >Geez. See the first paragraph in my OP. > >Yeah, a lot of tape in there. When IBM was asking here about software delivery >not on tape I should have said "will you update the SMPE manuals also?" > Me, too. >Yes, we use GIMZIP. And GIMSMP. And pax. All we are supporting currently for >delivery is FTP from our server. We support FTP straight to the customer's >mainframe, because a customer told me "if I have to use a PC to install it, >it's not a real mainframe program." Okay, whatever. > Must the customer do BINARY; MGET to get all the piece parts (which sounds like few in your case)? If you can support "FTP straight" it's hardly any extra effort for you to support RECEIVE FROMNETWORK (but it burdens the customer with crafting CLIENT and SERVER data sets). We don't support FTP straight; partly security; partly a Corporate Standard requiring everything, product or service, to be in a .zip. I suppose the customer could unzip it with "jar", but rather I pax everything into a superarchive and zip that. >SMPE is in place. The only thing new was a load module with an alias that is >critical to its operation. If it's a "real mainframe program", it's delivered in individual ++MOD elements and linked at customer's site with ++JCLIN. That permits far more chaotic maintenance than ++PROGRAM. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE MCS construction question re aliases
... by real mainframe programmers, without benefit of documentation LOL. We tell them BINARY GET fmid.pax (REPLACE Everything is in that one piece and then we have them do pax -rv -f /blahblah/fmid.pax and then ogetx /blahblah/fmid/INSTJCL MY.PDS and they are off and running. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 28, 2015 2:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMPE MCS construction question re aliases On Thu, 28 May 2015 13:52:56 -0700, Charles Mills wrote: >Geez. See the first paragraph in my OP. > >Yeah, a lot of tape in there. When IBM was asking here about software delivery >not on tape I should have said "will you update the SMPE manuals also?" > Me, too. >Yes, we use GIMZIP. And GIMSMP. And pax. All we are supporting currently for >delivery is FTP from our server. We support FTP straight to the customer's >mainframe, because a customer told me "if I have to use a PC to install it, >it's not a real mainframe program." Okay, whatever. > Must the customer do BINARY; MGET to get all the piece parts (which sounds like few in your case)? If you can support "FTP straight" it's hardly any extra effort for you to support RECEIVE FROMNETWORK (but it burdens the customer with crafting CLIENT and SERVER data sets). We don't support FTP straight; partly security; partly a Corporate Standard requiring everything, product or service, to be in a .zip. I suppose the customer could unzip it with "jar", but rather I pax everything into a superarchive and zip that. >SMPE is in place. The only thing new was a load module with an alias that is >critical to its operation. If it's a "real mainframe program", it's delivered in individual ++MOD elements and linked at customer's site with ++JCLIN. That permits far more chaotic maintenance than ++PROGRAM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
On Thu, 28 May 2015 07:56:03 -0700, Charles Mills wrote: . . . > >I would assume C++ gets the stack at startup, not on the first external >call. Interesting thought. I have this very vague recollection, that when RPTSTG is ON, things are set up so that the stack is always too small (or gives that appearance), so that routine gets called every time. However, it has been a very long time since I was near anything like that, things may have changed, and perhaps I had the story wrong in the first place. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE MCS construction question re aliases
On Thu, 28 May 2015 14:23:05 -0700, Charles Mills wrote: >... by real mainframe programmers, without benefit of documentation LOL. > >We tell them > >BINARY >GET fmid.pax (REPLACE > Much the same here, except that by our Corporate Standard they must first un-zip it or un-jar it. Do any have restrictions on FTP? Because of our Corporate Standard, we recommend BINARY PUT fmid.pax ... from the waystation. There's no other way they could get through the Javascript to our server. (BTW, does anyone have "curl https://..."; working? I tried it yesterday and it couldn't find its certificate bundle with both hands. Works fine from Linux.) >Everything is in that one piece and then we have them do > >pax -rv -f /blahblah/fmid.pax > >and then > >ogetx /blahblah/fmid/INSTJCL MY.PDS > (You could bypass that step with "UDLIST /blahblah/fmid/INSTJCL", but we don't tell them that because real mainframe products don't use UDLIST.) >and they are off and running. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE MCS construction question re aliases
Have not run into any restrictions on FTP but this process is fairly new. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 28, 2015 2:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMPE MCS construction question re aliases On Thu, 28 May 2015 14:23:05 -0700, Charles Mills wrote: >... by real mainframe programmers, without benefit of documentation LOL. > >We tell them > >BINARY >GET fmid.pax (REPLACE > Much the same here, except that by our Corporate Standard they must first un-zip it or un-jar it. Do any have restrictions on FTP? Because of our Corporate Standard, we recommend BINARY PUT fmid.pax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
Well that would make sense ... In my case the program does not ABEND if some function -- also relative branch -- is called first rather than ISAUTH, which makes no sense at all. I have not tried every possibility, for example - what if I called some other function rather than ISAUTH at the early point in the C++ logic where I call (or comment out the call to) ISAUTH? - what if I called ISAUTH later in the program, after other functions had been called successfully? Seems to me if I were writing a "how much heap actually got used" tool I would just initialize the whole heap to X'DEADBEEF' or X'8BADF00D' or something and then at EOJ search from the top for the end of the initial value. But what do I know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andy Wood Sent: Thursday, May 28, 2015 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) On Thu, 28 May 2015 07:56:03 -0700, Charles Mills wrote: . . . > >I would assume C++ gets the stack at startup, not on the first external >call. Interesting thought. I have this very vague recollection, that when RPTSTG is ON, things are set up so that the stack is always too small (or gives that appearance), so that routine gets called every time. However, it has been a very long time since I was near anything like that, things may have changed, and perhaps I had the story wrong in the first place. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious U4088-63 from RPTSTG(ON)
Charles (and others) Has LE obsconded with SDSF's *RESERVED* use of ISA prefix? Ed On May 28, 2015, at 4:58 PM, Charles Mills wrote: Well that would make sense ... In my case the program does not ABEND if some function -- also relative branch -- is called first rather than ISAUTH, which makes no sense at all. I have not tried every possibility, for example - what if I called some other function rather than ISAUTH at the early point in the C++ logic where I call (or comment out the call to) ISAUTH? - what if I called ISAUTH later in the program, after other functions had been called successfully? Seems to me if I were writing a "how much heap actually got used" tool I would just initialize the whole heap to X'DEADBEEF' or X'8BADF00D' or something and then at EOJ search from the top for the end of the initial value. But what do I know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Andy Wood Sent: Thursday, May 28, 2015 2:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) On Thu, 28 May 2015 07:56:03 -0700, Charles Mills wrote: . . . I would assume C++ gets the stack at startup, not on the first external call. Interesting thought. I have this very vague recollection, that when RPTSTG is ON, things are set up so that the stack is always too small (or gives that appearance), so that routine gets called every time. However, it has been a very long time since I was near anything like that, things may have changed, and perhaps I had the story wrong in the first place. -- 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: Mysterious U4088-63 from RPTSTG(ON)
Entry point names are fair game, right? Only program module names have reserved prefixes -- at least that is what SMPE (which I was just reading) seems to imply. In any event, ISAUTH works in every circumstance I have tried except (IEABRCX && RPTSTG(ON)). But who knows. I certainly do not have all the answers. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Thursday, May 28, 2015 4:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Mysterious U4088-63 from RPTSTG(ON) Charles (and others) Has LE obsconded with SDSF's *RESERVED* use of ISA prefix? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: (OT) Re: Question on 3270 Devices
https://www.youtube.com/watch?v=1DOEDT6XGBk One of many Sy / si routines on the Jack Benny Show. https://www.youtube.com/watch?v=JRlmb0xAtBs Mel Blanc biography show. On Thu, May 28, 2015 at 2:15 PM, Ward, Mike S wrote: > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Friday, May 22, 2015 10:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (OT) Re: Question on 3270 Devices > > On Fri, 22 May 2015 09:56:13 -0500, John McKown wrote: >> >>My sister opened a computer store in Hawaii. She sells C shells down by >>the seashore. >> > I miss Mel Blanc. > > Suffering succotash. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > == > This email, and any files transmitted with it, is confidential and intended > solely for the use of the individual or entity to which it is addressed. If > you have received this email in error, please notify the system manager. This > message contains confidential information and is intended only for the > individual named. If you are not the named addressee, you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this message by mistake and delete > this e-mail from your system. If you are not the intended recipient, you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
Re: Mysterious U4088-63 from RPTSTG(ON)
SDSF I believe is ISF Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Ed Gould > Sent: Thursday, May 28, 2015 4:39 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Mysterious U4088-63 from RPTSTG(ON) > > Charles (and others) > > Has LE obsconded with SDSF's *RESERVED* use of ISA prefix? > > Ed > > On May 28, 2015, at 4:58 PM, Charles Mills wrote: > > > Well that would make sense ... > > > > In my case the program does not ABEND if some function -- also > > relative branch -- is called first rather than ISAUTH, which makes no > > sense at all. > > > > I have not tried every possibility, for example > > > > - what if I called some other function rather than ISAUTH at the early > > point in the C++ logic where I call (or comment out the call > > to) ISAUTH? > > - what if I called ISAUTH later in the program, after other functions > > had been called successfully? > > > > Seems to me if I were writing a "how much heap actually got used" > > tool I would just initialize the whole heap to X'DEADBEEF' or > > X'8BADF00D' or something and then at EOJ search from the top for the > > end of the initial value. But what do I know. > > > > Charles > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of Andy Wood > > Sent: Thursday, May 28, 2015 2:33 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Mysterious U4088-63 from RPTSTG(ON) > > > > On Thu, 28 May 2015 07:56:03 -0700, Charles Mills > > wrote: > > > > . . . > >> > >> I would assume C++ gets the stack at startup, not on the first > >> external call. Interesting thought. > > > > I have this very vague recollection, that when RPTSTG is ON, things > > are set up so that the stack is always too small (or gives that > > appearance), so that routine gets called every time. > > > > However, it has been a very long time since I was near anything like > > that, things may have changed, and perhaps I had the story wrong in > > the first place. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
I'm sure that GDPS can do more than what we use it for. We mirror and recover parallel sysplexes as well between data centers. Even if I had only monoplexes mission critical to my business, I would still use DASD mirroring (XRC or whatever) and recover at a 'cool' site via GDPS, which handles DASD and CECs alike. In my view, what's truly crucial to a business is data. I need to IPL a system to resume business with data intact. If a few hours elapse, so be it. Compare that with the ancient goal (wish) of restoring data from tape. Hopeless. The thought of running a parallel sysplex across data centers 100+ KM apart gives me the freaking heebie-jeebies. Even if my communication (DWDM) were absolutely 100% reliable, where would my data actually live? Volume ABC123 lives at one data center or the other. If the owning data center fails, my sysplex is toast. If I mirror ABC123, I can only update one copy or the other. I can't update both or I'll screw the 'other' guy. Maybe there are technical answers that I don't understand. I stand to be educated. . . . 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 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Thursday, May 28, 2015 11:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LPAR MOBILITY But GDPS is not just a Disaster Recovery solution. It can "live" swap from data center to data center, within data centers. Are you saying that you are just a base sysplex using GDPS? Rob Schramm On Thu, May 28, 2015 at 1:55 PM J O Skip Robinson wrote: > GDPS has about as much to do with 'parallel sysplex' as TSO has to do > with 'time sharing'. For us, GDPS automates disaster recovery. Before > GDPS, we had to do a lot of manual procedures that GDPS performs > without the need for fingers on a keyboard. Included in our DR > environment is one monoplex LPAR that runs TPX. This LPAR has no need > for sysplex resources but has to run in DR, which we view as business > resumption after a catastrophic data center failure. RTO is important, > but a few hours is far preferable to the alternative abyss. > > . > . > . > 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 > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Rob Schramm > Sent: Thursday, May 28, 2015 6:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: LPAR MOBILITY > > Interesting, never thought someone would consider GDPS on anything but > parallel sysplex. What would be the point? I could buy a Ferrari and > remove the wheels.. But it wouldn't be much fun...and would be a very > expensive chair. > > Seems more like the person is looking for parallel sysplex / > sysplex-in-a-box plus automation. > > Rob Schramm > > On Thu, May 28, 2015, 9:01 AM IBMZOS < > 00af65f10fb1-dmarc-requ...@listserv.ua.edu> wrote: > > > Thank's Jan for detailed reply. Yes for the impact of LPM. We use it > > for planned outages, and work fine. I cannot do with my sysplex, > > because your reply is applicable to a Parallel sysplex, which is a > > HIGH > step forward. > > From all the reply, i understand that Parallel Syplex is really the > > solution. Just curious if LPM or Live Guest Migration is announced > > one day on Z/OS, for planned outages... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LPAR MOBILITY
On 5/28/2015 9:20 PM, J O Skip Robinson wrote: I'm sure that GDPS can do more than what we use it for. We mirror and recover parallel sysplexes as well between data centers. Even if I had only monoplexes mission critical to my business, I would still use DASD mirroring (XRC or whatever) and recover at a 'cool' site via GDPS, which handles DASD and CECs alike. In my view, what's truly crucial to a business is data. I need to IPL a system to resume business with data intact. If a few hours elapse, so be it. Compare that with the ancient goal (wish) of restoring data from tape. Hopeless. The thought of running a parallel sysplex across data centers 100+ KM apart gives me the freaking heebie-jeebies. Even if my communication (DWDM) were absolutely 100% reliable, where would my data actually live? Volume ABC123 lives at one data center or the other. If the owning data center fails, my sysplex is toast. If I mirror ABC123, I can only update one copy or the other. I can't update both or I'll screw the 'other' guy. Maybe there are technical answers that I don't understand. I stand to be educated. . . . 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 Skip, IBM just announced multi-target PPRC, so you can do multiple copies to different places. GDPS is working to add the support for it. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
New Line vs. Line Feed
Hi allI am dealing with some C package on classic z/OS (PDS/E, no USS). When C reads text files it inserts 0x15 in the end of the record (it goes that far as to drop the trailing blanks and substitute them with one 0x15 for fixed length records, but I think that there is an option to override that). 0x15 is defined as New Line, but there is a separate character, 0x25 that is defined as Line Feed. Does anybody know why do we need two characters that seem to do the same thing (besides the evil desire to confuse the poor user :) Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Line vs. Line Feed
It's actually much worse. There are three: Ebcdic: CR = x0D NL = x15 LF = x25 Originally, CR only moved the print back to the first position of the same line. LF only moved the print down one line without moving sideways. NL moved both down and to the first position of the line. When it was designed, they were using teletype machines and simple printers. No CRTs. Historically: 1930's had the Teletype standard: International Telegraph Alphabet No. 2 (ITA2); which had both a CR and a LF and required both at the end of a line. 1950's IBM introduces BCD and adds NL 1960's IBM introduces EBCDIC and continued using the 3 values. 1960's ATT pushes for a replacement of ITA2 which the ATA published as ASCII in 1963. (One of their requirements was 7 bit so EBCDIC was ruled out.) In the ASCII world, CR and LF were the standard until the mid-1960's when the Multics developers decided that using two characters was stupid and they started using just LF. Unix and follow-on OSs carried on the same tradition. Today, it's a mess. Windows wants CRLF. Internet RFCs normally use CRLF. Mac and Linux use just LF. Interesting, Windows Notepad requires CRLF, but Windows Wordpad will read and display a LF only file correctly and even change the file to CRLF when saved. Tony Thigpen Ze'ev Atlas wrote on 05/28/2015 11:29 PM: Hi allI am dealing with some C package on classic z/OS (PDS/E, no USS). When C reads text files it inserts 0x15 in the end of the record (it goes that far as to drop the trailing blanks and substitute them with one 0x15 for fixed length records, but I think that there is an option to override that). 0x15 is defined as New Line, but there is a separate character, 0x25 that is defined as Line Feed. Does anybody know why do we need two characters that seem to do the same thing (besides the evil desire to confuse the poor user :) Ze'ev Atlas -- 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: New Line vs. Line Feed
On Thu, May 28, 2015 at 10:29 PM, Ze'ev Atlas < 004b34e7c98a-dmarc-requ...@listserv.ua.edu> wrote: > Hi allI am dealing with some C package on classic z/OS (PDS/E, no USS). > When C reads text files it inserts 0x15 in the end of the record (it goes > that far as to drop the trailing blanks and substitute them with one 0x15 > for fixed length records, but I think that there is an option to override > that). 0x15 is defined as New Line, but there is a separate character, > 0x25 that is defined as Line Feed. Does anybody know why do we need two > characters that seem to do the same thing (besides the evil desire to > confuse the poor user :) Ze'ev Atlas > 0x15 is _NOT_ a Line Feed character. It is a New Line (NEL) character from the 3215 console days. In EBCDIC, 0x25 is the true Line Feed character. On the 3215, the NEL was a single byte which did a carriage return and line feed operation all in one. If you sent a 0x15 (LF) to a 3215, the platen (roller) would advance one line, but the print head would remain stationary. As a side note (as I have heard it), the reason that Windows uses CRLF as a line ending is because MS-DOS did the same. MS-DOS used CRLF because CPM-80 used CRLF. And, finally, CPM-80 used CRLF because the common printers at the time could not do a carriage return / line feed in a single operation. So, Gary Kindall (author of CPM-80) decided to end text files with CRLF so that he didn't need to complicate the printer driver to put a LF in when a CR was detected. This made good sense in the day that 64K RAM and a 1 Mhz 8080 was top of the line equipment for the hobbyist. -- My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Line vs. Line Feed
On Thu, 28 May 2015 23:34:53 -0500, John McKown wrote: > >0x15 is _NOT_ a Line Feed character. It is a New Line (NEL) character from >the 3215 console days. In EBCDIC, 0x25 is the true Line Feed character. On >the 3215, the NEL > >was a single byte which did a carriage return and line feed operation all >in one. If you sent a 0x15 (LF) to a 3215, the platen (roller) would >advance one line, but the print head would remain stationary. > >As a side note (as I have heard it), the reason that Windows uses CRLF as a >line ending is because MS-DOS did the same. MS-DOS used CRLF because CPM-80 >used CRLF. And, finally, CPM-80 used CRLF because the common printers at >the time could not do a carriage return / line feed in a single operation. >So, Gary Kindall (author of CPM-80) decided to end text files with CRLF so >that he didn't need to complicate the printer driver to put a LF in when a >CR was detected. This made good sense in the day that 64K RAM and a 1 Mhz >8080 was top of the line equipment for the hobbyist. > The Teletype 33, running at 10 CPS, could do a CR in less than 0.2 seconds; a LF in less than 0.1 second, so it made sense to use so the combined operation completed before the next printable character was issued. Taking its cue from the 3215, VM CP (CP/67?) used NL as a command separator. When the first C compilers, from ISVs, not IBM, and on VM, not MVS appeared, they used 0x15 -- UNIX was not a concern. Then OMVS used 0x15 for compatibility with those compilers. Using a device-specific hardware command to separate records in a general file makes as little sense as Assembler H's use of machine carriage control. A device-neutral convention might have beem Record Separator, ASCII 0x1e. CMS Pipelines's A2E/E2A map: ASCII EBCDIC NEL 0x85 <--> NL 0x15 LF 0x0a <--> LF 0x25 ... as do Linux iconv commands and subroutines, and even OMVS's "dd" command. This results in painful incompatibilities. The standouts are OMVS iconv and other utilities. IBM clearly violates a standard. Footnotes on various reference manual pages do not excuse such a violation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Line vs. Line Feed
t...@vse2pdf.com (Tony Thigpen) writes: > It's actually much worse. There are three: > > Ebcdic: > CR = x0D > NL = x15 > LF = x25 > > Originally, CR only moved the print back to the first position of the > same line. LF only moved the print down one line without moving > sideways. NL moved both down and to the first position of the line. > > When it was designed, they were using teletype machines and simple > printers. No CRTs. > > Historically: > > 1930's had the Teletype standard: International Telegraph Alphabet > No. 2 (ITA2); which had both a CR and a LF and required both at the > end of a line. > > 1950's IBM introduces BCD and adds NL > 1960's IBM introduces EBCDIC and continued using the 3 values. > > 1960's ATT pushes for a replacement of ITA2 which the ATA published as > ASCII in 1963. (One of their requirements was 7 bit so EBCDIC was > ruled out.) > > In the ASCII world, CR and LF were the standard until the mid-1960's > when the Multics developers decided that using two characters was > stupid and they started using just LF. Unix and follow-on OSs carried > on the same tradition. > > Today, it's a mess. Windows wants CRLF. Internet RFCs normally use > CRLF. Mac and Linux use just LF. > > Interesting, Windows Notepad requires CRLF, but Windows Wordpad will > read and display a LF only file correctly and even change the file to > CRLF when saved. IBM did much of the standardization for ASCII and 360 originally was suppose to be an ASCII machine ... unfortunately the 360 ASCII unit record gear wasn't ready ... and the decision was made to go (temporarily) with the "old" BCD unit record gear (but there was some unfortunate side-effects of that decision). EBCDIC and the P-Bit, The Biggest Computer Goof Ever http://www.bobbemer.com/P-BIT.HTM The culprit was T. Vincent Learson. The only thing for his defense is that he had no idea of what he had done. It was when he was an IBM Vice President, prior to tenure as Chairman of the Board, those lofty positions where you believe that, if you order it done, it actually will be done. I've mentioned this fiasco elsewhere. ... snip ... by the father of ASCII http://www.bobbemer.com/FATHEROF.HTM his history index http://www.bobbemer.com/HISTORY.HTM -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
