Re: Bytes in a 3390 track - reason for the question

[Paul Schuster]

TRKCALC knows everything.

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

Re: To share or not to share DASD

[Joel C. Ewing]

But its not just a case of whether you trust they will not intentionally 
damage something, but the ease of accidentally causing integrity 
problems by not knowing when others have touched catalogs, volumes, or 
datasets on DASD that is physically shared but not known to be shared by 
the Operating System.  If many people are involved, the coordination 
procedures involved to prevent damage, assuming such procedures are even 
feasible, are a disaster waiting to happen.


 If volumes are SMS, all datasets must be cataloged and the associated 
catalogs must be accessed from any system that accesses those 
datasets.   If the systems are not in a relationship that enables proper 
catalog sharing, access and possible modification of the catalog from 
multiple systems causes the cached versions of catalog data to become 
out of sync with actual content on the drive when the catalog is altered 
from a different system, and there is a high probability the catalog 
will become corrupted on all systems.


Auditors are justified in being concerned whether independent RACF 
databases on multiple systems will always be in sync to properly protect 
production datasets from unintentional access or unauthorized access if 
test LPARs share access to production volumes.  There should always be 
multiple barriers to doing something bad because accidents happen -- 
like forgetting to change a production dataset name in what was intended 
to be test JCL.


There are just two many bad things that can happen if you try to share 
things that are only designed for sharing within a sysplex. The only 
relatively safe way to do this across independent LPARs is 
non-concurrently:   have a set of volumes and a catalog for HLQ's of 
just the datasets on those volumes that is also located on one of those 
volumes, and only have those volumes on-line to one system at a time and 
close, and deallocate all datasets and the catalog on those volumes 
before taking them offline to move them to a different system.


A much simpler and safer solution is to not share DASD volumes across 
LPARs not in the same sysplex, to maintain a unique copy of datasets on 
systems where they are needed, and to use a high-speed communication 
link between the LPARs to transmit datasets from one system to another 
when there is a need to resync those datasets from a production LPAR.


Joel C Ewing


On 11/24/22 21:38, Farley, Peter wrote:


Not necessarily true in a software development environment where all members of the team 
need to share all their data everywhere.  "Zero trust" is anathema in a 
development environment.

If you don't trust me then fire me.  It's cleaner that way.

Shakespeare was *almost* right.  First get rid of all the auditors, *then* get 
rid of all the lawyers.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Thursday, November 24, 2022 5:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: To share or not to share DASD

If you were asking in a security context, I would advise against it in nearly 
all cases.
Auditors will not like that a system's data can be accessed without reference 
to the RACF (or ACF2, or TSS) system that is supposed to protect it.

Lennie Dymoke-Bradshaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gord Neill
Sent: 24 November 2022 20:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: To share or not to share DASD

G'day all,
I've been having discussions with a small shop (single mainframe, 3 separate LPARs, no 
Sysplex) regarding best practices for DASD sharing.  Their view is to share all DASD 
volumes across their 3 LPARs (Prod/Dev/Test) so their developers/sysprogs can get access 
to current datasets, but in order to do that, they'll need to use GRS Ring or MIM with 
the associated overhead.  I don't know of any other serialization products, and since 
this is not a Sysplex environment, they can't use GRS Star.  I suggested the idea of no 
GRS, keeping most DASD volumes isolated to each LPAR, with a "shared string"
available to all LPARs for copying datasets, but it was not well received.

Just curious as to how other shops are handling this.  TIA!


Gord Neill | Senior I/T Consultant | GlassHouse Systems
--
...


--
Joel C. Ewing

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

Re: To share or not to share DASD

[Farley, Peter]

Not necessarily true in a software development environment where all members of 
the team need to share all their data everywhere.  "Zero trust" is anathema in 
a development environment.

If you don't trust me then fire me.  It's cleaner that way.

Shakespeare was *almost* right.  First get rid of all the auditors, *then* get 
rid of all the lawyers.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lennie Dymoke-Bradshaw
Sent: Thursday, November 24, 2022 5:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: To share or not to share DASD

If you were asking in a security context, I would advise against it in nearly 
all cases.
Auditors will not like that a system's data can be accessed without reference 
to the RACF (or ACF2, or TSS) system that is supposed to protect it. 

Lennie Dymoke-Bradshaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gord Neill
Sent: 24 November 2022 20:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: To share or not to share DASD

G'day all,
I've been having discussions with a small shop (single mainframe, 3 separate 
LPARs, no Sysplex) regarding best practices for DASD sharing.  Their view is to 
share all DASD volumes across their 3 LPARs (Prod/Dev/Test) so their 
developers/sysprogs can get access to current datasets, but in order to do 
that, they'll need to use GRS Ring or MIM with the associated overhead.  I 
don't know of any other serialization products, and since this is not a Sysplex 
environment, they can't use GRS Star.  I suggested the idea of no GRS, keeping 
most DASD volumes isolated to each LPAR, with a "shared string"
available to all LPARs for copying datasets, but it was not well received.

Just curious as to how other shops are handling this.  TIA!


Gord Neill | Senior I/T Consultant | GlassHouse Systems
--

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: To share or not to share DASD

[Lennie Dymoke-Bradshaw]

