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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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 /

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

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

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

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

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

Re: z13 BC????

http://www.share.org/p/do/sd/topic=421=11359 Part 1 http://www.share.org/p/do/sd/topic=421=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:

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=11359 Part 1 http://www.share.org/p/do/sd/topic=421=11320 Part 2 -Original

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

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

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