Exclusive ENQ on a TSO logon procedure

Greetings ,  Can somebody tell me what if a proclib containing a TSO logon procedure has got a DISP=OLD in a user submitted JCL or if somebody opens a logon procedure in ISPF edit mode  and keep it that way for few hours. Will the rest of the users be able to log on using the same logon

AW: Re: DFsort and zIIP

>DFSORT can use zIIP on behalf of DB2 utilities, but not otherwise. Here's >more information: > >At this time, IBM has no plan for enabling DFSORT to exploit the system z9 >Integrated Information Processor (zIIP). IBM realizes DFSORT remains a >prominent component of our customers' batch

Re: Exclusive ENQ on a TSO logon procedure

There is a big difference between a job allocating a proclib with DISP=OLD and a user editing a logonproc with ISPF. The job with DISP=OLD blocks the entire proclib. ISPF issues an ENQ with DISP=SHR on the proclib and issues its own ENQ on the member with DISP=OLD. This way the

Re: Exclusive ENQ on a TSO logon procedure

There is a big difference between a job allocating a proclib with DISP=OLD and a user editing a logonproc with ISPF. The job with DISP=OLD blocks the entire proclib. ISPF issues an ENQ with DISP=SHR on the proclib and issues its own ENQ on the member with DISP=OLD. This way the library is

Re: Node.js for z/OS: Emerging Now

How exciting. It's good to see IBM putting code on Github. I was aware that IBM were porting libuv so it was no suprise to see them working on V8 on the road to Node. A z/OS port of V8 sure makes porting code that depends on it a hell of a lot easier, for example - MongoDB. On 18/07/2016

Re: Exclusive ENQ on a TSO logon procedure

If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it already has allocated (as you mentioned). Kind of a chicken and egg problem: how can a user logon without having read the logonproc? Kees. -Original Message- From: IBM Mainframe Discussion List

Re: Exclusive ENQ on a TSO logon procedure

If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it already has allocated (as you mentioned). Kind of a chicken and egg problem: how can a user logon without having read the logonproc? Kees. Oh yeah..You are right.. . That explains why User C was able to log on .

Re: SMFPRMxx

>I'm trying to determine if they are actually being called/used. If you have the exits defined then they're going to be called, for the events for which they are defined. The displays can tell you the names of the exit routines associated with the exit. It does not give any information about

AW: Re: Exclusive ENQ on a TSO logon procedure

>If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it >already has allocated (as you >mentioned). Kind of a chicken and egg problem: >how can a user logon without having read the logonproc? >Kees. > >Oh yeah..You are right.. . That explains why User C was able to log

Re: Job Search

My organization has just posted a CICS sysprog job (below). There's good support for Telecommunting here and if you've got solid skills working remote should not be a deal breaker. Problem is the pay is well below market rates. We have several unfilled positions zOS/DB2/CICS/automation but

Re: FLASHCOPY QUESTION

Esmie, Let me give it a try. I think you're getting confused due to terminology and different views of the copies. From a z/OS point of view, both the examples you show are doing full volume copies of data from your IN to your OUT. Once the job is done, you have 2 full copies of the data,

Re: DFsort and zIIP

IBM markets DB2SORT, which is Syncsort/MFX with modifications to specifically work with and enhance sorting performed for DB2 Utilities and offloads portions of its processing to z/IIP engines when possible. Syncsort/MFX also offloads portions of its processing to z/IIP engines. Syncsort

Bsam VS Qsam for VB records

Hi, Would anyone know the plus and or minus for using BSAM as opposed to QSAM for VB records. It seems with BSAM there is more control e.g. specifying the BDW as well as the RDW. Wondering about performance. I am guessing if you know what you are doing BSAM would be faster. If anyone could

Re: Exclusive ENQ on a TSO logon procedure

On Tue, Jul 19, 2016 at 6:50 AM, Peter Hunkeler wrote: > > >If a user logs on, it is JES2 that reads the logonproc from PROCLIB, > which it already has allocated (as you >mentioned). Kind of a chicken and > egg problem: how can a user logon without having read the logonproc? >

FLASHCOPY QUESTION

