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

[Campbell Jay]

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 retired mainframer
Sent: Tuesday, July 19, 2016 7:44 PM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 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

Since you already posted that you have no data class active and a null SMS 
configuration, it is unlikely that DFSMS has any effect on block size.  If the 
data was written with QSAM, then QSAM performed the blocking (per the DCB 
parameters specified on the DD statement used to identify the output dataset) 
as well as constructing the RDWs and BDW.

You also posted that the problem was with the BDW and not the RDWs.  What do 
you think the problem is?  How did you determine that?  Can you post the first 
8 bytes of the block in question (BDW+RDW, no proprietary data)?

--
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: Bsam VS Qsam for VB records

[retired mainframer]

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

Since you already posted that you have no data class active and a null SMS 
configuration, it is unlikely that DFSMS has any effect on block size.  If the 
data was written with QSAM, then QSAM performed the blocking (per the DCB 
parameters specified on the DD statement used to identify the output dataset) 
as well as constructing the RDWs and BDW.

You also posted that the problem was with the BDW and not the RDWs.  What do 
you think the problem is?  How did you determine that?  Can you post the first 
8 bytes of the block in question (BDW+RDW, no proprietary data)?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

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 end up with EBCDIC characters where the RDW is supposed to be.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 19, 2016 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 had commented that they didn't know how a BDW with zero length could be 
created. It wasn't done in this case, but here's a way it could be done. Not by 
*really* writing a block with a zero BDW, but sticking in a lump of data which 
will later *look like* a block (very superficially) but will presumably cause 
something weird to ensue.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bsam VS Qsam for VB records

[Bill Woodger]

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 had commented that they didn't know how a BDW with zero length could be 
created. It wasn't done in this case, but here's a way it could be done. Not by 
*really* writing a block with a zero BDW, but sticking in a lump of data which 
will later *look like* a block (very superficially) but will presumably cause 
something weird to ensue.

Requires deliberation, or accidental use of wrong LRECL/RECFM (other than 
expected) with DISP=MOD and then the "fix" (correctl LRECL/RECFM) with DISP=MOD 
and add at least one more record). A variation of the "corrupt a loadlib by 
writing a source to it".

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Paul Gilmartin]

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, 
>and the "normal" RECFM/LRECL, write a good record. Then try to read the data.
>
I don't believe DISP=MOD will ever extend an existing block if that's what
you were expecting; it will always start a new block.

Tricky to do accidentally, but sometimes you find someone who errs, and then 
tries to "correct" without realising the full consequences.
>
That sort of thing should always be done with a copy of the data.

But I believe the OP has explained that a dump of the disk file showed
that BDW was valid but corrupted on input by ?SAM.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bsam VS Qsam for VB records

[Bill Woodger]

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 read the data. 
Tricky to do accidentally, but sometimes you find someone who errs, and then 
tries to "correct" without realising the full consequences.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

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 Behalf 
Of Charles Mills
Sent: Tuesday, July 19, 2016 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 read the data?" and 
not "how do we zap the data to make it fit our model of correct?"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FAMS?

[Steve Smith]

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 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 customer must sign an NDS and pay for
> the privilege (or use NFS)?  What century does IBM think this is, anyway!?
>
> Are you allowed even to tell me it's secret?  I suppose that explains the
> conspicuous silence here of IBM employees.  I wonder whether the
> meager information will be removed from future editions of the NFS
> description.  And from the APARs.
>
>
> On Tue, 19 Jul 2016 07:39:00 -0400, Ken Smith wrote:
>
> >You probably knew this but if you can run under ISPF, batch or
> interactive,
> >use LMMSTATS.
> >
> I believe not.  As an experiment, I created a couple PDS members with
> IEBGENER, no ISPF involved.  NFS shows timestamps consistent with
> those in the job log and differing by 0.1995 seconds which I assume is
> job step overhead.  ISPF member list shows no stats whatever for those
> members.  Would LMMSTATS in a program show me any different?
> If you believe so, I'll try an experiment, but I'm skeptical.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

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 read the data?" and 
not "how do we zap the data to make it fit our model of correct?"

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Blaicher, Christopher Y.
Sent: Tuesday, July 19, 2016 12:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 if an RDW is 
incorrect.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Tom Marchant]

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 meaning for a VB file. The blocksize need not be a 
multiple of lrecl, and in most VB data sets the records are of varying lengths. 
As a consequence, the size of the blocks will usually be of varying lengths. If 
the data set was created with one block size and was subsequently written to 
(MOD) by a program that specified a different blocksize, the DSCB would have 
been updated to reflect the more recent blocksize, which may not be enough to 
read existing blocks on the data set.

This is largely guesswork and supposition, based upon minimal information 
provided.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDW corruption

[Campbell Jay]

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 PM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 RECFM=VB,LRECL=32756,BLKSIZE=32760.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Monday, July 18, 2016 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RDW corruption

I know my boss assigned me this problem As an aside if I register my IRS e-mail 
on IBM-Main is there a way not get every e-mail I don't mind it in my personel 
e-mail But I have a lot of other stuff on my irs.gov e-mail



> On Jul 18, 2016, at 3:21 PM, Campbell Jay 
wrote:
> 
> Have a current SR open with IBM...   57827 082 000
> Our output is VB  LRECL=31996  BLKSIZE=32000.
> Using BUFL=32600 fixes our problem.
> SR was opened to find out why that works.
> 
> Jay Campbell
> IBM OS Support Section
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] 
> On Behalf Of Joe Reichman
> Sent: Monday, July 18, 2016 3:17 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: RDW corruption
> 
> Hi,
> 
> 
> 
> I have a program that generates a corrupted RDW The file is a VB file. 
> I coded a synad exit but it didn't take (it was never given control)
> 
> 
> 
> When I go into ISPF and I do a max down I can see where ISPF can't 
> read
the next record as I get "* * * I/O error detected, i/o terminated * * *"
> 
> 
> 
> As there anything/exit I can do to capture this the program seems to go to
> EOJ  
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: VTOC Listing utility with PDSE V2 Maxgen Info?

[Steve Smith]

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
reported on in many ways.

Disclaimer: I work for Rocket, and as a matter of fact, wrote the PDSE
support.  I'm biased, but I say it's pretty good :-).

That said, I agree that the lack of PDSE information in catalogs and VTOCs
is unfortunate, as is the secrecy about the internal organization.

sas

On Tue, Jul 19, 2016 at 11:49 AM, Tom Conley 
wrote:

> 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)
>> Mainframe Systems Programmer
>> Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
>> VA OI Service Delivery & Engineering
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
> Nope, it ain't in the VTOC.  The PDSE version and maxgen info is embedded
> in the dataset, so you have to open it to determine the version.  My
> requirement to externalize the version indicator to the VTOC or catalog was
> DOA.
>
> Regards,
> Tom Conley
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDW corruption

[Barry Merrill]

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 RECFM=VB,LRECL=32756,BLKSIZE=32760.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Monday, July 18, 2016 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RDW corruption

I know my boss assigned me this problem As an aside if I register my IRS
e-mail on IBM-Main is there a way not get every e-mail I don't mind it in my
personel e-mail But I have a lot of other stuff on my irs.gov e-mail



> On Jul 18, 2016, at 3:21 PM, Campbell Jay 
wrote:
> 
> Have a current SR open with IBM...   57827 082 000
> Our output is VB  LRECL=31996  BLKSIZE=32000.
> Using BUFL=32600 fixes our problem.
> SR was opened to find out why that works.
> 
> Jay Campbell
> IBM OS Support Section
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] 
> On Behalf Of Joe Reichman
> Sent: Monday, July 18, 2016 3:17 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: RDW corruption
> 
> Hi,
> 
> 
> 
> I have a program that generates a corrupted RDW The file is a VB file. 
> I coded a synad exit but it didn't take (it was never given control)
> 
> 
> 
> When I go into ISPF and I do a max down I can see where ISPF can't read
the next record as I get "* * * I/O error detected, i/o terminated * * *"
> 
> 
> 
> As there anything/exit I can do to capture this the program seems to go to
> EOJ  
> 
> 
> --
> 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: Bsam VS Qsam for VB records

