Re: Determine level of fragmentation in VTOCIX?

2019-07-15 Thread Mike Schwab 
Yes.  LOTS of small report datasets.  We had problems with them too.
Ended up creating Mod 9 VTOCs on Mod 3s.  The sizes in IBMś ICKDSF
manual are for a volume filled will 1 track datasets.

On Mon, Jul 15, 2019 at 4:47 PM Gibney, Dave  wrote:
>
> The pointer to DCOLLECT and reporting on Free VIRs (MXG variable DCVFRVIRS) 
> has helped me find potential problem volumes.
> And rebuilding the VTOCIX (ICFDSF REFORMAT REFVTOC EXTINDEX(current size)) 
> has seemed to have repaired the few volumes that were giving me trouble. I 
> also found several volumes where the VTOCIX was still (or back) in OSVTOC 
> format. I am resetting (BUILDIX IXVTOC)  them.
>
> What I still don't know is why, out of 24 volumes (with identical, AFAICT, 
> SMS attributes on the storage group) most have 300-400 datasets and 3 have 
> 2000-4000+ datasets. Even repaired, the volume that first got my attention, 
> with 4366 datasets has only 36 free VIR as opposed to the ~250 that most of 
> the others have.
>
> I am beginning to suspect that the Control-D product has some "feature" where 
> it "prefers" specific volumes despite SMS, as most of the 2000 to 4000 
> datasets are archived reports. But, there are some archived report datasets 
> on the other volumes.
>
> I am thinking I'll QUINEW the 3 outlier volumes and see what happens.
>
>
> > -Original Message-
> > From: Willie Bunter 
> > Sent: Monday, July 15, 2019 6:44 AM
> > To: Gibney, Dave 
> > Subject: Re: Determine level of fragmentation in VTOCIX?
> >
> > Hi Dave,
> >
> > Just curious.  Were you able to fix the problem?  Was your question
> > answered?
> >
> > Thanks.
>
>
> --
> 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: Determine level of fragmentation in VTOCIX?

2019-07-15 Thread Gibney, Dave 
The pointer to DCOLLECT and reporting on Free VIRs (MXG variable DCVFRVIRS) has 
helped me find potential problem volumes.
And rebuilding the VTOCIX (ICFDSF REFORMAT REFVTOC EXTINDEX(current size)) has 
seemed to have repaired the few volumes that were giving me trouble. I also 
found several volumes where the VTOCIX was still (or back) in OSVTOC format. I 
am resetting (BUILDIX IXVTOC)  them.

What I still don't know is why, out of 24 volumes (with identical, AFAICT, SMS 
attributes on the storage group) most have 300-400 datasets and 3 have 
2000-4000+ datasets. Even repaired, the volume that first got my attention, 
with 4366 datasets has only 36 free VIR as opposed to the ~250 that most of the 
others have.

I am beginning to suspect that the Control-D product has some "feature" where 
it "prefers" specific volumes despite SMS, as most of the 2000 to 4000 datasets 
are archived reports. But, there are some archived report datasets on the other 
volumes.

I am thinking I'll QUINEW the 3 outlier volumes and see what happens.


> -Original Message-
> From: Willie Bunter 
> Sent: Monday, July 15, 2019 6:44 AM
> To: Gibney, Dave 
> Subject: Re: Determine level of fragmentation in VTOCIX?
> 
> Hi Dave,
> 
> Just curious.  Were you able to fix the problem?  Was your question
> answered?
> 
> Thanks.


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

Re: Determine level of fragmentation in VTOCIX?

2019-07-12 Thread Allan Staller 
". Odds are real strong that we will be off of z/OS by January 2021, July at 
latest."

I've heard that one before. Usually about 5-10 years after the previous "we'll 
be off by"

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Thursday, July 11, 2019 4:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Determine level of fragmentation in VTOCIX?

Thanks, converting to CSSMTP is something I am considering. But, I am unlikely 
to go to z/OS 2.3, probably not even 2.2. Odds are real strong that we will be 
off of z/OS by January 2021, July at latest. Management really doesn't wish to 
renew the MFaaS contract.