Gentle Readers, I was wondering if any of you can clear up understating about FlashCopy. In the following example COPY INDYNAM(SYS012) OUTDYNAM(DCN00) CANCELERROR - PURGE ALLEXCP ALLDATA(*) OPT(4) ADMIN FCNOCOPY - DUMPCOND FR(REQ) DEBUG(FRMSG(DETAILED)) My

Re: FAMS?

You probably knew this but if you can run under ISPF, batch or interactive, use LMMSTATS. Otherwise found this on the format of the PDS directory: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54mc00/ispmc28.htm Ken On Mon, Jul 18, 2016 at 12:18 PM, Paul Gilmartin <

Re: Bsam VS Qsam for VB records

As Far as I can see all the I/O we do here is qsam There was an issue here as Jay Campbell pointed out where writing a VB record had a valid RDW but the BDW was zeros. Using qsam I would have no idea what the BDW was as the system takes care of that. I am assuming if you use BSAM you decide

Re: Bsam VS Qsam for VB records

I wonder what application it is that justifies considering this. It is not the 80's anymore. And even with QSAM you have the BUFNO parameter. If you really want to go down to the details, consider EXCP (I did, 35 years ago). Kees. -Original Message- From: IBM Mainframe Discussion List

Re: Bsam VS Qsam for VB records

That’s what I meant Joe Reichman Joe Reichman   IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F  7:30 am - 4:00 pm -Original Message- From:

Re: Default space allocation

I have, and it wasn't apparent in there that it would have the effect we've seen. Andy Styles z/Series Systems Programmer     -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: 19 July 2016 15:49 To:

Re: Bsam VS Qsam for VB records

Nothing. Data 1-LRECL, no RDW, no BDW. On Tue, Jul 19, 2016 at 10:15 AM, Reichman Joseph wrote: > With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? > > Joe Reichman > Joe Reichman > > IT Specialist > Master Files Division > New Carrollton Federal

Re: Bsam VS Qsam for VB records

With RECFM=U what you see is what you get. You will receive whatever is on the disk in a physical block. (Let's skip what is really happening under the covers in modern DASD.) You will get whatever was written. If it is a well-formed block written by QSAM RECFM=VB, or written with BSAM or even

Default space allocation

Hi All, We've had a minor issue a few times over the past year or so. On our GDPS control systems, we have a null SMS configuration - all datasets are allocated with UNIT=SYSALLDA (I think I'm explaining this right), otherwise you get SPECIFY DEVICE OR CANCEL. The issue we seem to have hit

VTOC Listing utility with PDSE V2 Maxgen Info?

Is there a utility available out there that will generate a vtoc listing that includes pdse version info and also maxgen info ? Thanks -- Lionel B. Dyck (TRA Contractor) Mainframe Systems Programmer Enterprise

Re: DFsort and zIIP

On Tue, 19 Jul 2016 08:26:45 +0200, Peter Hunkeler wrote: >>DFSORT can use zIIP on behalf of DB2 utilities, but not otherwise. Here's >>more information: > > >>At this time, IBM has no plan for enabling DFSORT to exploit the system z9 >>Integrated Information Processor (zIIP). IBM realizes

Re: Bsam VS Qsam for VB records

Agreed 100% with @Kees and @John. I would say "if you have to ask the question then you should not be using BSAM." I did not read the RDW thread but consider that if your block descriptor word is mucked up when using QSAM all you have to do is open a problem with IBM. If your block descriptor

Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G wrote: > On Jul 19, 2016, at 9:39 AM, Reichman Joseph > wrote: > > > > I am not thinking of moving this in production it may help me track down > a problem > > If your motivation is to examine

Re: Bsam VS Qsam for VB records

There is at least one TSO ZAP command on the CBT tape. It's very useful for examining DASD data. You don't actually need to alter any data; just look at it. The command is highly agnostic and will read pretty much any block. It won't tell you how an RDW got broken, but it can show the results

Re: Bsam VS Qsam for VB records

On Jul 19, 2016, at 9:39 AM, Reichman Joseph wrote: > > I am not thinking of moving this in production it may help me track down a > problem If your motivation is to examine the physical blocks, why not read with QSAM specifying RECFM=U? -- Pew, Curtis G

Re: Default space allocation

Have you checked out the ALLOCxx member of SYS1.PARMLIB (Or your version)? Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Styles, Andy (SD EP zPlatform) > Sent: Tuesday, July 19, 2016 7:34 AM > To:

