Re: PROGRAMS in Pathway
- From: Keith Dick <kdick@xxxxxxx>
- Date: Mon, 04 Apr 2011 03:58:05 -0700
On Apr 1, 11:07 pm, Keith Dick <kd...@xxxxxxx> wrote:
On Apr 1, 11:32 am, Keith Dick <kd...@xxxxxxx> wrote:
On Mar 30, 12:40 am, Keith Dick <kd...@xxxxxxx> wrote:
Eternal September wrote:
"wbreidbach" <wolfgang.breidb...@xxxxxxxxxxxxxxxxxxxxx> wrote in message
On 29 Mrz., 10:46, Keith Dick <kd...@xxxxxxx> wrote:
On Mar 26, 3:17 am, spamb...@xxxxxxxxxx (Doug Miller) wrote:
In article <CZGdnXDkT51lYxHQnZ2dnUVZ5v-dn...@xxxxxxxxxxxx>,
If you are trying to learn how to use PROGRAMs to test Screen Cobol
that are written for IBM 3270 terminals, I am not sure what all you
need to do
to make that work. I'm sure there are 3270 emulators available for the
Absolutely, there are -- probably many more 3270 emulators are available
I am not sure how you can configure things to use such emulators with
NonStop system. Someone with experience doing that would have to tell
recall that there was (at least at one time) a way to configure an IBM
such that you could logon and run TACL and other conversational
it. I do not know whether you could use Pathway RUN PROGRAM commands
such a terminal to run Screen Cobol programs (the setup might not have
able to switch between conversational and block mode).
Yep, handles that just fine.
I am trying to run existing screen cobol codes with TERMINAL IS
IBM-3270 using WIN6530 software.
In win6530, i tried to create a IBM3270 profile and run MYPROGRAM
program object. all data was scattered on the screen,
I tried with outsideview 3270 profile also, got the same weird
characters on the screen. I tried 3270 profile with all possible
options, character set is something different.
Does anybody know how to setup a 3270 correctly on WIN6530/outsideview?
I know almost nothing about using 3270 emulation, so do not take what I
say below as having much credibility. I hope someone who does know a lot
about using 3270 emulation will reply.
I assume that you tried to tell win6530 to switch to IBM-3270 emulation
after entering the RUN command to start the Screen Cobol program that was
compiled to address a 3270 device. Did it accept the switch or give you
some error? If there is a way to get win6530 to display what emulation it
is currently using, did you check after making the switch to see whether
the switch to IBM-3270 actually was done?
I know nothing of win6530, but I would not be surprised if it were the
case that you must choose the emulation before making a connection. So
that is one possible reason it might not work -- you might not have been
able to get the emulator to switch to 3270 emulation.
If your emulator is in 3270 mode before you connect, I would not expect it
to connect successfully to the normal TELSERV services, since I imagine
all the connection stuff is expecting to communicate in ASCII, but in 3270
emulation, the emulator would be using EBCDIC.
I was not able to find anything in the manuals about TCP/IP configuration
that even hint that it is possible to use a 3270 emulator connected via
TCP/IP (though I might just not know where to look). The traditional way
3270 devices were supported on NonStop systems was via a Wide Area Network
controller (byte sync or bit sync, I don't remember which). I believe the
current method for doing that is via a SWAN concentrator. Those SWAN
concentrators are connected to the NonStop system via TCP/IP, but it very
well might be that a 3270 device can only be used properly when going
through the SWAN concentrator, not going directly to the NonStop system's
TCP/IP port. Again, I remind you that I know very little about this
subject. I hope someone who does know how to connect 3270 devices sees
your post and replies.- Zitierten Text ausblenden -
- Zitierten Text anzeigen -
I think you got the problem, Keith. The NonStop does not support SNA
via TCP/IP and that is what would be needed here. In the older times
we connected 3270 terminals to the Tandem via the Sage (pre-SWAN) and
a 327x controller.
NonStop supports TCP/IP via Ethernet (DLSW), but I do not think this
is usable here.
As far as I remember you need the SNAX product to support 3270
terminals but we did that about 20 years ago when the terminals were
Support for the exchange of 3270 data streams over TCP/IP is provided on the
NSK by the Enhanced TN3270 Server product. It works with both TACL and
Pathway type applications. The remote client must be TN3270 capable and
there are inexpensive PC based products out there. Google is your friend.
The standard TN3270 protocol is basically Telnet using 3270 data streams.
Thanks for your reply, Eternal September. I imagined that kind of support was technically possible, but I had no idea whether it actually had been done.
I imagine that this product is a separately purchased product that ChinmaY is unlikely to have already installed on the system. Or is it commonly included?
I looked at the manual (for ChinmaY, it is "TN3270e Server Manual" reachable fromwww.hp.com/go/nonstop-docsintheusual way). It appears from that manual that setting up TN3270e is not very difficult. Could you check what I wrote below and correct it?
1. Start ETN32SRV and let most parameters default. Something like this:
ETN32SRV/NAME $ETN,NOWAIT/ 2000 -s
I get the impression that including -s (for SNAX/XF mode) is advisable, but
I did not find a good explanation of when one would want the other mode (AM3270
mode), so that might be wrong.
Might need to add -r if the emulator requires the remote form of 3270 commands.
Might need to set PARAM TCPIP^PROCESS^NAME if the default of $ZTC0 is not suitable.
2. Use ETN32COM to configure a window, something like this:
~ ADD WINDOW #WIN1, TERMINAL
See note below about the WINDOW attributes.
3. Maybe start a TACL on that window:
TACL/NAME,NOWAIT,IN $ETN.#WIN1,OUT $ETN.#WIN1/
The manual does not mention this, but I don't see anything else that says how
a TACL gets started for the window.
4. Use a 3270 emulator to connect to port 2000 on the NonStop system.
I imagine how this is done depends on the emulator used. Somehow one must tell it the IP address or DNS name of the NonStop system and port 2000.
I don't know whether one specifies the terminal model or other parameters.
5. Once connected, logon and run the Pathway PROGRAM
Once the connection is made, one should logon to TACL as normal, then use a PATHCOM RUN command
to start the Pathway PROGRAM.
I imagine that for testing purposes, the instructions about how to use RECONNECT MODEM in the
Screen COBOL program can be ignored, but I am not certain of that.
When adding a WINDOW, one has the option of specifying the IP address from which the emulator connection request will come. I think it is unnecessary to use that. One also has the option of specifying an LUNAME. It is not clear to me whether that is something one should normally do or not.
I believe one does not have to logon to TACL and use a PATHCOM RUN command. It ought to be possible to skip step 3 and change step 5 to something like:
5. In PATHCOM, ADD a TERM specifying $ETN.#WIN1 as the FILE attribute
(and other attributes suitable for running the Screen COBOL program to be tested).
Once the 3270 emulator is connected, START that TERM. The Screen COBOL's initial
screen should appear in the window of the 3270 emulator.
Hi All, Thanks for sharing your thoughts.
I am already using ETN32COM to add a window and adding a term in
pathway to connect to that window.
The way you said worked fine, starting a tacl, and its IN and OUT to
window #WIN1 in TN3270. I got a tacl prompt when i connected via 3270
emulator. I logged in and RUN my PROGRAM in pathway and got INITIAL
screen on my monitor. :) Thank you :)
WIN6530 software has 3270 emulation mode. I was using 3270 emulation
mode and trying to RUN MYPROGRAM. But it did not work.
That is good news. Thank you for telling us the result. So often we make suggestions and never learn whether they helped or not. I am happy to learn that these suggestions worked.
This really helped me to understand PROGRAMS and types of terminals. I
had to find way by myself because nobody on my floor knows what
PROGRAMS are :)
What you say surprises me a little. My experience with Pathway was that everyone used PROGRAMs to test their Screen Cobol programs. But the situations I saw were all with users whose applicatons used only 6530 terminals, where nothing extra had to be done beyond setting up the PROGRAM. Maybe the use of PROGRAMs is much less among programmers who develop Screen COBOL for 3270 terminals.
I'm glad you now understand how to use PROGRAMs with the 3270 emulator. Perhaps you can spread the knowledge to those around you and make their work a
read more »
We are all using pathway terminals and TN3270 windows. To debug a
term, we do a INSPECT command in pathway to a TACL terminal. I liked
the idea of PROGRAMS that create a temporary terminal in TCP and
destroyed when disconnected.
Given your explanation, I think I understand a little more about the way you and your colleagues have been working, but there are still some points that are not clear. I think your colleagues are not running TACLs on their TN3270 windows, and so, from a 6530 window that has a TACL, they configure a TERM for their TN3270 window in order to run the Screen Cobol that is written for a 3270 device.
I do not know very much about TN3270e. If it can be set up in a way such that a person's TN3270 window always has the same device name on the NonStop system, then the FILE attribute of the TERM used by that person can always be the same, and the commands to configure the TERM could be prepared once and used repeatedly from an OBEY file or a TACL macro. That would make things pretty easy to use. In fact, the TERM probably could be configured once and used for many days or weeks.
If the TN3270 window could have a different device name each time you start it, then one would have to determine the device name each time and modify the TERM configuration commands to specify the appropriate device name in the FILE command each time.
It seems to me that the approach of starting a TACL on the TN3270 windows, then using a RUN PROGRAM command from that TACL to start the Screen Cobol requires about the same amount of effort as the former approach, and so does not have much advantage. Perhaps that lack of advantage is why none of your colleagues learned about PROGRAMs.
On the other hand, if you and your colleagues have been running TACLs on your TN3270 windows all or most of the time, then it would take a bit less work to use the RUN PROGRAM way to start a Screen Cobol program for testing. You would still need a second window from which to use Inspect. Although you can get TACL and other interactive conversational programs to work on a TN370 window, I do not believe that is how your group has been working, and I am not recommending that you switch to it.
In environments where everyone already has a TACL running on a 6530 window, using RUN PROGRAM to start a Screen Cobol on your program is a lot simpler than the alternative.
Why still 3270 terminals are being used, even if we have new terminal
types? Do they have any advantages over 6530 terminals?
If you are asking in general why the 3270 protocol is still being used, I imagine that is because it is well known and other protocols, such as the 6530 protocol, do not have any great advantage over it. So people stick with what is familiar. I do not know the protocols in enough detail to give a detailed comparison, but my impression is that they provide roughly the same features, except that the 3270 protocol does not have a conversational mode. I do not know why terminals that support both block mode and conversational mode were not implemented by extending the 3270 protocol. Perhaps it had to do with the fact that the 3270 protocol uses EBCDIC and that was not a natural fit with computers whose native character set was ASCII. Perhaps it is just that, in the 1970s, manufacturers felt more free to introduce incompatible terminals than might be the case today.
Also I would like to know what are the latest and efficient ways of
using screen cobol programs.
If you have specific questions about using Screen Cobol, post them and we probably can help. I believe there have been no new features or techniques developed in recent times for Screen Cobol. Screen Cobol was developed between 20 and 30 years ago and has been mostly unchanged since. There might be techniques that are new to you, but without the context of a specific question, we would not know what would be useful to suggest.
- Prev by Date: Re: PROGRAMS in Pathway
- Next by Date: Re: PROGRAMS in Pathway
- Previous by thread: Re: PROGRAMS in Pathway
- Next by thread: Re: PROGRAMS in Pathway