RE: Free OS/400

GLNOWRKX works here as well.  It's GLNOADDX, GLNOEDTX and GLNOINQX that
fail.  As far as I can tell, it dies because nobody writes to ASSUME, and so
the output specification for the record is dropped, and therefore the field
CMDTXT is not defined.  In ZIPCEDTX, C$INPT and CMDTXT are defined in a data
structure, included via a /COPY.

Further looking pins it down to a bad /COPY.  The GLNO programs are trying
to /COPY from $BLDCMDW65, which doesn't exist, while the ZIPC programs use
$BLDCMDW40, which does.  A guess would say that $BLDCMDW65 splits CMDTXT
into two 65-byte fields.

Other than that, I'm whacking my head against a wall trying to decide how
much trouble it's going to be to have multiple programs using the same
display file, but I don't think it will cause a problem.  It's certainly not
something I recommend to people; I'm always a big believer in smaller is
better.  But this will be an interesting challenge.

DFRWRT doesn't require INVITE.  I've used it extensively in previous lives.

Seeya when I get back.

Joe

> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of James W. Kilgore
> Sent: Monday, July 09, 2001 4:36 PM
> To: MIDRANGE-L@midrange.com
> Subject: Re: Free OS/400
>
>
> 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
> +---
>

+---
| 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
+---