Odd MOVE question
md2100
FD the-file.
01 the-rec.
05 field-1 pic 9(9).
05 field-2 pic X(9).
05 field-3 pic X.
working-storage section.
77 fd-field-name pic x(20).
77 result pic (1024).
Is there any way to 'indirectly' reference/MOVE an item? In other
words, something like this:
accept fd-field-name.
move <reference>fd-field-name to result.
Example, if the fd-field-name entered is "field-1", the result in
'result' is the _contents_ of field-1 from the-rec? What I'm trying
to avoid is a huge EVALUATE that explicitly moves each FD field name
to 'field-value' based on the value of 'fd-field-name', ala:
EVALUATE fd-field-name
when "field-1" move field-1 to result
when "field-2" move field-2 to result
when "field-3" move field-3 to result
...ad nauseum...
END-EVALUATE
The program I'm writing needs to support multiple files, some with
hundreds of fields, and some that change so it could get ugly quick.
Being able to move by reference could potentially save thousands of
lines of code. BTW, this will be under MF COBOL and any MF-specific
solutions (ie, non-portable) are fine. I have to believe someone has
jumped this fence before.
TIA
Leif Svalgaard
One approximation to what you want could be:
01 rec1.
02 field-val pic x(9) occurs 1000 times.
77 field-nbr pic 999.
77 result pic x(1024).
accept field-nbr
move field-val (field-nbr) to result
Michael Mattias
datatypes and sizes, ACCEPT the dataname and then do a lookup, go get the
data and MOVE it. And I do mean, YOU can do it (not me).
--
Michael Mattias
Tal Systems
Racine WI USA
michael...@gte.net
Leif Svalgaard <le...@leif.org> wrote in message
news:iep06.30016$7V2.3...@typhoon.austin.rr.com...
lcccpi...@my-deja.com
ma...@bellsouth.net (md2100) wrote:
we have a file with a key and part of the key is the record type.
the file has 9 different record types we just redefine the the rest of
the record 9 times. Depending on the record type we know where the
data is.
Try a group moves you have a large field in the record layout. Then
you define several areas of the same size in working storage. Then you
can move the entire group depending on a condition. If you made it all
one big table with sections occupying the same space and redefine it
with an occurs you could use a subscript to move it.
Some compilers
Sent via Deja.com
http://www.deja.com/
md2100
>In article <3a4214db....@news1.lig.bellsouth.net>,
> ma...@bellsouth.net (md2100) wrote:
>
>we have a file with a key and part of the key is the record type.
>
>the file has 9 different record types we just redefine the the rest of
>the record 9 times. Depending on the record type we know where the
>data is.
>
>Try a group moves you have a large field in the record layout. Then
>you define several areas of the same size in working storage. Then you
>can move the entire group depending on a condition. If you made it all
>one big table with sections occupying the same space and redefine it
>with an occurs you could use a subscript to move it.
I appreciate people's responses, but I guess I didn't describe the
problem well enough. For starters, modifying an FD is not an option.
We have several hundred FD's. Creating table mappings for each of
those would also be a herculean task, especially considering all the
bizarre redefines, group levels, data types etc that are in the file
descriptions over the past 14 years. That's a metadata model, which
we simply don't have.
What I would like to be able to do is directly associate an FD's data
item _name literal_ to the actual data item's _value_ at run time. If
I can dynamically do it as I had asked is possible, it solves my
problem. The only other viable option is to explicitly code/account
for each and every field in every FD some way or another. Again, what
I'm looking for is this:
77 WS-FLD-NAME pic 9(20) value "REC-FLD-1".
77 WS-RESULT pic x(80).
MOVE (reference modifier)WS-FLD-NAME to WS-RESULT.
or
MOVE FUNCTION XYZ (WS-FLD-NAME) to WS-RESULT.
and WS-RESULT would contain the actual _contents_ of REC-FLD-1 record
field, not the literal "REC-FLD-1". I suspect I'm looking for a magic
solution that may not exist.
luke
In article <3a4270b7....@news1.lig.bellsouth.net>,
md2100
>Are you looking to optimize performance or maintainability?
Both. If my pie-in-the-sky solution is possible, there'd be virtually
no maintenance required and performance would be quite satisfactory (I
would think anyway).
William Wood
statement), but the trick is to be able to write the code quickly and
easily. If I got stuck with this one I would write a program that would
read an FD, parse it into the fields, and create a flat file with the code
for the EVALUATE statement. You should be able to write a generic program
(I think) and then run however many FDs you have through it. Just a
thought...
--
Bill
"md2100" <ma...@bellsouth.net> wrote in message
news:3a4270b7....@news1.lig.bellsouth.net...
William M. Klein
"object code" - so knowing (at run-time) a specified field-name does NOT
let you get at the proper location in storage.
There are TIMES when certain compilers do store data-names (usually for
debugging purposes) - but those are usually "internal-only" interfaces and
won't help.
THEORETICALLY, if your compiler provides a compile-time listing that shows
"offsets" in storage of specified data-names, then you could "process" the
compiler listing to get the offset in storage of what you want (based on the
field-name). This "processing" could be done once (per compile) and create
a data-set to be read by your actual program. My guess is that this would
be a WHOLE LOT more trouble than individual EVALUATE statements - but it
could be done (but most vendors do NOT guarantee that their compiler
listings don't change between releases - so you might need to "change" your
processing routine - each time you apply maintenance to your compiler).
--
Bill Klein
wmklein <at> ix.netcom.com
"md2100" <ma...@bellsouth.net> wrote in message
news:3a4270b7....@news1.lig.bellsouth.net...
rip...@kcbbs.gen.nz
> I appreciate people's responses, but I guess I didn't describe the
> problem well enough. For starters, modifying an FD is not an option.
> We have several hundred FD's. Creating table mappings for each of
> those would also be a herculean task, especially considering all the
> bizarre redefines, group levels, data types etc that are in the file
> descriptions over the past 14 years. That's a metadata model, which
> we simply don't have.
>
> What I would like to be able to do is directly associate an FD's data
> item _name literal_ to the actual data item's _value_ at run time. If
> I can dynamically do it as I had asked is possible, it solves my
> problem. The only other viable option is to explicitly code/account
> for each and every field in every FD some way or another. Again, what
> I'm looking for is this:
> I suspect I'm looking for a magic
> solution that may not exist.
The short answer is no you can't do, in Cobol, what you are asking for.
Are you writing a report writer ? (as distinct from a report generator).
Many years ago I started developing what I called a 'synthetic system'
written in Cobol so that I could easily develop a generalised file
maintenance and report writer that would handle a large part of the
basics for a production system. This has worked well over the years.
The basic synthetic system is based on a restricted set of FDs that
describe a set of files into which actual data files are forced. This
gives somewhat inefficient use of record space, but disk drives are
cheap. For each actual file a dictionary gives the relationship between
the fields, by type and index, and the field name. A screen layout text
file specifies how the fields for a given file are laid out in the
maintenance program and a script file describes the reports required.
When a new system is required the base can be thrown together very
quickly so that master file data entry can proceed while I design the
rest of the system. All file maint and reporting is quickly implemented
with text dictionary, screen and report scripts.
When I started retroactively applying the report writer to existing
systems I redesigned it slightly using a file module for each file and
designed a large interface containing enough fields of sufficient size
to cater for every possible layout. The file module then does a MOVE of
each record field into the interface, thus every record looks the same
to the report writer. Each file also needs a dictionary to say where in
the interface the data can be found:
Interface:
01 Interface-Record.
03 IR-Key PIC X(32).
03 IR-Flag PIC X OCCURS 40.
03 IR-Word PIC X(4) OCCURS 40.
03 IR-Value PIC S9(8)V99 OCCURS 50.
03 IR-Text PIC X(40) OCCURS 50.
03 IR-Date PIC 9(6) OCCURS 20.
Each File-Handler:
READ file ..
MOVE DaDa-Key TO IR-Key
MOVE DaDa-Replaced TO IR-Flag(1)
MOVE DaDa-Unit TO IR-Word(1)
MOVE DaDa-Name TO IR-Text(1)
MOVE DaDa-Address TO IR-Text(2)
.... for every field to somewher in interface
Each Dictionary:
*FILE DADA
REPLACED,F,1
UNITCODE,W,1
NAME,T,1
ADDRESS,T,1
Keep the number of types to a minimum becasue an EVALUATE will be
required for this.
Then the dictionary can be used to determine the type and index with a
simple IF .. ELSE or EVALUATE it can be accessed. The report writer (if
this is what it is) can handles every file via its file handler in a
consistent way. The field names can be presented as a list to the user
for selection and/or can be used in a script, such as
*REPORT OVERLIMIT
*FILE DADA
*COMPUTE
TOTALBAL=BALANCE0,E,BALANCE3 (E is sum of)
OVERLIMIT=TOTALBAL,-,CREDIT
*SELECT
CREDIT > 0 (only print if there is a credit limit)
OVERLIMIT > 0 (only print if balance > credit limit)
*SORT
OVERLIMIT,D (sort to descending ie worst first)
*LINE 1
NAME
PHONE
TOTALBAL
CREDIT
LASTPAID
LASTPAYMENT
*ENDREPORT
(This is the sort of thing my report writer does)
Michael Mattias
> What I would like to be able to do is directly associate an FD's data
> item _name literal_ to the actual data item's _value_ at run time....
You have described your problem (desire?) more than well enough.
The problem is, once the program is compiled, those datanames do not exist
anymore - they've all been translated into offsets and the approriate
machine instructions used to reflect the PICTURE clause available at COMPILE
time for any operations using those datanames.
Unless you take on the "herculean" task of coding those names, you cannot do
what you want to do.
(Unless, of course, you write a program to parse the source code and
generate all the necessary tables and MOVEs. )
--
Michael C. Mattias
Tal Systems
Racine WI
michael...@gte.net
luke
I neglected to mention that you are indeed looking for a magic solution
that does not exist.
Your options here depend on whether you want performance or
maintainability.
For performance, I like the idea posted by <lcccpi...@my-deja.com>:
"... just redefine the record 9 times. Depending on the record type we
know where the data is."
I see no problem with redefining the record 500 times in your case. We
do it all the time. I know of no upward limit on how many redefines
you may have of the same record. If anybody does know please enlighten
me by posting a reply to this.
Jerry P
In our case, a user selects a field (to appear on an output report or
to be used in a calculation or have its contents moved to another
field, etc.).
We have a table (actually a text file read into the program)
name
...
Addr1 ACxxxxyyyy
Addr2 ACxxxxyyyy
City ACxxxxyyyy
....
Where "A" implies alphanumeric (other choices are D=date, 0-9=numeric
decimal places, etc.)
"C" denotes which file (C=Customer), xxxx = offset from beginning of
record to 1st byte of field, and
yyyy=length of field. Sort of a poor-man's data-dictionary.
The user selects the field name(s) to use, say on a report.
This text list is searched once per run to determine the
characteristics of each item in the report. These characteristics are
stored in a table: For example ifteen selected fields, fifteen entries
in the table.
The code, then is:
PERFORM VARYING INDX FROM 1 BY 1
UNTIL INDX > NUM-ELEMENTS
MOVE TABLE-BEG(INDX) TO MYBEG
MOVE TABLE-LEN(INDX) TO MYLEN
EVALUATE TABLE-TYPE(INDX)
WHEN 'A' PERFORM MOVE-ALPHA
WHEN 'N' PERFORM MOVE-NUMBER
WHEN 'D' PERFORM MOVE-DATE
END-EVALUATE
END-PERFORM.
...
MOVE-ALPHA.
MOVE INPUT-REC(MYBEG:MYLEN) TO PRINT-LINE(NEXT-COL:MYLEN).
MOVE-NUMBER
is trickier. Ours is somewhat simplified since we deal with only
two types of numbers s9(5)V99 or S9(5).
"md2100" <ma...@bellsouth.net> wrote in message
news:3a4214db....@news1.lig.bellsouth.net...
RJones1005
Sounds like a job for pointers to me. I know our MicroFocus Complier at work
supports pointers, but beats the heck out of me how to make them work. Is
Microfocus COBOL unique in this feature?
William M. Klein
workstation compilers do now - and they will be included in the next
ANSI/ISO Standard. HOWEVER, they still won't help take a data-name and
dynamically (at run-time) find the values in that data item. As stated
earlier, most compilers do NOT store data-names in object code - so there is
no way to find the storage location (at run-time) from a data-name.
--
Bill Klein
wmklein <at> ix.netcom.com
"RJones1005" <rjone...@aol.com> wrote in message
news:20001222225415...@ng-ct1.aol.com...
Thane Hubbell
and destination names). There's a pre-processor available that
implements it.
---
Try a better search engine: http://www.google.com
My personal web site: http://www.geocities.com/Eureka/2006/
Thane Hubbell
VALIDATE certainly WILL handle this. Here's the code:
FD The-File.
01 The-rec.
05 Field-1 Pic 9(9)
Present When Fd-Field-Name = "FIELD-1" Destination result.
05 Field-2 Pic X(9)
Present When Fd-Field-Name = "FIELD-2" Destination result.
05 Field-3 Pic X
Present When Fd-Field-Name = "FIELD-3" Destination result.
Accept Fd-Field-Name
Move Function Upper-case (Fd-Field-Name) to Fd-Field-Name
Validate The-Rec.
Now, in the draft standard you can do this - as the Upper-case
function can be used as an identifier...
FD The-File.
01 The-rec.
05 Field-1 Pic 9(9)
Present When Function Upper-Case (Fd-Field-Name) = "FIELD-1"
Destination result.
05 Field-2 Pic X(9)
Present When Function Upper-Case (Fd-Field-Name) = "FIELD-2"
Destination result.
05 Field-3 Pic X
Present When Function Upper-Case (Fd-Field-Name) = "FIELD-3"
Destination result.
This is NOT available in the pre-processor of which I spoke - but the
VALIDATE CAN be used now by using this preprocessor - you can find
more infomation on it at:
(You may have to send an email from there - a cursory look didn't
reveal the pre-processor -- but I have it on good authority that it
exists).
K Ledding
comment, you may want to create a sub-program to handle all the file access.
My husband is a cobol programmer and they have 1 assembler program handling
ALL I/O for all their files! I believe he said they pass a name (123.xyz)
and the verb (read, etc). The result is that all of the mess is isolated
from the program being developed.
Just a thought.
Karen
Thane Hubbell <tha...@softwaresimple.com> wrote in message
news:3a4abacf...@news1.attglobal.net...
NA
K Ledding <kled...@eircom.net> wrote:
[snippage]
>My husband is a cobol programmer and they have 1 assembler program handling
>ALL I/O for all their files! I believe he said they pass a name (123.xyz)
>and the verb (read, etc). The result is that all of the mess is isolated
>from the program being developed.
Yow... I wrote one of those in COBOL, years on back; it contained the last
GO TO DEPENDING ON that I ever had implemented into Prod.
Ahhhhh, for the Oldene Dayse... and a Good Thing that They've passed, too!
DD
Paul Knudsen
I've worked on did this. There were different called programs for
sequential and vsam. It was for efficiency, I suppose. The calls
were logical enough once you got used to them. I doubt it would be
much fo a gain today, and maybe a loss since COBOL programs calling
Assembler have to be compiled with Data(24).
On Fri, 29 Dec 2000 11:47:28 -0000, "K Ledding" <kled...@eircom.net>
wrote:
William M. Klein
expecting them.
NOTE: If this statement doesn't mean anything to you - it is an IBM
mainframe compiler option available since VS COBOL II.
--
Bill Klein
wmklein <at> ix.netcom.com
"Paul Knudsen" <pknu...@gw.total-web.net> wrote in message
news:3a4cb81d...@news.gw.total-web.net...
Alain Reymond
set address of <variable> to <pointer>
and all instructions using pointers. They might solve your needs.
Alain Reymond
YukonMama
>Date: 12/29/00 6:47 AM Eastern Standard Time
>Message-id: <9M_26.2421$s4....@news.indigo.ie>
>
>Just to add one more thought on your need to support so many files, per your
>comment, you may want to create a sub-program to handle all the file access.
>My husband is a cobol programmer and they have 1 assembler program handling
>ALL I/O for all their files! I believe he said they pass a name (123.xyz)
>and the verb (read, etc). The result is that all of the mess is isolated
>from the program being developed.
>
>Just a thought.
>Karen
>
Ut oh - does your DH work at GTEDs? I read your post to my DH and he went
screaming from the room (having done a stint there trying to understand their
billing programs) He's much better now.
Paul Knudsen
option in our production assembler.
My main point is that there's no longer any reason to do I-O in
assembler.
Binyamin Dissen
wrote:
:>OK, it could be site specific. I've never been able to find a 31 bit
:>option in our production assembler.
As assembler is coded directly, rather than compiled, there is not concept of
a 31 bit option. The code and interfaces have to be written to handle 31 bit.
There are AMODE and RMODE assembler directives, but all they do is set
indicators in the object deck so that the linkage editor can determine, if not
given explicit AMODE & RMODE instruction, what is the least restrictive
environment required. If the directives are not specified they default to
24/24.
:>My main point is that there's no longer any reason to do I-O in
:>assembler.
Certain I/O can not be done in COBOL, such as when the format/record length of
the files is not known.
For example, without assembler, how would you handle a case where the RECFM is
FB but the LRECL can be one of 80, 122, 155, 193, etc.?
:>On Fri, 29 Dec 2000 10:43:59 -0600, "William M. Klein"
:><wmk...@ix.netcom.com> wrote:
:>>COBOL can "happily" CALL DATA(31) programs - assuming the Assembler is
:>>expecting them.
>
:>>NOTE: If this statement doesn't mean anything to you - it is an IBM
:>>mainframe compiler option available since VS COBOL II.
--
Binyamin Dissen <bdi...@dissensoftware.com>
Binyamin Dissen <bdi...@netvision.net.il>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Paul Knudsen
<post...@dissensoftware.com> wrote:
>On Sat, 30 Dec 2000 18:46:17 GMT pknu...@gw.total-web.net (Paul Knudsen)
>wrote:
>
>:>OK, it could be site specific. I've never been able to find a 31 bit
>:>option in our production assembler.
>
>As assembler is coded directly, rather than compiled, there is not concept of
>a 31 bit option. The code and interfaces have to be written to handle 31 bit.
So that it. Well as I said, the modules I was talking about were
written back int he 80's.
>There are AMODE and RMODE assembler directives, but all they do is set
>indicators in the object deck so that the linkage editor can determine, if not
>given explicit AMODE & RMODE instruction, what is the least restrictive
>environment required. If the directives are not specified they default to
>24/24.
>
>:>My main point is that there's no longer any reason to do I-O in
>:>assembler.
>
>Certain I/O can not be done in COBOL, such as when the format/record length of
>the files is not known.
>
>For example, without assembler, how would you handle a case where the RECFM is
>FB but the LRECL can be one of 80, 122, 155, 193, etc.?
I'd tell whoever is trying to send me the stupid thing to format it
properly.