strange action of CALLed programs 
Author Message
 strange action of CALLed programs

ok, i moved all of my source over to fujitsu 4 and compiled the
project.  the main program when [f2] is pressed calls the "create
estimate" program.  create estimate gets all the items on the estimate,
totals and saves them, then gets the customer's info.  2 screen i-o
routines that PERFORM UNTIL KEY-CODE = 4 ([f4] key pressed).  the first
time i execute the program, the estimating works fine.  the second time
the f2 key is pressed at the main screen, the called create estimate pgm
skips the 2 screen io routines.  i finally added a line right at the
beginning of the called pgm's source to move zero to key-code.  in
version 3, i never had this problem.  anyone run into something like
this?


Sun, 18 Mar 2001 03:00:00 GMT  
 strange action of CALLed programs

<SNIP>

*Any* unititialized  variables can be anything at the start of a Cobol
program. I am presuming that "key-code" is in your working storage.
It should be initialized with a VALUE statement.  You are probably
starting with high values, and it is {*filter*}ing up a logical
or on the shift key as a result.



Sun, 18 Mar 2001 03:00:00 GMT  
 strange action of CALLed programs
key-code is initialized in W-S with value zero.  remember key-code and
key-type are fields of TERM-KEY which is CRT STATUS.  in fujitsu v3 i
didn't have to move zeroes to them in the procedure division, just init
with VALUE ZERO in the W-S section.  in v4, i have to MOVE ZERO to them
in the procedure division or suffer annoying results.


Mon, 19 Mar 2001 03:00:00 GMT  
 strange action of CALLed programs

Quote:

>key-code is initialized in W-S with value zero.  remember key-code and
>key-type are fields of TERM-KEY which is CRT STATUS.  in fujitsu v3 i
>didn't have to move zeroes to them in the procedure division, just init
>with VALUE ZERO in the W-S section.  in v4, i have to MOVE ZERO to them
>in the procedure division or suffer annoying results.

From your description, it would seem that version 3 was not conforming to
the ANSI standard.  A CALLed program is to be in its last state (e.g.
working-storage variables unchanged) unless:

1.  The CALLed program contains the INITIAL clause in the PROGRAM-ID
paragraph, or

2.  The CALLed program was CANCELed.

Perhaps the version 3 behavior was changed to conform to the standard in
version 4.  If Fujitsu provides any "what's new" document, this might
(should) be listed, since, as you have determined, it does affect program
behavior.

Tom Morrison
Liant Software Corporation



Mon, 19 Mar 2001 03:00:00 GMT  
 strange action of CALLed programs


Quote:
> ok, i moved all of my source over to fujitsu 4 and compiled the
> project.  the main program when [f2] is pressed calls the "create
> estimate" program.  create estimate gets all the items on the estimate,
> totals and saves them, then gets the customer's info.  2 screen i-o
> routines that PERFORM UNTIL KEY-CODE = 4 ([f4] key pressed).  the first
> time i execute the program, the estimating works fine.  the second time
> the f2 key is pressed at the main screen, the called create estimate pgm
> skips the 2 screen io routines.  i finally added a line right at the
> beginning of the called pgm's source to move zero to key-code.  in
> version 3, i never had this problem.  anyone run into something like
> this?

Probalbly the way the called programs are initialized - put a "VALUE"
clause in the Working-Storage item and use IS INITIAL after the
program name on the PROGRAM ID line of the called program.  That will
properly initialize any Working-Storage entries when the call is made.


Mon, 19 Mar 2001 03:00:00 GMT  
 strange action of CALLed programs

Quote:

>key-code is initialized in W-S with value zero.  remember key-code and
>key-type are fields of TERM-KEY which is CRT STATUS.  in fujitsu v3 i didn't
>have to move zeroes to them in the procedure division, just init with VALUE
>ZERO in the W-S section.  in v4, i have to MOVE ZERO to them in the procedure
>division or suffer annoying results.

You might want to start using the INITIALIZE verb religiously. The nice about
INITIALIZE is that if you have an item like this:

