fmtdta or what? - IBM AS400

This is a discussion on fmtdta or what? - IBM AS400 ; Here's a bit of a poser... I have a data file, externally defined, but a problem. There is one big field defined as "multi-use" in it, and some data in this field is alpha, zoned, packed, etc. Varies for different ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: fmtdta or what?

  1. fmtdta or what?

    Here's a bit of a poser...

    I have a data file, externally defined, but a problem. There is one
    big field defined as "multi-use" in it, and some data in this field is
    alpha, zoned, packed, etc. Varies for different records.

    Now I need some records out of this file. Because there is some
    packed data (but not so defined in the file dds) here is what I'm
    thinking I need to do.

    Create a new physical file with nothing in it - use later. Create DDS
    for the file layout I want to end up with.

    Use FMTDTA to get the records from the data file that I want.

    Program describe the input fields from the sorted file. Now even
    though there are some different "multi-use" records in the file, the
    ones I extract using FMTDTA will all be the same.

    Do a CPYF of the file from the FMTDTA processing and copy to a member
    in my new physical file, no map option, etc.

    Now I can create LF's of this file; and can use externally defined
    fields from it in my report program.

    Is this a reasonable way to approach this problem? I am sure many of
    you are cringing at FMTDTA and I could use a reference to entering the
    source sort specifications if anyone could give me an example.

    I think the reason I have to use FMTDTA though is because of that
    multi-use field. It's like 30 characters. In the records there are
    sub-fields, but not consistent. In other words, in some records, there
    are 3 packed fields and 3 character fields. In others, there are 5
    character fields. However, I do know if I use the FMTDTA, the
    resulting record set from my selection will all be structured
    identically, so at that point could be "externally defined". So I'm
    thinking by using FMTDTA, I can get the records I want, then CPYF them
    into an externally defined file with the fields defined as they will
    be from the FMTDTA, and then go from there.

    Is there a better way to do this? I don't think there's a way to
    create a LF that can do this for me; I think FMTDTA is really my only
    option.

    Any examples or suggestions???

    Thanks,

    ga
    nospam@nospam.fmctc.com

  2. Re: fmtdta or what?

    CPYF with INCCHAR(SOMEFILD NN *EQ 'something') or
    INCREL((*IF SOMEFILD *EQ 'something')) and
    FMTOPT(*NOCHK) does the job without FMTDTA for what i give you an
    example here:
    FMTDTA INFILE((Lib/FileIn))
    OUTFILE(lib/FileOut)
    SRCFILE(lib/TxtFile) SRCMBR(Name)
    OPTION(*NOCHK *NOPRT)

    lib/TxtFile Mbr(Name) contains (eg):
    HFILE 10A X
    I C 132EQCA
    IAC 1 4EQC0625
    FNC 1 4
    FNC 5 10
    FDC

    It is formated statements like RPG there!

    Regards, Martin


    ga schrieb:
    > Here's a bit of a poser...
    >
    > I have a data file, externally defined, but a problem. There is one
    > big field defined as "multi-use" in it, and some data in this field is
    > alpha, zoned, packed, etc. Varies for different records.
    >
    > Now I need some records out of this file. Because there is some
    > packed data (but not so defined in the file dds) here is what I'm
    > thinking I need to do.
    >
    > Create a new physical file with nothing in it - use later. Create DDS
    > for the file layout I want to end up with.
    >
    > Use FMTDTA to get the records from the data file that I want.
    >
    > Program describe the input fields from the sorted file. Now even
    > though there are some different "multi-use" records in the file, the
    > ones I extract using FMTDTA will all be the same.
    >
    > Do a CPYF of the file from the FMTDTA processing and copy to a member
    > in my new physical file, no map option, etc.
    >
    > Now I can create LF's of this file; and can use externally defined
    > fields from it in my report program.
    >
    > Is this a reasonable way to approach this problem? I am sure many of
    > you are cringing at FMTDTA and I could use a reference to entering the
    > source sort specifications if anyone could give me an example.
    >
    > I think the reason I have to use FMTDTA though is because of that
    > multi-use field. It's like 30 characters. In the records there are
    > sub-fields, but not consistent. In other words, in some records, there
    > are 3 packed fields and 3 character fields. In others, there are 5
    > character fields. However, I do know if I use the FMTDTA, the
    > resulting record set from my selection will all be structured
    > identically, so at that point could be "externally defined". So I'm
    > thinking by using FMTDTA, I can get the records I want, then CPYF them
    > into an externally defined file with the fields defined as they will
    > be from the FMTDTA, and then go from there.
    >
    > Is there a better way to do this? I don't think there's a way to
    > create a LF that can do this for me; I think FMTDTA is really my only
    > option.
    >
    > Any examples or suggestions???
    >
    > Thanks,
    >
    > ga
    > nospam@nospam.fmctc.com


  3. Re: fmtdta or what?

    Good suggestion on the copyfile, problem there is that I almost need
    to be able to do more than one INCCHAR criteria...but you've given me
    some good ideas and thanks a ton for the sample FMTDTA.

    Martin Hinze wrote:

    >CPYF with INCCHAR(SOMEFILD NN *EQ 'something') or
    >INCREL((*IF SOMEFILD *EQ 'something')) and
    >FMTOPT(*NOCHK) does the job without FMTDTA for what i give you an
    >example here:
    > FMTDTA INFILE((Lib/FileIn))
    > OUTFILE(lib/FileOut)
    > SRCFILE(lib/TxtFile) SRCMBR(Name)
    > OPTION(*NOCHK *NOPRT)
    >
    >lib/TxtFile Mbr(Name) contains (eg):
    > HFILE 10A X
    > I C 132EQCA
    > IAC 1 4EQC0625
    > FNC 1 4
    > FNC 5 10
    > FDC
    >
    >It is formated statements like RPG there!
    >
    >Regards, Martin
    >
    >
    >ga schrieb:
    >> Here's a bit of a poser...
    >>
    >> I have a data file, externally defined, but a problem. There is one
    >> big field defined as "multi-use" in it, and some data in this field is
    >> alpha, zoned, packed, etc. Varies for different records.
    >>
    >> Now I need some records out of this file. Because there is some
    >> packed data (but not so defined in the file dds) here is what I'm
    >> thinking I need to do.
    >>
    >> Create a new physical file with nothing in it - use later. Create DDS
    >> for the file layout I want to end up with.
    >>
    >> Use FMTDTA to get the records from the data file that I want.
    >>
    >> Program describe the input fields from the sorted file. Now even
    >> though there are some different "multi-use" records in the file, the
    >> ones I extract using FMTDTA will all be the same.
    >>
    >> Do a CPYF of the file from the FMTDTA processing and copy to a member
    >> in my new physical file, no map option, etc.
    >>
    >> Now I can create LF's of this file; and can use externally defined
    >> fields from it in my report program.
    >>
    >> Is this a reasonable way to approach this problem? I am sure many of
    >> you are cringing at FMTDTA and I could use a reference to entering the
    >> source sort specifications if anyone could give me an example.
    >>
    >> I think the reason I have to use FMTDTA though is because of that
    >> multi-use field. It's like 30 characters. In the records there are
    >> sub-fields, but not consistent. In other words, in some records, there
    >> are 3 packed fields and 3 character fields. In others, there are 5
    >> character fields. However, I do know if I use the FMTDTA, the
    >> resulting record set from my selection will all be structured
    >> identically, so at that point could be "externally defined". So I'm
    >> thinking by using FMTDTA, I can get the records I want, then CPYF them
    >> into an externally defined file with the fields defined as they will
    >> be from the FMTDTA, and then go from there.
    >>
    >> Is there a better way to do this? I don't think there's a way to
    >> create a LF that can do this for me; I think FMTDTA is really my only
    >> option.
    >>
    >> Any examples or suggestions???
    >>
    >> Thanks,
    >>
    >> ga
    >> nospam@nospam.fmctc.com


    ga
    nospam@nospam.fmctc.com

  4. Re: fmtdta or what?

    Here are some old notes I saved on using SQL for unfomated data.
    It may help you.
    ************************************************** ****
    /* I share your frustration over the variable record
    types. I have a client that uses an older version of
    what is now PowerMHS, and some of the files, e.g.
    CDTMAS, have a couple of identifiable fields as the
    key, then one massive multi-hundred byte field that
    contains the meaningful data. I still chuckle over the
    fact that the name of that field is UNUSED.

    Anyway, you *can* view the contents of the part of the
    record that is of interest. A field described
    (internally, in this case) as PIC S9(009)V99 COMP is a
    packed decimal field, and will occupy 6 bytes in the
    record format. Let's assume it starts in position 31
    of the record; let's also use the ironic field name
    UNUSED. Then to see the contents, you could code your
    SQL statement as: */

    select hex(substr(unused,31,6))
    from cdtmas
    where rectyp = 'B' and [blah blah blah] ;

    /* If the field contained the value 1234567, then the
    resulting display would be:

    00001234567F

    If you actually wanted to use this value in some
    arithmetic computation in your SQL statement, you'd
    have to pick off the digits and convert them into a
    numeric representation, which you could do as follows: */

    select dec(left(hex(substr(unused,31,6)),11))
    from cdtmas
    where [blah blah blah] ;

    /* Note that you'd lose your decimal point this way, but
    you could implicitly get it back by dividing by 100. */

    SELECT wcpno,wckey,DEC(SUBSTR(WCDTA,1,15),15) @APACC,
    DEC(SUBSTR(WCDTA,16,15),15) @APDSE FROM MSWCP100 WHERE WCKEY =
    'APGLAC';

    On Thu, 31 Jul 2008 06:48:20 -0500, ga wrote:

    >Good suggestion on the copyfile, problem there is that I almost need
    >to be able to do more than one INCCHAR criteria...but you've given me
    >some good ideas and thanks a ton for the sample FMTDTA.
    >
    >Martin Hinze wrote:
    >
    >>CPYF with INCCHAR(SOMEFILD NN *EQ 'something') or
    >>INCREL((*IF SOMEFILD *EQ 'something')) and
    >>FMTOPT(*NOCHK) does the job without FMTDTA for what i give you an
    >>example here:
    >> FMTDTA INFILE((Lib/FileIn))
    >> OUTFILE(lib/FileOut)
    >> SRCFILE(lib/TxtFile) SRCMBR(Name)
    >> OPTION(*NOCHK *NOPRT)
    >>
    >>lib/TxtFile Mbr(Name) contains (eg):
    >> HFILE 10A X
    >> I C 132EQCA
    >> IAC 1 4EQC0625
    >> FNC 1 4
    >> FNC 5 10
    >> FDC
    >>
    >>It is formated statements like RPG there!
    >>
    >>Regards, Martin
    >>
    >>
    >>ga schrieb:
    >>> Here's a bit of a poser...
    >>>
    >>> I have a data file, externally defined, but a problem. There is one
    >>> big field defined as "multi-use" in it, and some data in this field is
    >>> alpha, zoned, packed, etc. Varies for different records.
    >>>
    >>> Now I need some records out of this file. Because there is some
    >>> packed data (but not so defined in the file dds) here is what I'm
    >>> thinking I need to do.
    >>>
    >>> Create a new physical file with nothing in it - use later. Create DDS
    >>> for the file layout I want to end up with.
    >>>
    >>> Use FMTDTA to get the records from the data file that I want.
    >>>
    >>> Program describe the input fields from the sorted file. Now even
    >>> though there are some different "multi-use" records in the file, the
    >>> ones I extract using FMTDTA will all be the same.
    >>>
    >>> Do a CPYF of the file from the FMTDTA processing and copy to a member
    >>> in my new physical file, no map option, etc.
    >>>
    >>> Now I can create LF's of this file; and can use externally defined
    >>> fields from it in my report program.
    >>>
    >>> Is this a reasonable way to approach this problem? I am sure many of
    >>> you are cringing at FMTDTA and I could use a reference to entering the
    >>> source sort specifications if anyone could give me an example.
    >>>
    >>> I think the reason I have to use FMTDTA though is because of that
    >>> multi-use field. It's like 30 characters. In the records there are
    >>> sub-fields, but not consistent. In other words, in some records, there
    >>> are 3 packed fields and 3 character fields. In others, there are 5
    >>> character fields. However, I do know if I use the FMTDTA, the
    >>> resulting record set from my selection will all be structured
    >>> identically, so at that point could be "externally defined". So I'm
    >>> thinking by using FMTDTA, I can get the records I want, then CPYF them
    >>> into an externally defined file with the fields defined as they will
    >>> be from the FMTDTA, and then go from there.
    >>>
    >>> Is there a better way to do this? I don't think there's a way to
    >>> create a LF that can do this for me; I think FMTDTA is really my only
    >>> option.
    >>>
    >>> Any examples or suggestions???
    >>>
    >>> Thanks,
    >>>
    >>> ga
    >>> nospam@nospam.fmctc.com

    >
    >ga
    >nospam@nospam.fmctc.com


  5. Re: fmtdta or what?

    Surely what you need to do is define a multi format logical over the file
    don't you.

    Thats how the externalisation of multiformat S36 files was achieved.

    KP
    "ga" wrote in message
    news:se7294la2oh8li58ok5t8d8ft318tcc6ka@4ax.com...
    > Here's a bit of a poser...
    >
    > I have a data file, externally defined, but a problem. There is one
    > big field defined as "multi-use" in it, and some data in this field is
    > alpha, zoned, packed, etc. Varies for different records.
    >
    > Now I need some records out of this file. Because there is some
    > packed data (but not so defined in the file dds) here is what I'm
    > thinking I need to do.
    >
    > Create a new physical file with nothing in it - use later. Create DDS
    > for the file layout I want to end up with.
    >
    > Use FMTDTA to get the records from the data file that I want.
    >
    > Program describe the input fields from the sorted file. Now even
    > though there are some different "multi-use" records in the file, the
    > ones I extract using FMTDTA will all be the same.
    >
    > Do a CPYF of the file from the FMTDTA processing and copy to a member
    > in my new physical file, no map option, etc.
    >
    > Now I can create LF's of this file; and can use externally defined
    > fields from it in my report program.
    >
    > Is this a reasonable way to approach this problem? I am sure many of
    > you are cringing at FMTDTA and I could use a reference to entering the
    > source sort specifications if anyone could give me an example.
    >
    > I think the reason I have to use FMTDTA though is because of that
    > multi-use field. It's like 30 characters. In the records there are
    > sub-fields, but not consistent. In other words, in some records, there
    > are 3 packed fields and 3 character fields. In others, there are 5
    > character fields. However, I do know if I use the FMTDTA, the
    > resulting record set from my selection will all be structured
    > identically, so at that point could be "externally defined". So I'm
    > thinking by using FMTDTA, I can get the records I want, then CPYF them
    > into an externally defined file with the fields defined as they will
    > be from the FMTDTA, and then go from there.
    >
    > Is there a better way to do this? I don't think there's a way to
    > create a LF that can do this for me; I think FMTDTA is really my only
    > option.
    >
    > Any examples or suggestions???
    >
    > Thanks,
    >
    > ga
    > nospam@nospam.fmctc.com




  6. Re: fmtdta or what?

    ga wrote:
    > Good suggestion on the copyfile, problem there is that I almost need
    > to be able to do more than one INCCHAR criteria...but you've given me
    > some good ideas and thanks a ton for the sample FMTDTA.
    >
    > Martin Hinze wrote:
    >
    >> CPYF with INCCHAR(SOMEFILD NN *EQ 'something') or
    >> INCREL((*IF SOMEFILD *EQ 'something')) and
    >> FMTOPT(*NOCHK) does the job without FMTDTA <>


    The INCREL() on CPYF allows more logic than the one test for
    INCCHAR(), using *OR and *AND tests.
    http://publib.boulder.ibm.com/infoce...l3copyreco.htm

    Also a multiple format logical file [like, if familiar, an IDDU
    program described multi format physical file] can be used to choose
    those records that share the same layout\format.

    Regards, Chuck

  7. Re: fmtdta or what?

    Chuck,

    I haven't used CPYF allthat much, at least in the area of what I am
    trying to do here, but I need multiple INCCHAR selections and if I put
    a "+" sign on the INCREL parm, all it gives me is additional FIELD
    testing - in other words, I don't see how I can put another
    INCCHAR(SOMEFILD NN *EQ 'something2' in there. What am I missing
    (besides a brain...)???


    CRPence wrote:

    >ga wrote:
    >> Good suggestion on the copyfile, problem there is that I almost need
    >> to be able to do more than one INCCHAR criteria...but you've given me
    >> some good ideas and thanks a ton for the sample FMTDTA.
    >>
    >> Martin Hinze wrote:
    >>
    >>> CPYF with INCCHAR(SOMEFILD NN *EQ 'something') or
    >>> INCREL((*IF SOMEFILD *EQ 'something')) and
    >>> FMTOPT(*NOCHK) does the job without FMTDTA <>

    >
    > The INCREL() on CPYF allows more logic than the one test for
    >INCCHAR(), using *OR and *AND tests.
    >http://publib.boulder.ibm.com/infoce...l3copyreco.htm
    >
    > Also a multiple format logical file [like, if familiar, an IDDU
    >program described multi format physical file] can be used to choose
    >those records that share the same layout\format.
    >
    >Regards, Chuck


    ga
    nospam@nospam.fmctc.com

  8. Re: fmtdta or what?

    Yes, maybe that would have worked - I confess I get a little "tunnel
    visionish" at times. What I ended up doing, since it's a relatively
    small file, was read the file internally defined, grab the records I
    wanted, and output them to a new externally defined file. I took some
    of the suggestions here and just tweaked them a bit to make it a
    simpler solution than what I was originally thinking I had to do. It
    made it much simpler than the way I thought I might have to go about
    it.

    Everyone is great in this forum because everyone has a little
    different perspective on things and a lot of synergy exists as a
    result.

    It's working. maybe it could be done better than how I did it,
    but...the nice thing about iseries is there are 3+ ways to do about
    anything!

    Thanks for your suggestions everyone. I have saved them for future
    reference.

    Thanks again,
    ga

    "KevinP" wrote:

    >Surely what you need to do is define a multi format logical over the file
    >don't you.
    >
    >Thats how the externalisation of multiformat S36 files was achieved.
    >
    >KP
    >"ga" wrote in message
    >news:se7294la2oh8li58ok5t8d8ft318tcc6ka@4ax.com...
    >> Here's a bit of a poser...
    >>
    >> I have a data file, externally defined, but a problem. There is one
    >> big field defined as "multi-use" in it, and some data in this field is
    >> alpha, zoned, packed, etc. Varies for different records.
    >>
    >> Now I need some records out of this file. Because there is some
    >> packed data (but not so defined in the file dds) here is what I'm
    >> thinking I need to do.
    >>
    >> Create a new physical file with nothing in it - use later. Create DDS
    >> for the file layout I want to end up with.
    >>
    >> Use FMTDTA to get the records from the data file that I want.
    >>
    >> Program describe the input fields from the sorted file. Now even
    >> though there are some different "multi-use" records in the file, the
    >> ones I extract using FMTDTA will all be the same.
    >>
    >> Do a CPYF of the file from the FMTDTA processing and copy to a member
    >> in my new physical file, no map option, etc.
    >>
    >> Now I can create LF's of this file; and can use externally defined
    >> fields from it in my report program.
    >>
    >> Is this a reasonable way to approach this problem? I am sure many of
    >> you are cringing at FMTDTA and I could use a reference to entering the
    >> source sort specifications if anyone could give me an example.
    >>
    >> I think the reason I have to use FMTDTA though is because of that
    >> multi-use field. It's like 30 characters. In the records there are
    >> sub-fields, but not consistent. In other words, in some records, there
    >> are 3 packed fields and 3 character fields. In others, there are 5
    >> character fields. However, I do know if I use the FMTDTA, the
    >> resulting record set from my selection will all be structured
    >> identically, so at that point could be "externally defined". So I'm
    >> thinking by using FMTDTA, I can get the records I want, then CPYF them
    >> into an externally defined file with the fields defined as they will
    >> be from the FMTDTA, and then go from there.
    >>
    >> Is there a better way to do this? I don't think there's a way to
    >> create a LF that can do this for me; I think FMTDTA is really my only
    >> option.
    >>
    >> Any examples or suggestions???
    >>
    >> Thanks,
    >>
    >> ga
    >> nospam@nospam.fmctc.com

    >


    ga
    nospam@nospam.fmctc.com

  9. Re: fmtdta or what?

    We are not given enough information to know if field tests are
    sufficient to establish which rows to select. I was suggesting to
    replace the INCCHAR with INCREL. Since the noted file is now externally
    described, I was under the impression [for both suggestions, & nicest
    for MFLF] that fields could be used to test for selecting rows, rather
    than characters within the unformatted data. The MFLF is the better
    choice, so as to avoid using copies of the data.

    Regards, Chuck

    ga wrote:
    >
    > I haven't used CPYF all that much, at least in the area of what I am
    > trying to do here, but I need multiple INCCHAR selections and if I
    > put a "+" sign on the INCREL parm, all it gives me is additional
    > FIELD testing - in other words, I don't see how I can put another
    > INCCHAR(SOMEFILD NN *EQ 'something2' in there. What am I missing
    > (besides a brain...)???
    >
    > CRPence wrote:
    >
    >> ga wrote:
    >>>
    >>> Good suggestion on the copyfile, problem there is that I almost need
    >>> to be able to do more than one INCCHAR criteria...but you've given me
    >>> some good ideas and thanks a ton for the sample FMTDTA.
    >>>
    >>> Martin Hinze wrote:
    >>>
    >>>> CPYF with INCCHAR(SOMEFILD NN *EQ 'something') or
    >>>> INCREL((*IF SOMEFILD *EQ 'something')) and
    >>>> FMTOPT(*NOCHK) does the job without FMTDTA <>

    >>
    >> The INCREL() on CPYF allows more logic than the one test for
    >> INCCHAR(), using *OR and *AND tests.

    http://publib.boulder.ibm.com/infoce...l3copyreco.htm
    >>
    >> Also a multiple format logical file [like, if familiar, an IDDU
    >> program described multi format physical file] can be used to choose
    >> those records that share the same layout\format.


+ Reply to Thread