Topic
  • 3 replies
  • Latest Post - ‏2013-03-25T03:52:13Z by SystemAdmin
SystemAdmin
SystemAdmin
112 Posts

Pinned topic Any alternatives to userid.DRLFPROF ?

‏2013-03-14T15:44:13Z |
At our shop any userid.* datasets are deleted at the end of day has they're automatically labelled to temporary storage class on creation.

Is there an alternative to starting the TDSz dialogues without using userid.DRLFPROF ?

e.g. PERMLOC.DRLFPROF

The only alternative I can think of is creating a CLIST what will ALLOCATE and copy DRLFPROF every time user starts TDS on the ISPF primary panel. Wondering if there's a more elegant and better way to accomplish this.

Any or all help appreciated,

-Paul
Updated on 2013-03-25T03:52:13Z at 2013-03-25T03:52:13Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    112 Posts

    Re: Any alternatives to userid.DRLFPROF ?

    ‏2013-03-14T16:09:10Z  
    Paul,
    I tend to recommend a local copy of the DRLEINI1 exec. You'll find the following section, pretty easy to use a common data set.

    "VGET ZUSER SHARED"
    If rc > 0 Then
    Call Dialog_error "VGET"
    /* savmemb = zuser||'.DRLFPROF' */
    savmemb = 'TIVDS.V1R81.LOCAL.DRLFPROF'

    Al
  • SystemAdmin
    SystemAdmin
    112 Posts

    Re: Any alternatives to userid.DRLFPROF ?

    ‏2013-03-25T03:50:57Z  
    Paul,

    I think AlH's solution may well be the best. If you require user-specific DRLFPROF members, you can keep them all in one area (hopefully immune from the policy police) and use the code:

    
    
    "VGET ZUSER SHARED" If rc > 0 Then Call Dialog_error 
    "VGET" 
    /* savmemb = zuser||'.DRLFPROF' */ savmemb = 
    'TDSZ181.'||zuser||
    ".DRLFPROF'
    


    That way, you can have still individual DRLFPROF members such as TDSZ181.PAX.DRLFPROF and TDSZ181.BOB.DRLFPROF.

    That change is fairly simple so, on the rare chance we ship a new DRLEINI1 with an APAR (or you install a new release), it should be very easy to change the new one as well.

    Another alternative I can think of is a request to your management to have their deletion policies changed. I suspect we both know how that suggestion would be treated :-)

    Alternatively, you could try a marketing request to IBM to get them to change how the profile member is found but that wouldn't be a quick solution by any means, given the small number of people who have ever requested it.
  • SystemAdmin
    SystemAdmin
    112 Posts

    Re: Any alternatives to userid.DRLFPROF ?

    ‏2013-03-25T03:52:13Z  
    Paul,

    I think AlH's solution may well be the best. If you require user-specific DRLFPROF members, you can keep them all in one area (hopefully immune from the policy police) and use the code:

    <pre class="jive-pre"> "VGET ZUSER SHARED" If rc > 0 Then Call Dialog_error "VGET" /* savmemb = zuser||'.DRLFPROF' */ savmemb = 'TDSZ181.'||zuser|| ".DRLFPROF' </pre>

    That way, you can have still individual DRLFPROF members such as TDSZ181.PAX.DRLFPROF and TDSZ181.BOB.DRLFPROF.

    That change is fairly simple so, on the rare chance we ship a new DRLEINI1 with an APAR (or you install a new release), it should be very easy to change the new one as well.

    Another alternative I can think of is a request to your management to have their deletion policies changed. I suspect we both know how that suggestion would be treated :-)

    Alternatively, you could try a marketing request to IBM to get them to change how the profile member is found but that wouldn't be a quick solution by any means, given the small number of people who have ever requested it.
    Apologies, I got one of the quotes wrong. It should have been:

    
    
    "VGET ZUSER SHARED" If rc > 0 Then Call Dialog_error 
    "VGET" 
    /* savmemb = zuser||'.DRLFPROF' */ savmemb = 
    'TDSZ181.'||zuser||
    '.DRLFPROF'