Re: Bsam VS Qsam for VB records

With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? Joe Reichman Joe Reichman   IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693 TOD M - F  7:30 am

Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 9:02 AM, Reichman Joseph wrote: > Hi, > > Would anyone know the plus and or minus for using BSAM as opposed to QSAM > for VB records. It seems with BSAM there is more control e.g. specifying > the BDW as well as the RDW. Wondering about

Re: Bsam VS Qsam for VB records

Cumulative RDW's+4 (first beginners error). Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Reichman Joseph Sent: 19 July, 2016 16:33 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Bsam VS Qsam for VB records As Far as I can see

Re: DFsort and zIIP

The largest benefit is a financial one: you don't pay the zIIP MSUs. A performance benefit can come from the fact that the zIIP is always running at full speed, while your CP's can run at lower speeds. Kees. -Original Message- From: IBM Mainframe Discussion List

Re: Default space allocation

TSO ISPF I.4 DATACLAS column 8, 9, 10, 11(and 12 for PDS). On Tue, Jul 19, 2016 at 9:34 AM, Styles, Andy (SD EP zPlatform) <00d68f765d25-dmarc-requ...@listserv.ua.edu> wrote: > Hi All, > > We've had a minor issue a few times over the past year or so. On our GDPS > control systems, we have a

Re: Bsam VS Qsam for VB records

I am not thinking of moving this in production it may help me track down a problem Joe Reichman Joe Reichman   IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917) 748-9693

AW: Re: Exclusive ENQ on a TSO logon procedure

​>As as aside on this, as I understand it, this only applies to data sets >allocated via JCL. That is, if you allocate a PROCLIB inside the JES2PARM >(see below), the DSNs listed do have, and keep, the normal allocation (SHR >as I recall when JES2 does the DYNALLOC). This is true but the

Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 9:32 AM, Reichman Joseph wrote: > As Far as I can see all the I/O we do here is qsam There was an issue > here as Jay Campbell pointed out where writing a VB record had a valid RDW > but the BDW was zeros. Using qsam I would have no idea what the

Re: Default space allocation

I assume you meant ISMF; we don't have any data classes active on these systems. Andy Styles z/Series Systems Programmer   -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: 19 July 2016 15:42 To:

Re: Default space allocation

That means you are taking defaults. So the Init and Tuning Reference will provide more info ALLOCxx (allocation system defaults) Use the ALLOCxx member of SYS1.PARMLIB to define installation defaults for: Unit names (dynamic allocation, unit-affinity-ignored, and redirection from TAPE)

Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 10:15 AM, Reichman Joseph wrote: > With RECFM=U there is 1 record per block and the BDW is RDW + 4 ? > ​Technically speaking, with RECFM=U there is not a BDW. There is just a bunch of bytes with no access method imposed interpretation. You must

Re: VTOC Listing utility with PDSE V2 Maxgen Info?

On 7/19/2016 11:35 AM, Dyck, Lionel B. , TRA wrote: Is there a utility available out there that will generate a vtoc listing that includes pdse version info and also maxgen info ? Thanks -- Lionel B. Dyck (TRA Contractor)

FW: Bsam VS Qsam for VB records

The original post had as noted below, two slashes, but the ListServer rejected with: Your message is being returned to you unprocessed because it looks like a LISTSERV command, rather than material intended for distribution to the members of the IBM-MAIN list. Please note that LISTSERV

Re: DFsort and zIIP

There is one potential zIIP performance problem that we learned about as we moved to DB2 V10, which enabled more zIIP processing than was available in V9. The scenario went something like this. zIIP dispatching was not as sophisticated as GP dispatching. If available zIIPs got overloaded, DB2

Re: Default space allocation

Sure - but these are the settings: SPACE PRIMARY(10) SECONDARY(10) DIRECTORY(0) MEASURE(TRK) PRIM_ORG(ALX) NORLSE UNIT NAME(SYSALLDA) So I'm reading that as equivalent to SPACE=(TRK,(10,10)) by default, very different to the 45K tracks

Re: FAMS?

On Mon, 18 Jul 2016 23:05:44 -0400, Steve Smith wrote: >FAMS is a secret interface. IBM may or may not provide the >documentation upon receipt of a signed NDA, and presumably, a "nominal" fee. > I'm aghast! You mean IBM has (finally) started keeping timestamps on (some) files but to see them a