I am very much in a keep it going/minimal disruption mode.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Cieri, Anthony
> Sent: Thursday, July 11, 2019 2:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determine level of fragmentation in VTOCIX?
>
> Dave,
>
> This does not answer your question, but it appears from the error
> messages that you are still running the older zOS SMTP task. ZOS
> Communication Server now provides a new CSSMTP task, which no longer
> copies the spool files to sequential dataset and plays the dataset  "rename"
> game.  SMTP is going to be dropped from support soon ( after zOS V2.2 ??)
> We use to see errors like these from time to time, but they have
> disappeared since migrated to CSSMTP.
>
> Hth
> Tony
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Thursday, July 11, 2019 4:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Determine level of fragmentation in VTOCIX?
>
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders.
> *** ]]
>
>
> Is there a way to determine if and how much a VTOCIX is fragmented.
> Way back when (when disk wasn't quite so cheap), we standardized on
> parking the VTOCIX in the 14 tracks left in the 1st cylinder, and for
> a Mod-3, VTOC of
> 105 tracks (7CYL) immediately following, and usually a 2 CYL VVDS
> right after that. Most of my SMS managed application disks still
> follow this. And it worked well for many years.
>
> But, during high volumes of SMTP activity, I have begun to get:
>
> IEC603I VTOC ERRORS MAY EXIST ON C465,PPRD22,8,027
> IEC331I 042-002(0812041B),SMTP,SMTP,RNAM,IGG0CLH2
> IEC331I VOL,PPRD22,NAME,SMTP.CONN257.NOTE IGD17003I PERMANENT I/O
> ERROR ON VOLUME PPRD22 139 FOR DATA SET SMTP.CONN257.NOTE HISTORIC
> RETURN CODE IS 8 DADSM DIAGNOSTIC INFORMATION IS 0812041B IGD306I
> UNEXPECTED ERROR DURING IGGDAR02 PROCESSING 140 RETURN CODE 8 REASON
> CODE 27 THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA SMS MODULE
> TRACE BACK - VTSDA VTSCU VTSCT VTSRN SSIRT SYMPTOM RECORD CREATED,
> PROBLEM ID IS IGD00898 IEC614I RENAME FAILED - RC 008, DIAGNOSTIC
> INFORMATION IS (0812041B),
> 141
> SMTP,PPRD22,SMTP.CONN257.NOTE
> EZA5544E Unable to RENAME file SMTP.CONN257.NOTE to SMTP.A0258454.NOTE
> rc=408
> EZA5568E UNABLE TO ALLOCATE ADDRBLOK DATA SET CORRECTLY
>
> SMTP is playing a dataset rename game - SMTP.TEMP.NOTE to
> SMTP.CONNnnn.NOTE (a 3 character length increase)
>
> SMTP then kindly sends a blank email to the recipient which then gets
> reported as suspicious :)
>
> I don't remember how we reached the numbers we used, but looking at
> the info the ICKDSF manual, the 14 track index should be large enough
> for the
> 5250 datasets possible with a 105 track VTOC. I an wondering if I can
> REFORMAT REFVTOC EXTINDEX(14) and get refreshed, unfragmented VTOCIX.
>
> Dave Gibney
> Information Technology Services
> Washington State University
>
>
> --
> 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
::DISCLAIMER::
--
The contents of this e-mail and

Re: Determine level of fragmentation in VTOCIX?

2019-07-12 Thread Allan Staller 
Reserve/Release processing?  Check GRSRNL00 for SYSIGGV2 (catalog) SYSZVTOC 
(obvious) SYSZVVDS (obvious),
Service class/dispatch priority of the CSSMTP task?

You might also try rebuilding the VTOCIX on the volume.

HTH,



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Thursday, July 11, 2019 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Determine level of fragmentation in VTOCIX?

