Is an SJP really that simple in a real application?
Probably not. Often the programs being called required simple (and sometimes complex) parameters to be passed to them and amongst them.
However, in this style of application design, groups of programs usually fall into large application groups that share a common parameter protocol.
By adding an REQUEST_TYPE (say) field to the information exchanged between RAMP scripts you can easily accommodate different program parameter protocols along these lines (logic is in pseudo code):
WRITE and READ the 5250 screen containing PGMNAME and REQUEST_TYPE
DOWHILE (REQUEST_TYPE not equal to "SIGNOFF")
CASE of REQUEST_TYPE
WHEN = "CALLP1" CALL PGM_NAME using calling protocol 1 for parameters
WHEN = "CALLP2" CALL PGM_NAME using calling protocol 2 for parameters
WHEN = "CALLP3" CALL PGM_NAME using calling protocol 3 for parameters
<etc>
ENDCASE
WRITE and READ the 5250 screen containing PGMNAME and REQUEST_TYPE
ENDWHILE
If you are used to RPG and CL programs you might not be aware just how flexible the IBM i program call interface is. Program parameters are just areas of memory and passed between programs as pointers. You might not know:
- Parameters do not have to be the exact length the called program defined. They just need to be as long or longer, which makes sharing and reusing a small set of parameter variables in a SJP quite simple.
- You can pass a program more parameters than it actually requires. The extra ones are generally ignored, which means you can have very few actual CALL commands in your program.
- You could directly pass parameter values from you RAMP scripts to the SJP and pass them into the called programs. You could also get retuned parameter values back into the script again using this approach. This means your RAMP scripts can call batch style programs as well.