[Blaicher, Christopher Y.]

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 if an RDW is 
incorrect.

The bigger question is what software created the file?  You are stuck trying to 
read it, but what created it badly?

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 2:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 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: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 2:25 PM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 . . .
>
> No one else seems to have suggested the "old time" solution to
> recovering the file data - does your shop license DITTO?  DITTO can
> access AND MODIFY disk blocks directly, without programming.  You can
> display blocks in the file until you get to the one you want and then
> update the BDW in that block based on the block length DITTO tells you it 
> read.
>
> If your shop does license DITTO the "disk modify" function is very
> likely security protected (or darn well ought to be, since it can
> really wreck things up if misused or abused), so you may need to
> interface with your security team to get appropriate authority.
>
> There is a "batch" interface to DITTO as well as TSO capability, so
> you could set it up as a batch job or try to accomplish it on the fly
> from TSO.  If it were me I would also try to make sure I have at least
> one safe volume backup of the disk containing that file in case things
> get messed up.  Caveat emptor.
>
> HTH
>
> Peter
>

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



--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

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 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: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 2:25 PM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 . . .
>
> No one else seems to have suggested the "old time" solution to 
> recovering the file data - does your shop license DITTO?  DITTO can 
> access AND MODIFY disk blocks directly, without programming.  You can 
> display blocks in the file until you get to the one you want and then 
> update the BDW in that block based on the block length DITTO tells you it 
> read.
>
> If your shop does license DITTO the "disk modify" function is very 
> likely security protected (or darn well ought to be, since it can 
> really wreck things up if misused or abused), so you may need to 
> interface with your security team to get appropriate authority.
>
> There is a "batch" interface to DITTO as well as TSO capability, so 
> you could set it up as a batch job or try to accomplish it on the fly 
> from TSO.  If it were me I would also try to make sure I have at least 
> one safe volume backup of the disk containing that file in case things 
> get messed up.  Caveat emptor.
>
> HTH
>
> Peter
>

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



--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Tom Marchant]

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 on disk are wrong, and can be 
corrected. Didn't Joe say that all I/O to the file has been using QSAM? If that 
is true, the BDW is the length of the block and to change it will likely cause 
errors.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Paul Gilmartin]

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 least as of 2.2.  Don't know about 2.1.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bsam VS Qsam for VB records

[Bill Woodger]

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 after the read and 
before you notice it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

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 . . .
>
> No one else seems to have suggested the "old time" solution to recovering
> the file data - does your shop license DITTO?  DITTO can access AND MODIFY
> disk blocks directly, without programming.  You can display blocks in the
> file until you get to the one you want and then update the BDW in that
> block based on the block length DITTO tells you it read.
>
> If your shop does license DITTO the "disk modify" function is very likely
> security protected (or darn well ought to be, since it can really wreck
> things up if misused or abused), so you may need to interface with your
> security team to get appropriate authority.
>
> There is a "batch" interface to DITTO as well as TSO capability, so you
> could set it up as a batch job or try to accomplish it on the fly from
> TSO.  If it were me I would also try to make sure I have at least one safe
> volume backup of the disk containing that file in case things get messed
> up.  Caveat emptor.
>
> HTH
>
> Peter
>

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



-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

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: Bsam VS Qsam for VB records

[Reichman Joseph]

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) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, July 19, 2016 2:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 - does your shop license DITTO?  DITTO can access AND MODIFY disk 
blocks directly, without programming.  You can display blocks in the file until 
you get to the one you want and then update the BDW in that block based on the 
block length DITTO tells you it read.

If your shop does license DITTO the "disk modify" function is very likely 
security protected (or darn well ought to be, since it can really wreck things 
up if misused or abused), so you may need to interface with your security team 
to get appropriate authority.

There is a "batch" interface to DITTO as well as TSO capability, so you could 
set it up as a batch job or try to accomplish it on the fly from TSO.  If it 
were me I would also try to make sure I have at least one safe volume backup of 
the disk containing that file in case things get messed up.  Caveat emptor.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 19, 2016 1:13 PM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 the start of the 
next record (next RDW) though some simple maths (adding).


On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph  wrote:
> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
> 
> Joe Reichman

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

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: Bsam VS Qsam for VB records

[Farley, Peter x23353]

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 - does your shop license DITTO?  DITTO can access AND MODIFY disk 
blocks directly, without programming.  You can display blocks in the file until 
you get to the one you want and then update the BDW in that block based on the 
block length DITTO tells you it read.

If your shop does license DITTO the "disk modify" function is very likely 
security protected (or darn well ought to be, since it can really wreck things 
up if misused or abused), so you may need to interface with your security team 
to get appropriate authority.

There is a "batch" interface to DITTO as well as TSO capability, so you could 
set it up as a batch job or try to accomplish it on the fly from TSO.  If it 
were me I would also try to make sure I have at least one safe volume backup of 
the disk containing that file in case things get messed up.  Caveat emptor.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 19, 2016 1:13 PM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 the start of the 
next record (next RDW) though some simple maths (adding).


On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph  wrote:
> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
> 
> Joe Reichman

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

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: Bsam VS Qsam for VB records

[Charles Mills]

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 want to see what is actually on the disk there are utilities that will 
show you that. I would guess IDCAMS DUMP with RECFM=U would be a good start, 
although I do not recall that I have ever actually done that, so I might be 
missing something. People have also suggested CBT tools IIRC. 

Even if you want to write a BSAM program for your own education or amusement, I 
would start with an existing dump utility so you can see what you will read 
with BSAM.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, July 19, 2016 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: DFsort and zIIP

[Peter Hunkeler]

>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 reason for the wait time mechanism 
is explained in Init Ref, IEAOPTxx.


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Default space allocation

[Lizette Koehler]

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 value for SPACE is a primary size equal to the size of the incoming 
data and a secondary size of approximately 25 percent of the primary.

So the original dataset probably was allocated with 45,000 tracks.  And so 
RECEIVE honored the size.  Unless you specify the difference on the RECEIVE 
command. 


The user can include RLSE on the Receive

RELEASE
specifies unused space to be released when the receive operation is 
complete.
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ikjc500/ikj2l2_RECEIVE_command_prompt_parameters1.htm

(watch the wrap) 

how are they doing the RECEIVE?  Interactively or via Batch Jobs?




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 8:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 we saw yesterday. We have no EXITxx members.
> 
> 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 16:12
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Default space allocation
> 
> -- This email has reached the Bank via an external source --
> 
> 
> 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)
> Space attributes
> TIOT size
> Handling allocation requests
> Catalog error policies.
> 
> These installation defaults for handling allocation requests can be overridden
> by installation exit routines specified in the EXITxx parmlib member. For
> information about the allocation exit routines, see z/OS MVS Installation
> Exits. After IPL, use the SETALLOC command to change any of the defaults
> (except for 2DGT_EXPDT).
> 
> 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 8:07 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: 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: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Default space allocation
> >
> > -- This email has reached the Bank via an external source --
> >
> >
> > 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: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: 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 is that people using XMIT/RECEIVE seem
> > > to allocate enormous datasets - one yesterday was 45K tracks, 1%
> > > used, which used up nearly all the free space on the volume, and
> > > caused another job to fail as it was unable to get the space it needed.
> > >
> > > I vaguely remember reading somewhere about default space allocation
> > > being something along the lines of "whatever space remains on the volume".
> > >
> > > Does this ring any bells with anyone, or am I just dreaming it? Can
> > > these parameters be changed, and if so, where? I've been hunting but
> > > can't track it down.
> > >
> > > Many thanks,
> > >
> > > --
> > > Andy Styles
> > > z/Series Systems Programmer