Re: DFsort and zIIP

You are correct that the ZIIP dispatcher is not as sophisticated as the regular dispatcher. If a ZIIP request is made and no ZIIP engine is available the dispatcher will wait a period of time, see ZIIPAWMT parameter in IEAOPTxx, which if none is available by the end of that time, it will

Re: FLASHCOPY QUESTION

Rex, Thanks for the explanation.  So as not to clutter the board I will take this offline. On Tue, 7/19/16, Pommier, Rex wrote: Subject: Re: FLASHCOPY QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Tuesday, July 19,

Re: Bsam VS Qsam for VB records

One more time: if it is on the disk then RECFM=U will "reveal" it. What you got on disk is what you will get with READ. The BDW is not inside QSAM. It is (or is not) on the disk. QSAM *interprets* it. Charles -Original Message- From: IBM Mainframe Discussion List

Re: Bsam VS Qsam for VB records

If you do not understand these things then writing a program with BSAM and/or RECFM=[something clever other than how the dataset was actually written] is not the way to do things -- except perhaps utterly as a learning exercise, not directly justified by an actual business requirement. If you

Re: Bsam VS Qsam for VB records

The problem is not the RDW it’s the BDW with QSAM that’s somewhere inside DFSMS code it doesn't seem RECFM=U would reveal that Joe Reichman Joe Reichman   IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965

Re: Default space allocation

So normally these defaults are used if not specified - Or you do not have DFSMS controlling through Dataclas. You may need to look at using a TSO Transmit/Receive exit to control it better. Since RECEIVE KNOWS how the dataset looked, it will use those values and not ALLOCxx. The default

Bsam VS Qsam for VB records

With RECFM=U, you get the entire physical record presented to you. It has no "length" as far as the system is concerned, it is just an amorphous lump of data. For VB-as-U the first four bytes are the RDW of what was the block, the next four bytes the RDW of the first record, and you can find

AW: Re: DFsort and zIIP

>You are correct that the ZIIP dispatcher is not as sophisticated as the >regular dispatcher. I dare to contradict, not intending to question you expertise. It is my understanding that there is only one dispatcher in MVS. It handles work on the CP WUQ as well as work on the zIIP WUQ. The

Re: Bsam VS Qsam for VB records

The I/O ERROR message should have a CCHHR associated with it. Using the CCHHR you can use AMASPZAP to dump that record or all the records on that track. You can then examine the record in question and determine if the BDW is correct, BDW should equal the block length reported by AMASPZAP, or

Re: RDW corruption

Our output is VB LRECL=31996 BLKSIZE=32000. > Using BUFL=32600 fixes our problem. It looks like your error is too small a BLKSIZE. The maximum BLKSIZE for VB or VBS is 32760, NOT your 32000. If BUFL=32600 then your use of BLKSIZE=32000 is short of the mark. To read ANY VB file, use

Re: VTOC Listing utility with PDSE V2 Maxgen Info?

Catalog Recovery+ from Rocket Software will show this information with its EXPLORE command. It is a recently added feature. EXPLORE gathers dataset information from catalogs, VVDS, VTOC, and for PDS/PDSE, from the dataset itself, and compiles it all into a comprehensive extract file that can be

Re: Bsam VS Qsam for VB records

I've been following the various attempts to help you fix your broken file with a block that has a zero BDW. How that ever happened is a mystery you really ought to engage IBM to help solve, BUT . . . No one else seems to have suggested the "old time" solution to recovering the file data -

Bsam VS Qsam for VB records

If you have confirmed it is on the disk (I assume you mean the BDW and RDW look OK) then it is being clobbered in code. If something is not correct immediately after doing a correct read (so assumption you have coded that correctly) then it is something for IBM. More likely is a program error

Re: Bsam VS Qsam for VB records

On Tue, 19 Jul 2016 13:24:37 -0500, John McKown wrote: > >​AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would >be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on >disk. AMASPZAP can also print the data, in HEX.​ > Rexx now deals with RECFM=U, at

Re: Bsam VS Qsam for VB records

