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 <IBM-MAIN@LISTSERV.UA.EDU> 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

Reply via email to