--
For IBM-MAIN subscribe / signoff / 

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

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 
Office (240) 613-4350
Cell (917) 748-9693
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Bill Woodger
Sent: Tuesday, July 19, 2016 1:13 PM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 the start of the 
next record (next RDW) though some simple maths (adding).


On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph  wrote:
> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
> 
> Joe Reichman

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

Bsam VS Qsam for VB records

[Bill Woodger]

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 the start of the 
next record (next RDW) though some simple maths (adding).


On Tuesday, 19 July 2016 17:15:53 UTC+2, Reichman Joseph  wrote:
> With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?
> 
> Joe Reichman

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

FW: Bsam VS Qsam for VB records

[Barry Merrill]

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 commands must always be sent to 
the LISTSERV address. If it was indeed  a command you were attempting to issue, 
then send it again to lists...@listserv.ua.edu for execution. Otherwise, please 
accept our apologies  and try to rewrite the message  with a slightly different 
wording -  for instance, change  the first word of  the message, enclose  it in 
quotation marks, insert a line of dashes at the beginning of your message, etc.


 THIS-IS-SLASH-SLASH  EXEC SAS
 THIS-IS-SLASH-SLASH  DATAFILE DD DSN=WHATEVER,DISP=SHR
 THIS-IS-SLASH-SLASH  SYSIN DD *
  DATA _NULL_;
  INFILE DATAFILE RECFM=U BLKSIZE=32760;
  INPUT;
  LIST;
  IF _N_ GT 10 THEN STOP;

will print a nice hex dump of each of the first 10 block.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 determine the 
number of bytes actually read by taking the number of bytes you requested to be 
read (the BLKSIZE basically) and subtract the CCW residual count to determine 
the number of bytes actually read. Luckily, IBM supplies an example.
ref:
http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idad400/len99.htm
​



>
> 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: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] 
> On Behalf Of John McKown
> Sent: Tuesday, July 19, 2016 10:57 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Bsam VS Qsam for VB records
>
> On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G < 
> curtis@austin.utexas.edu
> > 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 the physical blocks, why not read 
> > with QSAM specifying RECFM=U?
> >
>
> ​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then 
> use QSAM and "have fun".​ Or not, as the case may be.
>
>
>
> >
> > --
> > Pew, Curtis G
> > curtis@austin.utexas.edu
> > ITS Systems/Core/Administrative Services
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
>
>
>
> --
> "Worry was nothing more than paying interest on a loan that a man may 
> never borrow"
>
> From: "Quest for the White Wind" by Alan Black
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO 

Re: DFsort and zIIP

[Blaicher, Christopher Y.]

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 dispatch it on a GP 
engine rather than a ZIIP engine.  This creates ZIIP_ON_CP time in your SMF 
data.

Because of this wait time, especially if it is large, you can elongate the 
elapsed time of whatever is running trying to use the ZIIP engines.  By default 
that time is 3.2ms.

The trick is to know when you are getting held up too much by ZIIP dispatch and 
skip trying to use it.

I cannot remember right now the ROT for ZIIP percent active, but you cannot 
redline a ZIIP engine the way you can a GP engine.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, July 19, 2016 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 
performance could be severely impacted by a thrashing condition. We actually 
added another zIIP engine in advance of the V10 cutover.

I have no idea what might have happened otherwise. Was a bullet really dodged 
or merely imagined?  I don't believe that this issue had anything specifically 
to do with SORT.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, July 19, 2016 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: 19 July, 2016 16:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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
>>DFSORT remains a prominent component of our customers' batch
>>workloads.  However,  the added controls that would need to be
>>implemented in order to maintain our high standards for performance,
>>reliability and system integrity are not justified in view of
>>estimations that there is a low offload potential and the value to
>>clients may be marginal.[snip]
>
>I seem to remember that SyncSort offers an Add-On package that allows
>certain SyncSort processing to be offloaded to zIIPs. The above
>statement suggest that SyncSort's perfocmance is suffering from using
>zIIPs (simplified and exagerated, I know).

I understood "there is a low offload potential and the value to clients may be 
marginal" as meaning that there would not be much benefit in using zIIP. Not 
that it would be worse.

--
Tom Marchant


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

Re: FLASHCOPY QUESTION

[esmie moo]

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, 2016, 9:14 AM
 
 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, one on each volume.  The
 difference is what's going on in the back-end disk
 array.  
 
 In example 1, you
 have FCNC which from the back-end array, the only thing that
 happens is that a set of pointers (a track table) gets built
 but no data gets copied.  The only time data gets
 physically copied from source to target is when either the
 source or target data track is changed.  If the source data
 gets changed, a copy of the track gets put on the target
 before the source is updated.  In case of the target
 getting updated, the changed data is written to the
 target.  If, for example, in this scenario you are doing
 this copy with the intent of doing a DUMP of the target to
 tape, most of the data for the DUMP is actually coming from
 the SOURCE, because unless the data changed, the SOURCE is
 the only place the physical data resides.
 
 In example 2, FCINCREMENTAL
 does NOT mean do an incremental backup.  FC/DFDSS does a
 full background copy of all the data from the source to the
 target.  It still looks like it ran really fast to z/OS
 because as soon as the track table is built on the array,
 the array signals to z/OS the backup is done.  However, the
 back end is still copying all the data to the target.  Why
 use FCINCR then?  Under normal FC processing, if you
 don't use FCNC, the background copy is initiated, and
 then once all the data is copied to the target, the
 relationship between source and target is terminated, and
 the 2 volumes are now stand-alone.  If FCINCR is specified
 like in your example, the relationship remains in place with
 the track table now indicating which tracks have changed
 since the FC ran.  If you then come along and run another
 COPY command with the same source and target, the array uses
 the track table and only updates the changed tracks, thus
 (potentially) significantly reducing the load on the array
 if there wasn't much change in the data.  
 
 So in short, FCNC only copies
 changed tracks from the source to the target, but FCINCR
 forces a full back-end copy of all the data from source to
 target on initial setup.  Note in the DFDSS manual is that
 FCNC and FCINCR are mutually exclusive.
 
 HTH,
 
 Rex
 
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of esmie moo
 Sent: Tuesday, July
 19, 2016 6:59 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: 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 understanding is that an
 Incremental copy is being performed because FCNOCPY is
 specified.  My understanding of Incremental is that only
 the updated tracks are copied over to the target volume. 
 Please correct me if I am wrong.
 
 Also, I have this example.  Is this for a FULL
 FlashCopy of a volume?  However, I am confused that the
 FCINCREMENTAL parm is specified which would indicate that
 this is an incremental copy
 
 COPY FULL INDYNAM(ZFSZ01) OUTDYNAM(ZWATP0) ALLE
 ALLD(*) -           
 FASTREPLICATION(REQUIRED) FCINCREMENTAL
 DUMPCONDITIONING ADMIN PURGE   
 
 Could someone clear up this
 for me?
 
 Thanks in
 advance.
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions, send email to lists...@listserv.ua.edu
 with the message: INFO IBM-MAIN
 
 
 The information contained in
 this message is confidential, protected from disclosure and
 may be legally privileged.  If the reader of this message
 is not the intended recipient or an employee or agent
 responsible for delivering this message to the intended
 recipient, you are hereby notified that any disclosure,
 distribution, copying, or any action taken or action omitted
 in reliance on it, is strictly prohibited and may be
 unlawful.  If you have received this communication in
 error, please notify us immediately by replying to this
 message and destroy the material in its entirety, whether in
 electronic or hard copy format.  Thank you.
 
 
 --
 For IBM-MAIN subscribe / signoff / archive
 access instructions,
 send email to 

