RE: 5250 Data Stream

[Tim McCarthy <TimM@xxxxxxxxxxxxxxxxxx>]

You'll be able to read the 5250 data stream directly from the VT APIs
and write it directly to the device so your knowledge of 5250 doesn't
have to be extensive. Obviously if you intend to parse out certain info
you'll need to know where to look. I wrote such an application a while
ago but it's in MI so probably not much use to you. The gist of this
is...you'll need to define two display formats with identical record
format names. You define a record in one with a 1838 byte field (SCREEN)
and a record in the other using USRDEFN. Before running your application
you need to OVRDSPF from the first to the second (need lvlchk(*NO) too).
In your program you'll need to sub-structure SCREEN into four fields
SLGH 2bin, RLGH 2bin, SFUNC 1char, and S5250. You copy the 5250 stream
from the API into the S5250 field, put the length of the stream from the
API in SLGH, make RLGH=size of S5250 and make SFUNC either hex71 or
hex73 depending on whether this is a WRITE or an EXFMT (which depends on
what the read from the API said). And may the force be with you.      

TrailBlazer Systems, Inc.
http://www.softwarejungle.com
AS/400 E-Commerce Solutions

Chaos, panic, & disorder - my work here is done.

> -----Original Message-----
> From: dhandy@isgroup.net [SMTP:dhandy@isgroup.net]
> Sent: Wednesday, August 18, 1999 7:29 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: 5250 Data Stream
> 
> Benjamin,
> 
> >Is it possible to write 5250 data stream directly to a twinax
> attached
> >terminal? I think the DDS keyword USRDFN can be used for that
> purpose, 
> 
> Correct.  The USRDFN keyword exists only to allow you to write 5250
> data streams directly.  You must provide the complete data stream,
> including the leading length bytes, the send or send/rcv or whatever
> opcode byte, all WTD, SOH, SBA, SOF, FFW, FCW, IC, etc orders, and a
> trailing ReadInput command if the format has input capable fields.
> 
> The 5250 data stream is documented in the 5494 Functions Reference
> manual, which should be on your softcopy CD.
> 
> I'd caution against using it in a production line-of-business
> application though, unless you can make a strong case for the need.
> It is not something that very many people can maintain.  If you do use
> it, make sure you document what you do very carefully.
> 
> Instead of USRDFN (also known as UDDS, User Defined Data Streams),
> consider the Dynamic Screen Manager APIs.  IBM added these in about
> '92 so that you can dynamically control the screen format without the
> need to directly work at the data stream level.  
> 
> This may be more maintainable than using UDDS itself.  If you really
> want a sample UDDS program, I can send you a simple example.  But I've
> never deployed UDDS (or DSM) in a production app, even though I know
> how -- I tend to think it is better to only use in utility type
> programs, not production applications.
> 
> Doug
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---