Is there a way to determine if and how much a VTOCIX is fragmented. Way back 
when (when disk wasn't quite so cheap), we standardized on parking the VTOCIX 
in the 14 tracks left in the 1st cylinder, and for a Mod-3, VTOC of 105 tracks 
(7CYL) immediately following, and usually a 2 CYL VVDS right after that. Most 
of my SMS managed application disks still follow this. And it worked well for 
many years.

But, during high volumes of SMTP activity, I have begun to get:

IEC603I VTOC ERRORS MAY EXIST ON C465,PPRD22,8,027
IEC331I 042-002(0812041B),SMTP,SMTP,RNAM,IGG0CLH2
IEC331I VOL,PPRD22,NAME,SMTP.CONN257.NOTE IGD17003I PERMANENT I/O ERROR ON 
VOLUME PPRD22 139 FOR DATA SET SMTP.CONN257.NOTE HISTORIC RETURN CODE IS 8 
DADSM DIAGNOSTIC INFORMATION IS 0812041B IGD306I UNEXPECTED ERROR DURING 
IGGDAR02 PROCESSING 140 RETURN CODE 8 REASON CODE 27 THE MODULE THAT DETECTED 
THE ERROR IS IGDVTSDA SMS MODULE TRACE BACK - VTSDA VTSCU VTSCT VTSRN SSIRT 
SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00898 IEC614I RENAME FAILED - RC 008, 
DIAGNOSTIC INFORMATION IS (0812041B),
141
SMTP,PPRD22,SMTP.CONN257.NOTE
EZA5544E Unable to RENAME file SMTP.CONN257.NOTE to SMTP.A0258454.NOTE
rc=408
EZA5568E UNABLE TO ALLOCATE ADDRBLOK DATA SET CORRECTLY

SMTP is playing a dataset rename game - SMTP.TEMP.NOTE to SMTP.CONNnnn.NOTE (a 
3 character length increase)

SMTP then kindly sends a blank email to the recipient which then gets reported 
as suspicious :)

I don't remember how we reached the numbers we used, but looking at the info 
the ICKDSF manual, the 14 track index should be large enough for the 5250 
datasets possible with a 105 track VTOC. I an wondering if I can REFORMAT 
REFVTOC EXTINDEX(14) and get refreshed, unfragmented VTOCIX.

Dave Gibney
Information Technology Services
Washington State University


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: Determine level of fragmentation in VTOCIX?

2019-07-11 Thread Gibney, Dave 
DSCBs or datasets are pretty equivalent for this calc. Although I'm not sure 
free spaces are indexed.
Anyway, the messages are clear, it's my VTOCIX that is full, not the VTOC. 
With Curtis's clue, I'll check and confirm via DCOLLECT/MXG and then rebuild 
the VTOCIX.