Re: FAMS?

[Paul Gilmartin]

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 customer must sign an NDS and pay for
the privilege (or use NFS)?  What century does IBM think this is, anyway!?

Are you allowed even to tell me it's secret?  I suppose that explains the
conspicuous silence here of IBM employees.  I wonder whether the
meager information will be removed from future editions of the NFS
description.  And from the APARs.


On Tue, 19 Jul 2016 07:39:00 -0400, Ken Smith wrote:

>You probably knew this but if you can run under ISPF, batch or interactive,
>use LMMSTATS.
>
I believe not.  As an experiment, I created a couple PDS members with
IEBGENER, no ISPF involved.  NFS shows timestamps consistent with
those in the job log and differing by 0.1995 seconds which I assume is
job step overhead.  ISPF member list shows no stats whatever for those
members.  Would LMMSTATS in a program show me any different?
If you believe so, I'll try an experiment, but I'm skeptical.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Default space allocation

[Styles, Andy (SD EP zPlatform)]

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 we saw yesterday. We have no EXITxx members. 

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 16:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Default space allocation

-- This email has reached the Bank via an external source --
 

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)
Space attributes
TIOT size
Handling allocation requests
Catalog error policies.

These installation defaults for handling allocation requests can be overridden 
by installation exit routines specified in the EXITxx parmlib member. For 
information about the allocation exit routines, see z/OS MVS Installation 
Exits. After IPL, use the SETALLOC command to change any of the defaults 
(except for 2DGT_EXPDT).

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 8:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Default space allocation
> 
> -- This email has reached the Bank via an external source --
> 
> 
> 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: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: 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 is that people using XMIT/RECEIVE seem 
> > to allocate enormous datasets - one yesterday was 45K tracks, 1% 
> > used, which used up nearly all the free space on the volume, and 
> > caused another job to fail as it was unable to get the space it needed.
> >
> > I vaguely remember reading somewhere about default space allocation 
> > being something along the lines of "whatever space remains on the volume".
> >
> > Does this ring any bells with anyone, or am I just dreaming it? Can 
> > these parameters be changed, and if so, where? I've been hunting but 
> > can't track it down.
> >
> > Many thanks,
> >
> > --
> > Andy Styles
> > z/Series Systems Programmer

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. 
Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England 
and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered 
Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. 
Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: 
Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. 
Telephone: 0345 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Cheltenham & Gloucester plc is authorised and regulated by the Financial 
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings 
is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, 

Re: VTOC Listing utility with PDSE V2 Maxgen Info?

[Tom Conley]

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)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Nope, it ain't in the VTOC.  The PDSE version and maxgen info is 
embedded in the dataset, so you have to open it to determine the 
version.  My requirement to externalize the version indicator to the 
VTOC or catalog was DOA.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFsort and zIIP

[Jesse 1 Robinson]

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 
performance could be severely impacted by a thrashing condition. We actually 
added another zIIP engine in advance of the V10 cutover. 

I have no idea what might have happened otherwise. Was a bullet really dodged 
or merely imagined?  I don't believe that this issue had anything specifically 
to do with SORT. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, July 19, 2016 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: 19 July, 2016 16:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 
>>DFSORT remains a prominent component of our customers' batch 
>>workloads.  However,  the added controls that would need to be 
>>implemented in order to maintain our high standards for performance, 
>>reliability and system integrity are not justified in view of 
>>estimations that there is a low offload potential and the value to 
>>clients may be marginal.[snip]
>
>I seem to remember that SyncSort offers an Add-On package that allows 
>certain SyncSort processing to be offloaded to zIIPs. The above 
>statement suggest that SyncSort's perfocmance is suffering from using 
>zIIPs (simplified and exagerated, I know).

I understood "there is a low offload potential and the value to clients may be 
marginal" as meaning that there would not be much benefit in using zIIP. Not 
that it would be worse.

--
Tom Marchant


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

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 EXCP by a 
competent programmer "emulating" well-formed RECFM=VB, then yes, you will get a 
BDW followed by one or more RDW+record, with BDW = sum of all RDWs plus 4. If 
something else was written you will get that.

>From QSAM's point of view, yes RECFM=U is one record per block, or, depending 
>on which explanation you choose, no records and only blocks.

Whether whoever wrote it viewed things differently is an unanswerable question. 
Whether they were that competent programmer is an unanswerable question. 
Whether you choose to view things differently is its own question. You might 
choose to "deblock" the data in any way you chose. You might write a "dump" 
program that dealt with the data one byte at a time, with no other structure.

It is still hard for me to picture the question to which BSAM is the answer. In 
1975, yes, I wrote a marvelous "database" system which used BSAM under the 
covers. In 2016 it's hard for me to picture.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

With RECFM=U there is 1 record per block and the BDW is RDW + 4 ?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

VTOC Listing utility with PDSE V2 Maxgen Info?

[Dyck, Lionel B. (TRA)]

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 Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

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
determine the number of bytes actually read by taking the number of bytes
you requested to be read (the BLKSIZE basically) and subtract the CCW
residual count to determine the number of bytes actually read. Luckily, IBM
supplies an example.
ref:
http://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idad400/len99.htm
​



>
> 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: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On
> Behalf Of John McKown
> Sent: Tuesday, July 19, 2016 10:57 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: Bsam VS Qsam for VB records
>
> On Tue, Jul 19, 2016 at 9:54 AM, Pew, Curtis G <
> curtis@austin.utexas.edu
> > 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 the physical blocks, why not read
> > with QSAM specifying RECFM=U?
> >
>
> ​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use
> QSAM and "have fun".​ Or not, as the case may be.
>
>
>
> >
> > --
> > Pew, Curtis G
> > curtis@austin.utexas.edu
> > ITS Systems/Core/Administrative Services
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> "Worry was nothing more than paying interest on a loan that a man may
> never borrow"
>
> From: "Quest for the White Wind" by Alan Black
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

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: Bsam VS Qsam for VB records

[Jesse 1 Robinson]

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 in 
full-screen mode. It requires no programming. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Reichman Joseph
Sent: Tuesday, July 19, 2016 8:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:57 AM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 the physical blocks, why not read 
> with QSAM specifying RECFM=U?
>

​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM 
and "have fun".​ Or not, as the case may be.



>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Mike Schwab]

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 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: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On 
> Behalf Of John McKown
> Sent: Tuesday, July 19, 2016 10:57 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: 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 the physical blocks, why not read
>> with QSAM specifying RECFM=U?
>>
>
> That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM 
> and "have fun". Or not, as the case may be.
>
>
>
>>
>> --
>> Pew, Curtis G
>> curtis@austin.utexas.edu
>> ITS Systems/Core/Administrative Services
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
>
> --
> "Worry was nothing more than paying interest on a loan that a man may never 
> borrow"
>
> From: "Quest for the White Wind" by Alan Black
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

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  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:57 AM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 the physical blocks, why not read 
> with QSAM specifying RECFM=U?
>

​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use QSAM 
and "have fun".​ Or not, as the case may be.



>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Default space allocation

[Lizette Koehler]

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)
Space attributes
TIOT size
Handling allocation requests
Catalog error policies.

