Re: DSPFFD question.

On 19-Feb-2012 02:20 , Raja Ayyer wrote:

<<SNIP>>

My requirement was to get the record length of a file in order to
pass that to a file transfer program as a parameter. I used DSPFD
command in a CL program. The command used in order to get the record
length of a particular database file that I was interested in is as
below:

DSPFD FILE(xxxxDTA/xxxxPF) TYPE(*RCDFMT) OUTPUT(*OUTFILE)
OUTFILE(QTEMP/xxxxPF)

The record length of xxxxDTA/xxxxPF is 5777
The record length I see in the OUTFILE is 290. This was my problem.

The above exhibits the problem with using /words/ instead of scripting the actions. There is nothing there to describe how to "see" what is claimed in words to have been seen; i.e. what steps do _I_ need to perform in order to have that value 290 manifest visibly to me.?

The above quoted DSPFD should have logged the following message:
"1 records added to member xxxxPF in file xxxxPF in QTEMP."

In order to check the file field description of the OUTFILE, I used
a DSPFFD command:

DSPFFD QTEMP/xxxxPF

I assumed that I'd see the record length of QTEMP/xxxxPF (i.e the
OUTFILE) to be the same (5777).

So here we must presume that we /see/ 290 instead; i.e. not even stated here in /words/ to clarify :-(

The output file that was created for DSPFD, the file xxxxPF in QTEMP contains "data", specifically _1_ row [or record] of data, per the aforementioned CPF3030 "1 records added...". That one row of data is what describes the file xxxxPF in library xxxxDTA; i.e. a row of data that describes the Record Format of the named FILE().

The request to DSPFFD QTEMP/xxxxPF displays the record format layout, the fields, of the file xxxxPF in QTEMP. That is metadata [of the output file], not the row data _in_ the output file. The data *in* the file xxxxPF in QTEMP must be reviewed to see the record length of the file xxxxPF in xxxxDTA.

Should I be looking for that somewhere else other than in the
OUTFILE?

No; not elsewhere. Do look "in the OUTFILE". Actually *in* the OUTFILE, i.e. the *data* in the OUTFILE, rather than looking at the metadata about the Output File.

As Vern already mentioned, a very simple means to review that row of data is the CL request to:
RUNQRY *NONE QRYFILE(QTEMP/xxxxPF)

Via SQL an effective equivalent to the RUNQRY is:
SELECT * FROM QTEMP/xxxxPF

More specifically, the desired information can be viewed with:
SELECT RFLEN FROM QTEMP/xxxxPF
/* RFLEN is the column for "Record format length"; */
/* refer to DSPFFD QAFDRFMT or DSPFFD QTEMP/xxxxPF */
/* to confirm that RFLEN data is the RcdFmtLen */

On Sat, 18 Feb 2012 12:31:09 -0800 CRPence wrote:

<<SNIP>>
If not simply a misunderstanding of what was being viewed [e.g.
accidentally viewing DSPFFD of the named OUTFILE() in library
QTEMP, instead of looking at the value of RFLEN for the row data
stored in the output file], then perhaps a detailed description
involving the scripted requests and the effect\output of each step,
rather than the attempt to describe in /words/ would be more
fruitful.?

Seems the issue was indeed, the alluded-as "a misunderstanding".

Regards, Chuck