FEATS@VTVM1.BITNET (Steve Greenfield) (11/01/90)
I am writing a command processor to run on NetView and I had a couple of concerns about the best way to approach some problems. The code uses the NetView presentation services to send a 3270 data stream to the terminal (erase/write) and waits for a response from the user (aid '7D'/ enter). The problem I am confronted with is how to take the input from the screen and disect it. If the user only fills in 1 field (which should occur most of the time) then I get the aid, cursor location, sba , addr and then the field of data (i.e.; x'7D 4DC9 11 4CF8'+field of data). If the user fills in all 13 fields then I obviously receive 13 sba's, addr's and 13 fields of data. What is the best way to move this data from the input area to the work fields. What I am trying to do is build a table which contains 13 sets of information. The first 2 bytes contain a addr (i.e.; x'4CF8'), the next 4 bytes contain the address of the field I want to move the input into, and the last 4 bytes contain the length of the field. When I receive my input I find the 2 bytes after the sba (x'11') and compare that to my table. When I match I then EXECUTE a move using the length entry in my table and the address in my table to move the data from the input area to the work area! Isn't this a roundabout way of performing this type of function?
eric@sunic.sunet.se (Eric Thomas SUNET) (11/02/90)
In article <9011011400.AA10311@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >What I am trying to do is build a table which contains 13 sets of information. >The first 2 bytes contain a addr (i.e.; x'4CF8'), the next 4 bytes contain >the address of the field I want to move the input into, and the last 4 bytes >contain the length of the field. When I receive my input I find the 2 bytes >after the sba (x'11') and compare that to my table. When I match I then >EXECUTE a move using the length entry in my table and the address in my >table to move the data from the input area to the work area! This will not work because the amount of data you get from the terminal may not match the length you have defined for the field. You may get less data if the field is, say, 80 bytes and only 10 bytes were entered, or more data, if APL characters have been typed. So what you really want to do is a MVCL with appropriate padding, after computing the length of the data coming from the terminal (locating the next X'11' or end of buffer) and checking that you don't get more than the field has; if you do, it might be better to re-write the screen and ask the user to retype (with one of the early generations of 3277 you could delete start-fields using a particular sequence, and then you could type as much data as you wanted in a field, it was nice to do that and take bets on whether software X would survive or die of a storage overlay). Finally, it is not a good idea to keep the SBA's in machine form (eg X'4CF8') in your table, because that format is not the same for 132-cols terminals. It is much better to store row/col values, and convert the machine form to row/col before scanning the table. Take a look at XEDIT sources for an example of how this can be done. Eric
eric@BLOOM-BEACON.MIT.EDU (Eric Thomas SUNET) (11/02/90)
In article <9011011400.AA10311@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >What I am trying to do is build a table which contains 13 sets of information. >The first 2 bytes contain a addr (i.e.; x'4CF8'), the next 4 bytes contain >the address of the field I want to move the input into, and the last 4 bytes >contain the length of the field. When I receive my input I find the 2 bytes >after the sba (x'11') and compare that to my table. When I match I then >EXECUTE a move using the length entry in my table and the address in my >table to move the data from the input area to the work area! This will not work because the amount of data you get from the terminal may not match the length you have defined for the field. You may get less data if the field is, say, 80 bytes and only 10 bytes were entered, or more data, if APL characters have been typed. So what you really want to do is a MVCL with appropriate padding, after computing the length of the data coming from the terminal (locating the next X'11' or end of buffer) and checking that you don't get more than the field has; if you do, it might be better to re-write the screen and ask the user to retype (with one of the early generations of 3277 you could delete start-fields using a particular sequence, and then you could type as much data as you wanted in a field, it was nice to do that and take bets on whether software X would survive or die of a storage overlay). Finally, it is not a good idea to keep the SBA's in machine form (eg X'4CF8') in your table, because that format is not the same for 132-cols terminals. It is much better to store row/col values, and convert the machine form to row/col before scanning the table. Take a look at XEDIT sources for an example of how this can be done. Eric
TOM@PENNDRLS.BITNET ("Thomas D. Denier") (11/02/90)
I think the scheme Steve Greenfield describes for parsing 3270 input is going to have problems with fields containing nulls. A keyboard operator can fill all or part of a field with nulls using the Erase EOF key or the Delete key. If I remember correctly, only the non-null characters in a field are sent to the host in response to a Read Buffer command. If a field contains nulls the string sent to the host will have fewer characters than the field length. I think Steve Greenfields algorithm will treat the next SBA character, its address, and some of the data from the next field as part of the field in this case.
eric@sunic.sunet.se (Eric Thomas SUNET) (11/04/90)
In article <9011011914.AA18019@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >If I remember correctly, only the non-null >characters in a field are sent to the host in response to a Read >Buffer command. That's correct, except it's READ MODIFIED he is using. READ BUFFER returns everything on the screen, and in a different format. Eric
eric@sunic.UUCP (Eric Thomas SUNET) (11/04/90)
In article <9011011914.AA18019@ucbvax.Berkeley.EDU> IBM 370 Assembly Programming Discussion List <ASM370@OHSTVMA.BITNET> writes: >If I remember correctly, only the non-null >characters in a field are sent to the host in response to a Read >Buffer command. That's correct, except it's READ MODIFIED he is using. READ BUFFER returns everything on the screen, and in a different format. Eric
jcallen@Encore.COM (Jerry Callen) (11/05/90)
>>If I remember correctly, only the non-null >>characters in a field are sent to the host in response to a Read >>Buffer command. > >That's correct, except it's READ MODIFIED he is using. READ BUFFER returns >everything on the screen, and in a different format. > > Eric Quibble, quibble. The first responder was STILL correct; READ MODIFIED also returns only the non-null characters in the field. [Aside: won't those $#@ 3270s EVER die the death they deserve???] -- Jerry Callen jcallen@encore.com
eric@sejnet.sunet.se (Eric Thomas, SUNET) (11/06/90)
In article <13143@encore.Encore.COM>, jcallen@Encore.COM (Jerry Callen) writes... >>>If I remember correctly, only the non-null >>>characters in a field are sent to the host in response to a Read >>>Buffer command. >> >>That's correct, except it's READ MODIFIED he is using. READ BUFFER returns >>everything on the screen, and in a different format. >> >> Eric > >Quibble, quibble. The first responder was STILL correct; READ MODIFIED also >returns only the non-null characters in the field. READ MODIFIED does not *also* return only the non-null characters; it returns only non-null characters *unlike* READ BUFFER, which returns everything, including nulls, and in a different format. >[Aside: won't those $#@ 3270s EVER die the death they deserve???] Don't be ridiculous, they are by far superior to the piece of ASCII junk I am typing this note from. For one thing, they don't interrupt the host every time I hit a key. You may have noticed that I am typing this note from a host different from the one I normally use; I have spent half a day installing a news reader on a VMS machine just because I simply could not stand having what I type echoed 5 seconds after the fact on the Unix box I was using before (response time is better on the VAX because it basically stands idle most of the time, and has nothing better to do than service my keystrokes). Oh well, I'm afraid it's just a religious issue. I simply fail to understand how people can accept, in 1990, to have to wait 5 seconds for what they type to be echoed because the computer is too slow to take care of their keystrokes. Yeah, sure, I can buy my own workstation and forget about it, but how many 3270 terminals do you get for the price of a workstation? Eric
eric@SEJNET.SUNET.SE ("Eric Thomas, (11/06/90)
In article <13143@encore.Encore.COM>, jcallen@Encore.COM (Jerry Callen) writes... >>>If I remember correctly, only the non-null >>>characters in a field are sent to the host in response to a Read >>>Buffer command. >> >>That's correct, except it's READ MODIFIED he is using. READ BUFFER returns >>everything on the screen, and in a different format. >> >> Eric > >Quibble, quibble. The first responder was STILL correct; READ MODIFIED also >returns only the non-null characters in the field. READ MODIFIED does not *also* return only the non-null characters; it returns only non-null characters *unlike* READ BUFFER, which returns everything, including nulls, and in a different format. >[Aside: won't those $#@ 3270s EVER die the death they deserve???] Don't be ridiculous, they are by far superior to the piece of ASCII junk I am typing this note from. For one thing, they don't interrupt the host every time I hit a key. You may have noticed that I am typing this note from a host different from the one I normally use; I have spent half a day installing a news reader on a VMS machine just because I simply could not stand having what I type echoed 5 seconds after the fact on the Unix box I was using before (response time is better on the VAX because it basically stands idle most of the time, and has nothing better to do than service my keystrokes). Oh well, I'm afraid it's just a religious issue. I simply fail to understand how people can accept, in 1990, to have to wait 5 seconds for what they type to be echoed because the computer is too slow to take care of their keystrokes. Yeah, sure, I can buy my own workstation and forget about it, but how many 3270 terminals do you get for the price of a workstation? Eric