× 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.



Hi all, I have been out of touch with the "400" for quite a few years,
so never really got around to learning the new ile specifics.

As this is my first post to this group I hope this email suits all the
requirements.

I have managed to get some access to a V5R3 system (I think it is,
pub1.de), and so want to get up to speed as quickly as possible with a
view to getting back into working with the /i.

What I intend to do is take an old "template" combined
workwith/edit,change,view,delete program I created for use in various
sites and update it as far as possible to use as many of the new
features as can be half inched into it. (sql, sub procedures,
getters/setters/free format/encapsulation/etc.)

With this end I have a question about using/creating sub procedures (I
think they are called) and as to how I can define them, use them, and
"hide" an implementation of the basic working structure of the program
and just expose the bits needed to make a unique program, if such a
thing is possible.

A simplistic example of part of the program would be a slf "work with"
view... the logic original subroutines were along the lines of...

*enter
exsr sfl1fill
exsr setllfile
begsr setllfile
setll namedfile
< return
exsr readfile
begsr readfile
readf namedfile
< return
etc...

Now it seems to me that sfl1fill could all be "hidden" in a service
program (workwithlogic) that purely maintains the program flow logic and
as such would be written once and re-used in a multitude of programs.

It would contain the following...
procedure sfl1fill
call procedure setllfile
call procedure readfile
call procedure filetosflfields
etc.

Within the "main" portion of the template program
(myworkwithprogram1/2/3/etc.) would be sub procedures (stubs) and these
would be called setllfile/readfile and the programmer would have to edit
which files were accessed/how etc... very much how existing template
programs were done in the past.

It would contain the following..
procedure setllfile
program specific code
procedure readfile
program specific code
procedure filetosflfields
move filefield>s1field
more program specific code
etc.

Now my question is, can a service program/or module or some other type
see (or be made to see) procedures that exist within the code that is
calling the service program that although "defined" in some way, have
wildly varying code within it, such as differing file names, key fields,
etc, but will have a non changing fixed parameter list to the
procedures.

I hope this makes sense? I guess in "PC" speak its the equivilent of
"header" files which define the template parameters with the actual
implimentation written in other C files, and a nice be long compile
pulls everything together to a final single program/application.

If so, is there any simple examples, or pointers to manuals/red books
that show this kind of thing.

Thanks in advance, Jon.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.