Re: Free OS/400 -- MIDRANGE-L

Joe,

Did I really say simple? :)  Mercy!

I just did an EDTLIBL on my system and reduced my library list to
wyatterppb, qgpl and qtemp, did a change curlib to wyatterppb and
compiled GLNOWRKX.

It compiled without a hitch and scanning the source member shows field
CMDTXT is defined in the display file GLNODSPF.  Make sure that you are
compiling with CRTRPTPGM.  Although I don't use the auto report feature,
by compiling them this way it will sort the source in the right place. 
For example, /COPY member $BLDCMDTXT contains a subroutine, a couple of
data structures and an array.  I think that if you use CRTRPGPGM it will
not put the data structures in the 'I' spec region and you will get two
errors: entry out of sequence and undefined field.

I use the WORKSTN status feedback within the /COPY member $TIMEDOUT to
test of a workstation has timed out to permit a graceful (seton LR) exit
and to test if a function key was pressed.

I will admit that I do a lot of stuff with /COPY, but I don't perform
display I/O within them.  At least not that I recall.  I take that back,
when someone does a 'position to' I perform a binary halving of the
subfile entries.

Maybe this is a bad habit, but I compile all display formats with
DFRWRT(*YES) which, AFAIK, requires the use of the INVITE keyword.  I've
been doing it so long this way it's just habit.  I also break a panel
down into components, title, body (which may be a single record or
SFL/SFLCTL combo), function keys and error messages.

I also use a shared ODP for display files and some components are used
by multiple programs.  For example, GLNOEDT and GLNOADD use the same
screen components.  I don't believe that I have any named record
actually have the same name in two display files, yet have their
contents be different.  When writing the panels, I would ask myself
"Will I have any problems if I took all my display file source and made
one huge member out of it?"  So although both GLNODSPF and ZIPCDSPF
contain record CMDDSP, the source for record CMDDSP are identical.

It would not be difficult to consolidate the components and make what
few changes would be required to the RPG programs.

I would be happy with a +90% conversion.  As I said before, I've been at
this too long to worry about having to make minor adjustments to each
and every program.  As a matter of fact, since I have certain
programming rules, I could write a conversion plug-in to handle my
particular "style".

Don't worry about the time frame, the fact that you'll even touch it
with a pole shorter than 10' already has me impressed ;-)

J. Kilgore

Joe Pluta wrote:
> 
> James, I don't know how quickly this can be done.  Your "simple" system
> consists of over 100 source members, including dozens of /COPY members.  I
> tried to compile them, and source members GLNOADDX, GLNOEDTX and GLNOINQX
> all failed compile.  Also, you use the workstation INFDS, which as you can
> imagine is going to be a bit difficult to implement.  However, from what I
> can tell of the programs, none seem to actually use the INFDS fields, even
> though they /COPY them in.
> 
> I will say this: copy members are brutal on all types of conversion
> programs, especially if you have logic in them.  You have to decide how to
> handle the possibility of requiring two different changes depending on the
> program including the /COPY.  For example, if you /COPY in the line
> "EXFMTRCD01" for two different displays, it could be problematic as to how
> to replace that code.  I have similar issues with using a /COPY for *INZSR.
> 
> At the same time, your display files are rather unusual.  Two of them have
> over 20 separate record formats, including multiple error message subfiles
> and windows.  Another uses the INVITE keyword, which I don't support.  A bit
> beyond the pale of a "simple" application.
> 
> All that said, it SEEMS that your "simple" system might still be able to run
> through the converter, since you've not done anything particularly
> outlandish.  I just need to have versions that compile.  The three programs
> that failed all failed because the fields C$INPT and CMDTXT were not
> defined.
> 
> I'm out of town tomorrow conferring with potential business partners, so I
> won't be able to touch this until Wednesday or Thursday.
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---