Thanks to all for the help.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Mike Schwab
> Sent: Thursday, July 11, 2019 3:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determine level of fragmentation in VTOCIX?
> 
> Don't you mean 5250 DSCBs?  1 for the first 5 extents on a PS, and 1 if any
> extents over 5 to the limit?  Also you have to have a DSCB for each free space
> extent.  My guess is your VTOC is full, because when you need another
> extent, you also need a free space record.
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__en.wikipedia.org_wiki_Volume-5FTable-5Fof-
> 5FContents=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw=u9g8rUevBoyCPAdo5sWE9w=PVubGLGfvoz3GXBke48wI2veoJ3
> ilGiF4T_wx_JLE3o=TZAmDqparOHhNMhXohu0SwylCZscUGOx9gCM7furq
> ws=
> 
> Here is the table of Maximum VTOC and VTOCIX sizes for various devices and
> 3380/3390 number of cylinders.  EAVs would use the 64K cylinder size.
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ibm.com_support_knowledgecenter_en_SSLTBW-
> 5F2.3.0_com.ibm.zos.v2r3.ickug00_ick40744.htm-23ick40-2Dgen745-5F-
> 5Fmvtoc=DwIFaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw=u9g8rUevBoyCPAdo5sWE9w=PVubGLGfvoz3GXBke48wI2veoJ3
> ilGiF4T_wx_JLE3o=UBqnH6rbqMudvVVOjW3y1eA3ruFjAEBN9Yp6Do5Qe-
> 0=
> 
> On Thu, Jul 11, 2019 at 8:47 PM Gibney, Dave  wrote:
> >
> > Is there a way to determine if and how much a VTOCIX is fragmented. Way
> back when (when disk wasn't quite so cheap), we standardized on parking
> the VTOCIX in the 14 tracks left in the 1st cylinder, and for a Mod-3, VTOC of
> 105 tracks (7CYL) immediately following, and usually a 2 CYL VVDS right after
> that. Most of my SMS managed application disks still follow this. And it
> worked well for many years.
> >
> > But, during high volumes of SMTP activity, I have begun to get:
> >
> > IEC603I VTOC ERRORS MAY EXIST ON C465,PPRD22,8,027
> > IEC331I 042-002(0812041B),SMTP,SMTP,RNAM,IGG0CLH2
> > IEC331I VOL,PPRD22,NAME,SMTP.CONN257.NOTE IGD17003I PERMANENT
> I/O
> > ERROR ON VOLUME PPRD22 139 FOR DATA SET SMTP.CONN257.NOTE
> HISTORIC
> > RETURN CODE IS 8 DADSM DIAGNOSTIC INFORMATION IS 0812041B
> IGD306I
> > UNEXPECTED ERROR DURING IGGDAR02 PROCESSING 140 RETURN CODE 8
> REASON
> > CODE 27 THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA SMS
> MODULE
> > TRACE BACK - VTSDA VTSCU VTSCT VTSRN SSIRT SYMPTOM RECORD
> CREATED,
> > PROBLEM ID IS IGD00898 IEC614I RENAME FAILED - RC 008, DIAGNOSTIC
> > INFORMATION IS (0812041B),
> > 141
> > SMTP,PPRD22,SMTP.CONN257.NOTE
> > EZA5544E Unable to RENAME file SMTP.CONN257.NOTE to
> SMTP.A0258454.NOTE
> > rc=408
> > EZA5568E UNABLE TO ALLOCATE ADDRBLOK DATA SET CORRECTLY
> >
> > SMTP is playing a dataset rename game - SMTP.TEMP.NOTE to
> > SMTP.CONNnnn.NOTE (a 3 character length increase)
> >
> > SMTP then kindly sends a blank email to the recipient which then gets
> > reported as suspicious :)
> >
> > I don't remember how we reached the numbers we used, but looking at
> the info the ICKDSF manual, the 14 track index should be large enough for
> the 5250 datasets possible with a 105 track VTOC. I an wondering if I can
> REFORMAT REFVTOC EXTINDEX(14) and get refreshed, unfragmented
> VTOCIX.
> >
> > Dave Gibney
> > Information Technology Services
> > Washington State University
> >
> >
> > --
> > 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: Determine level of fragmentation in VTOCIX?

2019-07-11 Thread Gibney, Dave 


> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Pew, Curtis G
> Sent: Thursday, July 11, 2019 3:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determine level of fragmentation in VTOCIX?
> 
> On Jul 11, 2019, at 3:43 PM, Gibney, Dave
> mailto:gib...@wsu.edu>> wrote:
> 

> I don't remember how we reached the numbers we used, but looking at the
> info the ICKDSF manual, the 14 track index should be large enough for the
> 5250 datasets possible with a 105 track VTOC. I an wondering if I can
> REFORMAT REFVTOC EXTINDEX(14) and get refreshed, unfragmented
> VTOCIX.
> 
> 
> Every week I run DCOLLECT to get the count of free VIRs on my SMS
> volumes. If that number gets too small (which it hasn’t for quite a while, as
> I’ve increased the size of the VTOC indices on all volumes) then I run ICKDSF
> ‘BUILDIX OS NOPURGE’ followed by ‘BUILDIX IX’. That always seemed to
> prevent these errors.
> 

Thanks, I should have thought to look at DCOLLECT. Which is run daily into MXG. 
I suspect I can pull this info easily with this clue :)
Also, thanks for the confirmation that the index rebuild should help.

> 
> --
> Pew, Curtis G
> curtis@austin.utexas.edu<mailto:curtis@austin.utexas.edu>
> 
> 
> 
> 
> 
> 
> --
> 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: Determine level of fragmentation in VTOCIX?

2019-07-11 Thread Mike Schwab 
Don't you mean 5250 DSCBs?  1 for the first 5 extents on a PS, and 1
if any extents over 5 to the limit?  Also you have to have a DSCB for
each free space extent.  My guess is your VTOC is full, because when
you need another extent, you also need a free space record.
https://en.wikipedia.org/wiki/Volume_Table_of_Contents

Here is the table of Maximum VTOC and VTOCIX sizes for various devices
and 3380/3390 number of cylinders.  EAVs would use the 64K cylinder
size.  
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ickug00/ick40744.htm#ick40-gen745__mvtoc

