Re: Deleting a dataset that GRS has enqueued.
On Jan 27, 2016, at 10:43 PM, TonyB wrote: Years ago I recall a young sys prog asking for advice on this forum. She qualified her request by stating "but please, no system programmer tricks." I don't call her issue but clearly a risk averse solution was desired. Sent from BlueMail That is fine but in *THIS* entry the author asked a question with no such pre qualifications. My answer would have been different if the author had said so. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
Skip: I somewhat agree with your entry, however until IBM comes up with an legit way of accomplishing the task you do what must be done to get the job done. Ed On Jan 27, 2016, at 10:26 PM, Skip Robinson wrote: I have no answer for SMS involvement, but I'm uncomfortable with geek-heavy proposals that involve unnatural acts performed under the aura of special knowledge and privilege. Zapping production volumes? Puh-lease. Even the GRS tweak has a risk. RNL can be modified dynamically, but once that's done, the next system to IPL must come up with an RNL that exactly matches the running GRSplex or it will wait state. This requirement complicates the task and, depending on the end state, may leave the DSN in question with no cross system protection at all. Surely that's not an intended result. As a professional group, we sysprogs need to edge away from doing things just because we know how and have the power. The king will behead a loose-cannon magician in favor of a semi-droll jester. (Been devouring Gallivant.) . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert A. Rosenberg Sent: Wednesday, January 27, 2016 04:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued. At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a dataset that GRS has enqueued.: On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote: Try disabling the VVDS on the volume amaspzap the dataset to change the name. delete the dataset with iehprogm enable the vvds on the volume ITYM disable the VTOC index. I wouldn't want to do it that way. I think that what Kees suggested is a better solution. Tell GRS not to propagate the ENQ. -- Tom Marchant If you are going to go the amaspzap route but do not want to disable/enable the vvds, there is a simpler way of cleaning up the vvds. There is a "VVDS is Dirty" bit in the VTOC Format 4 record. Use Superzap to display its current state (there is a special Dataset Name that accesses the needed Format 4 record and gives you full access to the VTOC). Now do the Dataset rename, run IEHPROGM, and zap the byte to flip the bit on. The operating system will see the bit set and rebuild the VVDS for you. Note that the dirty bit might be for a dirty VTOC but I think that the VVDS will will be rebuilt in this case. Also the Dataset's Format 1 record can be ZAPPED which will delete it for you and the VTOC will be updated to compensate due to the dirty flag. -- 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: Deleting a dataset that GRS has enqueued.
Years ago I recall a young sys prog asking for advice on this forum. She qualified her request by stating "but please, no system programmer tricks." I don't call her issue but clearly a risk averse solution was desired. Sent from BlueMail On Jan 27, 2016, 10:26 PM, at 10:26 PM, Skip Robinson wrote: >I have no answer for SMS involvement, but I'm uncomfortable with >geek-heavy >proposals that involve unnatural acts performed under the aura of >special >knowledge and privilege. Zapping production volumes? Puh-lease. Even >the GRS >tweak has a risk. RNL can be modified dynamically, but once that's >done, the >next system to IPL must come up with an RNL that exactly matches the >running >GRSplex or it will wait state. This requirement complicates the task >and, >depending on the end state, may leave the DSN in question with no cross >system protection at all. Surely that's not an intended result. > >As a professional group, we sysprogs need to edge away from doing >things >just because we know how and have the power. The king will behead a >loose-cannon magician in favor of a semi-droll jester. (Been devouring >Gallivant.) > >. >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >jo.skip.robin...@att.net > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Robert A. Rosenberg >> Sent: Wednesday, January 27, 2016 04:59 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued. >> >> At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a >> dataset that GRS has enqueued.: >> >> >On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote: >> > >> >>Try disabling the VVDS on the volume >> >>amaspzap the dataset to change the name. >> >>delete the dataset with iehprogm >> >>enable the vvds on the volume >> > >> >ITYM disable the VTOC index. I wouldn't want to do it that way. >> >I think that what Kees suggested is a better solution. Tell GRS not >to >> >propagate the ENQ. >> > >> >-- >> >Tom Marchant >> >> If you are going to go the amaspzap route but do not want to >disable/enable >> the vvds, there is a simpler way of cleaning up the vvds. There is a >"VVDS >is >> Dirty" bit in the VTOC Format 4 record. Use Superzap to display its >current >> state (there is a special Dataset Name that accesses the needed >Format 4 >> record and gives you full access to the VTOC). Now do the Dataset >rename, >run >> IEHPROGM, and zap the byte to flip the bit on. The operating system >will >see >> the bit set and rebuild the VVDS for you. Note that the dirty bit >might be >for a >> dirty VTOC but I think that the VVDS will will be rebuilt in this >case. >Also the >> Dataset's Format 1 record can be ZAPPED which will delete it for you >and >the >> VTOC will be updated to compensate due to the dirty flag. > >-- >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: Deleting a dataset that GRS has enqueued.
I have no answer for SMS involvement, but I'm uncomfortable with geek-heavy proposals that involve unnatural acts performed under the aura of special knowledge and privilege. Zapping production volumes? Puh-lease. Even the GRS tweak has a risk. RNL can be modified dynamically, but once that's done, the next system to IPL must come up with an RNL that exactly matches the running GRSplex or it will wait state. This requirement complicates the task and, depending on the end state, may leave the DSN in question with no cross system protection at all. Surely that's not an intended result. As a professional group, we sysprogs need to edge away from doing things just because we know how and have the power. The king will behead a loose-cannon magician in favor of a semi-droll jester. (Been devouring Gallivant.) . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Robert A. Rosenberg > Sent: Wednesday, January 27, 2016 04:59 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued. > > At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a > dataset that GRS has enqueued.: > > >On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote: > > > >>Try disabling the VVDS on the volume > >>amaspzap the dataset to change the name. > >>delete the dataset with iehprogm > >>enable the vvds on the volume > > > >ITYM disable the VTOC index. I wouldn't want to do it that way. > >I think that what Kees suggested is a better solution. Tell GRS not to > >propagate the ENQ. > > > >-- > >Tom Marchant > > If you are going to go the amaspzap route but do not want to disable/enable > the vvds, there is a simpler way of cleaning up the vvds. There is a "VVDS is > Dirty" bit in the VTOC Format 4 record. Use Superzap to display its current > state (there is a special Dataset Name that accesses the needed Format 4 > record and gives you full access to the VTOC). Now do the Dataset rename, run > IEHPROGM, and zap the byte to flip the bit on. The operating system will see > the bit set and rebuild the VVDS for you. Note that the dirty bit might be for a > dirty VTOC but I think that the VVDS will will be rebuilt in this case. Also the > Dataset's Format 1 record can be ZAPPED which will delete it for you and the > VTOC will be updated to compensate due to the dirty flag. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
On Wed, 27 Jan 2016 18:36:02 -0500, Don Poitras wrote: >In article <2525643717796095.wa.m42tomibmmainyahoo@listserv.ua.edu> you >wrote: > >> There is another impediment, IMO. That is that XPLINK-64 cannot easily >> coexist with either XPLINK-31 or with standard linkage. So, if you have >> an application that consists of several modules, they have to be either >> all XPLINK-64 or none of them. > >Your third sentence is refuted by your second. Yes, it's not easy, but >it can be done. IBM could make this easier if they would do the work to >provide 64-bit DLLs for more of their products. I should have written, "XPLINK-64 cannot coexist with XPLINK-31 or with non-XPLINK LE programs in the same LE enclave." The issue is that the LE control blocks are not compatible between these three LE environments. IMO it is a reason for LE to provide support for 64-bit code using standard (F4SA, F5SA, etc.) save areas. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
On Wed, 27 Jan 2016 19:59:13 -0500, Robert A. Rosenberg wrote: >At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a >dataset that GRS has enqueued.: > >>On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote: >> >>>Try disabling the VVDS on the volume >> >>ITYM disable the VTOC index. > >If you are going to go the amaspzap route but do not want to >disable/enable the vvds, What does "Disable the VVDS" mean? >there is a simpler way of cleaning up the >vvds. There is a "VVDS is Dirty" bit in the VTOC Format 4 record. FSVO "simpler". and ITYM VTOCIX >Use >Superzap to display its current state (there is a special Dataset >Name that accesses the needed Format 4 record and gives you full >access to the VTOC). Now do the Dataset rename, run IEHPROGM, and zap >the byte to flip the bit on. Yeah, that's simpler than BUILDIX. Or not. >The operating system will see the bit >set and rebuild the VVDS for you. Note that the dirty bit might be >for a dirty VTOC but I think that the VVDS will will be rebuilt in >this case. Again, VTOC Index, not VVDS. The information in the VVDS cannot be rebuilt automatically in the case of a failure. The VTOC Index is optional and can be rebuilt from the VTOC. -- Tom Marhant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/VM "load from dvd or server"
>>> On 1/27/2016 at 05:30 PM, "R.S." wrote: > z/VM Installation Manual says I should first launch Integrated 3270 > console before Load. > Otherwise I get wait state. > > Q: can I use other console instead, for example ICC console? As long as it looks like a 3270-type console, you should be able to get it to work. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MODULE AMODE
Hi Frank, we have noticed the same problem and I'm currently working on a fix. No ETA. Raise a PMR if you want to track to resolution. Cheers Hank, FA Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
At 10:32 -0600 on 01/27/2016, Tom Marchant wrote about Re: Deleting a dataset that GRS has enqueued.: On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote: Try disabling the VVDS on the volume amaspzap the dataset to change the name. delete the dataset with iehprogm enable the vvds on the volume ITYM disable the VTOC index. I wouldn't want to do it that way. I think that what Kees suggested is a better solution. Tell GRS not to propagate the ENQ. -- Tom Marchant If you are going to go the amaspzap route but do not want to disable/enable the vvds, there is a simpler way of cleaning up the vvds. There is a "VVDS is Dirty" bit in the VTOC Format 4 record. Use Superzap to display its current state (there is a special Dataset Name that accesses the needed Format 4 record and gives you full access to the VTOC). Now do the Dataset rename, run IEHPROGM, and zap the byte to flip the bit on. The operating system will see the bit set and rebuild the VVDS for you. Note that the dirty bit might be for a dirty VTOC but I think that the VVDS will will be rebuilt in this case. Also the Dataset's Format 1 record can be ZAPPED which will delete it for you and the VTOC will be updated to compensate due to the dirty flag. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
On Wed, 27 Jan 2016 17:33:47 -0600, Walt Farrell wrote: > >Will GRS allow you to change the RNL specifications for a resource that is >already ENQ'd? Or, perhaps a more accurate question: will the change take >effect before the resource becomes DEQ'd everywhere? > I thought from discussions here a few years ago that IBM has provided a facility that supports renaming of an ENQUEUEd DSN, in the VTOC, after requesting confirmation from the operators' console that that DSN on that volume is *not* the one to which the ENQ pertains. Don't know how it interacts with catalog, SMS, indexed VTOCs, automated operations, ... This amounts to institutionalizing the technique of zapping the VTOC while placing the integrity burden on a human being. --- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MODULE AMODE
The following data is from IBM Fault Analyzer for two different programs. Program CICSDD2E is a CICS program and program EDFY04 is a batch program. On the one for CICSDD2E, for Type=MODULE, it shows AMODE=24. But this program was compiled and linked as AMODE 31 (and in fact there is no longer an AMODE option for Enterprise COBOL). So I am wondering where this AMODE 24 came from, and if it means I am doing something not quite right. Point Of Failure LINKEDIT Map: Address Offset Length Type Date Time RMODE AMODE Language Name 13ACDC30017C00 MODULE 2015/06/17 09:15:28 24 CICSDD2E 13ACDC30016164 CSECT 2015/06/17 09:15:24 ANY MIN COBOL CICSDD2E 13ACDC3000 EP CICSDD2E 13AE3D9816168 28 CSECT 2011/06/14 ANY 31ASM DFHELII 13AE3DC016190 E10 CSECT 2011/06/14 ANY 31ASM DFHMQSTB 13AE4BD016FA0 18 CSECT 2011/03/15 ANY MIN ASM CEESG005 13AE4BE816FB8 30 CSECT 2011/06/14 ANY MIN ASM DFHDLIAI 13AE4C1816FE8 28 CSECT 2011/03/18 ANY MIN ASM CEEBETBL 13AE4C4017010 B0 CSECT 2011/03/18 ANY MIN ASM CEESTART 13AE4CF0170C0 580 CSECT 2011/03/15 ANY 31ASM IGZCBSO 13AE527017640 B8 CSECT 2011/03/18 ANY MIN ASM CEEARLU 13AE5328176F8 2A0 CSECT 2011/03/18 ANY 31ASM CEEBPIRA 13AE55C817998 E2 CSECT 2011/03/18 ANY MIN ASM CEECPYRT 13AE56B017A80 70 CSECT 2011/03/18 ANY MIN ASM CEEBPUBT 13AE572017AF0 A4 CSECT 2011/03/18 ANY MIN ASM CEEBTRM 13AE57C817B98 5C CSECT 2011/03/18 ANY MIN ASM CEEBLLST 13AE582817BF88 CSECT 2011/03/18 ANY MIN ASM CEEBINT Point Of Failure LINKEDIT Map: Address Offset Length Type Date Time RMODE AMODE Language Name 10A120000 B000 MODULE 2015/03/29 12:49:18 31 EDFY04 10A120000 9F1C CSECT 2015/03/29 12:49:16 ANY MIN COBOL EDFY04 10A1200000 EP EDFY04 10A1BF20 9F20 18 CSECT 2011/03/15 ANY MIN ASM CEESG005 10A1BF38 9F38 28 CSECT 2011/03/18 ANY MIN ASM CEEBETBL 10A1BF60 9F60 B0 CSECT 2011/03/18 ANY MIN ASM CEESTART 10A1C010 A010 580 CSECT 2011/03/15 ANY 31ASM IGZCBSO 10A1C590 A590 B8 CSECT 2011/03/18 ANY MIN ASM CEEARLU 10A1C648 A648 2A0 CSECT 2011/03/18 ANY 31ASM CEEBPIRA 10A1C8E8 A8E8 E2 CSECT 2011/03/18 ANY MIN ASM CEECPYRT 10A1C9D0 A9D0 70 CSECT 2011/03/18 ANY MIN ASM CEEBPUBT 10A1CA40 AA40 A4 CSECT 2011/03/18 ANY MIN ASM CEEBTRM 10A1CAE8 AAE8 5C CSECT 2011/03/18 ANY MIN ASM CEEBLLST 10A1CB48 AB488 CSECT 2011/03/18 ANY MIN ASM CEEBINT Both programs show this output from the z/OS BINDER step: SAVE MODULE ATTRIBUTES: AC 000 AMODE31 It doesn't appear to be causing any issues, but it is perplexing me. Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL v5
On Wednesday, 27 January 2016 17:26:04 UTC, Barry Lichtenstein wrote: > It's not the JCL per-se. The combination of XOBJ object modules and the > Prelinker was a tactical solution to advancements in programs, originally > created for C programs. XOBJ object modules addressed several deficiencies > in OBJ object modules, such the ability to have long case-sensitive external > symbol names. > > While it does the intended job, the Prelinker has several drawbacks, such as > the inability to incrementally rebind a module so created (read "csect > replacement"). The prelinker does not handle GOFF object modules such as > produced by C/C++ with XPLINK and COBOL V5. GOFF object modules can define > characteristics of a program which cannot be represented in a load module. > > Note that the binder has been producing program objects for over 25 years. It > is difficult to make significant enhancements to OBJ object module and load > module formats. Some important things have been added such as AMODE 64 and > quad-word alignment. > > barry_lichtenst...@us.ibm.com > Sorry, I was still being unclear. What I meant is that if you run JCL which uses a PDSE as output for executable programs, then you are using a PDSE. If you run JCL that uses a PDS, then you are using a PDS. Using a PDSE in the JCL to compile a PL/I program does not mean that PL/I can only produce code requiring Program Objects, which was that little side-track in the discussion. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
In article <2525643717796095.wa.m42tomibmmainyahoo@listserv.ua.edu> you wrote: > On Wed, 27 Jan 2016 16:31:17 -0500, Farley, Peter wrote: > >Some of us may have to be dragged kicking and screaming into > >that 64-bit future because of PDSE-fear, but it is coming nonetheless. > There is another impediment, IMO. That is that XPLINK-64 cannot easily > coexist with either XPLINK-31 or with standard linkage. So, if you have > an application that consists of several modules, they have to be either > all XPLINK-64 or none of them. > -- > Tom Marchant Your third sentence is refuted by your second. Yes, it's not easy, but it can be done. IBM could make this easier if they would do the work to provide 64-bit DLLs for more of their products. As more customers go to 64-bit, the presure for that will build. Another issue is IEEE float. Hex float can be used by XPLINK callers, but the HFP library is non- XPLINK, so ends up being much slower. If your code is in a high-level language, you can mostly get by by using FLOAT(IEEE), but if you have lots of assembler math routines (I wonder who would have those?), you're going to have to dig in a bit. I highly recommend the floating point chapters in John Erman's assembler book for teaching yourself the fine points of this stuff. The pop is probably good enough for the mathmeticians among us, but I needed a primer. You can download here: http://idcp.marist.edu/enterprisesystemseducation/Assembler%20Language%20Programming%20for%20IBM%20z%20System%20Servers.pdf -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
On Wed, 27 Jan 2016 19:18:26 +, Vernooij, CP (ITOPT1) - KLM wrote: > What is wrong with this solution, it is the easiest in my opinion: update > parmlib- set grs - delete. > >You can tell GRS to keep the ENQ for that DSNAME local in the GRSRNLxx parmlib >member. In that case the name must be available only >in the LPAR where you do the delete. > >Example: >RNLDEF RNL(EXCL) TYPE(SPECIFIC) >QNAME(SYSDSN) >RNAME(SYS1.DAE) Will GRS allow you to change the RNL specifications for a resource that is already ENQ'd? Or, perhaps a more accurate question: will the change take effect before the resource becomes DEQ'd everywhere? -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
On Wed, 27 Jan 2016 16:31:17 -0500, Farley, Peter wrote: >Some of us may have to be dragged kicking and screaming into >that 64-bit future because of PDSE-fear, but it is coming nonetheless. There is another impediment, IMO. That is that XPLINK-64 cannot easily coexist with either XPLINK-31 or with standard linkage. So, if you have an application that consists of several modules, they have to be either all XPLINK-64 or none of them. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/VM "load from dvd or server"
z/VM Installation Manual says I should first launch Integrated 3270 console before Load. Otherwise I get wait state. Q: can I use other console instead, for example ICC console? -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Future shock (Was: COBOL v5)
On Wed, 27 Jan 2016 10:59:52 -0800, Ed Jaffe wrote: > >If old-school OBJ modules now support quad-word alignment, why does >HLASM warn for NOGOFF with SECTALGN(16)? > >** ASMA216W Quad-word alignment in NOGOFF object text > Perhaps as an early warning to any programmer suspected of having aspirations to feed such a NOGOFF object to Linkage Editor? My SYSEXEC is a concatenation of PDS and UNIX directories. That's not supported. IBM has sternly told me that when I attempted to report a problem. Yet I prefer its shortcoming to the alternative of synching EXECs between PDS and UNIX. Our site shares PDSEs transplex to test systems. Not supported. Yet we prefer the recurrent ENQ lockouts to the chore of synching content among multiple PDSEs. Make lemonade. If I had a buggy whip, I'd complain that I can't use it to control my Tesla. If I had a Tesla. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
On Wed, 27 Jan 2016 13:40:38 -0600, Ed Gould wrote: > >Since COBOL does not and will not in the foreseeable future need >amode 64 I find the argument un helpful. > I think the argument was intended to be taken as a frinstance. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
I guess I have to disagree with that assessment as well. What is COBOL V5 but a pathway into the future for COBOL? With the new shared code generation back-end, getting to AMODE64 COBOL is a SMOP for Tom Ross and the COBOL team at IBM. Some of us may have to be dragged kicking and screaming into that 64-bit future because of PDSE-fear, but it is coming nonetheless. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Wednesday, January 27, 2016 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 Peter: I agree with you. BUT as we have heard many times IBM doesn't see a need for this and have relegated COBOL to the dust bin of history. We have had discussions on here about the need but until there is critical mass IBM will not consider this as a "need". Then IBM will probably come up with a half cocked idea like mandating PDSE's. Ed On Jan 27, 2016, at 2:00 PM, Farley, Peter x23353 wrote: > Sorry Ed, many shops and application programmers disagree strongly > with that opinion. AMODE64 for COBOL for us is a must-get-to for > large in-core tables and many other application needs, in the same > way and for many of the same reasons that 31-bit COBOL was a > necessity in the 24-bit COBOL era when the 8 or 10 Mib private > region size was the constraint. > > It isn't for large *programs* that AMODE64 is needed, but for large > *data*. For sure I'm not about to write or support program code > that occupies more than 2GiB of storage, but surely you can see the > extreme usefulness of multi-GiB of main-storage data accessed by a > program. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] On Behalf Of Ed Gould > Sent: Wednesday, January 27, 2016 2:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: COBOL v5 > > On Jan 27, 2016, at 11:25 AM, Barry Lichtenstein wrote: > > >> Note that the binder has been producing program objects for over 25 >> years. It is difficult to make significant enhancements to OBJ >> object module and load module formats. Some important things have >> been added such as AMODE 64 and quad-word alignment. >> >> barry_lichtenst...@us.ibm.com > > Since COBOL does not and will not in the foreseeable future need > amode 64 I find the argument un helpful. > > Ed -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 and FONTS; Moving from z/OS 1.13
On thinking about this some more, I'm not sure I can do this. My OMVS HLQ is in the NOT-shared Master catalogs for each LPAR. I know I can have SYS1 and PAGE successfully defined in multiple catalogs. But, not anything else. The catalog/VVDS relationship will be broke in the other Lpars. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, David Allen,Jr > Sent: Thursday, January 14, 2016 11:56 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: z/OS 2.1 and FONTS; Moving from z/OS 1.13 > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of Elardus Engelbrecht > > Sent: Wednesday, January 13, 2016 9:40 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: z/OS 2.1 and FONTS; Moving from z/OS 1.13 > > > > Gibney, David Allen,Jr wrote: > > > > > I have a small shop, 4 monoplex LPARs, no GRS. Very careful > > > sharing of a > > limited set of disks including the system resident (IPL) volume, a > > Mod-27. Up until now, I have made separate (R/O) copies of the ROOT > > and other system > > ZFS/HFS(s) for each LPARs. > > > This new Unix filesystem with FONTS is not small and I am > > > wondering if it > > is safe to have only one (R/O) copy of it (probably on the IPL > > volume), shared by two or more LPARs? > > > > That's possible (sharing of IPL volser) as long all those LPARS are on > > the same z/OS level. > > I have been sharing the traditional RESVOL since at least z/OS 1.7 > > > > > > My SMP/E points to an entirely separate target Mod 27 and set of > > > OMVS > > files. These are cloned after maintenance to alternating IPL and > > maintenance level OMVS files. > > > > What is your catalog setup? Do you have separate master catalogs and > > their own set of user catalogs? Or are you sharing your catalogs? > > > > Mostly LPAR specific catalog systems. My two sandboxes share several > USERCATS. > OMVS HLQ is in the unshared Master(s) Which could complicate things :) > > > > I believe it is safe to share a Read Only OMVS dataset, unless you > > have something to prevent sharing of such OMVS datasets, for example > > having a folder which is written to. > > I am figuring on mounting them R/O. > > > > > Of course, moving from z/OS v1.13 to 2.1 requires two different IPL > > volsers during rolling upgrades. > > All independent monoplexes, but yes new IPL volumes for the new 2.1 system. > No real co-existence, just need to insure viable fallback. Never been able to > justify the CPU resources for even basic Sysplex. And never really had the > need. We have multiple Lpars to isolate production from development from > sandbox work. > > Part of my concern is that I only have 16 M27 defined. (user to make do with > 12 M9 before our last DASD upgrade). I'm running short until I complete the > migrations > > > > > Groete / Greetings > > Elardus Engelbrecht > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13 BC????
Yeah. Same here. Think I searched on IBM Z13 SAPR and got the .pdf's directly. I posted the https url but guess it gets whacked by the gateway if you're not a search engine. Sorry for the confusion. In a message dated 1/27/2016 7:48:57 A.M. Central Standard Time, bill.wood...@gmail.com writes: Harv Emery's Seattle Presentation on z13/zBX The results gave directly downloadable PDFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
Peter: I agree with you. BUT as we have heard many times IBM doesn't see a need for this and have relegated COBOL to the dust bin of history. We have had discussions on here about the need but until there is critical mass IBM will not consider this as a "need". Then IBM will probably come up with a half cocked idea like mandating PDSE's. Ed On Jan 27, 2016, at 2:00 PM, Farley, Peter x23353 wrote: Sorry Ed, many shops and application programmers disagree strongly with that opinion. AMODE64 for COBOL for us is a must-get-to for large in-core tables and many other application needs, in the same way and for many of the same reasons that 31-bit COBOL was a necessity in the 24-bit COBOL era when the 8 or 10 Mib private region size was the constraint. It isn't for large *programs* that AMODE64 is needed, but for large *data*. For sure I'm not about to write or support program code that occupies more than 2GiB of storage, but surely you can see the extreme usefulness of multi-GiB of main-storage data accessed by a program. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Ed Gould Sent: Wednesday, January 27, 2016 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 On Jan 27, 2016, at 11:25 AM, Barry Lichtenstein wrote: Note that the binder has been producing program objects for over 25 years. It is difficult to make significant enhancements to OBJ object module and load module formats. Some important things have been added such as AMODE 64 and quad-word alignment. barry_lichtenst...@us.ibm.com Since COBOL does not and will not in the foreseeable future need amode 64 I find the argument un helpful. Ed -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: OMVS file changes for z/OS 1.13 -> z/OS 2.1
Thanks Marna, My Serverpac, OS212016, did contain the other levels of Java, just not the 7.0. Doesn't really matter to me, as the only Java I have is CA-MSM. I've tried for fire up zOSMF, but on a zAAP/zIIPless z9-L03 capped at 16 MSU, it doesn't run well. Correct on the PHP/Python. I wouldn't know the difference :) I also don't know Liberty Profile from WasOEM :) My main concern here was preparing my filesystem BPXPRM member. z/OS 1.13 added a fair number of ZFS containers. I became concerned when they disappeared in z/OS 2.1 and I didn't find referneces to this removal in the migration guide. I accept the they aren't part of z/OS. Since Serverpac came out, I don't useually look deeply at the Program Directories :( Anyway, thanks to all, I'm ok for now. Doing this only every two years keeps if entertaining. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Marna WALLE > Sent: Wednesday, January 27, 2016 6:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: OMVS file changes for z/OS 1.13 -> z/OS 2.1 > > Hi Dave, > Here's some information for you. > > Java 6, 7, 8 and other levels are not "gone". They are all still on the > ServerPac > Shopz checklist, but maybe you just didn't order them?The last I looked, > there were 10 (yes, ten) levels of Java that you could get with z/OS V2.1 and > z/OS V2.2 ServerPac. For z/OS V2.2, we recommend that you get Java 7.1 64- > bit so that you can use z/OSMF on z/OS V2.2. If you are missing a level of > Java you need, please get it via a Product ServerPac. > > For the DDDEFs you mentioned, they aren't part of the z/OS product itself, so > they won't be mentioned in the z/OS Migration book. They should be > mentioned in their own products' publications. I did find that in the z/OSMF > V2.1 program directory that: > > File systems that are deleted from WebSphere Application Server OEM > Edition for z/OS V7.0: BBN.SBBN7ZFS or BBN.SBBN7HFS. > > SBBNCON1 looks to also be associated with the WAS OEM Edition (which was > replaced with WAS Liberty Profile), so I think that's what's happened to that > DDDEF too.Remember with WAS Liberty Profile, there were a lot of > changes, so I'd expect that several DDDEFs were removed, from the OEM > Edition. > > IBM Ported Tools never had Python, but I suspect it was PHP. Here's the > things that are no longer offered in IBM Ported Tools V1.3: bzip2, cURL, > Perl, > sudo, and PHP. Here's the things that still exist in IBM Ported Tools V1.3: > OpenSSH, Xvfb, IBM HTTP Server Powered by Apache at 8.5.5 (aka Apache > 2.2). > > I hope this helps. > -Marna WALLE > IBM Poughkeepsie > > -- > 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: COBOL v5
Sorry Ed, many shops and application programmers disagree strongly with that opinion. AMODE64 for COBOL for us is a must-get-to for large in-core tables and many other application needs, in the same way and for many of the same reasons that 31-bit COBOL was a necessity in the 24-bit COBOL era when the 8 or 10 Mib private region size was the constraint. It isn't for large *programs* that AMODE64 is needed, but for large *data*. For sure I'm not about to write or support program code that occupies more than 2GiB of storage, but surely you can see the extreme usefulness of multi-GiB of main-storage data accessed by a program. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Wednesday, January 27, 2016 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 On Jan 27, 2016, at 11:25 AM, Barry Lichtenstein wrote: > Note that the binder has been producing program objects for over 25 > years. It is difficult to make significant enhancements to OBJ > object module and load module formats. Some important things have > been added such as AMODE 64 and quad-word alignment. > > barry_lichtenst...@us.ibm.com Since COBOL does not and will not in the foreseeable future need amode 64 I find the argument un helpful. Ed -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Neat python library: NJElib
I just came across this. It is a python library which allows NJE communications. It looks "neat" to me. I have done a quick test from my Linux/Intel system to my z/OS sandbox and I can at least connect. I don't have a z/VM or z/Linux system . I haven't tried anything fancy like submitting jobs or retrieving output as yet. I might look into writing an NJE daemon in order to have a on-going NJE connection for job submission / retrieval. Of course, mapping the user ids betwee z/Linux to z/OS (or other) might be a bit of a bother. https://github.com/zedsec390/NJElib -- Werner Heisenberg is driving down the autobahn. A police officer pulls him over. The officer says, "Excuse me, sir, do you know how fast you were going?" "No," replies Dr. Heisenberg, "but I know where I am." Computer Science is the only discipline in which we view adding a new wing to a building as being maintenance -- Jim Horning Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. He's about as useful as a wax frying pan. 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: Deleting a dataset that GRS has enqueued.
On Jan 27, 2016, at 11:24 AM, Tom Brennan wrote: I did that zap a few times until I found the BYPASSNQ program from Gilbert Saint-Flour. I believe he used the old method of SVC screening to replace the ENQ SVC with a BR14 just for the running task, then he called the program specified on the parm. A genius method, but of course this was before the RACF option was available. //BYPASSNQ EXEC PGM=BYPASSNQ,PARM=IEHPROGM //STEPLIB DD DSN=SOME.APFAUTH.LOAD.LIBRARY,DISP=SHR //VOL DD UNIT=DISK,VOL=SER=R16RES,DISP=OLD //SYSPRINT DD SYSOUT=* //SYSINDD * RENAME DSNAME=SYS1.SCSQANLE,VOL=3390=R16RES,NEWNAME=SYS2.SCSQANLE I abhor any front ending PERIOD even from vendors. I ask vendors before buying their product if they do so and reject any that do. Ed Ed Gould wrote: Try disabling the VVDS on the volume amaspzap the dataset to change the name. delete the dataset with iehprogm enable the vvds on the volume Ed On Jan 27, 2016, at 9:00 AM, Peter Ten Eyck wrote: A question about deleting a dataset that GRS (z/OS 1.13) has enqueued. We have two LPARs in a sysplex, each with their own catalog structure. There is a dataset named the same and cataloged in each LPAR on two different volumes. I would like to delete the dataset in one of the LPARs, but the name is in use by the other LPAR and enqueued by GRS. Any suggestions of how to delete the dataset in the LPAR (and on the volume) that is not being used? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM- MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
On Jan 27, 2016, at 11:25 AM, Barry Lichtenstein wrote: It's not the JCL per-se. The combination of XOBJ object modules and the Prelinker was a tactical solution to advancements in programs, originally created for C programs. XOBJ object modules addressed several deficiencies in OBJ object modules, such the ability to have long case-sensitive external symbol names. While it does the intended job, the Prelinker has several drawbacks, such as the inability to incrementally rebind a module so created (read "csect replacement"). The prelinker does not handle GOFF object modules such as produced by C/C++ with XPLINK and COBOL V5. GOFF object modules can define characteristics of a program which cannot be represented in a load module. Note that the binder has been producing program objects for over 25 years. It is difficult to make significant enhancements to OBJ object module and load module formats. Some important things have been added such as AMODE 64 and quad-word alignment. barry_lichtenst...@us.ibm.com Since COBOL does not and will not in the foreseeable future need amode 64 I find the argument un helpful. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Quadword Alignment in OBJ Modules (Was: COBOL v5)
Ed Jaffe wrote: On 1/27/2016 9:25 AM, Barry Lichtenstein wrote: Note that the binder has been producing program objects for over 25 years. It is difficult to make significant enhancements to OBJ object module and load module formats. Some important things have been added such as AMODE 64 and quad-word alignment. If old-school OBJ modules now support quad-word alignment, why does HLASM warn for NOGOFF with SECTALGN(16)? ** ASMA216W Quad-word alignment in NOGOFF object text Good question! See zOS MVS Program Management: Advanced Facilities (SA23-1392-00), in the section titled "ESD record" - it's clear you can create an SD, PC or CM symbol with quadword alignment.You can also see the definitions for RMODE 64 and AMODE 64 there. The section on "Load module formats" also indicates how to specify quad-word alignment on these symbols. Furthmore, from the HLASM Programmar's Guide (SC26-4941-06) we can also find the same definitions in the section named "ESD record format". I wonder why HLASM generates this warning - the description for it says: -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
Yes, this is good. I will try that. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
On Jan 27, 2016, at 9:53 AM, Elardus Engelbrecht wrote: Ed Gould wrote: Try disabling the VVDS on the volume amaspzap the dataset to change the name. delete the dataset with iehprogm enable the vvds on the volume You're a dangerous fella! ;-) Good advice, but that is not for the faint hearted... SNIP Of course you are correct. But each person should know his environment and I do mean know. I expect the person asking on here to know his job and part of the job is to be able situations like this. If he/she doesn't then he should state his expertise (or lack there of). If he/she is not knowledgeable then they should say so. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
What is wrong with this solution, it is the easiest in my opinion: update parmlib- set grs - delete. You can tell GRS to keep the ENQ for that DSNAME local in the GRSRNLxx parmlib member. In that case the name must be available only in the LPAR where you do the delete. Example: RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(SYS1.DAE) Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Ten Eyck Sent: Wednesday, January 27, 2016 4:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting a dataset that GRS has enqueued. Yes. The owner (in use) of the dataset is known. GRS has an enq on that dataset name. I am trying to delete "that dataset name" in a different LPAR on a different volume. I am wondering if there is a way to "notify” GRS that it is OK to let me delete this "version" of the dataset. -- 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: Need to find the DSN from where load module was loaded
On Wed, 27 Jan 2016 10:21:55 -0600, Support, DUNNIT SYSTEMS LTD. wrote: >Thank you for sending me the code. I haven't looked at it yet but I'll narrow >down what I'm talking about: > >1. Environment is batch or ISPF. Check is during execution. Code is Assembler. >2. Looking for origin DSN of program module which was loaded via LOAD macro. >3. Loadlib can be in JOBLIB, STEPLIB or ISPF LIBDEF. >4. There may be multiple loadlibs concatenated together in the DD allocation. You still haven't said why you are doing this, and what you hope to accomplish with the information. That may be important to getting the best answer. For the general case, as far as I know, you cannot determine the answer with certainty. For some specific cases of module access you may be able to determine the answer with a fair degree of certainty, but probably not 100% unless you are the owner of the code that loaded the module, and can guarantee the environment that code is running in. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Quadword Alignment in OBJ Modules (Was: COBOL v5)
On 1/27/2016 9:25 AM, Barry Lichtenstein wrote: Note that the binder has been producing program objects for over 25 years. It is difficult to make significant enhancements to OBJ object module and load module formats. Some important things have been added such as AMODE 64 and quad-word alignment. If old-school OBJ modules now support quad-word alignment, why does HLASM warn for NOGOFF with SECTALGN(16)? ** ASMA216W Quad-word alignment in NOGOFF object text -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13 BC????
Thanks Mark for pointing that out. SHARE is anxious to be 'the place to go for answers'. It gives us pause when Google can lead a horse to water that the horse cannot find from the river bank. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net jo.skip.robin...@gmail.com > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mark Post > Sent: Wednesday, January 27, 2016 10:18 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: z13 BC > > >>> On 1/27/2016 at 08:43 AM, Carlos Bodra > wrote: > > I haven*t access to protect area of Share Sessions handouts. > > If you create an account on the web site, you will be able to access the content > without having to resort to using search engines. > > > Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
If/when PL/1 supports 64-bit, the executable will have to live in a program object if compiled 64-bit. That's the same state of the C compiler today. It's not the 64-bit part that requires that, but XPLINK which is required to run 64-bit with IBM's compilers. In article <56a78e69.5010...@t-online.de> you wrote: > In the PL/1 mailing list, Peter Elderon (IBM) explicitly stated that there > are no plans to force the PL/1 users to PDSEs, so IMO this is not true > for PL/1, > at least. > Kind regards > Bernd > Am 26.01.2016 um 15:10 schrieb Steve Thompson: > > IIRC: At Share 2015 in Seattle, wasn't it stated that the COBOL 5 code > > generator is the one that PL/1, C/C++, and a few others are using or > > will (soon) be using? > > > > IOW: The "architecture aware" code generator was going to be common. > > That means it will be generating program objects. > > > > > > Regards, > > Steve Thompson -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13 BC????
>>> On 1/27/2016 at 08:43 AM, Carlos Bodra wrote: > I haven*t access to protect area of Share Sessions handouts. If you create an account on the web site, you will be able to access the content without having to resort to using search engines. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to find the DSN from where load module was loaded
A bit of extra info, IEWLFMD apparently has the DDNAME of on offset +2C and the concatenation number on offset +34. I think you would be able to go from there, although, again, pretty sure that's not intended programming interface and "can break at any time" type of thing. Regards, Leo -Original Message- From: Leonardo Vaz Sent: Wednesday, January 27, 2016 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RE: Need to find the DSN from where load module was loaded I was just comparing what you want with what TSO ISRDDN provides, if ISRDDN does it, you should be able to do it too. It was just my guess that ISRDDN uses CSVQUERY to get that information, I'm not sure how it does it, but I just did a quick test with CSVQUERY and it looks like the information you are looking for might be in OUTPDATA, the last full word of the 16 bytes has a pointer to a IEWLFMD. I don't think that is the intended programming interface though, maybe someone else can help us here. Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Support, DUNNIT SYSTEMS LTD. Sent: Wednesday, January 27, 2016 12:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need to find the DSN from where load module was loaded Hello Leondardo, In this case, we can exclude the LINKLST. Since this is also applicable to a batch job environment and we're talking about during actually execution time, TSO ISRDDN is not applicable. Looking at the CSVQUERY macro documentation, am I correct in assuming this will NOT give me what I need under the circumstances? Or is the CSVQUERY macro my direct ticket to finding the DSN of the program brought into storage by a LOAD in both batch and ISPF environments? -- 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: Need to find the DSN from where load module was loaded
I was just comparing what you want with what TSO ISRDDN provides, if ISRDDN does it, you should be able to do it too. It was just my guess that ISRDDN uses CSVQUERY to get that information, I'm not sure how it does it, but I just did a quick test with CSVQUERY and it looks like the information you are looking for might be in OUTPDATA, the last full word of the 16 bytes has a pointer to a IEWLFMD. I don't think that is the intended programming interface though, maybe someone else can help us here. Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Support, DUNNIT SYSTEMS LTD. Sent: Wednesday, January 27, 2016 12:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need to find the DSN from where load module was loaded Hello Leondardo, In this case, we can exclude the LINKLST. Since this is also applicable to a batch job environment and we're talking about during actually execution time, TSO ISRDDN is not applicable. Looking at the CSVQUERY macro documentation, am I correct in assuming this will NOT give me what I need under the circumstances? Or is the CSVQUERY macro my direct ticket to finding the DSN of the program brought into storage by a LOAD in both batch and ISPF environments? -- 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: Deleting a dataset that GRS has enqueued.
Good info thanks. Sadly the dataset is SMS managed. So reading the documentation you provided, it does not seem like that will work. Scratching head still.. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL v5
It's not the JCL per-se. The combination of XOBJ object modules and the Prelinker was a tactical solution to advancements in programs, originally created for C programs. XOBJ object modules addressed several deficiencies in OBJ object modules, such the ability to have long case-sensitive external symbol names. While it does the intended job, the Prelinker has several drawbacks, such as the inability to incrementally rebind a module so created (read "csect replacement"). The prelinker does not handle GOFF object modules such as produced by C/C++ with XPLINK and COBOL V5. GOFF object modules can define characteristics of a program which cannot be represented in a load module. Note that the binder has been producing program objects for over 25 years. It is difficult to make significant enhancements to OBJ object module and load module formats. Some important things have been added such as AMODE 64 and quad-word alignment. barry_lichtenst...@us.ibm.com On Tue, 26 Jan 2016 13:52:28 -0600, Bill Woodger wrote: > Sorry not to be clear that I was paraphrasing the PL/I Programming Guide: > > > "Cataloged procedures IBMZCB and IBMZCBG use features of the program > management binder introduced in DFSMS/MVS ® 1.4 in place of the prelinker > supplied with Language Environment. These procedures produce a program object > in a PDSE. > > Cataloged procedures IBMZCPL, IBMZCPLG and IBMZCPG use the prelinker > supplied with Language Environment and produce a load module in PDS. Use > these procedures if you do not want to use a PDSE. > > ... > > The IBMZCB cataloged procedure, shown in Figure 11 on page 142, includes two > procedure steps: PLI, which is identical to cataloged procedure IBMZC, and > BIND, > which invokes the Program Management binder (symbolic name IEWBLINK) to > bind the object module produced in the first procedure step. > ... > > The IBMZCPL cataloged procedure, shown in Figure 13, includes three procedure > steps: PLI, which is identical to cataloged procedure IBMZC; PLKED, which > invokes the Language Environment prelinker; and LKED, which invokes the > linkage editor (symbolic name IEWL) to link-edit the object module produced in > the first procedure step." > > At the end of the day, it is the JCL which determines where the executable > program resides. > > PL/I can create programs which do not require to be a Program Object. COBOL > V5 cannot. > > Aside 1: Without an "unless we feel like it" clause, I'm not buying a "we > won't do that" unless the Board are behind it. > > Aside 2: Who thought it was a good idea to name a place where one or more > Object Programs can turn up a Program Object. That's clear, right? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
I did that zap a few times until I found the BYPASSNQ program from Gilbert Saint-Flour. I believe he used the old method of SVC screening to replace the ENQ SVC with a BR14 just for the running task, then he called the program specified on the parm. A genius method, but of course this was before the RACF option was available. //BYPASSNQ EXEC PGM=BYPASSNQ,PARM=IEHPROGM //STEPLIB DD DSN=SOME.APFAUTH.LOAD.LIBRARY,DISP=SHR //VOL DD UNIT=DISK,VOL=SER=R16RES,DISP=OLD //SYSPRINT DD SYSOUT=* //SYSINDD * RENAME DSNAME=SYS1.SCSQANLE,VOL=3390=R16RES,NEWNAME=SYS2.SCSQANLE Ed Gould wrote: Try disabling the VVDS on the volume amaspzap the dataset to change the name. delete the dataset with iehprogm enable the vvds on the volume Ed On Jan 27, 2016, at 9:00 AM, Peter Ten Eyck wrote: A question about deleting a dataset that GRS (z/OS 1.13) has enqueued. We have two LPARs in a sysplex, each with their own catalog structure. There is a dataset named the same and cataloged in each LPAR on two different volumes. I would like to delete the dataset in one of the LPARs, but the name is in use by the other LPAR and enqueued by GRS. Any suggestions of how to delete the dataset in the LPAR (and on the volume) that is not being used? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to find the DSN from where load module was loaded
Hello Leondardo, In this case, we can exclude the LINKLST. Since this is also applicable to a batch job environment and we're talking about during actually execution time, TSO ISRDDN is not applicable. Looking at the CSVQUERY macro documentation, am I correct in assuming this will NOT give me what I need under the circumstances? Or is the CSVQUERY macro my direct ticket to finding the DSN of the program brought into storage by a LOAD in both batch and ISPF environments? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zEDC
Funny observation regarding zEDC: z/OS 1.13 does not use zEDC, but HCD dialogs allow to define zEDC cards. So far so good... ...but you cannot activate such IODF. It is also not allowed to update IOCDS with zEDC defined. I haven't tried to use IOCP.txt as a method to update IOCDS, but I believe it should work. Same restriction apply to OSD chpid with "Physical network ID" assigned. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to find the DSN from where load module was loaded
3. Include linklist too. I think you are looking for something like the "TSO ISRDDN" then "LOAD modname", it load the module then tells you where it was loaded from, my guess is that it loads the module then issues a CSVQUERY to obtain the information of where it was loaded from (OUTDSKEY?). Bad part though: "Note that the format of this key is not part of the programming interface." Is that what you are looking for? Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Support, DUNNIT SYSTEMS LTD. Sent: Wednesday, January 27, 2016 11:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need to find the DSN from where load module was loaded Hello Eileen, Thank you for sending me the code. I haven't looked at it yet but I'll narrow down what I'm talking about: 1. Environment is batch or ISPF. Check is during execution. Code is Assembler. 2. Looking for origin DSN of program module which was loaded via LOAD macro. 3. Loadlib can be in JOBLIB, STEPLIB or ISPF LIBDEF. 4. There may be multiple loadlibs concatenated together in the DD allocation. Jerry -- 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: Deleting a dataset that GRS has enqueued.
I vote for the RACF profile. This is what that mechanism was designed for. The dataset does not just disappear. In ISPF, you get a very explicit prompt that what you're doing is potentially dangerous and requires extra care. Furthermore, you don't need any special cleanup process afterwards as you would with tweaking GRS. In my shop, creation of a special, even temporary RACF profile requires approval. As a senior sysprog, I'm blessed with access to profile STGADMIN.DPDSRN.* . This allows me to handle any dataset without hoopla. I do this responsibly and very infrequently. 'False contention' within GRS can cause production failures, not just inconvenience. I believe that a shop needs a process in place to fix these problems before they become Sev 1 incidents. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net jo.skip.robin...@gmail.com > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tom Marchant > Sent: Wednesday, January 27, 2016 08:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: Deleting a dataset that GRS has enqueued. > > On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote: > > >Try disabling the VVDS on the volume > >amaspzap the dataset to change the name. > >delete the dataset with iehprogm > >enable the vvds on the volume > > ITYM disable the VTOC index. I wouldn't want to do it that way. > I think that what Kees suggested is a better solution. Tell GRS not to > propagate > the ENQ. > > -- > Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zEDC
The announced requirement indicates it is only associated with the Processor hardware: * z13, EC12 or BC13 * zEDC Express (min of two recommended) * all systems accessing compressed data have zEDC Express (recommended) * z/OS V2.1 or later w zEDC feature & PTFs It mentions there is minimal CPU overhead, which implies there may still be some compression overhead versus no compression, but much less than before and offset by lower CPU for I/O or other moving of compressed data. One chart looked like compression still requires BSAM/QSAM files to be Extended Format files, which used to exclude hardware compression for PDS/PDSE files. Any one know for sure if that is still the case? One good argument, besides prior CPU overhead, for keeping the old ISPF PACKED data support was that hardware compression still didn't support PDS/PDSE libraries. It would sure be nice if large source libraries could finally get the benefit of hardware compression as well. Obviously one would want to be sure your DR site also had required supporting hardware. Joel C. Ewing On 01/27/2016 09:53 AM, Lizette Koehler wrote: > Is there any hardware dependencies, like IBM Hardware only or can it be on > any vendor DASD hardware? > > Lizette > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Jackson, Robin W. Contractor >> Sent: Wednesday, January 27, 2016 8:48 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: zEDC >> >> I am a proponent of zEDC and would recommend to management enabling this >> feature, (which is presently configured 'FEATURENAME(zEDC) STATE(DISABLED)' >> in IFAPRD00. >> >> My question relative to this issue would be my ability to present to >> management a position that would demonstrate the comparison cost savings >> relative to the 'zEDC' cost(s). >> >> Any suggestions? I have considered running this by Cheryl Watson. >> >> Thanks, >> >> Rob Jackson >> robin.w.jack...@ssa.gov >> rwjackso...@msn.com >> Office: 1-877-897-0598 ext. 10462 >> Cell: (615) 689-1435 >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Scott Barry >> Sent: Monday, January 25, 2016 11:09 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: zEDC >> >> Yes, a client we support is seeing very positive results, exploiting zEDC >> data-compression (up to 8-to-1) with SMF LOGSTREAMs and sequential datasets; >> just now starting to investigate DFHSM opportunities. Important to stay >> current on IBM z/OS maintenance -- most recent was a nagging S002-F6 >> intermittent ABEND which was corrected with maintenance. >> >> Scott Barry >> SBBWorks, Inc. >> >> >> On Fri, 22 Jan 2016 20:38:50 +, Phillips, Thomas >> wrote: >> >>> Is anyone using the new zEDC cards in a production environment? We are >> running z13's with z/OS 2.1. >>> Feel free to contact me offline, if you'd like. >>> >>> Thanks, >>> Tom Phillips >>> Principal Financial Group >>> -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
On Wed, 27 Jan 2016 09:51:56 -0600, Norbert Friemel wrote: >1. Create RACF facility class profile STGADMIN.DPDSRN.olddsname, rename the >dataset (ISPF 3.4), delete the renamed dataset >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s382/2.6.3.4 One of the conditions to be able to do this: "The data set is not SMS-managed." -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
On Wed, 27 Jan 2016 09:37:29 -0600, Ed Gould wrote: >Try disabling the VVDS on the volume >amaspzap the dataset to change the name. >delete the dataset with iehprogm >enable the vvds on the volume ITYM disable the VTOC index. I wouldn't want to do it that way. I think that what Kees suggested is a better solution. Tell GRS not to propagate the ENQ. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to find the DSN from where load module was loaded
Hello Eileen, Thank you for sending me the code. I haven't looked at it yet but I'll narrow down what I'm talking about: 1. Environment is batch or ISPF. Check is during execution. Code is Assembler. 2. Looking for origin DSN of program module which was loaded via LOAD macro. 3. Loadlib can be in JOBLIB, STEPLIB or ISPF LIBDEF. 4. There may be multiple loadlibs concatenated together in the DD allocation. Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zEDC
From Redbook SG24-8259-00 and from my initial cursory glance did not see any other hardware specific requirement(s). The solution is a combination of the zEDC capability in IBM z/OS V2.1 and the zEDC Express hardware feature (FC# 0420, see Figure 1-1) available from zEC12 general availability (GA2). Thanks, Rob Jackson robin.w.jack...@ssa.gov rwjackso...@msn.com Office: 1-877-897-0598 ext. 10462 Cell: (615) 689-1435 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Wednesday, January 27, 2016 10:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: zEDC Is there any hardware dependencies, like IBM Hardware only or can it be on any vendor DASD hardware? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Jackson, Robin W. Contractor > Sent: Wednesday, January 27, 2016 8:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: zEDC > > I am a proponent of zEDC and would recommend to management enabling > this feature, (which is presently configured 'FEATURENAME(zEDC) > STATE(DISABLED)' > in IFAPRD00. > > My question relative to this issue would be my ability to present to > management a position that would demonstrate the comparison cost > savings relative to the 'zEDC' cost(s). > > Any suggestions? I have considered running this by Cheryl Watson. > > Thanks, > > Rob Jackson > robin.w.jack...@ssa.gov > rwjackso...@msn.com > Office: 1-877-897-0598 ext. 10462 > Cell: (615) 689-1435 > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Scott Barry > Sent: Monday, January 25, 2016 11:09 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: zEDC > > Yes, a client we support is seeing very positive results, exploiting > zEDC data-compression (up to 8-to-1) with SMF LOGSTREAMs and > sequential datasets; just now starting to investigate DFHSM > opportunities. Important to stay current on IBM z/OS maintenance -- > most recent was a nagging S002-F6 intermittent ABEND which was corrected with > maintenance. > > Scott Barry > SBBWorks, Inc. > > > On Fri, 22 Jan 2016 20:38:50 +, Phillips, Thomas > wrote: > > >Is anyone using the new zEDC cards in a production environment? We > >are > running z13's with z/OS 2.1. > > > >Feel free to contact me offline, if you'd like. > > > >Thanks, > >Tom Phillips > >Principal Financial Group > > -- 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: zEDC
Is there any hardware dependencies, like IBM Hardware only or can it be on any vendor DASD hardware? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jackson, Robin W. Contractor > Sent: Wednesday, January 27, 2016 8:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: zEDC > > I am a proponent of zEDC and would recommend to management enabling this > feature, (which is presently configured 'FEATURENAME(zEDC) STATE(DISABLED)' > in IFAPRD00. > > My question relative to this issue would be my ability to present to > management a position that would demonstrate the comparison cost savings > relative to the 'zEDC' cost(s). > > Any suggestions? I have considered running this by Cheryl Watson. > > Thanks, > > Rob Jackson > robin.w.jack...@ssa.gov > rwjackso...@msn.com > Office: 1-877-897-0598 ext. 10462 > Cell: (615) 689-1435 > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Scott Barry > Sent: Monday, January 25, 2016 11:09 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: zEDC > > Yes, a client we support is seeing very positive results, exploiting zEDC > data-compression (up to 8-to-1) with SMF LOGSTREAMs and sequential datasets; > just now starting to investigate DFHSM opportunities. Important to stay > current on IBM z/OS maintenance -- most recent was a nagging S002-F6 > intermittent ABEND which was corrected with maintenance. > > Scott Barry > SBBWorks, Inc. > > > On Fri, 22 Jan 2016 20:38:50 +, Phillips, Thomas > wrote: > > >Is anyone using the new zEDC cards in a production environment? We are > running z13's with z/OS 2.1. > > > >Feel free to contact me offline, if you'd like. > > > >Thanks, > >Tom Phillips > >Principal Financial Group > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
Ed Gould wrote: >Try disabling the VVDS on the volume >amaspzap the dataset to change the name. >delete the dataset with iehprogm >enable the vvds on the volume You're a dangerous fella! ;-) Good advice, but that is not for the faint hearted... Peter Ten Eyck wrote: >> A question about deleting a dataset that GRS (z/OS 1.13) has enqueued. We >> have two LPARs in a sysplex, each with their own catalog structure. There is >> a dataset named the same and cataloged in each LPAR on two different >> volumes. I would like to delete the dataset in one of the LPARs, but the >> name is in use by the other LPAR and enqueued by GRS. Any suggestions of how >> to delete the dataset in the LPAR (and on the volume) that is not being used? and >Yes. The owner (in use) of the dataset is known. GRS has an enq on that >dataset name. I am trying to delete "that dataset name" in a different LPAR on >a different volume. I am wondering if there is a way to "notify” GRS that it >is OK to let me delete this "version" of the dataset. No, this is WAD! There is not a way to tell GRS you want to bypass it. You're just trying to bypass the integrity of z/OS. Please reread Lizette's good advice. She is a serious expert, trust me! I would suggest that you stop that owner, get rid of the offending dataset by RENAMING (not delete) it and catalog it if needed and start that owner. If the owner is running fine, you can then delete that offending dataset. And no, as a RACF admin, I will not give access with a special profile to delete that reserved dataset. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
On Wed, 27 Jan 2016 09:00:05 -0600, Peter Ten Eyck wrote: >A question about deleting a dataset that GRS (z/OS 1.13) has enqueued. > >We have two LPARs in a sysplex, each with their own catalog structure. There >is a dataset named the same and cataloged in each LPAR on two different >volumes. > >I would like to delete the dataset in one of the LPARs, but the name is in use >by the other LPAR and enqueued by GRS. Any suggestions of how to delete the >dataset in the LPAR (and on the volume) that is not being used? 1. Create RACF facility class profile STGADMIN.DPDSRN.olddsname, rename the dataset (ISPF 3.4), delete the renamed dataset http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s382/2.6.3.4 or 2. Use program BYPASSNQ ( File183 http://www.cbttape.org/cbtdowns.htm ) Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to find the DSN from where load module was loaded
I have a program that finds the dsn that load modules are in. there is a version for CICS and one for TSO. I will send you the code but it is kind of hard to follow. you start by locating the DEB queues, get the DCB and DDN from the DEB queue, issue a BLDL on the DCB to see if the load module is there. then you read the JFCB for the DDN and extract the DSN. jerry, Send me your email address and I will send you the code. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Support, DUNNIT SYSTEMS LTD. Sent: Wednesday, January 27, 2016 7:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Need to find the DSN from where load module was loaded I tried searching archives. for this. Environment might be batch or ISPF, if it makes a difference. Need to know control block hop sequence and what MACRO calls are needed. Thanks, Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by replying to this e-mail and delete the e-mail from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zEDC
I am a proponent of zEDC and would recommend to management enabling this
feature, (which is presently configured 'FEATURENAME(zEDC) STATE(DISABLED)' in
IFAPRD00.
My question relative to this issue would be my ability to present to management
a position that would demonstrate the comparison cost savings relative to the
'zEDC' cost(s).
Any suggestions? I have considered running this by Cheryl Watson.
Thanks,
Rob Jackson
robin.w.jack...@ssa.gov
rwjackso...@msn.com
Office: 1-877-897-0598 ext. 10462
Cell: (615) 689-1435
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Scott Barry
Sent: Monday, January 25, 2016 11:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC
Yes, a client we support is seeing very positive results, exploiting zEDC
data-compression (up to 8-to-1) with SMF LOGSTREAMs and sequential datasets;
just now starting to investigate DFHSM opportunities. Important to stay
current on IBM z/OS maintenance -- most recent was a nagging S002-F6
intermittent ABEND which was corrected with maintenance.
Scott Barry
SBBWorks, Inc.
On Fri, 22 Jan 2016 20:38:50 +, Phillips, Thomas
wrote:
>Is anyone using the new zEDC cards in a production environment? We are
>running z13's with z/OS 2.1.
>
>Feel free to contact me offline, if you'd like.
>
>Thanks,
>Tom Phillips
>Principal Financial Group
>
>-Message Disclaimer-
>
>This e-mail message is intended only for the use of the individual or entity
>to which it is addressed, and may contain information that is privileged,
>confidential and exempt from disclosure under applicable law. If you are not
>the intended recipient, any dissemination, distribution or copying of this
>communication is strictly prohibited. If you have received this communication
>in error, please notify us immediately by reply email to conn...@principal.com
>and delete or destroy all copies of the original message and attachments
>thereto. Email sent to or from the Principal Financial Group or any of its
>member companies may be retained as required by law or regulation.
>
>Nothing in this message is intended to constitute an Electronic signature for
>purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic
>Signatures in Global and National Commerce Act ("E-Sign") unless a specific
>statement to the contrary is included in this message.
>
>If you no longer wish to receive any further solicitation from the Principal
>Financial Group you may unsubscribe at
>https://www.principal.com/do-not-contact-form any time.
>
>If you are a Canadian resident and no longer wish to receive commercial
>electronic messages you may unsubscribe at
>https://www.principal.com/do-not-email-request-canadian-residents any time.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
Try disabling the VVDS on the volume amaspzap the dataset to change the name. delete the dataset with iehprogm enable the vvds on the volume Ed On Jan 27, 2016, at 9:00 AM, Peter Ten Eyck wrote: A question about deleting a dataset that GRS (z/OS 1.13) has enqueued. We have two LPARs in a sysplex, each with their own catalog structure. There is a dataset named the same and cataloged in each LPAR on two different volumes. I would like to delete the dataset in one of the LPARs, but the name is in use by the other LPAR and enqueued by GRS. Any suggestions of how to delete the dataset in the LPAR (and on the volume) that is not being used? -- 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: Need to find the DSN from where load module was loaded
Sorry, I am NOT clear on what you are trying to accomplish here. There is also a consideration on how the module is retrieved, Links, or calls, or transfer of control, and so on. Is this self-contained inside your program? Or are you trying to find modules in any asid and where they are called? Is this from within a subsystem (like CICS or IMS) or an STC? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Wednesday, January 27, 2016 8:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Need to find the DSN from where load module was loaded > > Are you creating a real time search process? Or is this after the fact? > There are many tools and processes that could accomplish your requirement. > > I am on clear on what problem you are trying to solve. > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Support, DUNNIT SYSTEMS LTD. > > Sent: Wednesday, January 27, 2016 5:17 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Need to find the DSN from where load module was loaded > > > > I tried searching archives. for this. Environment might be batch or > > ISPF, if it makes a difference. Need to know control block hop > > sequence and what MACRO calls are needed. > > > > Thanks, > > Jerry > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to find the DSN from where load module was loaded
Are you creating a real time search process? Or is this after the fact? There are many tools and processes that could accomplish your requirement. I am on clear on what problem you are trying to solve. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Support, DUNNIT SYSTEMS LTD. > Sent: Wednesday, January 27, 2016 5:17 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Need to find the DSN from where load module was loaded > > I tried searching archives. for this. Environment might be batch or ISPF, if > it makes a difference. Need to know control block hop sequence and what MACRO > calls are needed. > > Thanks, > Jerry > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
You can tell GRS to keep the ENQ for that DSNAME local in the GRSRNLxx parmlib member. In that case the name must be available only in the LPAR where you do the delete. Example: RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(SYS1.DAE) Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Ten Eyck Sent: Wednesday, January 27, 2016 4:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Deleting a dataset that GRS has enqueued. Yes. The owner (in use) of the dataset is known. GRS has an enq on that dataset name. I am trying to delete "that dataset name" in a different LPAR on a different volume. I am wondering if there is a way to "notify” GRS that it is OK to let me delete this "version" of the dataset. -- 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: Deleting a dataset that GRS has enqueued.
GRS serializes resources so datasets are protected. When you say the OWNER IS KNOWN, who is the owner? Some owners require special actions to be able to do what you do. If you do this incorrectly, you might cause an application to come down or an IPL. By not providing the information that is requested, you might not get a complete process for what you want to do. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Ten Eyck > Sent: Wednesday, January 27, 2016 8:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Deleting a dataset that GRS has enqueued. > > Yes. The owner (in use) of the dataset is known. GRS has an enq on that > dataset name. I am trying to delete "that dataset name" in a different LPAR on > a different volume. I am wondering if there is a way to "notify” GRS that it > is OK to let me delete this "version" of the dataset. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
If it is SYS1 there is a FACILITY class STGADMIN profile that will allow you to bypass the enqueue in 3.4 for rename only if you have access to the profile. On Wednesday, 27 January 2016, Peter Ten Eyck wrote: > Yes. The owner (in use) of the dataset is known. GRS has an enq on that > dataset name. I am trying to delete "that dataset name" in a different LPAR > on a different volume. I am wondering if there is a way to "notify” GRS > that it is OK to let me delete this "version" of the dataset. > > -- > 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: Deleting a dataset that GRS has enqueued.
Yes. The owner (in use) of the dataset is known. GRS has an enq on that dataset name. I am trying to delete "that dataset name" in a different LPAR on a different volume. I am wondering if there is a way to "notify” GRS that it is OK to let me delete this "version" of the dataset. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Deleting a dataset that GRS has enqueued.
First, make sure the one you are deleting is not the one I use, then you can 3.4 passing the VOLSER so you rename the dataset on the volume level (not catalogued), to any DSN that is not in use. Then you can delete the renamed dataset. Again, make sure the one you are deleting is not the one I use. Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Ten Eyck Sent: Wednesday, January 27, 2016 10:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Deleting a dataset that GRS has enqueued. A question about deleting a dataset that GRS (z/OS 1.13) has enqueued. We have two LPARs in a sysplex, each with their own catalog structure. There is a dataset named the same and cataloged in each LPAR on two different volumes. I would like to delete the dataset in one of the LPARs, but the name is in use by the other LPAR and enqueued by GRS. Any suggestions of how to delete the dataset in the LPAR (and on the volume) that is not being used? -- 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: Deleting a dataset that GRS has enqueued.
Could you do a D GRS,RES=(*,datasetname) and show the results? GRS reports owners, so it would help to know what tasks (like LLA) might be holding the resource. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Ten Eyck > Sent: Wednesday, January 27, 2016 8:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Deleting a dataset that GRS has enqueued. > > A question about deleting a dataset that GRS (z/OS 1.13) has enqueued. > > We have two LPARs in a sysplex, each with their own catalog structure. There > is a dataset named the same and cataloged in each LPAR on two different > volumes. > > I would like to delete the dataset in one of the LPARs, but the name is in use > by the other LPAR and enqueued by GRS. Any suggestions of how to delete the > dataset in the LPAR (and on the volume) that is not being used? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Deleting a dataset that GRS has enqueued.
A question about deleting a dataset that GRS (z/OS 1.13) has enqueued. We have two LPARs in a sysplex, each with their own catalog structure. There is a dataset named the same and cataloged in each LPAR on two different volumes. I would like to delete the dataset in one of the LPARs, but the name is in use by the other LPAR and enqueued by GRS. Any suggestions of how to delete the dataset in the LPAR (and on the volume) that is not being used? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS file changes for z/OS 1.13 -> z/OS 2.1
Hi Dave, Here's some information for you. Java 6, 7, 8 and other levels are not "gone". They are all still on the ServerPac Shopz checklist, but maybe you just didn't order them?The last I looked, there were 10 (yes, ten) levels of Java that you could get with z/OS V2.1 and z/OS V2.2 ServerPac. For z/OS V2.2, we recommend that you get Java 7.1 64-bit so that you can use z/OSMF on z/OS V2.2. If you are missing a level of Java you need, please get it via a Product ServerPac. For the DDDEFs you mentioned, they aren't part of the z/OS product itself, so they won't be mentioned in the z/OS Migration book. They should be mentioned in their own products' publications. I did find that in the z/OSMF V2.1 program directory that: File systems that are deleted from WebSphere Application Server OEM Edition for z/OS V7.0: BBN.SBBN7ZFS or BBN.SBBN7HFS. SBBNCON1 looks to also be associated with the WAS OEM Edition (which was replaced with WAS Liberty Profile), so I think that's what's happened to that DDDEF too.Remember with WAS Liberty Profile, there were a lot of changes, so I'd expect that several DDDEFs were removed, from the OEM Edition. IBM Ported Tools never had Python, but I suspect it was PHP. Here's the things that are no longer offered in IBM Ported Tools V1.3: bzip2, cURL, Perl, sudo, and PHP. Here's the things that still exist in IBM Ported Tools V1.3: OpenSSH, Xvfb, IBM HTTP Server Powered by Apache at 8.5.5 (aka Apache 2.2). I hope this helps. -Marna WALLE IBM Poughkeepsie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13 BC????
Got them Thanks Bill CARLOS BODRA IBM Certified zSystem São Paulo - SP - BRAZIL Em 27/01/2016 11:48, Bill Woodger escreveu: Harv Emery's Seattle Presentation on z13/zBX -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS file changes for z/OS 1.13 -> z/OS 2.1
The files below are part of z/OS Ported Tools
SHPEROOT (Perl ?)
SHPHROOT (Python ?)
The file below are part of z/OSMF 1.13 ("free websphere"). This was replaced by
the "Liberty Profile" in z/OS 2.1 so they are no longer needed.
SBBNCON1 (Webshere ?)
SBBN7HFS (Webshere ?
Also there is a new zFS containing the Compatability Fonts where were merged
into base z/OS. There is also a new PDS with the same information.
HTH,
This email including attachments may contain confidential information. If
you are not the intended recipient, do not copy, distribute or act on it.
Instead, notify the sender immediately and delete the message.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z13 BC????
On Wednesday, 27 January 2016 13:44:06 UTC, Carlos Bodra wrote: > I haven´t access to protect area of Share Sessions handouts. > > CARLOS BODRA > IBM Certified zSystem > São Paulo - SP - BRAZIL > I got to them by search-engineing for Harv Emery's Seattle Presentation on z13/zBX The results gave directly downloadable PDFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13 BC????
I haven´t access to protect area of Share Sessions handouts. CARLOS BODRA IBM Certified zSystem São Paulo - SP - BRAZIL Em 27/01/2016 10:51, Richards, Robert B. escreveu: http://www.share.org/p/do/sd/topic=421&sid=11359 Part 1 http://www.share.org/p/do/sd/topic=421&sid=11320 Part 2 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Wednesday, January 27, 2016 5:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z13 BC 404 not found -teD Original Message From: Ed Finnell Sent: Tuesday, January 26, 2016 16:25 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: z13 BC They've been doing announcements around SHARE so might be a good place to find out more faster. WSC's Harv Emery's Seattle Presentation on z13/zBX rollout super informative. https://share.confex.com/share/124/webprogram/Handout/ In a message dated 1/26/2016 10:45:13 A.M. Central Standard Time, allan.stal...@wunderman.com writes: Rumored to be announced this spring! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13 BC????
http://www.share.org/p/do/sd/topic=421&sid=11359 Part 1 http://www.share.org/p/do/sd/topic=421&sid=11320 Part 2 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Wednesday, January 27, 2016 5:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z13 BC 404 not found -teD Original Message From: Ed Finnell Sent: Tuesday, January 26, 2016 16:25 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: z13 BC They've been doing announcements around SHARE so might be a good place to find out more faster. WSC's Harv Emery's Seattle Presentation on z13/zBX rollout super informative. https://share.confex.com/share/124/webprogram/Handout/ In a message dated 1/26/2016 10:45:13 A.M. Central Standard Time, allan.stal...@wunderman.com writes: Rumored to be announced this spring! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Need to find the DSN from where load module was loaded
I tried searching archives. for this. Environment might be batch or ISPF, if it makes a difference. Need to know control block hop sequence and what MACRO calls are needed. Thanks, Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z13 BC????
404 not found -teD Original Message From: Ed Finnell Sent: Tuesday, January 26, 2016 16:25 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: z13 BC They've been doing announcements around SHARE so might be a good place to find out more faster. WSC's Harv Emery's Seattle Presentation on z13/zBX rollout super informative. https://share.confex.com/share/124/webprogram/Handout/Session16704 In a message dated 1/26/2016 10:45:13 A.M. Central Standard Time, allan.stal...@wunderman.com writes: Rumored to be announced this spring! -- 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
AW: Re: OMVS file changes for z/OS 1.13 -> z/OS 2.1
>Perl and PHP must now be obtained from Rocket Software but that is with 2.2 >not 2.1. This is independent of the z/OS release. It only depends on when you ordered the PortedTools. IBM has removed some components that previously have been part of the package. I seem to remember that this has been discussed here (or on some other forum I'm subscribed), but a quick search on IBM-MAIN's as well as MVS-OE's archives has not returned anything. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