01 My-Record.
  03 My-PicX    PIC X(256).
  03 My-Integer PIC 9(4).
  03 My-Counter PIC 9(9) COMP.
  03 My-Number  PIC S9(5)V9999.

A single INITIALIZE My-Record will correctly set all of the numbers to zero and
alpha* to spaces. Additionally, there's some options that allow you to
replace different types of data with arbitrary values:

INITIALIZE My-Record,
  REPLACING NUMERIC DATA BY 3141592
            ALPHABETIC DATA BY "ABCD"
            ALPHANUMERIC-EDITED DATA BY "You get the idea".

----
The opinions above are my own and may or may not match those of my employer.



Mon, 19 Mar 2001 03:00:00 GMT  
 strange action of CALLed programs
IDENTIFICATION DIVISION.
PROGRAM-ID.  CRTEST01 IS INITIAL.  ?

I've never seen the "IS INITIAL" clause in the program id line in the
books i have.  i stopped the strange behavior by adding the move zero
command, but i'll go back and use the is initial.  thanks.



Mon, 19 Mar 2001 03:00:00 GMT  
 strange action of CALLed programs

Quote:

>IDENTIFICATION DIVISION.
>PROGRAM-ID.  CRTEST01 IS INITIAL.  ?

>I've never seen the "IS INITIAL" clause in the program id line in the

The "is initial" clause forces the data division to be reset to the
initial state each time it is called.  It is the same as if you did
a "cancel" after each call.  If you do not use it (or cancel), then working
storage value will hold their value from one call to the next.


Tue, 20 Mar 2001 03:00:00 GMT  
 strange action of CALLed programs

Quote:

> IDENTIFICATION DIVISION.
> PROGRAM-ID.  CRTEST01 IS INITIAL.  ?

> I've never seen the "IS INITIAL" clause in the program id line in the
> books i have.  i stopped the strange behavior by adding the move zero
> command, but i'll go back and use the is initial.  thanks.

It's ANSI 85 COBOL standard  - older books may not have it.  You have
it coded correctly in the above example.


Tue, 20 Mar 2001 03:00:00 GMT  
 strange action of CALLed programs

Quote:

> > ok, i moved all of my source over to fujitsu 4 and compiled the
> > project.  the main program when [f2] is pressed calls the "create
> > estimate" program.  create estimate gets all the items on the estimate,
> > totals and saves them, then gets the customer's info.  2 screen i-o
> > routines that PERFORM UNTIL KEY-CODE = 4 ([f4] key pressed).  the first
> > time i execute the program, the estimating works fine.  the second time
> > the f2 key is pressed at the main screen, the called create estimate pgm
> > skips the 2 screen io routines.  i finally added a line right at the
> > beginning of the called pgm's source to move zero to key-code.  in
> > version 3, i never had this problem.  anyone run into something like
> > this?

This is perfectly normal behaviour for a called program that
is called twice without an intervening CANCEL (or one that
works).  When a called routine is first called it is loaded
into memory and the WS areas have the values specified by
the VALUE clauses, where these don't exist the memory is
initialised to some arbitrary value.

When the program exits it still remains resident, a
subsequent call does _not_ cause the ws values to be
reset, they are left as they were on exit.  This is a
good thing as it allows the routine to remain active for
being called to do a variety of tasks.

To reset the memory of the called routine you need to
CANCEL it so it disappears from memory, then the next CALL
will reload it.

If you do have a CANCEL then it is not working.



Tue, 20 Mar 2001 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Call a checkbox action in code

2. Calling an action event from keypress

3. F8X: a call to action

4. CfP: DYNAMICS'97 - (Trans)Actions and Change in Logic Programming and Deductive Databases

5. CfP: DYNAMICS'97 - (Trans)Actions and Change in Logic Programming and Deductive Databases

6. How can I include in my VI actions like "Undo last action/redo last action"?

7. Call a REXX Exec and have it Address the calling program

8. Really Strange One ... Not returning from Sub Call

9. Strange Phone Call

10. Micro Focus CALL (or CHAIN) strange limitation

11. LINK command that calls a dialog with a map causes loss of place in calling program

12. MF-COBOL and DLL's: Call shows strange errors

 

 
Powered by phpBB® Forum Software