These installation defaults for handling allocation requests can be overridden 
by installation exit routines specified in the EXITxx parmlib member. For 
information about the allocation exit routines, see z/OS MVS Installation 
Exits. After IPL, use the SETALLOC command to change any of the defaults 
(except for 2DGT_EXPDT).

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 8:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Default space allocation
> 
> -- This email has reached the Bank via an external source --
> 
> 
> 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: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: 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 is that people using XMIT/RECEIVE seem
> > to allocate enormous datasets - one yesterday was 45K tracks, 1% used,
> > which used up nearly all the free space on the volume, and caused
> > another job to fail as it was unable to get the space it needed.
> >
> > I vaguely remember reading somewhere about default space allocation
> > being something along the lines of "whatever space remains on the volume".
> >
> > Does this ring any bells with anyone, or am I just dreaming it? Can
> > these parameters be changed, and if so, where? I've been hunting but
> > can't track it down.
> >
> > Many thanks,
> >
> > --
> > Andy Styles
> > z/Series Systems Programmer

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Default space allocation

[Styles, Andy (SD EP zPlatform)]

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: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Default space allocation

-- This email has reached the Bank via an external source --
 

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 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 is that people using XMIT/RECEIVE seem to 
> allocate enormous datasets - one yesterday was 45K tracks, 1% used, which 
> used up nearly all the free space on the volume, and caused another job to 
> fail as it was unable to get the space it needed.
>
> I vaguely remember reading somewhere about default space allocation being 
> something along the lines of "whatever space remains on the volume".
>
> Does this ring any bells with anyone, or am I just dreaming it? Can these 
> parameters be changed, and if so, where? I've been hunting but can't track it 
> down.
>
> Many thanks,
>
> --
> Andy Styles
> z/Series Systems Programmer
>
>
> Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 
> 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. 
> Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 
> 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. 
> Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
> Registered in Scotland no. SC327000. Telephone: 03457 801 801. 
> Cheltenham & Gloucester plc. Registered Office: Barnett Way, 
> Gloucester GL4 3RL. Registered in England and Wales 2299428. 
> Telephone: 0345 603 1637
>
> Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
> Regulation Authority and regulated by the Financial Conduct Authority and 
> Prudential Regulation Authority.
>
> Cheltenham & Gloucester plc is authorised and regulated by the Financial 
> Conduct Authority.
>
> Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester 
> Savings is a division of Lloyds Bank plc.
>
> HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
> Scotland no. SC218813.
>
> This e-mail (including any attachments) is private and confidential and may 
> contain privileged material. If you have received this e-mail in error, 
> please notify the sender and delete it (including any attachments) 
> immediately. You must not copy, distribute, disclose or use any of the 
> information in it or any attachments. Telephone calls may be monitored or 
> recorded.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. 
Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England 
and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered 
Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. 
Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: 
Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. 
Telephone: 0345 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Cheltenham & Gloucester plc is authorised and regulated by the Financial 
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings 
is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.

Re: Default space allocation

[Styles, Andy (SD EP zPlatform)]

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: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Default space allocation

-- This email has reached the Bank via an external source --
 

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: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 is that people using XMIT/RECEIVE seem 
> to allocate enormous datasets - one yesterday was 45K tracks, 1% used, 
> which used up nearly all the free space on the volume, and caused 
> another job to fail as it was unable to get the space it needed.
> 
> I vaguely remember reading somewhere about default space allocation 
> being something along the lines of "whatever space remains on the volume".
> 
> Does this ring any bells with anyone, or am I just dreaming it? Can 
> these parameters be changed, and if so, where? I've been hunting but 
> can't track it down.
> 
> Many thanks,
> 
> --
> Andy Styles
> z/Series Systems Programmer

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. 
Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England 
and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered 
Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. 
Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: 
Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. 
Telephone: 0345 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Cheltenham & Gloucester plc is authorised and regulated by the Financial 
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings 
is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

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 BDW was as
> the system takes care
>
> of that. I am assuming if you use BSAM you decide the number of records
> that make up a block and each record is proceeded by a RDW and the block
> which you write has cumulative BDW.
>
> Am I on the right track ?
>

​Yes, you are; BDW == sum(individual RDWs) + 4.​



>
> Joe Reichman
>


-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Exclusive ENQ on a TSO logon procedure

[Peter Hunkeler]

​>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 description of SCHEDxx explicitly mentions that JES2 is 
honouring the DSI/NODSI setting when doing its dynalloc.




>Also, if I remember correctly, when you specify NODSI, what actually 
>happens is that the data set _is_ enqueued when you do the START command, 
>but soon after (during the processing of the PPT entry?) the initiator will 
>release the ENQ. That is, if you have an STC defined with NODSI, but 
>something else has a DSN in the JCL "tied up" with a DISP=OLD type 
>allocation, then the START command will still get A "waiting on data sets" 
>message and will not be started until the DSN is available. 
​ 



Again true, but I did not mention it because (in normal situations) JES2's ENQs 
would have been released before any other job or TSO user can be started. Of 
course, if you ABEND JES2 and restart is, the situation is different. And it 
also does not help with $ADD PROC.


--
Peter Hunkeler
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

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 the physical blocks, why not read with
> QSAM specifying RECFM=U?
>

​That is what I do, with: RECFM=U,LRECL=32756,BLKSIZE=32760 and then use
QSAM and "have fun".​ Or not, as the case may be.



>
> --
> Pew, Curtis G
> curtis@austin.utexas.edu
> ITS Systems/Core/Administrative Services
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

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: Bsam VS Qsam for VB records

[Pew, Curtis G]

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
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Default space allocation

[Lizette Koehler]

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: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 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 is that people using XMIT/RECEIVE seem to
> allocate enormous datasets - one yesterday was 45K tracks, 1% used, which used
> up nearly all the free space on the volume, and caused another job to fail as
> it was unable to get the space it needed.
> 
> I vaguely remember reading somewhere about default space allocation being
> something along the lines of "whatever space remains on the volume".
> 
> Does this ring any bells with anyone, or am I just dreaming it? Can these
> parameters be changed, and if so, where? I've been hunting but can't track it
> down.
> 
> Many thanks,
> 
> --
> Andy Styles
> z/Series Systems Programmer

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Charles Mills]

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 is screwed up with BSAM -- well, get out the old 
debugging hat, and good luck!

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, July 19, 2016 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 19 July, 2016 16:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

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
TOD M - F  7:30 am  - 4:00 pm


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, July 19, 2016 10:37 AM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 19 July, 2016 16:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFsort and zIIP

[Vernooij, CP (ITOPT1) - KLM]

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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: 19 July, 2016 16:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 DFSORT remains a
>>prominent component of our customers' batch workloads.  However,  the
>>added controls that would need to be implemented in order to maintain our
>>high standards for performance, reliability and system integrity are not
>>justified in view of estimations that there is a low offload potential and 
>>the value to clients may be marginal.[snip]
>
>I seem to remember that SyncSort offers an Add-On package that allows 
>certain SyncSort processing to be offloaded to zIIPs. The above statement 
>suggest that SyncSort's perfocmance is suffering from using zIIPs (simplified 
>and exagerated, I know).

I understood "there is a low offload potential and the value to clients may be 
marginal" as meaning that there would not be much benefit in using zIIP. Not 
that it would be worse.

-- 
Tom Marchant

--
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: Default space allocation

