Another thing to add : The normal Alias deletion with : DEL ZOS.LUT.SAMPJCL
ALIAS does not deletes the alias but a CATALOG parameter with
CAT(ICF.RND.CATX) deletes the alias. Not sure why it is not picking up the
usercatalog automatically during deletion.


On Thu, Aug 22, 2013 at 4:19 PM, mf db <[email protected]> wrote:

> Hello,
>
> Below is the result of LISTCAT against the NONVSAM which I was trying to
> relate and I find there are two Alias being associated.
>
>
> 1IDCAMS  SYSTEM SERVICES                                           TIME:
> 0NONVSAM ------- ZOS.SAMPLJCL
>       HISTORY
>         DATASET-OWNER-----(NULL)     CREATION--------2009.043
>         RELEASE----------------2     EXPIRATION------0000.000
>         ACCOUNT-INFO-----------------------------------(NULL)
>         DSNTYPE----------LIBRARY
>       SMSDATA
>         STORAGECLASS ----XXXXXXX     MANAGEMENTCLASS------XXX
>         DATACLASS -------DEFAULT     LBACKUP ---0000.000.0000
>       VOLUMES
>         VOLSER------------XXXXXX     DEVTYPE------X'3010200F'     FSEQN-
>       ASSOCIATIONS
>         ALIAS----ZOS.LUT.SAMPJCL
>         ALIAS----ZOS.MUT.SAMPJCL
>       ATTRIBUTES
>       IN-CAT --- ICF.RND.CATX
>
>
> ZOS.LUT.SAMPJCL  - Is the One which does not appear in ISPF 3.4 search
> ZOS.MUT.SAMPLJCL - Via ISPF does not looks to be a alias but a PDS dataset.
>
>
>
>
> On Thu, Aug 22, 2013 at 11:24 AM, Gerhard Postpischil 
> <[email protected]>wrote:
>
>> On 8/21/2013 10:21 PM, John Gilmore wrote:
>>
>>> In one shop, call it S to protect the guilty, the applications
>>> programmers were very reluctant, perhaps for sentimental reasons, to
>>> give up using it long after any rationale for doing so had
>>> disappeared.  Making IEWL440 an alias for a more storage-intensive and
>>> much more efficient version of the linkage editor resolved this
>>> problem without discommoding the these sentimental S applications
>>> programmers.
>>>
>>
>> That brings back memories; we used a program named ZLKD from SHARE,
>> credited to Alan Fulford of "ALLIED BREWERIES, BURTON", 25/7/73 .
>> While the original was written for MFT, picking up the partition size, it
>> was easily converted to MVT. It checked the available storage, built a
>> modified PARM with the appropriate SIZE parameter, and invoked the largest
>> Linkage Editor that would fit. Our unprivileged users never had a chance to
>> mess up <g>
>>
>> Gerhard Postpischil
>> Bradford, Vermont
>>
>>
>> ------------------------------**------------------------------**
>> ----------
>> 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