Skip to Main Content
IBM Z Software


This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Delivered
Categories z/TPF
Created by Guest
Created on Sep 29, 2014

Remove 4D6 pool usage from ZMAIL STATUS entry

Each ZMAIL STATUS display requires two 4D6 pool records because it uses creates temporary data that is later deleted when the display is constructed.
This became a problem after we configured our remote system monitor to poll TPF every second with the ZMAIL STATUS entry. Because this is a test system the loss of 4D6 pool is more critical as we don't normally run recoup/PDU on these systems.
Could you please review the design to avoid the need for FC18 pool?
Our system monitor uses a PC based application and dedicated TPF LNIATA to transmit the monitor entries and receive the output.

Idea priority Medium
  • Guest
    Reply
    |
    Oct 14, 2015

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - Servers and Systems Software
    Product family - z Systems Software
    Product - z/TPF

    For recording keeping, the previous attributes were:
    Brand - WebSphere
    Product family - Transaction Processing
    Product - z/TPF

  • Guest
    Reply
    |
    Dec 9, 2014

    Information provided on how to map /tmp to MFS.

  • Guest
    Reply
    |
    Dec 6, 2014

    Thank you for your reply. Please change the status of this RFE to Information Provided.

  • Guest
    Reply
    |
    Dec 1, 2014

    Hello,

    We are ok for the first option.
    Regards.
    Didier Dusart.

  • Guest
    Reply
    |
    Nov 25, 2014

    More information needed - please comment on the two options described above.

  • Guest
    Reply
    |
    Oct 27, 2014

    Here are some options for this request. Please comment on these options.

    The first option is to map the "/tmp" directory into a MFS (memory-mapped file system). The thought being that /tmp is typically considered temporary and could be lost when the system is re-started. This would skip the use of 4D6 Pool Usage.

    The second option would be to allow for a configurable option in the tpf_mail.conf file (or environment variable) which allows the operator to specify the directory to create this temporary file which is used for zmail commands. The default would be '/tmp' to keep existing behavior uninterrupted, but could be overridden with this new option. If the customer already has a mmap'd file system they could point to that. If the customer wants to create a new memory mapped File System directory then the following procedures could be followed:

    tmpMesgDir = /tmp2

    Then tmp2 could potentially be mapped as a MFS directory (bypassing the pool usage).

    zfile mkdir /tmp2
    zfile chmod ??? /tmp2 <-- setup to limit access if desired
    zfile chown ??? /tmp2 <-- setup to limit access if desired
    zfile mount -t mfs -o -I=5,-S=5,-T=10 /tmp2 <-- where I is initial size, S is increment MB's and T is total size (MB's)

    If /tmp2 were to solely be used for zmail messages, then the directory could be very very small, as the files are deleted after the message is wtopc'd out.

    The second option requires coding updates from the lab.