[Mike Schwab]

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 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 is that people using XMIT/RECEIVE seem to 
> allocate enormous datasets - one yesterday was 45K tracks, 1% used, which 
> used up nearly all the free space on the volume, and caused another job to 
> fail as it was unable to get the space it needed.
>
> I vaguely remember reading somewhere about default space allocation being 
> something along the lines of "whatever space remains on the volume".
>
> Does this ring any bells with anyone, or am I just dreaming it? Can these 
> parameters be changed, and if so, where? I've been hunting but can't track it 
> down.
>
> Many thanks,
>
> --
> Andy Styles
> z/Series Systems Programmer
>
>
> Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
> Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank 
> plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in 
> England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. 
> Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. 
> SC327000. Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered 
> Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 
> 2299428. Telephone: 0345 603 1637
>
> Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
> Regulation Authority and regulated by the Financial Conduct Authority and 
> Prudential Regulation Authority.
>
> Cheltenham & Gloucester plc is authorised and regulated by the Financial 
> Conduct Authority.
>
> Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester 
> Savings is a division of Lloyds Bank plc.
>
> HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
> Scotland no. SC218813.
>
> This e-mail (including any attachments) is private and confidential and may 
> contain privileged material. If you have received this e-mail in error, 
> please notify the sender and delete it (including any attachments) 
> immediately. You must not copy, distribute, disclose or use any of the 
> information in it or any attachments. Telephone calls may be monitored or 
> recorded.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

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: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Vernooij, CP (ITOPT1) - KLM
Sent: Tuesday, July 19, 2016 10:39 AM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 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 the number of records that 
make up a block and each record is proceeded by a RDW and the block which you 
write has cumulative BDW.

Am I on the right track ?   

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: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 performance.
>
> I am guessing if you know what you are doing BSAM would be faster. If 
> anyone could point me to examples using BSAM would appreciated. As I 
> have mainly used QSAM specifying the RDW
>
> Thanks
>
> Joe Reichman
>

​In general (VB or FB), QSAM is much easier to program. The access method just 
hands you individual records. But you pay for this in that you cannot do I/O 
overlap yourself. With BSAM, you do a READ. But the _block_ is not available to 
you (for certain sure) until you do a CHECK. But this allows you to test the 
I/O ECB and "do something else" if it has not been POST'd yet. A type of 
"useful polling" loop. Also, if you are reading multiple files, you can do a 
ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O 
serially. Again performance. The problem is that _your code_ must de-block the 
​ individual records. For VB, you should probably determine the number of byte 
read in the block (they aren't necessarily all the same size, you
know) and check that the value in the BDW agrees with this number. And the code 
to do this is non-obvious because what you end up doing is knowing how many 
bytes you asked for and the I/O control block tells you the residual byte count 
- not the byte read but more like "you asked to read some bytes and there were 
​ were not enough in the block - the block was short by ? bytes). So the number 
of bytes read is the number of bytes you requested in the READ (not given back 
to you - you must remember) minus the "residual byte" count which is returned.

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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 

Re: Bsam VS Qsam for VB records

[Vernooij, CP (ITOPT1) - KLM]

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 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 the number of records that 
make up a block and each record is proceeded by a RDW and the block which you 
write has cumulative BDW.

Am I on the right track ?   

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: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 performance.
>
> I am guessing if you know what you are doing BSAM would be faster. If 
> anyone could point me to examples using BSAM would appreciated. As I 
> have mainly used QSAM specifying the RDW
>
> Thanks
>
> Joe Reichman
>

​In general (VB or FB), QSAM is much easier to program. The access method just 
hands you individual records. But you pay for this in that you cannot do I/O 
overlap yourself. With BSAM, you do a READ. But the _block_ is not available to 
you (for certain sure) until you do a CHECK. But this allows you to test the 
I/O ECB and "do something else" if it has not been POST'd yet. A type of 
"useful polling" loop. Also, if you are reading multiple files, you can do a 
ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O 
serially. Again performance. The problem is that _your code_ must de-block the 
​ individual records. For VB, you should probably determine the number of byte 
read in the block (they aren't necessarily all the same size, you
know) and check that the value in the BDW agrees with this number. And the code 
to do this is non-obvious because what you end up doing is knowing how many 
bytes you asked for and the I/O control block tells you the residual byte count 
- not the byte read but more like "you asked to read some bytes and there were 
​ were not enough in the block - the block was short by ? bytes). So the number 
of bytes read is the number of bytes you requested in the READ (not given back 
to you - you must remember) minus the "residual byte" count which is returned.

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: DFsort and zIIP

[Tom Marchant]

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 DFSORT remains a
>>prominent component of our customers' batch workloads.  However,  the
>>added controls that would need to be implemented in order to maintain our
>>high standards for performance, reliability and system integrity are not
>>justified in view of estimations that there is a low offload potential and 
>>the value to clients may be marginal.[snip]
>
>I seem to remember that SyncSort offers an Add-On package that allows 
>certain SyncSort processing to be offloaded to zIIPs. The above statement 
>suggest that SyncSort's perfocmance is suffering from using zIIPs (simplified 
>and exagerated, I know).

I understood "there is a low offload potential and the value to clients may be 
marginal" as meaning that there would not be much benefit in using zIIP. Not 
that it would be worse.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Vernooij, CP (ITOPT1) - KLM]

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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 19 July, 2016 16:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Bsam VS Qsam for VB records

IOW - unless you are very clever and you have a real need for I/O overlap
performance, and you don't mind the maintenance programmer cussing you out,
then I'd just go with QSAM.

-- 

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

Default space allocation

[Styles, Andy (SD EP zPlatform)]

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 is that people using XMIT/RECEIVE seem to 
allocate enormous datasets - one yesterday was 45K tracks, 1% used, which used 
up nearly all the free space on the volume, and caused another job to fail as 
it was unable to get the space it needed.

I vaguely remember reading somewhere about default space allocation being 
something along the lines of "whatever space remains on the volume". 

Does this ring any bells with anyone, or am I just dreaming it? Can these 
parameters be changed, and if so, where? I've been hunting but can't track it 
down.

Many thanks,

-- 
Andy Styles 
z/Series Systems Programmer


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. 
Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England 
and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered 
Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. 
Telephone: 03457 801 801. Cheltenham & Gloucester plc. Registered Office: 
Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. 
Telephone: 0345 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Cheltenham & Gloucester plc is authorised and regulated by the Financial 
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings 
is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[Reichman Joseph]

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 the number of records that 
make up a block and each record is proceeded by a RDW and the block which you 
write has cumulative BDW.

Am I on the right track ?   

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: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of John McKown
Sent: Tuesday, July 19, 2016 10:24 AM
To: IBM-MAIN@listserv.ua.edu
Subject: 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 performance.
>
> I am guessing if you know what you are doing BSAM would be faster. If 
> anyone could point me to examples using BSAM would appreciated. As I 
> have mainly used QSAM specifying the RDW
>
> Thanks
>
> Joe Reichman
>

​In general (VB or FB), QSAM is much easier to program. The access method just 
hands you individual records. But you pay for this in that you cannot do I/O 
overlap yourself. With BSAM, you do a READ. But the _block_ is not available to 
you (for certain sure) until you do a CHECK. But this allows you to test the 
I/O ECB and "do something else" if it has not been POST'd yet. A type of 
"useful polling" loop. Also, if you are reading multiple files, you can do a 
ECBLIST and wait for any one of the I/Os to complete instead of doing the I/O 
serially. Again performance. The problem is that _your code_ must de-block the 
​ individual records. For VB, you should probably determine the number of byte 
read in the block (they aren't necessarily all the same size, you
know) and check that the value in the BDW agrees with this number. And the code 
to do this is non-obvious because what you end up doing is knowing how many 
bytes you asked for and the I/O control block tells you the residual byte count 
- not the byte read but more like "you asked to read some bytes and there were 
​ were not enough in the block - the block was short by ? bytes). So the number 
of bytes read is the number of bytes you requested in the READ (not given back 
to you - you must remember) minus the "residual byte" count which is returned.

IOW - unless you are very clever and you have a real need for I/O overlap 
performance, and you don't mind the maintenance programmer cussing you out, 
then I'd just go with QSAM.

--
"Worry was nothing more than paying interest on a loan that a man may never 
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Bsam VS Qsam for VB records

