• Subject: Re: RPGIII question
  • From: MacWheel99@xxxxxxx
  • Date: Wed, 15 Nov 2000 13:38:59 EST

I do my internet communications from home PC where I do not have access to 
AS/400 & when I am at the office AS/400, I do not have internet access, so I 
am giving quickie replies from memory experience which may be occasionally 
flawed, as people have pointed out ... if I had only investigated this or 
that further.

I do not remember exactly what columns the "DS" goes in, but if you have a 
program with *LDA access, there is a place with UDS, which is a particular 
kind of DS (there are various other kinds) & I am referring to the blank DS 
kind.  I think Data Structures are a really cool programming technique - when 
your time permits, you really need to read up a bit on some of their uses.  I 
use several kinds & still struggling to learn the spectrum of functions.

You use the same identical fields as input specifications to define each 
CDE## in a column, just below the DS line, and in that same block you have 
your array.

So if the scenario was 20 fields at 3 decimal, that is an aggregate length of 
60
 1 to 60 is CDE defined in the DS as if it was a character field, but the 
earlier E-specs definition knows it is an array ... by this means your 
DS-definitions can exceed the ceiling on a field definition ... note here 
that you do NOT put the decimal into CDE definition in the DS

> Hi,
>  
>  This sounds exactly like what I need but I'm not quite sure how to
>  code it. Would it be possible to post an example?
>  Regards,
>  Matthias
>  > 
>  > >From Al Mac - here's how I do that
>  > 
>  > I create a data structure (DS) in the input specifications 
>  > in which I overlay
>  > CDE (array)
>  > CDE01 CDE02 CDE03 etc. fields such that
>  > CDE,1 is the same place as CDE01
>  > CDE,2 is the same place as CDE02
>  > etc.
>  > 
>  > When the physical file is read, the data automatically also goes into the
>  > data structure spaces CDE01 CDE02 etc. overlaying the CDE array contents.
>  > 
>  > Depending on how you access the physical file, 
>  > you may wish to have one array
>  > for input / output and another for processing within the calculations.
>  > 
>  > If you have a very large array, remember that output specifications & 
> > other places in the code need to fit in the array identification 
> > within 6 positions
>  > ... so you want to avoid either long array names or long indexes.  

In some programs I have an array
bottom of source
**
January
February
March
April

etc. which is defined as a 12 element array PER (for Period)
then I put the MONTH digits into field MO
and I use this in a fancy header, printing date in format
November 15, 2000
which looks a lot nicer than numbers with slashes
but in most programs I do not bother

>  > PER,MO for example (period month) fits, but nothing longer fits.

When you look at the compile listing ... right below the F specifications 
there is a format name, or something, which you refer to within the program - 
you can also do a rename on it in case of multiple logical accesses to the 
same file in the same program.  Whatever that name is in the F-specs when it 
brings in the external definition from the compile, is what you have to use 
in the input specifications.

When I do this kind of thing
 FINPUT   IF  E           K        DISK
               some BS in compile with over on right hand side INFILENAME
> file name and record format, respectively.

then I do not use INPUTR in my input specifications but
INFILENAME or whatever it is that the compile identified as the reference for 
accessing the file

When I saw INPUTR in Mike's post, I wondered ... 
Can you do a RENAME at the time of input instead of file specifications time?
Even if you could, it might not be smart ... it is easier to read this stuff 
when the file specifications are all on one page together.

>  Hi Mike,
>  
>  This doesn't work for me.
>  The compiler complains that INPUTR is defined more than once (4111),
>  which it is, once in the F-spec and again in the I-spec.
>  Where am I going wrong?
>  Regards,
>  Matthias
>  
>  Mike McKinney wrote:
>  > 
>  > Here is some sample code for renaming externally described fields as 
array
>  > elements.
>  > 
>  > FINPUT   IF  E           K        DISK
>  > 
>  >  E                    CDE        20  3 0
>  > 
>  >  IINPUTR
>  >  I              CDE01                           CDE,01
>  >  I              CDE02                           CDE,02
>  >  I              CDE03                           CDE,03
>  >  I              CDE04                           CDE,04
>  >  I              CDE05                           CDE,05

I think Mike's solution is much slicker than the one I gave you, from the 
perspective of what you asked for.
However, mine gives you access to both the array & field format ... change 
one & it also changes the other, which is important to me when I am also 
doing output to some file ... the output is in the form CDE##, while my 
calculation manipulation is in the CDE,C form.  In fact, if the output file 
has a different naming convention but same field sizes, I can overlay all 3 
in the same DS, and save the hassle of populating the output with any move 
statements.

Alister William Macintyre 
Computer Data Janitor etc. of BPCS 405 CD Rel-02 on 400 model 170 OS4 V4R3 
(forerunner to IBM e-Server i-Series 400)  @ http://www.cen-elec.com Central 
Industries of Indiana--->Quality manufacturer of wire harnesses and 
electrical sub-assemblies

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


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

This mailing list archive is Copyright 1997-2019 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].