Re: IEE345I Modify invalid authority
Thank you for your response So I believe I need to introduce RACF OPERCMDS even if it is maintained by ISFPRMXX. On Mon, 31 Aug, 2020, 9:11 am Brian Westerman, < brian_wester...@syzygyinc.com> wrote: > Even if you maintain SDSF via SAF (which you have to do by z/OS 2.5 > because that's all that will be supported) you will still have to update > the RACF OPERCMDS class (TSO RACF option 2 (general resource profiles)). > > The profile name you need to update (for MVS batch and STC's) is > MVS.MODIFY.**, for JES2 related stuff it would be JES2.MODIFY.**. I made > it simplistic by using the ** after the modify. You can actually get > pretty specific about what tasks are allowed to be modified by whom, but I > figured you just wanted to get around your problem right now. > > Brian > > -- > 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: IEE345I Modify invalid authority
Even if you maintain SDSF via SAF (which you have to do by z/OS 2.5 because that's all that will be supported) you will still have to update the RACF OPERCMDS class (TSO RACF option 2 (general resource profiles)). The profile name you need to update (for MVS batch and STC's) is MVS.MODIFY.**, for JES2 related stuff it would be JES2.MODIFY.**. I made it simplistic by using the ** after the modify. You can actually get pretty specific about what tasks are allowed to be modified by whom, but I figured you just wanted to get around your problem right now. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Simple VSAM question on sizing INDEX component
FWIW This VSAM index issue is most likely due to CI/CA splits. I would suggest unloading/deleting/reloading the complete VSAM cluster (if necessary ALTERing the original VSAM cluster to some temp other names instead of deleting it, after the unload and as a fall-back) to fix this. A FREESPACE(ca,ci) on reload is unlikely to achieve anything other than to waste DASD space. A dump of its current VSAM index would show what the actual problem is. On 31/08/2020 04:16, Mike Schwab wrote: > Well a 1, 2, 4, 7, 8, 11, 13, or 14 track index has 1 track CAs, 3, 6, > 9, or 12 for a 3 track CA, 5 or 10 for a 5 track CA, 15 tracks or more > for a 1 cylinder CA. Details then vary based on key size, > FREESPACE(ca ci) values, etc. Assuming reload after backup, delete, > define, restore. If you just delete old records then use will go up > with free space left by delete but insert doesn't use that space. > I.E. time stamp particularly bad primary key. > > On Sun, Aug 30, 2020 at 8:07 PM Michael Watkins > <032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: >> More efficient in terms of fewer index LEVELs as Tony Thigpen may have been >> getting at? I thought the number of LEVELs was contingent on the the size of >> the file and the number of CI and CA splits the index component had endured >> and not the allocation of contiguous space for the index component on DASD. >> A REORG should reduce the number of LEVELs to its smallest possible number, >> no? >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> Mike Schwab >> Sent: Sunday, August 30, 2020 7:48 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Simple VSAM question on sizing INDEX component >> >> CAUTION: This email originated from outside of the Texas Comptroller's email >> system. >> DO NOT click links or open attachments unless you expect them from the >> sender and know the content is safe. >> >> CYL(4 1) should leave one cylinder empty. Cylinder CA will result is a more >> efficient index. >> >> On Sun, Aug 30, 2020 at 5:12 PM Lizette Koehler >> wrote: >>> List - >>> >>> I have a VSAM Dataset that has grown over the years. When it was set >>> up - the INDEX space was left to default >>> >>> I am wondering if it makes sense to override the Track Allocation and >>> put it in Cylinders. >>> >>> We are noticing a little bit of an increase in run time during reorg. >>> I was wondering if this might be due to the data set having 3.4GB now. >>> >>> This file is EA/EF so it can grow >>> >>> Over 4500 Cylinders on the Data >>> >>> And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB >>> During reorg we offload records to an archive then reload the current >>> data back in >>> >>> This may be something I cannot improve on, just thought I would see if >>> there are any insights I am missing. >>> >>> Process: >>> Offload the data to a temp file >>> Archive records older than 2 weeks >>> Del/Def VSAM dataset >>> Reload current records to VSAM dataset >>> This runs daily >>> >>> Thank you >>> Lizette >>> >>> -- >>> 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 >> >> -- >> 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: IEE345I Modify invalid authority
Just curious why you do not control SDSF through your SAF Product. I removed all of my ISFPARMxx setup and allow our SAF to control who can do what in SDSF. Now the security team is responsible. Lizette -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Sent: Sunday, August 30, 2020 8:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IEE345I Modify invalid authority Hello I am trying to issue a command using SDSF batch and I end up with IEE345I Modify invalid authority failed by MVS We have secured SDSF using ISFPRM My ID and group are part of NTBL in ISFPRMxx and group name is assigned under the GROUP which maps to my RACF Group (Default) We are in zOS 2.2 and apart from above what else I need to look ? Any pointers are much appreciated Regards Peter -- 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
IEE345I Modify invalid authority
Hello I am trying to issue a command using SDSF batch and I end up with IEE345I Modify invalid authority failed by MVS We have secured SDSF using ISFPRM My ID and group are part of NTBL in ISFPRMxx and group name is assigned under the GROUP which maps to my RACF Group (Default) We are in zOS 2.2 and apart from above what else I need to look ? Any pointers are much appreciated Regards Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Simple VSAM question on sizing INDEX component
Well a 1, 2, 4, 7, 8, 11, 13, or 14 track index has 1 track CAs, 3, 6, 9, or 12 for a 3 track CA, 5 or 10 for a 5 track CA, 15 tracks or more for a 1 cylinder CA. Details then vary based on key size, FREESPACE(ca ci) values, etc. Assuming reload after backup, delete, define, restore. If you just delete old records then use will go up with free space left by delete but insert doesn't use that space. I.E. time stamp particularly bad primary key. On Sun, Aug 30, 2020 at 8:07 PM Michael Watkins <032966e74d0f-dmarc-requ...@listserv.ua.edu> wrote: > > More efficient in terms of fewer index LEVELs as Tony Thigpen may have been > getting at? I thought the number of LEVELs was contingent on the the size of > the file and the number of CI and CA splits the index component had endured > and not the allocation of contiguous space for the index component on DASD. A > REORG should reduce the number of LEVELs to its smallest possible number, no? > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Mike Schwab > Sent: Sunday, August 30, 2020 7:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Simple VSAM question on sizing INDEX component > > CAUTION: This email originated from outside of the Texas Comptroller's email > system. > DO NOT click links or open attachments unless you expect them from the sender > and know the content is safe. > > CYL(4 1) should leave one cylinder empty. Cylinder CA will result is a more > efficient index. > > On Sun, Aug 30, 2020 at 5:12 PM Lizette Koehler > wrote: > > > > List - > > > > I have a VSAM Dataset that has grown over the years. When it was set > > up - the INDEX space was left to default > > > > I am wondering if it makes sense to override the Track Allocation and > > put it in Cylinders. > > > > We are noticing a little bit of an increase in run time during reorg. > > I was wondering if this might be due to the data set having 3.4GB now. > > > > This file is EA/EF so it can grow > > > > Over 4500 Cylinders on the Data > > > > And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB > > During reorg we offload records to an archive then reload the current > > data back in > > > > This may be something I cannot improve on, just thought I would see if > > there are any insights I am missing. > > > > Process: > > Offload the data to a temp file > > Archive records older than 2 weeks > > Del/Def VSAM dataset > > Reload current records to VSAM dataset > > This runs daily > > > > Thank you > > Lizette > > > > -- > > 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 > > -- > 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: Simple VSAM question on sizing INDEX component
[Default] On 30 Aug 2020 15:12:07 -0700, in bit.listserv.ibm-main stars...@mindspring.com (Lizette Koehler) wrote: >List - > > > >I have a VSAM Dataset that has grown over the years. When it was set up - >the INDEX space was left to default > One other thing to check for in addition to the other recommendations given is whether or not the file should have grown this large. I ran into a case in one shop I was at where records were getting on the file but because of a coding error only certain ones were getting updated and removed. I was a systems programmer who went back into applications and was actually tracking down why a run time had increased. Clark Morris > >I am wondering if it makes sense to override the Track Allocation and put it >in Cylinders. > > > >We are noticing a little bit of an increase in run time during reorg. I was >wondering if this might be due to the data set having 3.4GB now. This file >is EA/EF so it can grow > > > >Over 4500 Cylinders on the Data > >And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB > > > > > >During reorg we offload records to an archive then reload the current data >back in. > > > >This may be something I cannot improve on, just thought I would see if there >are any insights I am missing. > > > >Process: >Offload the data to a temp file > >Archive records older than 2 weeks > >Del/Def VSAM dataset > >Reload current records to VSAM dataset > > > >This runs daily > > >Thank you > > > >Lizette > > >-- >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: Simple VSAM question on sizing INDEX component
Number of index levels is affected by data CA/CI sizes, index CA/CI sizes and how well the key "compresses" between adjacent CIs. Until you have a loaded file, you can't be positive about how many levels you have. But, once you have it loaded, it's easier to make adjustments prior to another re-load. Too many index levels usually indicate something else is not right. Tony Thigpen Michael Watkins wrote on 8/30/20 9:07 PM: More efficient in terms of fewer index LEVELs as Tony Thigpen may have been getting at? I thought the number of LEVELs was contingent on the the size of the file and the number of CI and CA splits the index component had endured and not the allocation of contiguous space for the index component on DASD. A REORG should reduce the number of LEVELs to its smallest possible number, no? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Sunday, August 30, 2020 7:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Simple VSAM question on sizing INDEX component CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. CYL(4 1) should leave one cylinder empty. Cylinder CA will result is a more efficient index. On Sun, Aug 30, 2020 at 5:12 PM Lizette Koehler wrote: List - I have a VSAM Dataset that has grown over the years. When it was set up - the INDEX space was left to default I am wondering if it makes sense to override the Track Allocation and put it in Cylinders. We are noticing a little bit of an increase in run time during reorg. I was wondering if this might be due to the data set having 3.4GB now. This file is EA/EF so it can grow Over 4500 Cylinders on the Data And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB During reorg we offload records to an archive then reload the current data back in This may be something I cannot improve on, just thought I would see if there are any insights I am missing. Process: Offload the data to a temp file Archive records older than 2 weeks Del/Def VSAM dataset Reload current records to VSAM dataset This runs daily Thank you Lizette -- 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 -- 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: Simple VSAM question on sizing INDEX component
More efficient in terms of fewer index LEVELs as Tony Thigpen may have been getting at? I thought the number of LEVELs was contingent on the the size of the file and the number of CI and CA splits the index component had endured and not the allocation of contiguous space for the index component on DASD. A REORG should reduce the number of LEVELs to its smallest possible number, no? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Sunday, August 30, 2020 7:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Simple VSAM question on sizing INDEX component CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. CYL(4 1) should leave one cylinder empty. Cylinder CA will result is a more efficient index. On Sun, Aug 30, 2020 at 5:12 PM Lizette Koehler wrote: > > List - > > I have a VSAM Dataset that has grown over the years. When it was set > up - the INDEX space was left to default > > I am wondering if it makes sense to override the Track Allocation and > put it in Cylinders. > > We are noticing a little bit of an increase in run time during reorg. > I was wondering if this might be due to the data set having 3.4GB now. > > This file is EA/EF so it can grow > > Over 4500 Cylinders on the Data > > And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB > During reorg we offload records to an archive then reload the current > data back in > > This may be something I cannot improve on, just thought I would see if > there are any insights I am missing. > > Process: > Offload the data to a temp file > Archive records older than 2 weeks > Del/Def VSAM dataset > Reload current records to VSAM dataset > This runs daily > > Thank you > Lizette > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Simple VSAM question on sizing INDEX component
CYL(4 1) should leave one cylinder empty. Cylinder CA will result is a more efficient index. On Sun, Aug 30, 2020 at 5:12 PM Lizette Koehler wrote: > > List - > > > > I have a VSAM Dataset that has grown over the years. When it was set up - > the INDEX space was left to default > > > > I am wondering if it makes sense to override the Track Allocation and put it > in Cylinders. > > > > We are noticing a little bit of an increase in run time during reorg. I was > wondering if this might be due to the data set having 3.4GB now. This file > is EA/EF so it can grow > > > > Over 4500 Cylinders on the Data > > And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB > > > > > > During reorg we offload records to an archive then reload the current data > back in. > > > > This may be something I cannot improve on, just thought I would see if there > are any insights I am missing. > > > > Process: > Offload the data to a temp file > > Archive records older than 2 weeks > > Del/Def VSAM dataset > > Reload current records to VSAM dataset > > > > This runs daily > > > Thank you > > > > Lizette > > > -- > 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: Simple VSAM question on sizing INDEX component
How many index levels do you have? Tony Thigpen Lizette Koehler wrote on 8/30/20 6:11 PM: List - I have a VSAM Dataset that has grown over the years. When it was set up - the INDEX space was left to default I am wondering if it makes sense to override the Track Allocation and put it in Cylinders. We are noticing a little bit of an increase in run time during reorg. I was wondering if this might be due to the data set having 3.4GB now. This file is EA/EF so it can grow Over 4500 Cylinders on the Data And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB During reorg we offload records to an archive then reload the current data back in. This may be something I cannot improve on, just thought I would see if there are any insights I am missing. Process: Offload the data to a temp file Archive records older than 2 weeks Del/Def VSAM dataset Reload current records to VSAM dataset This runs daily Thank you Lizette -- 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: Simple VSAM question on sizing INDEX component
Of course, buffering will probably do the most to improve VSAM REORG times.
For the sequential reads through the cluster that are typical of REORG
activity, add the ',AMP=('BUFNI=x,BUFND=yyy')' parameter to the DD card, where
'x' equals the number of index component LEVELS displayed in the IDCAMS
'LISTCAT ENT() ALL' output and 'yyy' equals the number of data
component CIs in one data CA.
This will assure that every chain of channel commands reads an entire virtual
cylinder. When the virtual read/write heads cross a cylinder boundaries, the
channel program will lose control, so no more than a cylinder can be read or
written by a channel program.
To optimize the value of 'yyy' for BUFND, look at the data component of the
'LISTC ENT() ALL'. Find the values for 'CI/CA' and 'TRACKS/CA'. Since
there are 15 tracks in a 3390 cylinder, you can easily calculate the number of
data CIs in one cylinder. Add one to this value and use that for BUFND.
Why add one? Some pople say the code reserves one CI for SPLIT activity, even
when the odds of it occuring are low. Some people say adding one for a CI
reserved for SPLIT activity is an old-wives tale, but it seems to work.
-Original Message-
From: Michael Watkins
Sent: Sunday, August 30, 2020 6:00 PM
To: IBM Mainframe Discussion List
Cc: Michael Watkins
Subject: RE: Simple VSAM question on sizing INDEX component
The index component alone is 2.4 MB? 2,400,000/56664 = 43 tracks? Sure,
Allocate the index component as 4 or even 5 cylinders primary and a single
cylinder secondary.
If the cluster has changed significantly over time, I might also run an IDCAMS
EXAMINE command:
EXAMINE NAME() INDEXTEST DATATEST
And look for:
IDC01728I FOUND n EMPTY CONTROL AREAS THAT HAVE NOT BEEN RECLAIMED IDC11775I
nnn DATA COMPONENT CIS ARE ESTIMATED TO BE UNREACHABLE
These may indicate that you want to change the index CI size, although buffer
specifications may also have to change if you do.
And I assume you have already activated 'CA reclaim' for all pertinent
DATACLASes in ISMF.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette Koehler
Sent: Sunday, August 30, 2020 5:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Simple VSAM question on sizing INDEX component
CAUTION: This email originated from outside of the Texas Comptroller's email
system.
DO NOT click links or open attachments unless you expect them from the sender
and know the content is safe.
List -
I have a VSAM Dataset that has grown over the years. When it was set up - the
INDEX space was left to default
I am wondering if it makes sense to override the Track Allocation and put it in
Cylinders.
We are noticing a little bit of an increase in run time during reorg. I was
wondering if this might be due to the data set having 3.4GB now. This file is
EA/EF so it can grow
Over 4500 Cylinders on the Data
And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB
During reorg we offload records to an archive then reload the current data back
in.
This may be something I cannot improve on, just thought I would see if there
are any insights I am missing.
Process:
Offload the data to a temp file
Archive records older than 2 weeks
Del/Def VSAM dataset
Reload current records to VSAM dataset
This runs daily
Thank you
Lizette
--
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: Simple VSAM question on sizing INDEX component
The index component alone is 2.4 MB? 2,400,000/56664 = 43 tracks? Sure, Allocate the index component as 4 or even 5 cylinders primary and a single cylinder secondary. If the cluster has changed significantly over time, I might also run an IDCAMS EXAMINE command: EXAMINE NAME() INDEXTEST DATATEST And look for: IDC01728I FOUND n EMPTY CONTROL AREAS THAT HAVE NOT BEEN RECLAIMED IDC11775I nnn DATA COMPONENT CIS ARE ESTIMATED TO BE UNREACHABLE These may indicate that you want to change the index CI size, although buffer specifications may also have to change if you do. And I assume you have already activated 'CA reclaim' for all pertinent DATACLASes in ISMF. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler Sent: Sunday, August 30, 2020 5:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Simple VSAM question on sizing INDEX component CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. List - I have a VSAM Dataset that has grown over the years. When it was set up - the INDEX space was left to default I am wondering if it makes sense to override the Track Allocation and put it in Cylinders. We are noticing a little bit of an increase in run time during reorg. I was wondering if this might be due to the data set having 3.4GB now. This file is EA/EF so it can grow Over 4500 Cylinders on the Data And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB During reorg we offload records to an archive then reload the current data back in. This may be something I cannot improve on, just thought I would see if there are any insights I am missing. Process: Offload the data to a temp file Archive records older than 2 weeks Del/Def VSAM dataset Reload current records to VSAM dataset This runs daily Thank you Lizette -- 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
Simple VSAM question on sizing INDEX component
List - I have a VSAM Dataset that has grown over the years. When it was set up - the INDEX space was left to default I am wondering if it makes sense to override the Track Allocation and put it in Cylinders. We are noticing a little bit of an increase in run time during reorg. I was wondering if this might be due to the data set having 3.4GB now. This file is EA/EF so it can grow Over 4500 Cylinders on the Data And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB During reorg we offload records to an archive then reload the current data back in. This may be something I cannot improve on, just thought I would see if there are any insights I am missing. Process: Offload the data to a temp file Archive records older than 2 weeks Del/Def VSAM dataset Reload current records to VSAM dataset This runs daily Thank you Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sending email from the Mainframe
My source is the IETF, and every issue is a semantic issue. I did searches for bounce and DSN on a bunch of RFCs, and they all agreed. In particular, thr RFC that you cited, 3464, lists DSN types that are not bounces. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> Sent: Sunday, August 30, 2020 11:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sending email from the Mainframe On 8/29/20 6:50 PM, Seymour J Metz wrote: > According to the IETF, every bounce is a DSN but not every DSN is a bounce. Would you please cite your source? I also wonder if we're having somewhat of a semantic issue. I'm specifically referring to a bounce (which is a superset of the latter) that is formatted per RFC 3464 -- An Extensible Message Format for Delivery Status Notifications (which is a subset of the former). Per RFC 3462 § 2 — Format of a Delivery Status Notification — A DSN is a MIME message with a top-level content-type of multipart/report (defined in [REPORT]). When a multipart/report content is used to transmit a DSN: (a) The report-type parameter of the multipart/report content is "delivery-status". (b) The first component of the multipart/report contains a human-readable explanation of the DSN, as described in [REPORT]. (c) The second component of the multipart/report is of content-type message/delivery-status, described in section 2.1 of this document. (d) If the original message or a portion of the message is to be returned to the sender, it appears as the third component of the multipart/report. Not all bounces conform to these specifications, ergo not all bounces are a DSN (as specified by RFC 3462). All (failure) DSNs are bounces. Aside: I guess there are also success DSNs. I don't know if they would be considered a bounce or not. They are an email about the delivery of another email, thus fall into the category of bounce like email. -- Grant. . . . unix || die -- 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: Sending email from the Mainframe
On 8/29/20 6:50 PM, Seymour J Metz wrote: According to the IETF, every bounce is a DSN but not every DSN is a bounce. Would you please cite your source? I also wonder if we're having somewhat of a semantic issue. I'm specifically referring to a bounce (which is a superset of the latter) that is formatted per RFC 3464 -- An Extensible Message Format for Delivery Status Notifications (which is a subset of the former). Per RFC 3462 § 2 — Format of a Delivery Status Notification — A DSN is a MIME message with a top-level content-type of multipart/report (defined in [REPORT]). When a multipart/report content is used to transmit a DSN: (a) The report-type parameter of the multipart/report content is "delivery-status". (b) The first component of the multipart/report contains a human-readable explanation of the DSN, as described in [REPORT]. (c) The second component of the multipart/report is of content-type message/delivery-status, described in section 2.1 of this document. (d) If the original message or a portion of the message is to be returned to the sender, it appears as the third component of the multipart/report. Not all bounces conform to these specifications, ergo not all bounces are a DSN (as specified by RFC 3462). All (failure) DSNs are bounces. Aside: I guess there are also success DSNs. I don't know if they would be considered a bounce or not. They are an email about the delivery of another email, thus fall into the category of bounce like email. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
