×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Hello, Willie:
After reading this thread (and a number of replies to your post), I
suspect there is more to the story.
For example, it seems that PROGA is running interactively, since it
displays a screen to "prompt" for various parameters (fill-in-the-blanks
form) to specify what to report on (ranges of values, selection
criteria, etc.).
Note that calling program PROGB to "print a report" (as part of the same
interactive job) might not be the best idea especially when many files
are processed and large reports may be produced. Typically, such reports
are produced in batch mode, e.g. by submitting a separate job to a job
queue, and having that job CALL PROGB (with appropriate parameters).
But, as you may have already discovered, passing parameters to a batch
job using the CALL command as the CMD on the SBMJOB command can be
tricky, especially if you have some numeric values, unless you create a
"command wrapper" for the called program. (This idea has been discussed
many times in various threads on MIDRANGE-L).
And, do not give up just yet -- "There is another way." -- an "old
school" technique that was originally crafted for just such purposes, by
using something known as the "Local Data Area" or *LDA.
What you can do is to have PROGA store the various "parameter"
information into the *LDA (typically mapped via a data structure) of the
current job, and then simply submit a simple CALL to PROGB, with no
parameters on the CALL command in the CMD parameter of the SBMJOB
command (You would typically use QCMDEXC to issue the SBMJOB command.).
Then, when the batch job runs, PROGB simply retrieves the values from
the *LDA. This technique has been around since at least the IBM
System/38, and possibly the System/34 and System/36 before that. It is
simple and very effective for this kind of situation. Just define a
data structure to "map" the layout of the *LDA, and use /COPY to copy
the data structure definition into both ProgA and ProgB.
Another perhaps more "modern" (or at least, more Unix-y) approach, would
be to store the desired parameter values as named environment variables
in the job, and specify CPYENVVAR(*YES) on the SBMJOB command. However,
this requires PROGB to retrieve each value by name.
Hope that helps.
All the best,
Mark S. Waterbury
> Willie J. Moore wrote:
What I need to do is the following:
ProgA displays a screen for data entry, then calls ProgB passing the entered data as parms. ProgB then prints a report.
My problem is ProgA. I have the program display the entry screen. And I can call ProgB. But how do I set up the parms to pass through to ProgB?
Any help or examples would be appreciated.
Thanks,
William Moore
California Fine Wire
805-489-5144
midrange.com