[John McKown]

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 performance.
>
> I am guessing if you know what you are doing BSAM would be faster. If
> anyone could point me to examples using BSAM would appreciated. As I have
> mainly used QSAM specifying the RDW
>
> Thanks
>
> Joe Reichman
>

​In general (VB or FB), QSAM is much easier to program. The access method
just hands you individual records. But you pay for this in that you cannot
do I/O overlap yourself. With BSAM, you do a READ. But the _block_ is not
available to you (for certain sure) until you do a CHECK. But this allows
you to test the I/O ECB and "do something else" if it has not been POST'd
yet. A type of "useful polling" loop. Also, if you are reading multiple
files, you can do a ECBLIST and wait for any one of the I/Os to complete
instead of doing the I/O serially. Again performance. The problem is that
_your code_ must de-block the ​
individual records. For VB, you should probably determine the number of
byte read in the block (they aren't necessarily all the same size, you
know) and check that the value in the BDW agrees with this number. And the
code to do this is non-obvious because what you end up doing is knowing how
many bytes you asked for and the I/O control block tells you the residual
byte count - not the byte read but more like "you asked to read some bytes
and there were
​ were not enough in the block - the block was short by ? bytes). So the
number of bytes read is the number of bytes you requested in the READ (not
given back to you - you must remember) minus the "residual byte" count
which is returned.

IOW - unless you are very clever and you have a real need for I/O overlap
performance, and you don't mind the maintenance programmer cussing you out,
then I'd just go with QSAM.

-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Bsam VS Qsam for VB records

[Reichman Joseph]

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 point me to examples using BSAM would appreciated. As I have mainly used 
QSAM specifying the RDW

Thanks

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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DFsort and zIIP

[Blaicher, Christopher Y.]

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 ZPSAVER offloads significant portions of its processing to z/IIP 
engines.

I am not aware of any of these products' "performance suffering from using 
zIIPs" in either billable TCB time or elapsed time.

Many years of research and development have gone into creating these products 
and I am proud to have been a small part of it.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Tuesday, July 19, 2016 2:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 workloads.
>However,  the added controls that would need to be implemented in order
>to maintain our high standards for performance, reliability and system
>integrity are not justified in view of estimations that there is a low
>offload potential and the value to clients may be marginal.[snip]





Interesting statement. I seem to remember that SyncSort offers an Add-On 
package that allows certain SyncSort processing to be offloaded to zIIPs. The 
above statement suggest that SyncSort's perfocmance is suffering from using 
zIIPs (simplified and exagerated, I know).


Also "IBM Sort for DB2 for z/OS" (can't remember the exact name), is offloading 
to zIIPs, if I remember correctly. This procuct is based on SyncSort code as 
far as I understand.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FLASHCOPY QUESTION

[Pommier, Rex]

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, one on each volume.  The 
difference is what's going on in the back-end disk array.  

In example 1, you have FCNC which from the back-end array, the only thing that 
happens is that a set of pointers (a track table) gets built but no data gets 
copied.  The only time data gets physically copied from source to target is 
when either the source or target data track is changed.  If the source data 
gets changed, a copy of the track gets put on the target before the source is 
updated.  In case of the target getting updated, the changed data is written to 
the target.  If, for example, in this scenario you are doing this copy with the 
intent of doing a DUMP of the target to tape, most of the data for the DUMP is 
actually coming from the SOURCE, because unless the data changed, the SOURCE is 
the only place the physical data resides.

In example 2, FCINCREMENTAL does NOT mean do an incremental backup.  FC/DFDSS 
does a full background copy of all the data from the source to the target.  It 
still looks like it ran really fast to z/OS because as soon as the track table 
is built on the array, the array signals to z/OS the backup is done.  However, 
the back end is still copying all the data to the target.  Why use FCINCR then? 
 Under normal FC processing, if you don't use FCNC, the background copy is 
initiated, and then once all the data is copied to the target, the relationship 
between source and target is terminated, and the 2 volumes are now stand-alone. 
 If FCINCR is specified like in your example, the relationship remains in place 
with the track table now indicating which tracks have changed since the FC ran. 
 If you then come along and run another COPY command with the same source and 
target, the array uses the track table and only updates the changed tracks, 
thus (potentially) significantly reducing the load on the array if there wasn't 
much change in the data.  

So in short, FCNC only copies changed tracks from the source to the target, but 
FCINCR forces a full back-end copy of all the data from source to target on 
initial setup.  Note in the DFDSS manual is that FCNC and FCINCR are mutually 
exclusive.

HTH,

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of esmie moo
Sent: Tuesday, July 19, 2016 6:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 understanding is that an Incremental copy is being performed because FCNOCPY 
is specified.  My understanding of Incremental is that only the updated tracks 
are copied over to the target volume.  Please correct me if I am wrong.

Also, I have this example.  Is this for a FULL FlashCopy of a volume?  However, 
I am confused that the FCINCREMENTAL parm is specified which would indicate 
that this is an incremental copy

COPY FULL INDYNAM(ZFSZ01) OUTDYNAM(ZWATP0) ALLE ALLD(*) -   
FASTREPLICATION(REQUIRED) FCINCREMENTAL DUMPCONDITIONING ADMIN PURGE   

Could someone clear up this for me?

Thanks in advance.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Job Search

[Ken Smith]

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 cannot attract experienced people.

Good luck!

Ken Smith
Comptroller (taxes) for State of Maryland
Annapolis MD

http://www.jobaps.com/MD/sup/BulPreview.asp?R1=16=004476=0002

On Mon, Jul 18, 2016 at 8:39 AM, william janulin <
008d52e04f2e-dmarc-requ...@listserv.ua.edu> wrote:

> Joe can be difficult to reach at times. You can also contacvt, which I
> have done because I am in the market as well, Chris Evans. I believe his
> moniker is ch...@spci.net. I am seeking any remote sysprog work, either
> zVM, zVSE, zOS or all of the above.
> Bill J.
>
>
> On Sunday, July 17, 2016 11:49 PM, Tom Conley <
> pinnc...@rochester.rr.com> wrote:
>
>
>  On 7/17/2016 5:38 AM, Richards, Robert B. wrote:
> > Rob,
> >
> > Try contacting Joe Gallaher at Systems Programming Consultants, Inc.
> (SPCI). He attends most SHARE conferences and would be my first stop if I
> were looking.
> > Plus, I've known him for over 35 years. :-)
> >
> > His email is quite simple: j...@spci.net
> >
> > Bob
> >
>
> I'll second that, Joe is the best.  I also use dice.com.
>
> Regards,
> Tom Conley
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Exclusive ENQ on a TSO logon procedure

[John McKown]

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?
> >Kees.
>  >
> >Oh yeah..You are right.. . That explains why User C was able to log on .
> Thank you Kees ...
>
>
> JES2 is usually defined with NODSI in the PPT (SCHEDxx) and does not hold
> an ENQ on the data sets it has allocated.
>

​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).
Example portion of JES2PARM:

PROCLIB(PROC02) DD(1)=(DSN=SYS4.MDOFPROC),
DD(2)=(DSN=SYS1.PROCLIB),
DD(3)=(DSN=SYS2.PROCLIB),
DD(4)=(DSN=SYS1.LI.PROCLIB)

Also, if I remember correctly, when you specify NODSI, what actually
happens is that the data set _is_ enqueued when you do the START command,
but soon after (during the processing of the PPT entry?) the initiator will
release the ENQ. That is, if you have an STC defined with NODSI, but
something else has a DSN in the JCL "tied up" with a DISP=OLD type
allocation, then the START command will still get A "waiting on data sets"
message and will not be started until the DSN is available.
​