If you were asking in a security context, I would advise against it in
nearly all cases.
Auditors will not like that a system's data can be accessed without
reference to the RACF (or ACF2, or TSS) system that is supposed to protect
it. 

Lennie Dymoke-Bradshaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Gord Neill
Sent: 24 November 2022 20:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: To share or not to share DASD

G'day all,
I've been having discussions with a small shop (single mainframe, 3 separate
LPARs, no Sysplex) regarding best practices for DASD sharing.  Their view is
to share all DASD volumes across their 3 LPARs (Prod/Dev/Test) so their
developers/sysprogs can get access to current datasets, but in order to do
that, they'll need to use GRS Ring or MIM with the associated overhead.  I
don't know of any other serialization products, and since this is not a
Sysplex environment, they can't use GRS Star.  I suggested the idea of no
GRS, keeping most DASD volumes isolated to each LPAR, with a "shared string"
available to all LPARs for copying datasets, but it was not well received.

Just curious as to how other shops are handling this.  TIA!


Gord Neill | Senior I/T Consultant | GlassHouse Systems




--
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: To share or not to share DASD

[Gibney, Dave]

Different RACF and fully shared DASD is a recipe for security problems and 
inconsistencies. I suppose RRSF could help. GRS ring is reported to be abysmal 
and nodes > 2
Same issues in trying to keep the catalogs in sync, which is required to SMS to 
be reliable. As will as trying to keep the SMS xCDS (and DFHSM) in sync.

I had 4 LPARS, all monoplex, perhaps a dozen, carefully shared volumes. 
Including the SYSRES. I did have separate Unix system filesystems for each.
All volumes were potentially shareable, but I varied most of them offline at 
IPL from the 3 LPARs they were a part of. 

I had separate SMS pools for the application data in each LPAR.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gord Neill
> Sent: Thursday, November 24, 2022 1:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: To share or not to share DASD
> 
> [EXTERNAL EMAIL]
> 
> Dave,
> Each LPAR has its own RACF and Catalogs, and they are using SMS.  This shop
> is currently running z/OS 1.9 on very old hardware, in the process of
> upgrading to current H/W and S/W.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gibney, Dave
> Sent: November 24, 2022 4:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: To share or not to share DASD
> 
> You can't share PDSE in such an environment. You can "get away"  with only
> and rarely updating from one LPAR, and reading in the others.
> 
> Multiple RACF databases?  Are the Catalogs the same and shared between all
> 3 LPARS?
> 
> Is the site using SMS?
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Gord Neill
> > Sent: Thursday, November 24, 2022 12:55 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: To share or not to share DASD
> >
> > [EXTERNAL EMAIL]
> >
> > G'day all,
> > I've been having discussions with a small shop (single mainframe, 3
> > separate LPARs, no Sysplex) regarding best practices for DASD sharing.
> > Their view is to share all DASD volumes across their 3 LPARs
> > (Prod/Dev/Test) so their developers/sysprogs can get access to current
> > datasets, but in order to do that, they'll need to use GRS Ring or MIM
> > with the associated overhead.  I don't know of any other serialization
> > products, and since this is not a Sysplex environment, they can't use
> > GRS Star.  I suggested the idea of no GRS, keeping most DASD volumes
> isolated to each LPAR, with a "shared string"
> > available to all LPARs for copying datasets, but it was not well received.
> >
> > Just curious as to how other shops are handling this.  TIA!
> >
> >
> > Gord Neill | Senior I/T Consultant | GlassHouse Systems
> >
> >
> >
> >
> > --
> > 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: To share or not to share DASD

[Gord Neill]

Dave,
Each LPAR has its own RACF and Catalogs, and they are using SMS.  This shop is 
currently running z/OS 1.9 on very old hardware, in the process of upgrading to 
current H/W and S/W.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: November 24, 2022 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: To share or not to share DASD

You can't share PDSE in such an environment. You can "get away"  with only and 
rarely updating from one LPAR, and reading in the others.

Multiple RACF databases?  Are the Catalogs the same and shared between all 3 
LPARS?

Is the site using SMS?

> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Gord Neill
> Sent: Thursday, November 24, 2022 12:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: To share or not to share DASD
> 
> [EXTERNAL EMAIL]
> 
> G'day all,
> I've been having discussions with a small shop (single mainframe, 3 
> separate LPARs, no Sysplex) regarding best practices for DASD sharing.  
> Their view is to share all DASD volumes across their 3 LPARs 
> (Prod/Dev/Test) so their developers/sysprogs can get access to current 
> datasets, but in order to do that, they'll need to use GRS Ring or MIM 
> with the associated overhead.  I don't know of any other serialization 
> products, and since this is not a Sysplex environment, they can't use 
> GRS Star.  I suggested the idea of no GRS, keeping most DASD volumes isolated 
> to each LPAR, with a "shared string"
> available to all LPARs for copying datasets, but it was not well received.
> 
> Just curious as to how other shops are handling this.  TIA!
> 
> 
> Gord Neill | Senior I/T Consultant | GlassHouse Systems
> 
> 
> 
> 
> --
> 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: To share or not to share DASD

[Gibney, Dave]

You can't share PDSE in such an environment. You can "get away"  with only and 
rarely updating from one LPAR, and reading in the others.