On Thu, Jul 11, 2019 at 8:47 PM Gibney, Dave  wrote:
>
> Is there a way to determine if and how much a VTOCIX is fragmented. Way back 
> when (when disk wasn't quite so cheap), we standardized on parking the VTOCIX 
> in the 14 tracks left in the 1st cylinder, and for a Mod-3, VTOC of 105 
> tracks (7CYL) immediately following, and usually a 2 CYL VVDS right after 
> that. Most of my SMS managed application disks still follow this. And it 
> worked well for many years.
>
> But, during high volumes of SMTP activity, I have begun to get:
>
> IEC603I VTOC ERRORS MAY EXIST ON C465,PPRD22,8,027
> IEC331I 042-002(0812041B),SMTP,SMTP,RNAM,IGG0CLH2
> IEC331I VOL,PPRD22,NAME,SMTP.CONN257.NOTE
> IGD17003I PERMANENT I/O ERROR ON VOLUME PPRD22 139
> FOR DATA SET SMTP.CONN257.NOTE
> HISTORIC RETURN CODE IS 8 DADSM DIAGNOSTIC INFORMATION IS 0812041B
> IGD306I UNEXPECTED ERROR DURING IGGDAR02 PROCESSING 140
> RETURN CODE 8 REASON CODE 27
> THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA
> SMS MODULE TRACE BACK - VTSDA VTSCU VTSCT VTSRN SSIRT
> SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00898
> IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0812041B),
> 141
> SMTP,PPRD22,SMTP.CONN257.NOTE
> EZA5544E Unable to RENAME file SMTP.CONN257.NOTE to SMTP.A0258454.NOTE
> rc=408
> EZA5568E UNABLE TO ALLOCATE ADDRBLOK DATA SET CORRECTLY
>
> SMTP is playing a dataset rename game - SMTP.TEMP.NOTE to SMTP.CONNnnn.NOTE 
> (a 3 character length increase)
>
> SMTP then kindly sends a blank email to the recipient which then gets 
> reported as suspicious :)
>
> I don't remember how we reached the numbers we used, but looking at the info 
> the ICKDSF manual, the 14 track index should be large enough for the 5250 
> datasets possible with a 105 track VTOC. I an wondering if I can REFORMAT 
> REFVTOC EXTINDEX(14) and get refreshed, unfragmented VTOCIX.
>
> Dave Gibney
> Information Technology Services
> Washington State University
>
>
> --
> 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: Determine level of fragmentation in VTOCIX?

2019-07-11 Thread Pew, Curtis G 
On Jul 11, 2019, at 3:43 PM, Gibney, Dave 
mailto:gib...@wsu.edu>> wrote:

But, during high volumes of SMTP activity, I have begun to get:

IEC603I VTOC ERRORS MAY EXIST ON C465,PPRD22,8,027
IEC331I 042-002(0812041B),SMTP,SMTP,RNAM,IGG0CLH2
IEC331I VOL,PPRD22,NAME,SMTP.CONN257.NOTE
IGD17003I PERMANENT I/O ERROR ON VOLUME PPRD22 139
FOR DATA SET SMTP.CONN257.NOTE
HISTORIC RETURN CODE IS 8 DADSM DIAGNOSTIC INFORMATION IS 0812041B
IGD306I UNEXPECTED ERROR DURING IGGDAR02 PROCESSING 140
RETURN CODE 8 REASON CODE 27
THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA
SMS MODULE TRACE BACK - VTSDA VTSCU VTSCT VTSRN SSIRT
SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00898
IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0812041B),
141
SMTP,PPRD22,SMTP.CONN257.NOTE
EZA5544E Unable to RENAME file SMTP.CONN257.NOTE to SMTP.A0258454.NOTE
rc=408
EZA5568E UNABLE TO ALLOCATE ADDRBLOK DATA SET CORRECTLY

SMTP is playing a dataset rename game - SMTP.TEMP.NOTE to SMTP.CONNnnn.NOTE (a 
3 character length increase)

SMTP then kindly sends a blank email to the recipient which then gets reported 
as suspicious :)