>
>
> --
> Peter Hunkeler
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
"Worry was nothing more than paying interest on a loan that a man may never
borrow"

From: "Quest for the White Wind" by Alan Black

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

FLASHCOPY QUESTION

[esmie moo]

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 understanding is that an Incremental copy is being performed because FCNOCPY 
is specified.  My understanding of Incremental is that only the updated tracks 
are copied over to the target volume.  Please correct me if I am wrong.

Also, I have this example.  Is this for a FULL FlashCopy of a volume?  However, 
I am confused that the FCINCREMENTAL parm is specified which would indicate 
that this is an incremental copy

COPY FULL INDYNAM(ZFSZ01) OUTDYNAM(ZWATP0) ALLE ALLD(*) -   
FASTREPLICATION(REQUIRED) FCINCREMENTAL DUMPCONDITIONING ADMIN PURGE   

Could someone clear up this for me?

Thanks in advance.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: Exclusive ENQ on a TSO logon procedure

[Peter Hunkeler]

>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 . Thank 
>you Kees ...




JES2 is usually defined with NODSI in the PPT (SCHEDxx) and does not hold an 
ENQ on the data sets it has allocated.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FAMS?

[Ken Smith]

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 <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> After my questions in a couple fora went unanswered, I looked further
> into NFS documentation:
>
> z/OS Network File System Guide and Reference
> SC26-7417-13
>
> ... File time stamps in UNIX format are part of the attributes required
> by the NFS protocol for NFS client/server communication. ...
>
> 2. MVS maintains the PDSE member create/change time stamp (mtime) in
> the
> PDSE AX cell. The Server uses a FileAccessMethodService (FAMS)
> call ...
>
> A Google search for FAMS returns the NFS reference, a SHARE presentation,
> a RFE,
> and several APARs.
>
> Where is this thing documented?  It should be useful.
>
> Also, from the NFS Guide:
>
> ... The server uses the following main time stamp sources to generate
> UNIX time stamps for MVS z/OS conventional (legacy) file systems:
>
> DSCB (data set control block)
> Master Catalog data set attribute extension (AX) cell
> PDSE member attribute extension (AX) cell
> ISPF member statistics
> TOD (current time_of_day on the server side).
>
> Rube Goldberg.
>
> -- gil
>
> --
> 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: SMFPRMxx

[Peter Relson]

>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 whether or not the exit 
is called. 

If you truly want to know if an exit routine is getting control, you could 
use a SLIP trap (one at a time) to capture some data upon entry to the 
exit routine (DISPLAY PROG,EXIT can tell you the exit routine address).

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Exclusive ENQ on a TSO logon procedure

[Roger Steyn]

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 . Thank 
you Kees ...


Roger Steyn  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Exclusive ENQ on a TSO logon procedure

[Vernooij, CP (ITOPT1) - KLM]

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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roger Steyn
Sent: 19 July, 2016 11:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 available for other task with 
DISP=SHR, but the member (logonproc) is exclusively in use by the ISPF user. 
 
This works this way for decades already. 


Well ... Let me put the scenario a bit more clear 

a) User A goes and edits the logon procedure in ISPF and doesn't come out of 
edit mode .
b) User B submits a Job  with SYS1.PROCLIB containing the logon proc with 
DISP=OLD 

Then the job  waits for an exclusive access for SYS1.PROCLIB which never 
gets satisfied as the proclib is already allocated with DISP=SHR by many things 
including JES2 -  This is normal 

Now , my understanding is - At this point , if a USER C tries to logon to the 
system using the same logon procedure in SYS1.PROCLIB , he shouldn't be able to 
as GRS has another Exclusive ENQ request waiting from the job  submitted by 
User B . Shouldn't that be honored before allowing others to access the proclib 
irrespective of DISP=SHR ?

TIA 

Roger Steyn 

--
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: Exclusive ENQ on a TSO logon procedure

[Roger Steyn]

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 available for other task with 
DISP=SHR, but the member (logonproc) is exclusively in use by the ISPF user. 
 
This works this way for decades already. 


Well ... Let me put the scenario a bit more clear 

a) User A goes and edits the logon procedure in ISPF and doesn't come out of 
edit mode .
b) User B submits a Job  with SYS1.PROCLIB containing the logon proc with 
DISP=OLD 

Then the job  waits for an exclusive access for SYS1.PROCLIB which never 
gets satisfied as the proclib is already allocated with DISP=SHR by many things 
including JES2 -  This is normal 

Now , my understanding is - At this point , if a USER C tries to logon to the 
system using the same logon procedure in SYS1.PROCLIB , he shouldn't be able to 
as GRS has another Exclusive ENQ request waiting from the job  submitted by 
User B . Shouldn't that be honored before allowing others to access the proclib 
irrespective of DISP=SHR ?

TIA 

Roger Steyn 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Exclusive ENQ on a TSO logon procedure

[Vernooij, CP (ITOPT1) - KLM]

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 available for other task with 
DISP=SHR, but the member (logonproc) is exclusively in use by the ISPF user.

This works this way for decades already.

Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roger Steyn
Sent: 19 July, 2016 10:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 procedure while the ENQ is on ?  
Well , this is on z/os 2.1 and i was surprised to see the enq doesn't hold 
anybody from logging on using the same logon procedure while there is an 
exclusive ENQ  . Does anyone know if this is a new feature in z/os 2.1 ? I am 
aware of the dynamic ENQ downgrade within a JCL having multiple steps . But the 
job which had a DISP=OLD in my system had only one step and it was hanging 
because someone had opened the logon proc in edit mode and forgot to come out 
of the session . 

TIA 

Roger Steyn 

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

Exclusive ENQ on a TSO logon procedure

[Roger Steyn]

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 procedure while the ENQ is on ?  
Well , this is on z/os 2.1 and i was surprised to see the enq doesn't hold 
anybody from logging on using the same logon procedure while there is an 
exclusive ENQ  . Does anyone know if this is a new feature in z/os 2.1 ? I am 
aware of the dynamic ENQ downgrade within a JCL having multiple steps . But the 
job which had a DISP=OLD in my system had only one step and it was hanging 
because someone had opened the logon proc in edit mode and forgot to come out 
of the session . 

TIA 

Roger Steyn 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[David Crayford]

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 9:35 PM, Timothy Sipples wrote:

I've seen some questions in IBM-MAIN (and elsewhere) about availability of
Node.js for z/OS. The latest version of Node.js is just starting to emerge
on z/OS, and that's great news of course. For the latest information (as of
July 14, 2016, at least), please take a look at Michael Dawson's article
here:

https://developer.ibm.com/node/2016/07/14/linuxone-ppc-aix-and-zos-support-in-the-node-js-community/

If you're wondering what Node.js is, this Wikipedia article explains the
basics:

https://en.wikipedia.org/wiki/Node.js

Node.js was introduced some time ago for Linux on z and LinuxONE and (of
course) continues to be updated and enhanced. IBM's builds are available
for download here:

https://developer.ibm.com/node/sdk/


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: DFsort and zIIP

[Peter Hunkeler]

>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 workloads.  However,  the
>added controls that would need to be implemented in order to maintain our
>high standards for performance, reliability and system integrity are not
>justified in view of estimations that there is a low offload potential and 
>the value to clients may be marginal.[snip]





Interesting statement. I seem to remember that SyncSort offers an Add-On 
package that allows certain SyncSort processing to be offloaded to zIIPs. The 
above statement suggest that SyncSort's perfocmance is suffering from using 
zIIPs (simplified and exagerated, I know).


Also "IBM Sort for DB2 for z/OS" (can't remember the exact name), is offloading 
to zIIPs, if I remember correctly. This procuct is based on SyncSort code as 
far as I understand.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN