Thanks ... will have to work it out ourselves then what just hoping that there was some tool... but what it to sometimes struggle make it so much more interesting
Before applying any effort on making such a translator(i.e. asm->cobol) one will have to see if it is really worth it.
e.g. If somebody has only 50-100 odd programs to be converted then its not worth investing effort on a translator which will take many months for itself to be developed in the first place.
Well, this is quite a code. I am wondering if it is just 1/100th or so, how big the whole utility would be?
Anyways, from the first looks, it seems to be comparing the assembler source statements with predefined literals/constants in the program and substituting equivalent cobol code for that. I think this conversion can be done in a high level language like cobol far easily and with relatively less effort.
What about those functionalities which are specific to assembler e.g TR or translate instruction?
Is this assuming that the opcode will always start from 9th column? If not then we'll need an aligning routine first to align the program as per the expectations.
Is this assuming that the opcode will always start from 9th column? If not then we'll need an aligning routine first to align the program as per the expectations.
1) Actually 9(3,R4) is the 10th column, since offsets in assembler are relative to zero.
2) The supplied code actually checks for the constant values 'CLC', 'CLI', 'CP ', or 'TM ' beginning in any of columns 10, 11, 12, or 13 due to the setting of the Record base address register (R4) to the address of the record (L R4,RECADD) and the setting of the loop counter (R5) to a value of 4 (LA R5,4), followed (if all of the Compares fail equality) by an increment of the Record base address register by 1 (( LA R4,1(R4)), followed by a BCT which decrements the loop counter and repeats the loop up to 3 more times - that is, until the loop counter becomes zero (BCT R5,LOOP4).
if the people who wrote the program are happy we are happy ...
I would have taken a different approach
consolidate in one <buffer> the instruction/macro
parse the thing into the three components <label> <opcode> <operands>
the program would have been more readable and probably more compact
Joined: 14 Apr 2010 Posts: 9 Location: Hartford, CT. USA
Code:
IOAREA DSECT
RGUSEGLV DS C SEGMENT CODE FOR THIS SEGMENT
RGUMIGX EQU X'02' Migratx indicator for trailer @PQ40
RGUHSDF DS C DELETE FLAG USED BY HSAM
HSAMDFLG EQU X'80' FLAGS HSAM THIS SPECIAL FORMAT DB
RGTRAILR EQU X'90' Trailer/statistics record @PQ40
RGPART EQU X'01' Partitioned DB @PQ40
RGFALLBK EQU X'02' Fallback from partitioned DB @KW30
RGMIGRAT EQU X'04' Migration to partitioned DB @PQ36
RGSTAT40 EQU X'08' 40-byte stat record @PQ72
RGUHDRLN DS H LENGTH OF HEADER PORITION OF RECORD
RGUSEGLN DS H LENGTH OF DATA PORITION OF RECORD
RGUSEGNM DS CL8 SEGMENT NAME
RGUSEGDF DS C DELETE FLAG OF SEGMENT
RGUPFCTR DS XL4 COUNTER FIELD OF PREFIX
IOTWFOR DS XL4 LOGICAL TWIN FORWARD POINTER
IOTWBACK DS XL4 LOGICAL TWIN BACKWARD POINTER
IOPAR DS XL4 LOGICAL PARENT POINTER
IOOLD DS XL4 OLD LOCATION OF RECORD
IOSEG DS 0CL1 VARIABLE LENGTH DATA FIELD
RGULEN EQU *-IOAREA Prefix length
MEND
PIOAREA DSECT
PGUSGLEV DS C Segment code for this segment
PGUHSDFP DS C Flag byte to identify DB type
PGTRAILR EQU X'90' Trailer/statistics record @P
PGUTYPE EQU X'01' Indicates partitioned DB
PGUTYPF EQU X'02' Indicates fallback from HALDB @P
PGUTYPM EQU X'04' Indicates migration
PGUST40 EQU X'08' Indicates 40-byte stat record @P
PGUHDRLG DS H Length of header portion of record
PGUSEGLG DS H Length of data portion of record
PGUSGNAM DS CL8 Segment name
PGUSGDFG DS C Delete flag of segment
PGUPXCTR DS XL4 Counter field of prefix
PGUSGPID DS XL2 Partition ID
PGUSRGNB DS XL2 Reorganization number
PGUILK DS XL8 ILK OF SEGMENT
PGUPPTR DS XL28 POINTER SET IF LC
PGIOSEG DS 0CL1 Variable length data field
PGULEN EQU *-PIOAREA Prefix length
MEND
Joined: 11 Jan 2012 Posts: 3 Location: United States
Speaking of Klingons: (old 80s joke follows)
What do Starship Enterprise and toilet paper have in common????
Both circle Uranus looking for Klingons.
****************************************************************
But seriously,
Assembler tip 1:
Instead of coding
CLC 9(3,R4),=C'CLC'
code CLC =C'CLC',9(R4)
you do not have to supply length because assembler calculates from literal
NOTE: assuming assembler op code starts in 10 I believe is wrong. I think it can start in pos. 2 until 10 with no label and pos. 3 until 10 with label.
Assembler tip 2:
After every I/O and macro, test something to see if it worked.
Plain old tip 3:
Forget doing this!
There is a reason no one has done this successfully or even attempted this. You have to have decades of experience with assembler and macros to even attempt a manual conversion, let alone a programmatic conversion. Bit handling and, as mentioned earlier, TR and TRT not being available in any language except assembler and sheer complexity of macros are just a few of the many, many daunting problems.
Also, writing your program in COBOL would be much easier. All you are really doing in your assembler program is parsing words while trying to generate COBOL statements.
I think you are basically about 1/100th of the way started.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I think this is about it for the first one. I have made all the binary (comp) fields unsigned, which I imagine matches your data, if not replace 9 with S9. I have used 9(8) for the word-sized binaries. I suggest only changing to (9) if you need all the digits. (9) is the worst size of COMP to do any 'rithmatic with.
The second record is straigthforward except for these two:
Code:
PGUILK DS XL8 ILK OF SEGMENT
PGUPPTR DS XL28 POINTER SET IF LC
Is the ILK a huge number or two smaller ones, or what? Other than that I think you've got enough to do the second record yourself, after all, it is only New Haven.
On that, how are we going to work this? Do I just contact the Mayor's office and he signs over the deeds? Does it include both the Universities?
I got burned in a deal like this once before. I swapped an OCCURS DEPENDING ON definition for the Brooklyn Bridge. Turned out it was a scam, though I don't know what the other guy thought he got out of it. I hope this doesn't go the same way.
So that you don't have to depend on what is specified for NUMPROC when the COBOL code is compiled, it's better to use S9(9) COMP-5 instead of S9(8) COMP. That way you will actually produce code that is functionally equivalent to the assembler code, i.e. it won't lop off the most significant digits if the number being stored is greater than 99,999,999.
Others have also said that there is no COBOL equivalent to TR. I beg to differ; INSPECT string CONVERTING string2 TO string3 will generate a TRanslate. I frequently use it to convert LOW-VALUES to SPACES and lower-case to upper-case.
For example,
INSPECT FIRST_NAME
CONVERTING
X'00818283848586878889919293949596979899A2A3A4A5A6A7A8A9'
TO ' ABCDEFGHIJKLMNOPQRSTUVWXYZ'
is equivalent to
Code:
TRTAB DC 256AL1(*-TRTAB) STANDARD TRANSLATE TABLE
ORG TRTAB
DC C' '
ORG TRTAB+C'a' (or +X'81')
DC C'ABCDEFGHI'
ORG TRTAB+C'j' (or +X'91')
DC C'JKLMNOPQR'
ORG TRTAB+C's' (or +X'A2')
DC C'STUVWXYZ'
ORG ,
.
.
.
TR FIRST_NAME,TRTAB (assuming HLASM)
In the old days of COBOL, TRANSFORM did the same thing.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Welcome Conrad.
NUMPROC doesn't affect binary fields. Perhaps you meant TRUNC?
In 2 1/2 years the OP has not complained. Without seeing the Assembler code, we can't tell if there is full use of the bits in any F's or H's. If there was full use, COMP-5 would be required. If not, not. since COMP-5 tends to generate more instructions than COMP and its aliases, I only use/recommend it when it is actually required.
You are correct about the INSPECT. Mr Bill is a regular advocate here of INSPECT ... CONVERTING ... with literals for that type of thing and other uses. (Without the literals, different code is generated).
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
I try to avoid ORG, though that won't stop me. This is very hard to type, but ...
Code:
TRTAB DC 0XL256'0',C' ',(C'a'-(*-TRTAB))AL1(*-TRTAB),C'ABCDEFGHI'>
,(C'j'-(*-TRTAB))AL1(*-TRTAB),C'JKLMNOPQR',(C's'-(*-TRTA>
B))AL1(*-TRTAB),C'STUVWXYZ',(256-(*-TRTAB))AL1(*-TRTAB)
This is the same, and it's easier to type.
Code:
TRTAB2 DC 0XL256'0',C' ',(C'a'-(*-TRTAB2))AL1(*-TRTAB2)
DC C'ABCDEFGHI'
DC (C'j'-(*-TRTAB2))AL1(*-TRTAB2)
DC C'JKLMNOPQR'
DC (C's'-(*-TRTAB2))AL1(*-TRTAB2)
DC C'STUVWXYZ'
DC (256-(*-TRTAB2))AL1(*-TRTAB2)
Instead of something like C'j' you can use C'J'-X'40'. That will work fine if you are using ORG instructions, but it does get clumsy in the complex DC instructions I've sort of fallen in love with.
If you really want to be clever, change something like C'ABCDEFGHI' to 9AL1(*-TRTAB+X'40').
Code:
TRTAB3 DC 0XL256'0'
ORG TRTAB3
DC C' ',(256-(*-TRTAB3))AL1(*-TRTAB3)
ORG TRTAB3+C'A'-X'40'
DC 9AL1(*-TRTAB3+X'40')
ORG TRTAB3+C'J'-X'40'
DC 9AL1(*-TRTAB3+X'40')
ORG TRTAB3+C'S'-X'40'
DC 8AL1(*-TRTAB3+X'40')
ORG ,
One serious flaw with all these translate tables is they wont't translate non-printables (except for X'00') to blanks, but I'll leave that as an exercise for all you lurkers out there who probably won't bother to try to understand these instructions.
.jpg)
