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)