I don't remember how we reached the numbers we used, but looking at the info 
the ICKDSF manual, the 14 track index should be large enough for the 5250 
datasets possible with a 105 track VTOC. I an wondering if I can REFORMAT 
REFVTOC EXTINDEX(14) and get refreshed, unfragmented VTOCIX.


Every week I run DCOLLECT to get the count of free VIRs on my SMS volumes. If 
that number gets too small (which it hasn’t for quite a while, as I’ve 
increased the size of the VTOC indices on all volumes) then I run ICKDSF
‘BUILDIX OS NOPURGE’ followed by ‘BUILDIX IX’. That always seemed to prevent 
these errors.


--
Pew, Curtis G
curtis@austin.utexas.edu






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

Re: Determine level of fragmentation in VTOCIX?

2019-07-11 Thread Gibney, Dave 
Thanks, converting to CSSMTP is something I am considering. But, I am unlikely 
to go to z/OS 2.3, probably not even 2.2. Odds are real strong that we will be 
off of z/OS by January 2021, July at latest. Management really doesn't wish to 
renew the MFaaS contract. 

I am very much in a keep it going/minimal disruption mode.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Cieri, Anthony
> Sent: Thursday, July 11, 2019 2:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Determine level of fragmentation in VTOCIX?
> 
>   Dave,
> 
>   This does not answer your question, but it appears from the error
> messages that you are still running the older zOS SMTP task. ZOS
> Communication Server now provides a new CSSMTP task, which no longer
> copies the spool files to sequential dataset and plays the dataset  "rename"
> game.  SMTP is going to be dropped from support soon ( after zOS V2.2 ??)
>   We use to see errors like these from time to time, but they have
> disappeared since migrated to CSSMTP.
> 
>   Hth
>   Tony
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Thursday, July 11, 2019 4:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Determine level of fragmentation in VTOCIX?
> 
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders. ***
> ]]
> 
> 
> Is there a way to determine if and how much a VTOCIX is fragmented. Way
> back when (when disk wasn't quite so cheap), we standardized on parking
> the VTOCIX in the 14 tracks left in the 1st cylinder, and for a Mod-3, VTOC of
> 105 tracks (7CYL) immediately following, and usually a 2 CYL VVDS right after
> that. Most of my SMS managed application disks still follow this. And it
> worked well for many years.
> 
> But, during high volumes of SMTP activity, I have begun to get:
> 
> IEC603I VTOC ERRORS MAY EXIST ON C465,PPRD22,8,027
> IEC331I 042-002(0812041B),SMTP,SMTP,RNAM,IGG0CLH2
> IEC331I VOL,PPRD22,NAME,SMTP.CONN257.NOTE IGD17003I PERMANENT
> I/O ERROR ON VOLUME PPRD22 139 FOR DATA SET SMTP.CONN257.NOTE
> HISTORIC RETURN CODE IS 8 DADSM DIAGNOSTIC INFORMATION IS
> 0812041B IGD306I UNEXPECTED ERROR DURING IGGDAR02 PROCESSING 140
> RETURN CODE 8 REASON CODE 27 THE MODULE THAT DETECTED THE ERROR
> IS IGDVTSDA SMS MODULE TRACE BACK - VTSDA VTSCU VTSCT VTSRN SSIRT
> SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00898 IEC614I RENAME
> FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0812041B),
> 141
> SMTP,PPRD22,SMTP.CONN257.NOTE
> EZA5544E Unable to RENAME file SMTP.CONN257.NOTE to
> SMTP.A0258454.NOTE
> rc=408
> EZA5568E UNABLE TO ALLOCATE ADDRBLOK DATA SET CORRECTLY
> 
> SMTP is playing a dataset rename game - SMTP.TEMP.NOTE to
> SMTP.CONNnnn.NOTE (a 3 character length increase)
> 
> SMTP then kindly sends a blank email to the recipient which then gets
> reported as suspicious :)
> 
> I don't remember how we reached the numbers we used, but looking at the
> info the ICKDSF manual, the 14 track index should be large enough for the
> 5250 datasets possible with a 105 track VTOC. I an wondering if I can
> REFORMAT REFVTOC EXTINDEX(14) and get refreshed, unfragmented
> VTOCIX.
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> 
> --
> 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: Determine level of fragmentation in VTOCIX?

