AS400 externally described Transaction File program

[Uvaiz]

Hi everyone,

I have designed a screen display program using an externally described Transaction File prompting to key an account. This program points to another program defined in the procedure division using the linkage parameter as follows.

LINKAGE SECTION.
01 LK-PARM-FIELDS.
05 LK-DEAL LIKE F-DEAL.


PROCEDURE DIVISION USING LK-PARM-FIELDS.

This works and the information correctly displayed. When the second program is ended with the GOBACK as follows returns back to the calling program and the prompt screen is again displayed.

000-MAIN-MODULE.

PERFORM 100-INITIALIZATION-RTN
PERFORM 200-PROMPT-SCREEN-RTN
UNTIL WS-FUNCTION-KEY-03.
PERFORM 300-TERMINATION-RTN.
GOBACK.


However when I attempt to select another account number in the first program nothing happens, but if I exit the program and rerun the program once again it works. The program looks like this.

PROCEDURE DIVISION.
PROCEDURE DIVISION. PROCEDURE DIVISION.
MAIN-PROCESS.

OPEN I-O DISPFILE.
ACCEPT CURRENT-DATE FROM DATE.
MOVE IND-OFF TO IN99 IN FORMAT1-I-INDIC.
PERFORM DISPLAY-SCREEN THRU READ-AND-PROCESS-SCREEN
UNTIL IN99 IN FORMAT1-I-INDIC = IND-ON.
CLOSE DISPFILE.
STOP RUN.

DISPLAY-SCREEN.

WRITE DISP-REC FORMAT IS "FORMAT1"
INDICATORS ARE FORMAT1-O-INDIC.

READ-AND-PROCESS-SCREEN.

MOVE ZEROS TO FORMAT1-I-INDIC.
READ DISPFILE FORMAT IS "FORMAT1"
INDICATORS ARE FORMAT1-I-INDIC.
IF IN51 IN FORMAT1-I-INDIC = IND-ON THEN
CALL "TESTINQ1" USING DEAL
ELSE
IF IN52 IN FORMAT1-I-INDIC = IND-ON THEN
CALL "DELCHGINQ2".

Can anyone kindly correct me if I have erred somewhere in my source please.

Thanks.
Tony

 

[TechBrave]

Hi Tony,

Could you give the structure for the field "FORMAT1-I-INDIC" in your working storage section??

I think its the line -
MOVE ZEROS TO FORMAT1-I-INDIC
that may be causing the problem since FORMAT1-I-INDIC is a flag and your loop is dependent on this flag.
Now, in the loop itself, you are modifying the contents of this flag so its not going back again inside the loop.

I hope this helps,

Thanks,
TB.

 

[Uvaiz]

Hi TB,

Thanks for your input. What I cannot understand is notwithstanding the passing of Zeros to Format1-I-INDIC the program works the first time around. However, once the called program is initiated and closed the next attempt without quiting the calling program entirely the next search is not successful. No error messages to determine the problem.

Thanks,
Tony

 

[fredericofonseca]

format1-I-INDIC values will always be initialized by the READ command.

The piece that is really more important here is the format1-O-INDIC, as this is what is going to "show" or "hide" the screen variables.

Normally the format1-i-indic will hold a "occurs 99 pic 1". if it is not then it will not hold all the possible indicators.

In order to help I think it would be better to have a FULL program. e.g. stripped of every piece of code that it not required to get the error.
Pretty much what you have + working storage and file definitions.

The select on this case is very important as it may affect the way the screen is handled.

And although from the example this does not seem to be the problem it is sometimes a requirement to have two writes for things to work as expected, specially if you are messing with output indicators and message files.


And when you say nothing happens what do you mean with it.

Does it go to the write? to the read? neither?

and another thing. The way the DDS was compiled can also have some effect, as well as some keywords within the DDS.



Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[Uvaiz]

Hi Frederico,

Thanks for your feedback. Here is the sequence of events which is as follows.

The Program A displays the screen

Screen A

1. DEALER CHANGES : PRESS F5 7552
2. REP CHANGES : PRESS F9

EXIT SCREEN : PRESS F3

Prompting for the account number as indicated above (7552) and pressing CF 05 to call the called program B and if account is found displays this

SCREEN B
DEALER CHANGES RECORD FOR 7552

OLD OLD NEW NEW ACCOUNT PROCESS
DEAL REP DEAL REP NUMBER DATE
7552 0002 XXXX XXXX XXXXXXXX 2001/08/22
7552 0002 XXXX XXXX XXXXXXXX 2001/08/22

Then pressing CA 03 in SCREEN B, program passes back to Program A and program A once again prompts the first SCREEN A. At this point I key another account number and expect the program A to loop back to Program B with the new account number. Instead the parameter when keyed is accepted but remains in Screen A. This is my first program using Calling Program and Called Program and not certain the location once the Called Program returns command to the Calling Program.

Trust this explains my logic to you.

Thanks,
Tony

 

[fredericofonseca]

It does explain the logic, but it doesn't help much.

The other requested information would!!

Have you tried source debug the program? (strisdb)
If not try it, and see what the program is doing.

You need to compile the programs with option *srcdbg

And look at the initialization of variables on program B.





Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[ceh4702]

There are instructions on how to write such a program in the book "Programming in COBOL 400" written by Cooper Stern & Stern, Publisher Wiley, 1997.

How come you are calling 2 proagrams and you say

CALL "TESTINQ1" USING DEAL

and

CALL "DELCHGINQ2".

I dont know why you use "Using Deal" on one and then you dont use a similar statement on the second one. The only thing I can think of is that the program you are calling is still running the second time around. I would have put it all in one program myself.

So what happens if the part number is not found in the file/database?

You use two indicators. IN51 AND IN52. Maybe one or both are invalid and the if is not working.




If you do not like my post feel free to point out your opinion or my errors.

 

[Uvaiz]

Thanks ceh4702,

Indeed your inputs were very useful. I do have the book Programming in COBOL 400 by Cooper and find it very useful. The programs TESTINQ1 and DELCHGINQ2 are working well when run individually. They both extract different information and if the criteria selection is not found then the message built within these individual program would be displayed.

You are right, I have intentionally left out the using statement in Call DELCHGINQ2 because I have omitted this calling program until I have successfully achieved the first calling program to work.

The purpose for calling either one of the programs by a calling program is to broaden my concept on interaction between Called and Calling program. The above book refers to this concept but not sufficiently explained with supporting example programs.

My program works the first time hence I believe the indicator IN51 does indeed work but not the second time around even if I choose the same criteria selection.

I have purchased a book Programming Subfiles in COBOL 400 by Jerry Goldson that seems to explain my problem and hoping to find a resolution soon.

Thanks
Tony