CALLNAT VS FETCH RETURN

what is the exact difference between CALLNAT and FETCH RETURN.
I Think in both cases we can pass parameters to Calling Program and Control Return to main Program ?
if this True , then in which case CALLNAT or FETCH RETURN are preferred.

First, a bit of Natural history. When Natural first came out, there was no such thing as subprograms (or lots of other object types for that matter). There were only programs. Thus, no CALLNAT. There was also no FETCH RETURN; only FETCH. FETCH, of course, is a one way trip. However, there was a powerful tool, no seemingly unknown by most new programmers, called the Stack.

When you do a FETCH PROG2 #A #B, control is passed from the the FETCH’er to the FETCH’ee, PROG2 in my code. The mechanism for “conveying” values of #A and #B is totally different than the mechanism with a CALLNAT. Basically, two entries are put on the top of the Stack; EXECUTE PROG2 would be the command on the top of the stack and values of #A and #B would be underneath that on the Stack. Control would be passed to PROG2 by PROG1 doing a STOP and Natural (the “monitor” as I call it) would then execute the command on the top of the Stack, namely the EXECUTE PROG2. The first INPUT statement in PROG2 (typically the first executable in PROG2) would then “pop” the values of #A and #B off the Stack into whatever variables were part of the INPUT statement; for example, INPUT #A-IMAGE and #B-IMAGE.

The problem of course was that programmers wanted to be able to return to PROG1 after PROG2 finished executing. There were many ways devised to simulate such behavior. PROG2 could Stack the command EXECUTE PROGRAM1 followed by some data. This would be read by the first INPUT statement in PROG1. That statement was typically conditional on *DATA being non zero (and, a positive number) which indicates there is a data “record” on the Stack waiting for an INPUT statement.

There were some very imaginative systems created using the FETCH and the Stack. However, along came progress. Natural added Subprograms, and the CALLNAT statement to invoke subprograms. This was done, if memory serves, at the same time that FETCH RETURN was added. The CALLNAT, however quickly began to replace the FETCH. The CALLNAT mechanism was far simpler than the very messy FETCH mechanism especially for data transfer. The parameter mechanism in CALLNAT (which originally had just the By Reference, but now also has By Value) makes it much simpler to code, and understand, and without messing up the Stack.

When FETCH first was implemented, global variables (ancestor of GDA) were used to facilitate the passage of values between programs. Today, FETCH and FETCH RETURN both allow the sharing of a GDA. The same sharing does not exist between an object (program or subprogram) that does a CALLNAT and the CALLNAT’ee. Nor, is it really needed anymore, given the power of BY REFERENCE and BY VALUE.

If you are developing new systems, it is likely you will not use FETCH or FETCH RETURN. They are far more cumbersome than CALLNAT. However, if you are maintaining, or enhancing older systems, you may well come across FETCH and FETCH RETURN. Be very careful when dealing with them. You may have one of the very imaginative navigation systems that were not always accompanied by comments.

You don’t really have a choice between FETCH (RETURN) or CALLNAT because FETCH is used to invoke a program and CALLNAT is used to invoke a subprogram. When building modern applications you create a small set of functions (programs) which call a larger set of common modules (subprograms), A menu system will handle the transfer of control to and between those functions, and that will be done via FETCH and FETCH RETURN.