Multiple RACF databases?  Are the Catalogs the same and shared between all 3 
LPARS?

Is the site using SMS?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Gord Neill
> Sent: Thursday, November 24, 2022 12:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: To share or not to share DASD
> 
> [EXTERNAL EMAIL]
> 
> G'day all,
> I've been having discussions with a small shop (single mainframe, 3 separate
> LPARs, no Sysplex) regarding best practices for DASD sharing.  Their view is 
> to
> share all DASD volumes across their 3 LPARs (Prod/Dev/Test) so their
> developers/sysprogs can get access to current datasets, but in order to do
> that, they'll need to use GRS Ring or MIM with the associated overhead.  I
> don't know of any other serialization products, and since this is not a 
> Sysplex
> environment, they can't use GRS Star.  I suggested the idea of no GRS,
> keeping most DASD volumes isolated to each LPAR, with a "shared string"
> available to all LPARs for copying datasets, but it was not well received.
> 
> Just curious as to how other shops are handling this.  TIA!
> 
> 
> Gord Neill | Senior I/T Consultant | GlassHouse Systems
> 
> 
> 
> 
> --
> 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

To share or not to share DASD

[Gord Neill]

G'day all,
I've been having discussions with a small shop (single mainframe, 3 separate 
LPARs, no Sysplex) regarding best practices for DASD sharing.  Their view is to 
share all DASD volumes across their 3 LPARs (Prod/Dev/Test) so their 
developers/sysprogs can get access to current datasets, but in order to do 
that, they'll need to use GRS Ring or MIM with the associated overhead.  I 
don't know of any other serialization products, and since this is not a Sysplex 
environment, they can't use GRS Star.  I suggested the idea of no GRS, keeping 
most DASD volumes isolated to each LPAR, with a "shared string" available to 
all LPARs for copying datasets, but it was not well received.

Just curious as to how other shops are handling this.  TIA!


Gord Neill | Senior I/T Consultant | GlassHouse Systems




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

Re: Bytes in a 3390 track - reason for the question

[Joe Monk]

i was just getting ready to say this same thing.

The 3390 reference shows that for a 3120 byte block, only 15 blocks fit on
a track, with a 16% space waste.

Your best bet is to use TRKCALC...
https://www.ibm.com/docs/en/zos/2.4.0?topic=instructions-performing-track-calculations-trkcalc-macro

Joe

On Thu, Nov 24, 2022 at 11:25 AM Joel C. Ewing  wrote:

> Subtracting the logical blocksize from either of those capacity numbers
> as you describe will not give correct results for blocks per track.  The
> only accurate way to determine how many blocks will fit on a 3390 track
> is to use the formulas from the 3390 Reference Summary (mentioned in
> previous post) to compute the number of 34-byte cells required to write
> the block and see if enough of the 1729 cells in the track remain.   For
> fixed-sized blocks of length requiring "x" cells, the number of blocks
> per track would be  floor(1729/x) .
>
> Alternatively,  there is a table in the 3390 Reference Summary on page
> 12 showing the minimum and maximum block sizes vs number of blocks per
> track.  It only has 86 rows (a blocksize of 1 byte only gets you 86
> usable bytes per track!), so you could store the Min, Max, and Records
> columns of that entire table in a program and look up any blocksize to
> see which which row min/max includes that blocksize and extract the
> blocks/track from the Records row of the table.
>
> If your object is to report how much resource the datasets are
> consuming, then tracks allocated makes the most sense.
>
> If your object is to report how much useful data is in the dataset, then
> the blocksize becomes potentially useful.  If you can get the
> last-track-used you can compute the number of actual blocks in the
> dataset within an accuracy of blocks-per-track - 1.
>
> The actual useful data per track vs best-case usage might also be useful
> if a sub-optimal blocksize has been chosen.
>
>  Joel C Ewing
>
> On 11/24/22 10:14, John Gateley wrote:
> > The reason for asking the question about bytes on a track is that I am
> writing programs to report on all disk datasets.
> > The first program looks at all on-line disk packs and extracts all
> format 1, 3, 8 and 9 DSCBs while also providing a summary of space
> available/used on each disk (similar to VTOC on CBT file 112).
> > The second program produces information for all datasets. If the
> secondary allocation is in blocks then that means the primary was also and
> I want to output the allocation like this BLK(00060,00020).
> > To do this I subtract the block size from 56664 repeatedly until the
> remainder is less than the block size which gives me the number of blocks
> in a track, multiply this by the primary allocation in tracks should give
> me the figure I want.
> > Except it doesn't.
> >
> > For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my
> program BLK(00072,00020).
> > With a blocksize of 3120 there are 18 blocks per track and 4 tracks are
> in use. 3 of them must be full so that gives 54 blocks meaning there are
> only 6 on the final track.
> >
> > The dataset is not extended format, PDSE, HFS or VSAM so I think I need
> to look at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many
> blocks would fit, I get 7 not 6.
> >
> > Alternatively, if I use 55996 I get 17 blocks per track meaning there
> are 9 on the last track and I get 7.
> >
> > I'm obviously missing something, and I am hoping someone can tell me
> what?
> >
> > DS1DSNAM  DSN1.SRCLIB.DATA
> > DS1FMTID  1
> > DS1DSSN   DB2C06
> > DS1VOLSQ  0001
> > DS1CREDT  78003A
> > DS1EXPDT  00
> > DS1NOEPV  01
> > DS1NOBDB  00
> > DS1FLAG1  00
> > DS1SYSCD  IBMOSVS2
> > DS1REFD   7A0148
> > DS1SMSFG  80
> > DS1SCXTF  80
> > DS1SCXTV  0FA04000
> > DS1DSORG  0200
> > DS1RECFM  90
> > DS1OPTCD  00
> > DS1BLKL   0C30
> > DS1LRECL  0050
> > DS1KEYL   00
> > DS1RKP
> > DS1DSIND  80
> > DS1SCAL1  50
> > DS1SCAL3  14
> > DS1LSTAR  15
> > DS1TRBAL  7E0A32266
> > DS1TTTHI  00
> > DS1EXT1   010C000B000C000E
> > DS1EXT2   
> > DS1EXT3   
> > DS1PTRDS  00
> >
> > Data Set Name . . . . : DSN1.SRCLIB.DATA
> >
> > General Data  Current Allocation
> >   Management class . . :Allocated blocks  . : 60
> >   Storage class  . . . :Allocated extents . : 1
> >Volume serial . . . : DB2C06 Maximum dir. blocks : 20
> >Device type . . . . : 3390
> >   Data class . . . . . :
> >Organization  . . . : POCurrent Utilization
> >Record format . . . : FB Used blocks . . . . : 7
> >Record length . . . : 80 Used extents  . . . : 1
> >Block size  . . . . : 3120   Used dir. blocks  . : 1
> >1st extent blocks . : 60 Number of members . : 0
> >Secondary blocks  . : 20
> >Data set name type  : PDS   Dates
> >Data set encryption : NO 

