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


  • Subject: Re: Subfiles as program defined?
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Thu, 19 Apr 2001 18:01:45 -0500 (CDT)


Jim,

If you're just looking for a quick hack to get this thing working, 
replace the READ/WRITE/EXFMT to the record format in question with
subroutines/subprocedures.

Make the subroutines use MOVE or EVAL to make the data go into each
of the data structures.

It shouldn't take more than a few minutes (using this method) to make it
so that you only have one field to deal with in the input specs.

The process of converting it to be externally defined is a bit more
difficult, but hardly an "extensive change".   Either use the same field
names in the ext def as you have in the program, or use SEU's ability
to find/replace a string to change all the field names in the program.

(and, of course, replace any EXCPT's with UPDATE/WRITE... but you did
that when you created your subroutines)  

Or maybe I don't understand?  Because this doesn't seem like it's that big
of a deal to me...


On Thu, 19 Apr 2001, Jim Langston wrote:

> Yes, the people who wrote this package develop, pretty much, spaghetti code.
> 
> And yes, eventually, all the files in the program will be externally
> defined, but this is one of many projects I have on my list and it needs to
> get done as soon as possible, yesterday if possible <grin>.
> 
> And, yes again, those were file keys in question for the data structures.
> 
> That's what I was afraid of, having to modify this program extensively
> to get it to work with externally described files.
> 
> Regards,
> 
> Jim Langston
> 
> VWilliamson@glazers.com wrote:
> > 
> > I've never heard of program describing a subfile.  From an old S36 person
> > whose converted several hundred to RPGIII and RPGIV.   How would you fill
> > it or readc the subfile records?
> > 
> > Is there some reason why you don't want to externally define the disk files
> > also?  At least 2 of the data structures look like definitions for file
> > keys.  These you can replace with KLIST if externally defined.  Otherwise,
> > I think you have no choice except to eval or move to these extra
> > definitions when you read each subfile record.
> > 
> > I guess it all depends if you're working with spaghetti code or not.
> > 
> > Valene M. Williamson
> > IBM Certified Specialist
> > vwilliamson@glazers.com
> > 972-448-8018
> > 
> > +---
> > | This is the RPG/400 Mailing List!
> > | To submit a new message, send your mail to RPG400-L@midrange.com.
> > | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator: 
>david@midrange.com
> > +---
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
> 

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.