If you are like me you've been pulling your hair out trying to mess with the TN5250 stream so that you can automate things from you Java applications.
Well stop messing with the protocol itself and let TN5250j do that for you.
Here's how to do it with Netbeans 6.9:
First get TN5250j from here.
Next you will need Netbeans, duh. Netbeans!
Now start a new Java application. On the next screen name the program TestApp.
Now make Main.java say the following:
Run your program and you should see the results in your output window.
Let me run through these lines. I'll have to break up a detail description of each line over the next few post.
ProtocolBean is a bean that the TN5250j exposes that allows programmers to use the bulk of TN5250j's api to control the TN5250 data stream. It wraps all the nasty stuff into one nice little bean. There is one catch to this. You cannot use the ProtocolBean inside of the AWT-Event Loop. So if you are doing a GUI then you'll need to start the session outside of the AWT-Event Loop.
The ProtocolBean has two constructors. I'm using the more basic one here. Using the basic ctor means that you have to call a couple of methods from ProtocolBean before starting up. I'll cover the other ctor later. Here we call the setHostName method which should not surprise you that it sets the IP address of the host.
Oh and by-the-by if you are wondering what the ctor for the protocol bean is doing... The first argument creates a config file that TN5250j will use and the second names the session. So if you've ever used the PCOMM ECL then you know all about this, if not, Sessions have two names an ID and a name. The ID runs from 1 to 65536 or so, in the order that you start them. The name is whatever you like to call stuff. Libraries, can access a client by either the ID... Look I'm getting off topic, we'll save all that for another day.
Okay next thing is the Session5250. We grab the session first and then connect. Long story short, you should always grab the session first and then call the connect method from the protocol bean.
Next is to grab the screen. Now I'm on a really slow connection so I added a Thread.sleep() to slow things down. I'll cover later how you can actually check if the connection is ready to be used.
First grab the screen into a Screnn5250 object.
Next we need to make a char[] it will act as a buffer for all the data that we will get form the TN5250 stream. Yes, this is how you must do it. No, there is no way around it. I've checked the source code for TN5250j.
Next I'm just going to print to stdout the actual screen. My screen defaults to 24x80. Most of the time this is what the stream will always be. However, at my company we have a system that does 27x132. You need to check to make sure that the system isn't requesting 27x132 because most of the time this will make the session end abnormally if you don't report that you can handle 27x132.
As you can see I use a for loop to add a new line at every 80 chars. This makes it look exactly like the terminal.
Oh yeah if you are wondering about that GetScreen method. The parameters are char[] that will act as the buffer. How large is the buffer? And from which plane should I get data from? I'll explain ScreenPlanes.PLANE_TEXT later. For now that's the one that you want.
Anyway...
So then I System.out.println() my StringBuilder.
Then I call the disconnect method from the session object.
You can download the source code for TN5250j and read all about the Session5250 and Screen5250 classes.
I've got to go for now!
Well stop messing with the protocol itself and let TN5250j do that for you.
Here's how to do it with Netbeans 6.9:
First get TN5250j from here.
Next you will need Netbeans, duh. Netbeans!
Now start a new Java application. On the next screen name the program TestApp.
Now make Main.java say the following:
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package testapp;
import java.net.UnknownHostException;
import org.tn5250j.Session5250;
import org.tn5250j.beans.ProtocolBean;
import org.tn5250j.framework.tn5250.Screen5250;
import org.tn5250j.framework.tn5250.ScreenPlanes;
public class Main {
/**
* @param args the command line arguments
*/
public static void main(String[] args) throws UnknownHostException, InterruptedException {
ProtocolBean pb = new ProtocolBean("test", "123");
pb.setHostName("192.168.1.2");
Session5250 session = pb.getSession();
pb.connect();
Screen5250 screen = session.getScreen();
char [] buffer = new char[1920];
StringBuilder sb = new StringBuilder();
Thread.sleep(3000L);
screen.GetScreen(buffer, 1920, ScreenPlanes.PLANE_TEXT);
String showme = new String(buffer);
for(int i=0;i<showme.length();i+=80) {
sb.append(showme.substring(i, i+80));
sb.append("\n");
}
System.out.println(sb.toString());
session.disconnect();
}
}
Run your program and you should see the results in your output window.
Let me run through these lines. I'll have to break up a detail description of each line over the next few post.
ProtocolBean is a bean that the TN5250j exposes that allows programmers to use the bulk of TN5250j's api to control the TN5250 data stream. It wraps all the nasty stuff into one nice little bean. There is one catch to this. You cannot use the ProtocolBean inside of the AWT-Event Loop. So if you are doing a GUI then you'll need to start the session outside of the AWT-Event Loop.
The ProtocolBean has two constructors. I'm using the more basic one here. Using the basic ctor means that you have to call a couple of methods from ProtocolBean before starting up. I'll cover the other ctor later. Here we call the setHostName method which should not surprise you that it sets the IP address of the host.
Oh and by-the-by if you are wondering what the ctor for the protocol bean is doing... The first argument creates a config file that TN5250j will use and the second names the session. So if you've ever used the PCOMM ECL then you know all about this, if not, Sessions have two names an ID and a name. The ID runs from 1 to 65536 or so, in the order that you start them. The name is whatever you like to call stuff. Libraries, can access a client by either the ID... Look I'm getting off topic, we'll save all that for another day.
Okay next thing is the Session5250. We grab the session first and then connect. Long story short, you should always grab the session first and then call the connect method from the protocol bean.
Next is to grab the screen. Now I'm on a really slow connection so I added a Thread.sleep() to slow things down. I'll cover later how you can actually check if the connection is ready to be used.
First grab the screen into a Screnn5250 object.
Next we need to make a char[] it will act as a buffer for all the data that we will get form the TN5250 stream. Yes, this is how you must do it. No, there is no way around it. I've checked the source code for TN5250j.
Next I'm just going to print to stdout the actual screen. My screen defaults to 24x80. Most of the time this is what the stream will always be. However, at my company we have a system that does 27x132. You need to check to make sure that the system isn't requesting 27x132 because most of the time this will make the session end abnormally if you don't report that you can handle 27x132.
As you can see I use a for loop to add a new line at every 80 chars. This makes it look exactly like the terminal.
Oh yeah if you are wondering about that GetScreen method. The parameters are char[] that will act as the buffer. How large is the buffer? And from which plane should I get data from? I'll explain ScreenPlanes.PLANE_TEXT later. For now that's the one that you want.
Anyway...
So then I System.out.println() my StringBuilder.
Then I call the disconnect method from the session object.
You can download the source code for TN5250j and read all about the Session5250 and Screen5250 classes.
I've got to go for now!