Re: Bytes in a 3390 track - reason for the question

[Joel C. Ewing]

Subtracting the logical blocksize from either of those capacity numbers 
as you describe will not give correct results for blocks per track.  The 
only accurate way to determine how many blocks will fit on a 3390 track 
is to use the formulas from the 3390 Reference Summary (mentioned in 
previous post) to compute the number of 34-byte cells required to write 
the block and see if enough of the 1729 cells in the track remain.   For 
fixed-sized blocks of length requiring "x" cells, the number of blocks 
per track would be  floor(1729/x) .


Alternatively,  there is a table in the 3390 Reference Summary on page 
12 showing the minimum and maximum block sizes vs number of blocks per 
track.  It only has 86 rows (a blocksize of 1 byte only gets you 86 
usable bytes per track!), so you could store the Min, Max, and Records 
columns of that entire table in a program and look up any blocksize to 
see which which row min/max includes that blocksize and extract the 
blocks/track from the Records row of the table.


If your object is to report how much resource the datasets are 
consuming, then tracks allocated makes the most sense.


If your object is to report how much useful data is in the dataset, then 
the blocksize becomes potentially useful.  If you can get the 
last-track-used you can compute the number of actual blocks in the 
dataset within an accuracy of blocks-per-track - 1.


The actual useful data per track vs best-case usage might also be useful 
if a sub-optimal blocksize has been chosen.


    Joel C Ewing

On 11/24/22 10:14, John Gateley wrote:

The reason for asking the question about bytes on a track is that I am writing 
programs to report on all disk datasets.
The first program looks at all on-line disk packs and extracts all format 1, 3, 
8 and 9 DSCBs while also providing a summary of space available/used on each 
disk (similar to VTOC on CBT file 112).
The second program produces information for all datasets. If the secondary 
allocation is in blocks then that means the primary was also and I want to 
output the allocation like this BLK(00060,00020).
To do this I subtract the block size from 56664 repeatedly until the remainder 
is less than the block size which gives me the number of blocks in a track, 
multiply this by the primary allocation in tracks should give me the figure I 
want.
Except it doesn't.

For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my program 
BLK(00072,00020).
With a blocksize of 3120 there are 18 blocks per track and 4 tracks are in use. 
3 of them must be full so that gives 54 blocks meaning there are only 6 on the 
final track.

The dataset is not extended format, PDSE, HFS or VSAM so I think I need to look 
at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many blocks would 
fit, I get 7 not 6.

Alternatively, if I use 55996 I get 17 blocks per track meaning there are 9 on 
the last track and I get 7.

I'm obviously missing something, and I am hoping someone can tell me what?

DS1DSNAM  DSN1.SRCLIB.DATA
DS1FMTID  1
DS1DSSN   DB2C06
DS1VOLSQ  0001
DS1CREDT  78003A
DS1EXPDT  00
DS1NOEPV  01
DS1NOBDB  00
DS1FLAG1  00
DS1SYSCD  IBMOSVS2
DS1REFD   7A0148
DS1SMSFG  80
DS1SCXTF  80
DS1SCXTV  0FA04000
DS1DSORG  0200
DS1RECFM  90
DS1OPTCD  00
DS1BLKL   0C30
DS1LRECL  0050
DS1KEYL   00
DS1RKP
DS1DSIND  80
DS1SCAL1  50
DS1SCAL3  14
DS1LSTAR  15
DS1TRBAL  7E0A32266
DS1TTTHI  00
DS1EXT1   010C000B000C000E
DS1EXT2   
DS1EXT3   
DS1PTRDS  00

