You can't have extended addressability without EXT, but you can have EXT 
without extended addressability.

On Wed, 16 Apr 2014 10:14:31 -0400, Nathan J Pfister <[email protected]> 
wrote:

>Thinking about this...can you have Extended Addressibility without EXT?  I
>didn't think you could, and a quick glance at the documentation is telling
>me that I can't.  Am I missing something?
>
>Thanks;
>
>Nathan Pfister
>zOS Systems Programmer
>AES\PHEAA - Tech Services
>[email protected]
>(717) 720-2663
>
>
>
>From:   "Peter X. DeFabritus" <[email protected]>
>To:     [email protected]
>Date:   04/16/2014 10:06 AM
>Subject:        Re: Extended Addressibility (was: ZFS - Allocation
>Failure)
>Sent by:        "IBM Mainframe Discussion List" <[email protected]>
>
>
>
>I have both extended data set format and extended addressability (which is
>different) set in out default data class.  There is no problem with
>extended addressability that I know of, which is what the OP was asking
>about, but there are several issues with extended data set format, as you
>said: temporary data sets, ISPF backup utility data sets, CA-Datacom data
>sets, CA-PDSMAN database, ADRDSSU backup data sets (which I believe has
>been fixed in z/OS 1.13), SAS data sets.
>
>On Wed, 16 Apr 2014 09:37:38 -0400, Nathan J Pfister
><[email protected]> wrote:
>
>>John et al;
>>
>>You say that EVERY DATACLAS you have is set to Extended Addressing?  Man,
>>we must have screwed something up when we tried that.  On our sandbox, we
>>created all of our DATACLAS to have Extended Addressing, and quite a few
>>different things broke.  Temporary datasets, Recovery datasets, certain
>>software datasets...Did none of that break for you?  Does any one else
>>have experience changing over to Extended Addressing?  Are there other
>>things that definitely will NOT work with Extended Addressing?
>>
>>Thanks;
>>
>>Nathan Pfister
>>zOS Systems Programmer
>>AES\PHEAA - Tech Services
>>[email protected]
>>(717) 720-2663
>>
>>
>>
>>From:   "John McKown" <[email protected]>
>>To:     [email protected]
>>Date:   04/16/2014 09:00 AM
>>Subject:        Re: ZFS - Allocation Failure
>>Sent by:        "IBM Mainframe Discussion List"
><[email protected]>
>>
>>
>>
>>Yes, you can alter an existing DATACLAS to have the Extended Addressing
>>attribute. HOWEVER! This does not affect _any_ existing data sets. It
>only
>>affect _NEW_ allocations. Every DATACLAS we have in our house has
>Extended
>>Addressing set. We have not noticed any impact from doing this. We did
>>this
>>because we had programmers use the non-Extended DATACLAS for VSAM data
>>sets, then get upset 8 months later when their "small" data set had to
>>exceed 4Gig. When told to unload/delete/define/reload, they got quite
>>incensed
>>
>>
>>On Wed, Apr 16, 2014 at 7:53 AM, Christian D
>><[email protected]>wrote:
>>
>>> Thank you sir. Is it possible to alter the existing Data clas to
>address
>>> the extended format ? Will there be any impact to the existing Datasets
>>?
>>>
>>>
>>> On Wed, Apr 16, 2014 at 6:14 PM, Staller, Allan <[email protected]
>>> >wrote:
>>>
>>> > *NO*
>>> >
>>> >
>>> > <snip>
>>> > I was getting the below error while allocating ZFS, I understand that
>>> VSAM
>>> > has a limit of 4GB and the below allocation is more than 4GB. We have
>>not
>>> > defined a DATACLAS to honour allocation more than 4GB. Is there a
>>other
>>> way
>>> > to allocate >4G of VSAM without having a dataclas ?
>>> >
>>> > IDCAMS  SYSTEM SERVICES TIME:
>>> > 3        04/16/14     PAGE
>>> > 1
>>> >
>>> >
>>> >  DEFINE CL
>>> > -
>>> >  (NAME(CHRIS.DB2.LOG) LIN SHR(3,3) -
>>> >  CYL(8000 1000)
>>> > -
>>> >  STORCLAS(SCSTOR)
>>> > -
>>> >  )
>>> >
>>> > IGD01010I ALLOCATION SET TO SGSTOR STORAGE GROUP IGD17103I CATALOG
>>ERROR
>>> > WHILE DEFINING VSAM DATA SET CHRIS.DB2.LOG RETURN CODE IS 140 REASON
>>CODE
>>> > IS 110 IGG0CLEV IGD306I UNEXPECTED ERROR DURING IGG0CLEV PROCESSING
>>> RETURN
>>> > CODE 140 REASON CODE
>>> > 110
>>> > THE MODULE THAT DETECTED THE ERROR IS
>>> > IGDVTSCU
>>> > SMS MODULE TRACE BACK - VTSCU VTSCT VTSCH VTSCG VTSCD VTSCC VTSCR
>>SSIRT
>>> > SYMPTOM RECORD CREATED, PROBLEM ID IS
>>> > IGD00475
>>> > IGD17219I UNABLE TO CONTINUE DEFINE OF DATA SET CHRIS.DB2.LOG
>IDC3014I
>>> > CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 140 - REASON
>>CODE
>>> IS
>>> > IDC3009I
>>> > IGG0CLEV-110
>>> > IDC3003I FUNCTION TERMINATED. CONDITION CODE IS
>>> > 12
>>> >
>>> >
>>> > IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS
>>> > 12
>>> > </snip>
>>> >
>>> >
>----------------------------------------------------------------------
>>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>>> > send email to [email protected] with the message: INFO
>IBM-MAIN
>>> >
>>>
>>> ----------------------------------------------------------------------
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to [email protected] with the message: INFO IBM-MAIN
>>>
>>
>>
>>
>>--
>>There is nothing more pleasant than traveling and meeting new people!
>>Genghis Khan
>>
>>Maranatha! <><
>>John McKown
>>
>>----------------------------------------------------------------------
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to [email protected] with the message: INFO IBM-MAIN
>>
>>
>>
>>
>>This message contains privileged and confidential information intended
>for the above addressees only.  If you
>>receive this message in error please delete or destroy this message
>and/or attachments.
>>
>>The sender of this message will fully cooperate in the civil and criminal
>prosecution of any individual engaging
>>in the unauthorized use of this message.
>>
>>----------------------------------------------------------------------
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to [email protected] with the message: INFO IBM-MAIN
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN
>
>
>
>
>This message contains privileged and confidential information intended for the 
>above addressees only.  If you
>receive this message in error please delete or destroy this message and/or 
>attachments.
>
>The sender of this message will fully cooperate in the civil and criminal 
>prosecution of any individual engaging
>in the unauthorized use of this message.
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to