|
View previous topic :: View next topic
|
| Author |
Message |
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
| dbzTHEdinosauer wrote: |
Ronald Burr,
thanks for the clarification. I spent some time going thru the manual and
missed the part that identifier-6 & 7 had to be elementary items. |
Dick,
This restriction borders on "nutty". Why would the compiler folks impose this?
Whether it's addressed at a group level or at an elementary level, it's the same address. 
I guess they have their reasons. 
BTW, I missed this too in the manual. 
Bill |
|
| Back to top |
|
 |
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
| Bill O'Boyle wrote: |
This restriction borders on "nutty". Why would the compiler folks impose this?
Whether it's addressed at a group level or at an elementary level, it's the same address.
Bill |
I agree.
The requirement that both of the identifiers be "elementary" items does seem a bit arbitrary, given that each of the group-items and its respective redefined elementary items have the same address, the same length, and the same class (alphanumeric).
I guess that's why I mis-remembered that requirement when I posted the original code. I only remembered the requirements that both identifiers had to have the same length, and that identifier-6 could not contain duplicate character values. Hopefully, I won't mis-remember similarly in the future. |
|
| Back to top |
|
|
acevedo
Active User
Joined: 11 May 2005
Posts: 344
Location: Spain
|
|
|
|
ooops... I had posted the same as Ronald Burr about the redefines... I hadn't read the 2 page.
 |
|
| Back to top |
|
|
essence21
New User
Joined: 05 Dec 2008
Posts: 20
Location: mumbai
|
|
|
|
Thanks All,
Its working perfectly now.
I feel the issue was cropping up due to 03 level defined under 05.. i now modified to 01 --> 03 --> 05.. And its working ok.
Thank you for your help...
Just one more thing i was wondering what be the CPU usage if this is inserted into a scheduler which runs 1 minute frequency and the field is PIC X(967) |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
An INSPECT...CONVERTING statement in COBOL results in assembler TRANSLATE instructions, which are very, very fast - especially when compared to any other method of performing the same task. The Principles of Operation Manual describes the TRANSLATE instruction thusly:
"The bytes of the first operand are selected one by one for translation, proceeding left to right. Each argument byte is added to the initial second operand address. The addition is performed following the rules for address arithmetic, with the argument byte treated as an eight-bit unsigned binary integer and extended with zeros on the left. The sum is used as the address of the function byte, which then replaces the original argument byte."
Since your source field is more than 256 bytes ( the limit for a single TRANSLATE instruction ), and of a FIXED length, I'm "assuming" that the compiler will simply generate FOUR such TRANSLATE instructions ( three of 256 bytes each, and one for the remainder (199 bytes)) in order to convert the entire field.
If the field were of a VARIABLE length, the underlying code would have to contain a "loop" to perform zero or more 256-byte TRANSLATEs, followed by one for the remainder ( when it becomes less than 256 bytes ). Though somewhat less efficient than when dealing with FIXED length fields, it would still be the fastest method available to accomplish the task. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Ron,
I believe the Assembler expansion for an INSPECT CONVERTING using WS fields in the FROM and TO, as opposed to literals in the FROM and TO, will cause a CALL/BALR to a COBOL run-time module.
I've found that when using literals and the target of the translation has a length of not greater than 768 and is not using reference modification, the compiler will generate three in-line "TR" instructions. Otherwise, a run-time module is called <sigh>.
For whatever reason (and I think this should be amended), the maximum literal length is 160, which is an odd maximum.
Bill |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
Inquiring minds want/need to know --- so I compiled a little test. You are correct, Bill - it appears that if the conversion tables are 256-bytes each (as in the code I provided), then a call is made to run-time subroutine IGZCIN1. I tried it both as a 967-byte source field, and as four smaller defined sub-fields - in each case calls were made to the subroutine (one for each defined field/sub-field, so it's presumably more efficient to convert one 967-byte field than four smaller fields).
| Code: |
L 2,92(0,9) TGTFIXD+92
L 15,68(0,2) V(IGZCIN1 )
LA 1,149(0,10) PGMLIT AT +145
BALR 14,15 |
|
|
| Back to top |
|
|
|
|