Data Set Name . . . . : DSN1.SRCLIB.DATA

General Data  Current Allocation

  Management class . . :Allocated blocks  . : 60
  Storage class  . . . :Allocated extents . : 1
   Volume serial . . . : DB2C06 Maximum dir. blocks : 20
   Device type . . . . : 3390
  Data class . . . . . :
   Organization  . . . : POCurrent Utilization
   Record format . . . : FB Used blocks . . . . : 7
   Record length . . . : 80 Used extents  . . . : 1
   Block size  . . . . : 3120   Used dir. blocks  . : 1
   1st extent blocks . : 60 Number of members . : 0
   Secondary blocks  . : 20
   Data set name type  : PDS   Dates
   Data set encryption : NO Creation date . . . : 2020/02/27
Referenced date . . : 2022/11/24
Expiration date . . : ***None***

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


--
Joel C. Ewing

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

Re: Bytes in a 3390 track - reason for the question

[Nigel Morton]

You're missing an allowance for an inter-block gap.

On Thu, 24 Nov 2022 at 16:14, John Gateley  wrote:

> The reason for asking the question about bytes on a track is that I am
> writing programs to report on all disk datasets.
> The first program looks at all on-line disk packs and extracts all format
> 1, 3, 8 and 9 DSCBs while also providing a summary of space available/used
> on each disk (similar to VTOC on CBT file 112).
> The second program produces information for all datasets. If the secondary
> allocation is in blocks then that means the primary was also and I want to
> output the allocation like this BLK(00060,00020).
> To do this I subtract the block size from 56664 repeatedly until the
> remainder is less than the block size which gives me the number of blocks
> in a track, multiply this by the primary allocation in tracks should give
> me the figure I want.
> Except it doesn't.
>
> For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my
> program BLK(00072,00020).
> With a blocksize of 3120 there are 18 blocks per track and 4 tracks are in
> use. 3 of them must be full so that gives 54 blocks meaning there are only
> 6 on the final track.
>
> The dataset is not extended format, PDSE, HFS or VSAM so I think I need to
> look at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many
> blocks would fit, I get 7 not 6.
>
> Alternatively, if I use 55996 I get 17 blocks per track meaning there are
> 9 on the last track and I get 7.
>
> I'm obviously missing something, and I am hoping someone can tell me what?
>
> DS1DSNAM  DSN1.SRCLIB.DATA
> DS1FMTID  1
> DS1DSSN   DB2C06
> DS1VOLSQ  0001
> DS1CREDT  78003A
> DS1EXPDT  00
> DS1NOEPV  01
> DS1NOBDB  00
> DS1FLAG1  00
> DS1SYSCD  IBMOSVS2
> DS1REFD   7A0148
> DS1SMSFG  80
> DS1SCXTF  80
> DS1SCXTV  0FA04000
> DS1DSORG  0200
> DS1RECFM  90
> DS1OPTCD  00
> DS1BLKL   0C30
> DS1LRECL  0050
> DS1KEYL   00
> DS1RKP
> DS1DSIND  80
> DS1SCAL1  50
> DS1SCAL3  14
> DS1LSTAR  15
> DS1TRBAL  7E0A32266
> DS1TTTHI  00
> DS1EXT1   010C000B000C000E
> DS1EXT2   
> DS1EXT3   
> DS1PTRDS  00
>
> Data Set Name . . . . : DSN1.SRCLIB.DATA
>
> General Data  Current Allocation
>  Management class . . :Allocated blocks  . : 60
>  Storage class  . . . :Allocated extents . : 1
>   Volume serial . . . : DB2C06 Maximum dir. blocks : 20
>   Device type . . . . : 3390
>  Data class . . . . . :
>   Organization  . . . : POCurrent Utilization
>   Record format . . . : FB Used blocks . . . . : 7
>   Record length . . . : 80 Used extents  . . . : 1
>   Block size  . . . . : 3120   Used dir. blocks  . : 1
>   1st extent blocks . : 60 Number of members . : 0
>   Secondary blocks  . : 20
>   Data set name type  : PDS   Dates
>   Data set encryption : NO Creation date . . . : 2020/02/27
>Referenced date . . : 2022/11/24
>Expiration date . . : ***None***
>
> --
> 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: Bytes in a 3390 track

[Joel C. Ewing]

But even if they do that under the covers at the track level, I would 
expect the DS8K boxes to still allocate/reserve total physical space for 
each emulated DASD unit under the worst case assumption that every track 
might be fully utilized.  Unless advertised as a more restricted version 
of 3390, It would be a poor emulation from a mainframer's viewpoint if 
your DASD subsystem could have a write to a virtual drive fail from lack 
of physical backup storage because someone actually figured out a useful 
application that would load up all drives with one max full-track record 
per track as permitted by the architecture definition.