2019-07-11 Thread Cieri, Anthony 
Dave, 

This does not answer your question, but it appears from the error 
messages that you are still running the older zOS SMTP task. ZOS Communication 
Server now provides a new CSSMTP task, which no longer copies the spool files 
to sequential dataset and plays the dataset  "rename" game.  SMTP is going to 
be dropped from support soon ( after zOS V2.2 ??)
We use to see errors like these from time to time, but they have 
disappeared since migrated to CSSMTP.

Hth
Tony 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Thursday, July 11, 2019 4:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Determine level of fragmentation in VTOCIX?

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


Is there a way to determine if and how much a VTOCIX is fragmented. Way back 
when (when disk wasn't quite so cheap), we standardized on parking the VTOCIX 
in the 14 tracks left in the 1st cylinder, and for a Mod-3, VTOC of 105 tracks 
(7CYL) immediately following, and usually a 2 CYL VVDS right after that. Most 
of my SMS managed application disks still follow this. And it worked well for 
many years.

But, during high volumes of SMTP activity, I have begun to get:

IEC603I VTOC ERRORS MAY EXIST ON C465,PPRD22,8,027
IEC331I 042-002(0812041B),SMTP,SMTP,RNAM,IGG0CLH2
IEC331I VOL,PPRD22,NAME,SMTP.CONN257.NOTE
IGD17003I PERMANENT I/O ERROR ON VOLUME PPRD22 139
FOR DATA SET SMTP.CONN257.NOTE
HISTORIC RETURN CODE IS 8 DADSM DIAGNOSTIC INFORMATION IS 0812041B
IGD306I UNEXPECTED ERROR DURING IGGDAR02 PROCESSING 140
RETURN CODE 8 REASON CODE 27
THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA
SMS MODULE TRACE BACK - VTSDA VTSCU VTSCT VTSRN SSIRT
SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00898
IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0812041B),
141
SMTP,PPRD22,SMTP.CONN257.NOTE
EZA5544E Unable to RENAME file SMTP.CONN257.NOTE to SMTP.A0258454.NOTE
rc=408
EZA5568E UNABLE TO ALLOCATE ADDRBLOK DATA SET CORRECTLY

SMTP is playing a dataset rename game - SMTP.TEMP.NOTE to SMTP.CONNnnn.NOTE (a 
3 character length increase)

SMTP then kindly sends a blank email to the recipient which then gets reported 
as suspicious :)

I don't remember how we reached the numbers we used, but looking at the info 
the ICKDSF manual, the 14 track index should be large enough for the 5250 
datasets possible with a 105 track VTOC. I an wondering if I can REFORMAT 
REFVTOC EXTINDEX(14) and get refreshed, unfragmented VTOCIX.

Dave Gibney
Information Technology Services
Washington State University


--
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: Determine level of fragmentation in VTOCIX?

2019-07-11 Thread John Abell 
Thanks.  
I will be back to you in the morning.

John T. Abell   
Tel:800-295-7608Option 4
President 
International:  1-416-593-5578  Option 4
E-mail:  john.ab...@intnlsoftwareproducts.com
Fax:800-295-7609

International:  1-416-593-5579


International Software Products
www.ispinfo.com


This email may contain confidential and privileged material for the sole use
of the intended recipient(s). Any review, use, retention, distribution or
disclosure by others is strictly prohibited. If you are not the intended 
recipient (or authorized to receive on behalf of the named recipient),
please contact the sender by reply email and delete all copies of this
message. Also,email is susceptible to data corruption, interception, 
tampering, unauthorized amendment and viruses. We only send and receive
emails on the basis that we are not liable for any such corruption,
interception, tampering, amendment or viruses or any consequence thereof.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gibney, Dave
Sent: Thursday, July 11, 2019 4:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Determine level of fragmentation in VTOCIX?

