|
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 +---
As an Amazon Associate we earn from qualifying purchases.
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.