IBM Z Hardware and Operating Systems Ideas Portal


This is the public portal for all IBM Z Hardware and Operating System related offerings. 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.

Add a new idea Subscribe
Status Future consideration
Workspace z/OS
Categories DFSMS DSS
Created by Guest
Created on Mar 16, 2017

RELATED IDEAS

Make DFDSS handle any type of dump file

DFDSS (ADRDSSU) writes variable-length records to a RECFM=U dataset. First, it would be good if it also supported RECFM=V for output, as that is a natural match for variable-length records. Regardless, if that RECFM=U file is ftp'ed to the PC and back, it will be reblocked and unreadable. It would be good if the RECFM=U file could be reblocked, as actually DFDSS stores its own length in the records, so it can figure out a reblocked dataset all by itself. In the absence of DFDSS being able to handle this natively, I have written a utility to restore original record lengths from a reblocked DFDSS file (see "use case" for code), so it is clearly possible. It would be good if DFDSS could handle this reblocked data regardless of whether a user has uploaded the binary file to a RECFM=FB or VB or U. ie totally flexible. Just to be clear, that means that a DFDSS record may be split across multiple RECFM=U blocks, and one RECFM=U block may contain more than one DFDSS record. That covers what I call non-RDW files.

People who know that DFDSS currently needs the record lengths preserved can achieve that by doing an IDCAMS REPRO from RECFM=U to RECFM=V and then transferring the file to the PC using the "rdw" option of ftp. That produces what I call "RDW files" and they look like this:

00260000 00000001 01010022 10108000

The first 4 bytes is the RDW, showing a record length of x'26' = 38. DFDSS's own length is also shown above as x'22' = 34 as expected. These files can be uploaded back to the mainframe and restored to a RECFM=V dataset (using a different utility while waiting for RFE 63596 to be implemented) and then IDCAMS REPRO to get them into RECFM=U so that they are acceptable to DFDSS. Once again, it would be good if DFDSS was totally flexible and could handle a "RDW file" that has been stored in *any* of RECFM FB/VB/U. It is very easy to distinguish whether a file is RDW or non-RDW - if the first 2 bytes are non-zero, then it is an RDW file, otherwise it is a non-RDW file.

In summary, what is needed is - be able to handle reblocking, be able to handle any RECFM, and be able to handle RDWs, so that the user can do anything at all with the DFDSS output file and DFDSS can cope with it.

Idea priority Low
  • Guest
    Reply
    |     Mar 20, 2017

    I would like the ability to ftp my DSS dump to the PC for general use. I'd like to be able to zip it, rar it, encrypt it, transfer to USB, upload using binary ftp to a Unix website, download it, and then finally ftp it back to a mainframe in binary mode so that it can be restored. ftp in binary mode, or ftp in rdw mode, are much simpler operations than trying to encapsulate the file as an AWS tape on the mainframe, or some other method to compensate for the fact that the RECFM=U file is in an essentially unmovable format. A file in RECFM=FB format is not unmovable. It is a cinch to move an FB file to/from the PC. RECFM=U would also be a cinch to download to/from the PC so long as the block boundaries are not considered to be important, and can thus be lost (ie reblocked). That is not the case with the DFDSS dump format - it cannot be rebocked.

  • Guest
    Reply
    |     Mar 20, 2017

    Why are you copying a DSS dump to your PC? I do not understand what you are trying to do and why a DSS dump with something other than RECFM=U is required.

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.