ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

email from iSeries

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • email from iSeries

    I am working on a process where the user can have a report emailed from the iSeries to a specific email address. The business does not enroll everyone in the distribution directory (WRKDIRE). Is there a way to adopt the authority to email from another userID that is enrolled? i.e. Could I enroll a dummy or generic userID then on the SNDDST command have the current user reference the generic userID?

  • #2
    Adopted authority doesn't apply here, as an e-mail address isn't an "authority". You could use the Profile Handle APIs to swap to a different user profile to send the e-mail, I suppose. My solution, however, would be to stop using SNDDST, and instead use an e-mail tool that doesn't require directory entries.

    Comment


    • #3
      Why even use the WRKDIRE then? Just substitute the email address with the generic email address. But then how will the user get the "report" you are emailing then. I did something like this but added an option in the spool file to email the report as a text file and added an option to email as a PDF. All free. I'm with Scott though. get rid of the SNDDST. There are many free email solutions out there. We use a combination of both.
      Or just make an email group in your exchange server called something @something.com then enroll just those people. Or create a list on the 400 for distribution manually and maintain it there.

      Comment


      • #4
        When the API or the chain, depending on which method you're using, does not find an entry, then you could just substitute a generic email address eg. donotreply@mydomain.xxx.

        Using the WRKDIRE records does not neccesitate using SNDDST to use email functions, but rather used to record information required in many applications. For example, the relevant contact details (name, tel, fax, email) are printed on different documents such as sales orders, invoices, purchase orders, etc.

        Regards

        Kit
        www.ecofitonline.com
        DeskfIT - ChangefIT - XrefIT
        Regards

        Kit
        http://www.ecofitonline.com
        DeskfIT - ChangefIT - XrefIT
        ___________________________________
        There are only 3 kinds of people -
        Those that can count and those that can't.

        Comment


        • #5
          First, I'd only use SNDDST as a temporary emergency method on an older unsupported system. But thinking back, I recall references to using the SNDDST USRID() parameter to see if it lets you send on behalf of another profile. It might be worth trying.

          If I needed to do it with any recent release, I'd use SNDSMTPEMM long before SNDDST. And I'd use the QSYGETPH/QWTSETP/QSYRLSPH APIs to switch to and from the generic e-mail profile that's been entered in the system directory to do the sending. But as already mentioned, there are other methods that can be even better. It may simply depend on what might be allowed to be installed.
          Tom

          There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

          Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

          Comment


          • #6
            You should be able to use the GRTUSRPMN command. So you have a profile enrolled in the Distribution Directory then for every profile you want to send emails via the SNDDST command you give them permission to run on behalf of the enrolled user / profile. This is done ahead of time and not within your program (although I suppose you could program the step in). As an example let say that user JDOE is enrolled in the Distribution Directory but you want JSMITH to also be able to email out. When you create the profile JSMITH you also add the step to grant permission via the command GRTUSRPMN TOUSER(JSMITH) FORUSER(JDOE). Should you need to change this, for example if JSMITH changes roles you can revoke the permission previously given RVKUSRPMN FROMUSER(JSMITH) FORUSER(JDOE) basically you just have the initial set up of going though the list of users already created who you want to be able to send and then from that point on just make it a step when creating new users who are going to need to send.

            Comment

            Working...
            X