On Tue, 19 Jul 2016 13:24:37 -0500, John McKown wrote: >​AMASPZAP can do the same thing. I don't know DITTO, so I'll guess it would >be easier to use. Personally, I'd hate to use AMASPZAP to correct BDWs on >disk. AMASPZAP can also print the data, in HEX.​ I'm baffled by the notion that the BDWs

Re: Bsam VS Qsam for VB records

I am in the process of running with RECFM=U (under TEST) I see that is shows both BDW and RDW Joe Reichman Joe Reichman   IT Specialist Master Files Division New Carrollton Federal Building, B7-182 OS:CTO:AD:CP:I:IB Flex M,T,Th,F Home office (240) 863 - 3965 Office (240) 613-4350 Cell (917)

Re: Bsam VS Qsam for VB records

On Tue, Jul 19, 2016 at 1:20 PM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > I've been following the various attempts to help you fix your broken file > with a block that has a zero BDW. How that ever happened is a mystery you > really ought to engage IBM to help solve, BUT . .

Re: Bsam VS Qsam for VB records

Thanks for all your help I really understand the problem thing is the file is huge and I don’t know by what factor DFSMS blocked and if the blocking is consistent meaning always by the same factor Joe Reichman Joe Reichman   IT Specialist Master Files Division New Carrollton Federal

Bsam VS Qsam for VB records

DISP=MOD does lead to a way to accidentally (or deliberately, as an exercise) create a "zero" BDW. With RECFM=F/FB/U and some LRECL, specified on the DD, write a lump of data with two bytes of binary zeros. Then with DISP=MOD again, and the "normal" RECFM/LRECL, write a good record. Then try to

Re: Bsam VS Qsam for VB records

On Tue, 19 Jul 2016 16:14:20 -0500, Bill Woodger wrote: >DISP=MOD does lead to a way to accidentally (or deliberately, as an exercise) >create a "zero" BDW. With RECFM=F/FB/U and some LRECL, specified on the DD, >write a lump of data with two bytes of binary zeros. Then with DISP=MOD again,

Re: Bsam VS Qsam for VB records... RDW corruption

2 threads going here. IBM is investigating. IBM has a dump of the bad block. Length is 31373. BDW good in the buffer. Bad when written. Ongoing. Jay Campbell IBM OS Support Section -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of

Re: Bsam VS Qsam for VB records

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Reichman Joseph > Sent: Tuesday, July 19, 2016 11:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Bsam VS Qsam for VB records > > Thanks for all your help I really understand

Re: Bsam VS Qsam for VB records

Or perhaps not, given IBM's reply. And given that IBM is working on it, I would move on to other things and let IBM work on it. The answer is still not BSAM programming or zapping. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On

Bsam VS Qsam for VB records

I previously acknowledged that the data looks OK. No, it is not an attempt to "extend" a block. It is to write a lump of data which, once the "correction" has been done (else the data can't be read as a VB anyway) will appear to be a VB "block", but which will start with binary zeros. Someone

Re: Bsam VS Qsam for VB records

Easy to do by accident: - a valid VB dataset - open and write DISP=MOD,RECFM=FB (erroneous JCL or program with hard-coded DCB) - open and read with explicit RECFM=VB in JCL or program - crash and burn Easy enough to do when hastily cobbling JCL together from different sources. You typically

Re: RDW corruption

IBM has a dump of the bad block. Length is 31373. BDW good in the buffer. Bad when written. Ongoing. Jay Campbell IBM OS Support Section -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf Of Barry Merrill Sent: Tuesday, July 19, 2016 3:12

Re: Bsam VS Qsam for VB records

On Tue, 19 Jul 2016 18:47:50 +, Reichman Joseph wrote: >Thanks for all your help I really understand the problem thing is the file is >huge and I don't know by what factor DFSMS blocked and if the blocking is >consistent meaning always by the same factor "Blocking factor" has little

Re: Bsam VS Qsam for VB records

IMHO the problem here is probably one of misunderstanding or misapplication (Dr. Merrill's pointing out of a JCL oddity, for example) and any zapping or BSAM programming is likely to turn it into a real problem of corrupted data on disk. The questions should be "how do we correct our error and

Re: FAMS?

The first rule of FAMS is you don't talk about FAMS. :-) I don't think that denying its existence is part of the contract, but I can't say anything else about it. sas On Tue, Jul 19, 2016 at 12:05 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 18 Jul