Data Stream Translation in C

[Guest.Visitor]

Has anyone used the Data Stream Tranlation API for C. I got the Virtual Terminal Emulator API to work but can't get the translation API (QD0STRTS)and(QD0TRNDS) to work. I can't seem to see any data stream at all. IBM is vague in this area so I'm looking for any examples of the use of this API.

[Guest.Visitor]

You don't mention what release you are on, but there was a bug in the header file QD0TRNDS where the 3rd parameter was prototyped as int rather than int *. This would prevent you from seeing the length of the generated data stream which sounds like what you seem to be reporting. This was fixed on RISC releases but appears to still exist for V3R1 and V3R2. If you are on V3R1/V3R2 copy the header file to a source file of your own, change the header, and then #include that header. You cannot directly modify the QSYSINC header as that source file only permits read operations. If this is not your problem could you provide additional information on what you are seeing. I played with these APIs years and years ago, but cannot find any of my code off hand.

[Guest.Visitor]

Thanks for your response. I'm on V4R3 and using a Virtual Terminal Emulator with the QTV0PNVT API. With this I am attempting to read the datastream created, with the QD0STRTS to start the translation and the QD0TRNDS API to Translate the Data Stream. I can read the dataque but the translation doesn't return more than the handle (at least as far as I can see using sprintf(buffer, "%s",handle). My basic direction is to do an emulation to 1920 data stream and this was the only direction I could find. If there is another way to produce a 1920 data stream I would be interested. Otherwise I need to figure out the translation API. Thanks for any help.

[D.Handy]

Bret, I can read the dataque but the translation doesn't return more than the handle Are you using QTVRDVT to read the buffer from the VT using the handle obtained from QTVOPNVT? When the data queue has an entry ID of " 2" then you must first use QTVRDVT to obtain the data. This data may then be sent to QD0TRNDS if that is what you are trying to do. (I'm not even sure what QD0TRNDS does when used with *FORMAT and 5250 as the I/O formats, which is what I presume you are trying. I've never used QD0TRNDS...) My basic direction is to do an emulation to 1920 data stream and this was the only direction I could find. If there is another way to produce a 1920 data stream I would be interested. What is it you are trying to do? In terms of producing data streams, the DSM api's can be very useful. Create a DSM buffer and let DSM build the data stream in the buffer instead of doing immediate operations. Then extract the data stream from the DSM buffer. But DSM would be useful if you were trying to create a display format on the fly, and I'm not sure this is what you are trying to do. Are you trying to write an emulator (eg WSG-like)? Run an interactive session under program control? Produce a 1920-byte image of a display from the data stream sent to a WS controller? Or ??? Doug

[Guest.Visitor]

Doug, You said you never used the QD0TRNDS but the other DSM apis are useful. What other DSM apis are you refering to? What I am trying to do is change from our current use of a SNA api that translates the data steam to an ASCII plain text 1920 character string, to a TCP/IP api that will do the same. I was hoping that using the QD0TRNDS api I would be able to take the data stream and strip out all the formmatting character to get just the 1920 character string. If you know of any other apis that would arrive at the plain character string please let me know.

[D.Handy]

Bret, You said you never used the QD0TRNDS I didn't even know it existed until your post. And I'm still not clear from the API docs what it is supposed to do when using *FORMAT instead of 3270xx for the translation mode. So I tried just adding some calls to QD0TRNDS (after QD0OPNTS of course) to see what it would pass back to me. I didn't find the magic incantation right away, and haven't got back to it. What other DSM apis are you refering to? There are a series of APIs called the Dynamic Screen Manager APIs. They were added to facilitate generating screen formats on the fly instead of using DDS for pre-formatted displays. Prior to the DSM apis it was necessary to use the DDS keyword USRDFN for this, and supply what became known as User Defined Data Streams (aka UDDS). Generating screen formats on the fly is useful in a number of tool/utility type programs. But this is very different than translating data streams like you would in emulation programs. I mentioned the DSM apis because they are good are encapsulating the details of the 5250 data stream from the programmer, but the program has to know how it wants to format the screen (eg get a file's definition and generate a screen format to match it). The DSM apis are also useful for determing the characteristics of a screen (eg is it 132 col capable? mouse present? color? GUI? etc) even when you only use DDS to present the screens. I also use the DSM apis to do things like retrieve the current screen image as a 1920 or 3564 character map. What I am trying to do is change from our current use of a SNA api that translates the data steam to an ASCII plain text 1920 character string, to a TCP/IP api that will do the same. Is this a 5250 data stream? 3270? What SNA api are you using to get it? Are you just trying to get the current screen image? Or is this part of an emulation tool? Doug