Is there a way to determine if and how much a VTOCIX is fragmented. Way back
when (when disk wasn't quite so cheap), we standardized on parking the
VTOCIX in the 14 tracks left in the 1st cylinder, and for a Mod-3, VTOC of
105 tracks (7CYL) immediately following, and usually a 2 CYL VVDS right
after that. Most of my SMS managed application disks still follow this. And
it worked well for many years.

But, during high volumes of SMTP activity, I have begun to get:

IEC603I VTOC ERRORS MAY EXIST ON C465,PPRD22,8,027
IEC331I 042-002(0812041B),SMTP,SMTP,RNAM,IGG0CLH2
IEC331I VOL,PPRD22,NAME,SMTP.CONN257.NOTE IGD17003I PERMANENT I/O ERROR ON
VOLUME PPRD22 139 FOR DATA SET SMTP.CONN257.NOTE HISTORIC RETURN CODE IS 8
DADSM DIAGNOSTIC INFORMATION IS 0812041B IGD306I UNEXPECTED ERROR DURING
IGGDAR02 PROCESSING 140 RETURN CODE 8 REASON CODE 27 THE MODULE THAT
DETECTED THE ERROR IS IGDVTSDA SMS MODULE TRACE BACK - VTSDA VTSCU VTSCT
VTSRN SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00898 IEC614I RENAME
FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0812041B),
141
SMTP,PPRD22,SMTP.CONN257.NOTE
EZA5544E Unable to RENAME file SMTP.CONN257.NOTE to SMTP.A0258454.NOTE
rc=408
EZA5568E UNABLE TO ALLOCATE ADDRBLOK DATA SET CORRECTLY

SMTP is playing a dataset rename game - SMTP.TEMP.NOTE to SMTP.CONNnnn.NOTE
(a 3 character length increase)

SMTP then kindly sends a blank email to the recipient which then gets
reported as suspicious :)

I don't remember how we reached the numbers we used, but looking at the info
the ICKDSF manual, the 14 track index should be large enough for the 5250
datasets possible with a 105 track VTOC. I an wondering if I can REFORMAT
REFVTOC EXTINDEX(14) and get refreshed, unfragmented VTOCIX.

Dave Gibney
Information Technology Services
Washington State University


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

Determine level of fragmentation in VTOCIX?

2019-07-11 Thread Gibney, Dave 
Is there a way to determine if and how much a VTOCIX is fragmented. Way back 
when (when disk wasn't quite so cheap), we standardized on parking the VTOCIX 
in the 14 tracks left in the 1st cylinder, and for a Mod-3, VTOC of 105 tracks 
(7CYL) immediately following, and usually a 2 CYL VVDS right after that. Most 
of my SMS managed application disks still follow this. And it worked well for 
many years.

But, during high volumes of SMTP activity, I have begun to get:

IEC603I VTOC ERRORS MAY EXIST ON C465,PPRD22,8,027
IEC331I 042-002(0812041B),SMTP,SMTP,RNAM,IGG0CLH2
IEC331I VOL,PPRD22,NAME,SMTP.CONN257.NOTE
IGD17003I PERMANENT I/O ERROR ON VOLUME PPRD22 139
FOR DATA SET SMTP.CONN257.NOTE
HISTORIC RETURN CODE IS 8 DADSM DIAGNOSTIC INFORMATION IS 0812041B
IGD306I UNEXPECTED ERROR DURING IGGDAR02 PROCESSING 140
RETURN CODE 8 REASON CODE 27
THE MODULE THAT DETECTED THE ERROR IS IGDVTSDA
SMS MODULE TRACE BACK - VTSDA VTSCU VTSCT VTSRN SSIRT
SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00898
IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (0812041B),
141
SMTP,PPRD22,SMTP.CONN257.NOTE
EZA5544E Unable to RENAME file SMTP.CONN257.NOTE to SMTP.A0258454.NOTE
rc=408
EZA5568E UNABLE TO ALLOCATE ADDRBLOK DATA SET CORRECTLY

SMTP is playing a dataset rename game - SMTP.TEMP.NOTE to SMTP.CONNnnn.NOTE (a 
3 character length increase)

SMTP then kindly sends a blank email to the recipient which then gets reported 
as suspicious :)

I don't remember how we reached the numbers we used, but looking at the info 
the ICKDSF manual, the 14 track index should be large enough for the 5250 
datasets possible with a 105 track VTOC. I an wondering if I can REFORMAT 
REFVTOC EXTINDEX(14) and get refreshed, unfragmented VTOCIX.

Dave Gibney
Information Technology Services
Washington State University


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