I got it i will use SQL to fetch the details which I want from the outfile.

Thanks for help…..

I created the sample program mentioned below.
PGM PARM(&JRN &JRNLIB &FROMDATE &FROMTIME)

DCL VAR(&JRN) TYPE(*CHAR) LEN(10)
DCL VAR(&JRNLIB) TYPE(*CHAR) LEN(10)
DCL VAR(&FROMDATE) TYPE(*CHAR) LEN(6)
DCL VAR(&FROMtime) TYPE(*CHAR) LEN(6)

DSPJRN JRN(&JRNLIB/&JRN) FILE((F4102)) +
RCVRNG(*CURCHAIN) FROMTIME(&FROMDATE +
&FROMTIME) OUTPUT(*OUTFILE) +
OUTFILFMT(*TYPE5) +
OUTFILE(mani/F4102JRN)

But i have other things to put in place….

As mentioned in above program ‘from date’ or ‘to date’ are specified as ‘*CURRENT’ then how can I change this into todays date (Don’t know if RTVSYSVAL help or not)

This programs should be universal across systems, so i need to make sure to retrieve the system name then also i need to use CHGVAR the output filename to mani/F4102JRN…

As I am not good in programming Please suggest.

As mentioned in above program ‘from date’ or ‘to date’ are specified as ‘*CURRENT’ then how can I change this into todays date

That can be a tricky thing to accomplish.

You could make various assumptions and write instructions that allowed “*CURRENT” to be typed into the same field that a real date might be typed into. That generally means that you define a basic text field and let users type any text at all; then you do whatever coding that you can think of to process all of the various possible “date” values to see if there really is a “date” there.

But IBM provides an alternative — command definitions.

By defining a command definition, you can describe an input field as a “date” that allows a particular special value, e.g., “*CURRENT”, in addition to actual dates. The command definition then enforces rules of dates. It only allows actual dates to be typed — except when the user types “*CURRENT”.

As part of your definition, you would add that an input value of “*CURRENT” should be changed to “0000000″ or some similar value. Your program will then see a single type of value, always seven digits and always either an actual date value like “1110621″ or “0000000″. (That first value is the seven-digit representation of “2011-06-21″. The digits represent CYYMMDD where the ‘C’ is known as the ‘century digit’. A ’1′ is for a date in the 2000s, and ’0′ would be from the 1900s. A ’2′ would be for the 2100s.)

It’s then easy for your program to recognize that “*CURRENT” was typed because that’s the only way that “0000000″ can get into your program.

Here’s how IBM defines the SCDDATE() parameter of the ADDJOBSCDE command:

             PARM       KWD(SCDDATE) +
                        TYPE(*DATE) +
                        DFT(*CURRENT) +
                        SPCVAL( +
                          (*CURRENT 000100) +
                          (*MONTHSTR 000200) +
                          (*MONTHEND 000300) +
                          (*NONE 000400)) +
                        EXPR(*YES) +
                        PROMPT('Schedule date, or' 4)

There are four “special values” allowed for that parm, each gets converted to a different numeric value that won’t match any possible valid date. You can prompt the ADDJOBSCDE command to see what the interface looks like for that parm.

In short, you can write a program that accepts a text value and does the logic necessary to handle dates and “*CURRENT” and all probable error values. Or you can write programming that merely recognizes that “0000000″ means “*CURRENT” and everything else is already a valid date.

In the first case, you also need to create a display file for your users to work with plus the logic to handle the display file. In the second case, you write a command definition which creates (and mostly manages) the display automatically.

How do you want things to work?

Tom

I think i will go ahead with first case…

I think i will go ahead with first case…

Good luck, then. You’ve got a messy, complex bunch of programming ahead of you.

You should probably start becoming familiar with the ILE CEE Date and Time APIs. Some of those might help in handling dates typed by users.

Tom