The old and long-withdrawn IBM 9393 RAMAC Virtual Array storage 
subsystem was was an interesting beast that didn't have fixed track 
mapping -- every new emulated track written went to a different place in 
the backstore with previous version of the track deleted.  There was 
even handshaking between MVS and the RAMAC subsystem when a dataset was 
deleted so that emulated tracks associated a deleted dataset could be 
deleted from the backstore even before the track was re-used.   Very 
efficient on physical subsystem storage, but also had some peculiar 
performance characteristics -- multitrack sequential writes could be 
faster than multi-track sequential reads -- And it was possible to get 
special alerts indicating the backstore occupancy was getting too high.


    Joel C Ewing

On 11/24/22 09:46, Paul Gorlinsky wrote:


Switching from "real" 3380s & 3390s to the emulated 3380s & 3390s has been an 
evolutionary path.

For example, with the P370 and its derivatives, each DASD unit was implemented 
as a single file on the hosting PC; AWSDISK. Hercules implemented the same file 
structure and later added a compressed version with track updates stored in a 
new file that could be later reorganized back into the base.

I would guess that the DS8K boxes today got a lot smarter and implemented the track data 
or even track record data as separate objects managed by a volume TOC mechanism; which 
facilities all the DS8K enhancements of volume cloning, fast copy, check pointing, 
versioning, etc.  "Sparse type" file systems are also more common today.

So individual dataset space is not a big issue.  You have to think at the 
enterprise level.

However, the individual still needs to allocate their datasets correctly to 
satisfy the OS ... or for the zOS people, get an X37 abend processor...

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


--
Joel C. Ewing

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

Bytes in a 3390 track - reason for the question

[John Gateley]

The reason for asking the question about bytes on a track is that I am writing 
programs to report on all disk datasets.
The first program looks at all on-line disk packs and extracts all format 1, 3, 
8 and 9 DSCBs while also providing a summary of space available/used on each 
disk (similar to VTOC on CBT file 112).
The second program produces information for all datasets. If the secondary 
allocation is in blocks then that means the primary was also and I want to 
output the allocation like this BLK(00060,00020).
To do this I subtract the block size from 56664 repeatedly until the remainder 
is less than the block size which gives me the number of blocks in a track, 
multiply this by the primary allocation in tracks should give me the figure I 
want.
Except it doesn't.

For the format 1 DSCB below ISPF 3;4 reports BLK(00060,00020) and my program 
BLK(00072,00020).
With a blocksize of 3120 there are 18 blocks per track and 4 tracks are in use. 
3 of them must be full so that gives 54 blocks meaning there are only 6 on the 
final track.

The dataset is not extended format, PDSE, HFS or VSAM so I think I need to look 
at DS1TRBAL, I subtracted 32266 from 56664 and worked out how many blocks would 
fit, I get 7 not 6.

Alternatively, if I use 55996 I get 17 blocks per track meaning there are 9 on 
the last track and I get 7.

I'm obviously missing something, and I am hoping someone can tell me what?

DS1DSNAM  DSN1.SRCLIB.DATA
DS1FMTID  1   
DS1DSSN   DB2C06  
DS1VOLSQ  0001
DS1CREDT  78003A  
DS1EXPDT  00  
DS1NOEPV  01  
DS1NOBDB  00  
DS1FLAG1  00  
DS1SYSCD  IBMOSVS2
DS1REFD   7A0148  
DS1SMSFG  80  
DS1SCXTF  80  
DS1SCXTV  0FA04000
DS1DSORG  0200
DS1RECFM  90  
DS1OPTCD  00  
DS1BLKL   0C30
DS1LRECL  0050
DS1KEYL   00  
DS1RKP
DS1DSIND  80  
DS1SCAL1  50  
DS1SCAL3  14  
DS1LSTAR  15  
DS1TRBAL  7E0A32266
DS1TTTHI  00  
DS1EXT1   010C000B000C000E
DS1EXT2   
DS1EXT3   
DS1PTRDS  00  

Data Set Name . . . . : DSN1.SRCLIB.DATA   
   
General Data  Current Allocation   
 Management class . . :Allocated blocks  . : 60
 Storage class  . . . :Allocated extents . : 1 
  Volume serial . . . : DB2C06 Maximum dir. blocks : 20
  Device type . . . . : 3390   
 Data class . . . . . :
  Organization  . . . : POCurrent Utilization  
  Record format . . . : FB Used blocks . . . . : 7 
  Record length . . . : 80 Used extents  . . . : 1 
  Block size  . . . . : 3120   Used dir. blocks  . : 1 
  1st extent blocks . : 60 Number of members . : 0 
  Secondary blocks  . : 20 
  Data set name type  : PDS   Dates
  Data set encryption : NO Creation date . . . : 2020/02/27
   Referenced date . . : 2022/11/24
   Expiration date . . : ***None***

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

Re: DFSORT: Building one record from two and ignore the rest

[Jack Zukt]

HI Kolusu,

Many thanks for your help.
If there is not a OHSM record for each DSNAME, I will have a bigger problem
to solve.
Best wishes,
Jack

On Thu, 24 Nov 2022 at 15:30, Sri h Kolusu  wrote:

> >>. So, what I need is to get the dataset name from the record that has
> "DSNAME =", the volser from the record that has "ODSN:" and format a single
> record with volser datasetname or datasetname volser
>
> Jack
>
> Use the following untested control cards which will give you the desired
> results assuming that DSNAME = record always have a OHSM  record as a pair.
>
> //SYSINDD *
>   OPTION COPY
>   INCLUDE COND=(02,08,CH,EQ,C'DSNAME =',OR,
> 02,05,CH,EQ,C'OHSM.')
>
>   INREC IFTHEN=(WHEN=GROUP,
>BEGIN=(02,08,CH,EQ,C'DSNAME ='),
>  END=(02,05,CH,EQ,C'OHSM.'),
> PUSH=(81:11,44))
>
>   OUTFIL INCLUDE=(02,05,CH,EQ,C'OHSM.'),
>BUILD=(81,44,   # DSNAME
>   2X,  # 2 SPACES
>   47,06)   # VOLSER
> /*
>
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
>
> --
> 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: Bytes in a 3390 track

[Paul Gorlinsky]

Switching from "real" 3380s & 3390s to the emulated 3380s & 3390s has been an 
evolutionary path. 

For example, with the P370 and its derivatives, each DASD unit was implemented 
as a single file on the hosting PC; AWSDISK. Hercules implemented the same file 
structure and later added a compressed version with track updates stored in a 
new file that could be later reorganized back into the base. 

I would guess that the DS8K boxes today got a lot smarter and implemented the 
track data or even track record data as separate objects managed by a volume 
TOC mechanism; which facilities all the DS8K enhancements of volume cloning, 
fast copy, check pointing, versioning, etc.  "Sparse type" file systems are 
also more common today. 

So individual dataset space is not a big issue.  You have to think at the 
enterprise level. 

However, the individual still needs to allocate their datasets correctly to 
satisfy the OS ... or for the zOS people, get an X37 abend processor...

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

Re: DFSORT: Building one record from two and ignore the rest

[Sri h Kolusu]

>>. So, what I need is to get the dataset name from the record that has "DSNAME 
>>=", the volser from the record that has "ODSN:" and format a single record 
>>with volser datasetname or datasetname volser

Jack

Use the following untested control cards which will give you the desired 
results assuming that DSNAME = record always have a OHSM  record as a pair.

//SYSINDD *
  OPTION COPY
  INCLUDE COND=(02,08,CH,EQ,C'DSNAME =',OR,
02,05,CH,EQ,C'OHSM.')

  INREC IFTHEN=(WHEN=GROUP,
   BEGIN=(02,08,CH,EQ,C'DSNAME ='),
 END=(02,05,CH,EQ,C'OHSM.'),
PUSH=(81:11,44))

  OUTFIL INCLUDE=(02,05,CH,EQ,C'OHSM.'),
   BUILD=(81,44,   # DSNAME
  2X,  # 2 SPACES
  47,06)   # VOLSER
/*


Thanks,
Kolusu
DFSORT Development
IBM Corporation



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

Re: Storage protection keys

[Paul Gorlinsky]

Apples and Oranges ... The final chip fab is usually the product of an 
underlying chip designed set with additional customization. 

Apple's M1 chip is a great example it is licensed ARM chip arch with lots 
of enhancements. So it is the M1 built on an ARM.

The way chips have been designed for several years now, is to use a set library 
of functions and pick and choose what you need. 

For example, from the ARM library, you take 4 performance cores, 2 efficient 
cores, 2 GPUs, a storage manager, interrupt controller, and PCIe for a start...

Then add 4M of L0 cache for each CPU, 32M L1 cache shared, and a 16G main 
storage and a 512G PCIe SSD ... all on the single chip carrier.

There were also enhancements added to facility Intel Emulation since they knew 
they had to support both native ARM instructs and run an emulator for all the 
existing Intel applications. Rosetta 2

Note: Apple did the same when they transitioned from the Power to Intel... 
Rosetta 

The Power CPUs are a great RISC engine. There were other projects in Apple at 
one time that had HPUX and AIX running on an Apple Power PC that never saw 
daylight ... 

But it is still an ARM ...

Intel's Xeon and Core chips are also RISC engines with X64 firmware ... Why do 
you think we get firmware patches to correct Xeon or Core instruction issues.

From a pure engineering stand, it would make sense to use the Power library as 
a foundation since they already owned the proven tech. Use it as a fast 
microcontroller, RISC engine, and add the additional functionality they needed 
to implement the zArch instruction set. That CHIP and Firmware would be 
uniquely a z-CHIP but at its heart is probably a Power engine. But it is just a 
guess.

When you couple the development of the z with the other two product lines, it 
is reasonable to assert that there is commonality there. Money being the 
driving force. 

It is also possible that the zArch engineers took an earlier version of the 
Power library and made it their own. Who actually knows what goes on that deep 
within IBM. 

Take the Z apart ... the Channel Cards, the IOP, the Storage books, the OSA, 
the PCIe interfaces, the Books that make up the CPUs, etc. This is a still a 
collection of microcontrollers working together to implement the z/Arch. 

It would also make good business sense that IBM would share as much tech as 
possible between the product lines of i-Server, p-Server and z-Server... in 
order to save costs.

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

Re: DFSORT: Building one record from two and ignore the rest

[Jack Zukt]

Hi Kolusu,

I must not have explained myself right.
The dataset name starts on position 11 of the record with "DSNAME ="
beginning on position 2 (the file has a recfm FBA); the volser starts on
position 47 of the record with "OHSM." beginning on position 2; all the
other records are irrelevant. So, what I need is to get the dataset name
from the record that has "DSNAME =", the volser from the record that has
"ODSN:" and format a single record with
volser datasetname
or
datasetname volser

Best wishes
Jack

On Thu, 24 Nov 2022 at 14:38, Sri h Kolusu  wrote:

> >> I need to create a single record, from the records with "DSNAME =" and
> "OHSM." with the dataset name from the first one (11(44)) and the volser
> from the last (47(6)):
> volser datasename
> or
> datasetname volser
>
>
> Jack,
>
> Your requirements do NOT match the input data.   For example, for DSNAME =
> record, where is the VOLSER ?
>
> //SYSINDD *
>   OPTION COPY
>   INCLUDE COND=(02,08,CH,EQ,C'DSNAME =',OR,
> 02,05,CH,EQ,C'OHSM.')
>
>   INREC IFTHEN=(WHEN=(02,08,CH,EQ,C'DSNAME ='),
>BUILD=(11,44)),
> IFTHEN=(WHEN=(02,05,CH,EQ,C'OHSM.'),
>BUILD=(02,51))
> /*
>
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
>
>
> --
> 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: Building one record from two and ignore the rest

[Sri h Kolusu]

>> I need to create a single record, from the records with "DSNAME =" and 
>> "OHSM." with the dataset name from the first one (11(44)) and the volser 
>> from the last (47(6)):
volser datasename
or
datasetname volser


Jack,

Your requirements do NOT match the input data.   For example, for DSNAME = 
record, where is the VOLSER ?

//SYSINDD *
  OPTION COPY
  INCLUDE COND=(02,08,CH,EQ,C'DSNAME =',OR,
02,05,CH,EQ,C'OHSM.')

  INREC IFTHEN=(WHEN=(02,08,CH,EQ,C'DSNAME ='),
   BUILD=(11,44)),
IFTHEN=(WHEN=(02,05,CH,EQ,C'OHSM.'),
   BUILD=(02,51))
/*


Thanks,
Kolusu
DFSORT Development
IBM Corporation



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

DFSORT: Building one record from two and ignore the rest

[Jack Zukt]

Hi,
I have a file that was built by a HSM command and that has a few thousand
groups of records such as this:
+1+2+3+4+5+6+7+8+9+0+1+2-
1- DFSMSHSM CONTROL DATASET - BACKUP DATASET-- LISTING - AT 10:34:25 ON
22/11/23 FOR SYSTEM=PRDX




 DSNAME = FXS.FORMCONT.CM.B211021A.FMTFGL.R1V02L02.QA   BACKUP FREQ = ***,
MAX ACTIVE BACKUP VERSIONS = ***


 BACKUP VERSION DATA SET NAME BACKUP FROM   BACKUP   BACKUP
  SYS GEN  VER  UNS/ RET  BACKUP NEW
  VOLUME VOLUME DATE TIME
  CAT NMBR NMBR RET  DAYS PROF   NAME


 OHSM.BACK.T280203.FXS.FORMCONT.B1301 TPV543 DVT554 21/10/28
03:01:07 YES 000  006   NO * NO N**
  ENCRYPTION TYPE = ***  KEYLABEL =




 TOTAL BACKUP VERSIONS = 01





 DSNAME = FXS.FORMCONT.CM.B211021A.FMTWSG.R1V02L01.QA   BACKUP FREQ = ***,
MAX ACTIVE BACKUP VERSIONS = ***


 BACKUP VERSION DATA SET NAME BACKUP FROM   BACKUP   BACKUP
  SYS GEN  VER  UNS/ RET  BACKUP NEW
  VOLUME VOLUME DATE TIME
  CAT NMBR NMBR RET  DAYS PROF   NAME


 OHSM.BACK.T291103.FXS.FORMCONT.B1301 TPV543 DVT361 21/10/28
03:11:17 YES 000  006   NO * NO N**
  ENCRYPTION TYPE = ***  KEYLABEL =



 TOTAL BACKUP VERSIONS = 01



I need to create a single record, from the records with "DSNAME =" and
"OHSM." with the dataset name from the first one (11(44)) and the volser
from the last (47(6)):

volser datasename
or
datasetname volser

Thank you for your help
Jack

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

Whether MSGFLD handle IOS050I,SUP(NO) in MPFLST.

[Jason Cai]

Hi all 

 IOS050I is defines in MPFLST as below:

IOS050I,SUP(NO)

IOS050I is defines in MSGFLD as below:

SPECIFIC MSGTHRESH=50,MSGLIMIT=20,INTVLTIME=1
SPECIFIC SYSIMTIME=0.25  
SPECIFIC MSGIMTIME=0.25  
MSG IOS050I NOLOG,NOAUTO,NODISPLAY,NORETAIN,NOIGNORE


Could you tell us whether MSGFLD  will handle ISO050I message or not ?

What is diffenent for MSGFLD between SUP(YES) and SUP(NO) msgid in MPFLST?

Thanks a lot!

Jason Cai

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

SAS ODS examples

[Kenneth J. Kripke]

Thank you Carmen and all who responded to my query.   

You have been MOST Helpful.

 

 

Sincerely; 

 

Kenneth Kripke 

: 

k.kri...@comcast.net 

 


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