|
View previous topic :: View next topic
|
| Author |
Message |
GAPX1
New User
Joined: 12 May 2007
Posts: 9
Location: arizona
|
|
|
|
Hi:
I have inherited some COBOL CICS programs which link to DFHL3270. They work as advertised. Issue is when changes are made to the maps, I am not sure how to apply these changes to the following structure, which seems to represent the map layout. This structure is passed as part of the inbound vector.
The literals seem to represent a row/column position on the map, but I am not really sure. Would anyone know how this structure applies to the map?
Thank you.
01 WS-LSMS550.
05 WS-LSMS130-FILLER1 PIC X(03) VALUE X'1140C1'.
05 WS-LSMS130-TRANSID PIC X(09) VALUE 'LSMU'.
05 WS-LSMS130-FILLER2 PIC X(03) VALUE X'11404B'.
05 WS-LSMS130-PATH PIC X(11) VALUE 'S550 ILEL '.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'11C6D1'.
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'11C761'.
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'11C8F1'.
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'114FC1'.
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'1150D1'. |
|
| Back to top |
|
 |
Jose Mateo
Active User
Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico
|
|
|
|
| What you are looking at is the DSECT generation of the BMS map. Each field on the screen has a attribute field of three bytes followed by the field. There's a input 01 level redefined by a output 01 level. |
|
| Back to top |
|
|
GAPX1
New User
Joined: 12 May 2007
Posts: 9
Location: arizona
|
|
|
|
Thank you Jose:
I understand each field on the map is preceded by 3 bytes (length & attribute).
But in my example, I don't see where the X'11404B' relates to the literal that follows it VALUE 'S550 ILEL ' which is 11 bytes in length.
Similarly, I don't see where the X'11C6D1' relates to the literal that follows it
VALUE '_', which is 1 byte in length, and so on....
Very confusing... |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
I understand each field on the map is preceded by 3 bytes (length & attribute).
But in my example, I don't see where the X'11404B' relates to the literal that follows it VALUE 'S550 ILEL ' which is 11 bytes in length.
Similarly, I don't see where the X'11C6D1' relates to the literal that follows it
VALUE '_', which is 1 byte in length, and so on.... |
Since the data in those fields are generated when the BMS map is compiled, you have no reason to understand the relationship between the literal and the field. When you make a change to the BMS map and recompile it, the data will be changed during the compilation process to be what it should be -- you have nothing to do with it. If you dig deeply enough into BMS, you can probably figure out what the relationships are but that is too deep for me -- as long as the map works the way it is supposed to work, I don't really care what the literal values are. |
|
| Back to top |
|
|
GAPX1
New User
Joined: 12 May 2007
Posts: 9
Location: arizona
|
|
|
|
Thank you Robert:
The underlying issue is that a non-mainframe application is using the DFHL3270 Bridge to initiate the request to the mainframe visa inbound and outbound vectors.
So I do not really have a BMS map being processed via the vectors. All I have on the mainframe side is the literal table mentioned above. So if the non-mainframe makes any changes to the mapping (on their side), I need to have the literal table modified to process those changes, and sent back to it. This is the main sources of my confusion!
Thank you. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
I think you COMPLETELY misunderstand the process of generating BMS maps. If the non-mainframe side needs changes to the BMS map, you -- or whoever -- codes up the changes in the BMS source code to match what is changed. You -- or whoever -- then compiles the BMS map using the standard BMS compile process for your site. This will convert the assembler macros into several things: a load module that CICS can use, and a high-level language source that can be used as a copy book for the high-level program. YOU do not have to change anything other than making the map match what the non-mainframe side needs. Once you do that and recompile the map, the DSECT will be generated with the correct literals. You do not have to worry about the literals since the system generates them.
If you expect to do anything else, you need to work with your site support group to understand what the process is AT YOUR SITE -- as it will not resemble anything used at the other thousands of CICS sites. |
|
| Back to top |
|
|
GAPX1
New User
Joined: 12 May 2007
Posts: 9
Location: arizona
|
|
|
|
Thank you Robert:
At the risk of being obnoxious about this, I don't think I am explaining my question very well. Let me give it another attempt!
I have struck out in asking our support folks for help.
Our COBOL program has no copybook for the symbolic map, nor does it contain any 'BMS' type references to the map in question. The map does certainly exist, both symbolic and physical, but the program makes no references to either. There are no CICS mapping commands in the program.
We are receiving via DFHL3270 requested fields from a non-mainframe source. There is a literal table in the COBOL program which builds the map image, and passes it back to the non-mainframe requestor.
We do know what the map looks like in the standard BMS world, but BMS is not being used in the process to build the map image.
The map image is created via a Working Storage table with literals and HEX values.
What I am questioning is the how the HEX values relate to the map layout.
The standard length and attribute bytes for each field do not seem to follow the 'normal' BMS mapping.
Here is a portion of this literal table:
01 WS-LSMS550.
05 WS-LSMS130-FILLER1 PIC X(03) VALUE X'1140C1'
05 WS-LSMS130-TRANSID PIC X(09) VALUE 'LSMU'.
05 WS-LSMS130-FILLER2 PIC X(03) VALUE X'11404B'
05 WS-LSMS130-PATH PIC X(11) VALUE 'S550 ILEL '.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'11C6D1'
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'11C761'
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'11C8F1'
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'114FC1'
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'1150D1'
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
05 WS-LSMS130-FILLER3 PIC X(03) VALUE X'11D161'
05 WS-LSMS130-F005 PIC X(1) VALUE '_'.
Thank you. |
|
| Back to top |
|
|
dneufarth
Active User
Joined: 27 Apr 2005
Posts: 419
Location: Inside the SPEW (Southwest Ohio, USA)
|
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
| Back to top |
|
|
|
|
