userid.FORTATTN.OBJ has the object of the Assembler program, which was prepared separately. I got the "assembler" listing just out of curiosity, which actually gave me some insight as to why compiled code differs from Assembler code, which I understood, in part, from earlier analysis, but this code expanded my understanding. To run it, just
... (PA1 executes ATTN on x3270, the emulator I use both at home and at work. Not sure why ATTN does nothing, and I mean NO THING. Mystery.)...
Perhaps I can provide some insight here.
Real 3270s did not have an ATTN key. In fact, the key labelled as Enter on most keyboards did nothing of the sort. It did do the equivalent of a carriage return line feed within the text buffer in the 3270 controller, but it did nothing to alert the mainframe computer. This fell to keys labeled as PA1, PA2 and (yes) Enter. The Enter key was on the bottom right, roughly where the right Control key is located on most PC keyboards.
The early 3270 emulators from IBM stayed more or less with the 3270 convention. The right Control key became the 3270 Enter key, the PC Enter key was a carriage control line feed as on real 3270s. Many emulators diverted from the 3270 standard over time. Many emulators use the PC Enter key as the primary Enter key. The PC Esc key morphed to the PA1 key in most emulators. Most emulators (including the grossly overpriced IBM emulator) permit some degree of keyboard redefinition. The better ones allow the right Control key to become the 3270 Enter key and the PC Enter key to resume its 3270 definition.
Some years ago I installed the X3270 emulator on my travel laptop and quickly gave up. It works well enough, but the keyboard drove me bonkers. In 2013 when I replaced the 2003 machine that had a decent, though not one of the name brand emulators on it, I went and actually bought the emulator I now use and installed on the 2013 desktop - which is still the main machine and travel laptop. I have carefully retained the install file and just last year successfully installed it on the the only Windoze 10 machine in the house.
I used to configure my emulators with the right CNTL key as ENTER until I was forced to use one for awhile where I couldn't figure out how to configure it. I eventually got used to using the PC enter key, with the SHIFT modifier for carriage return and no modifier for ENTER. I never went back to native 3270 key map.
One of the first emulators I got (because I hated the company-supplied one) was QWS3270 by Jolly Gian Software, a one-man shareware company (back then) based in Canada. It was really solid and looked great on the screen. (I just checked and it's still around but wow, really expensive.)
I used to work at <giant defense contractor> in the early 1990s. We had two 3090 600J machines (one of them had the vector facility installed), among other smaller mainframes for test systems and special projects. We even had a CRAY YMP. They ran a lot of NASTRAN on the CRAY and the 600J vector machine.
My job was in computer measurement and capacity planning. I used a 3179G terminal (graphics capable). But we also had the older 60 pound 3270 terminals that could also do graphics (blue lightning included) and some other 31xx terminals that did just green screen.
The keyboards for the 31xx models looked like a souped-up IBM PC keyboards, with 24 PF-keys in two rows across the top, 2 columns of miscellaneous keys at the far left, which included the ATTN key in the upper left column, and the standard PC arrow key cluster to the right and above those were the 3270-specific PA1...etc, keys. I even think this one had a 10-key cluster at the far right.
Seems like the ALT/ATTN key combo would get you out of some lockups where the PA1 key would not. But my memory may be faulty.
Sometimes I had to use the old 3270 terminals which had a unique keyboard feel and compact layout. A lot of people really preferred those. Practically needed a forklift to move them around though.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
I used the 31xx terminal for a while. I agree the keyboard appeared to be based on the IBM PC keyboard. Those were the days when IBM was at its best in many ways reusing technology. Few people recall, any more, that the keyboard for the 360/85, 370/165 and 370/168 graphic console (5450 for the /85, 3066 for the /165 and /168) was based on the keypunch keyboard! The 2540 reader-punch, a work horse on 360 and 370 machines, was based on the 1402 reader punch from the 1401, and the 1402, in turn, was based on an EAM machine from the 1950s.
I also used 3277 terminals for a while back in the 1970s. Provided it was channel attached it was a superb TSO terminal. Line attached, even at 9600 BPS, it wasn't a great TSO terminal, especially with SPF. For all that SPF did a great job compressing its screens, it still took too long to send a screen, even at 9600 BPS. Dropping multiple 3270s on a single 9600 BPS line, well, you could take naps waiting for screen updates. As an operator console it kind of sucked: the keyboard seemed to lock while data was being sent to the screen, which was all the time with an operator console. Still it was better than a 2260!
My employer was one of the first to get 3270s. We even had one catch fire on us!
I agree Jolly Giant has gotten awful damn greedy, though QWS3270 is a pretty decent emulator.
You can still get 24 function key keyboards fron Unicomp, though I don't know about emulator support. I'll probably try one of their regular keyboards when my present Cherry keyboard goes to keyboard heaven (or hell?) The keyboards sent out with just about all new machines su** big time
These days I configure my emulator as a 3290 single-display at 160×62. I love that amount of real-estate. You need a big monitor though (especially as I get older). I used to lust after the original amber plasma ones at <giant defense, inc.>. The engineers used them configured with 4 3278 screens to monitor all the LPARS, which was handy.
userid.FORTATTN.OBJ has the object of the Assembler program, which was prepared separately. I got the "assembler" listing just out of curiosity, which actually gave me some insight as to why compiled code differs from Assembler code, which I understood, in part, from earlier analysis, but this code expanded my understanding. To run it, just
call attn.load(attn)
after allocating FT06F001.
Interesting that this works fine under z/OS TSO. Under MVS3.8j/TSO, it behaves as I described earlier. I use z/OS at work, but it's not appropriate to do these tests there, even on our test system.
This research is for a personal hobby project. It's a period (circa 1977) Fortran program that originally ran on a Xerox Sigma 9 which I think was somewhat comparable to an s360, i.e. EBCDIC, big-endian, 32-bit, etc. I'm using a period, simulated IBM 3033 running MVS3.8j. There is a turnkey solution for simulating this platform, which is already loaded with the compilers needed for Fortran IV. I thought this might be an easy port, which is proving to be true for the Fortran code and the TOD assembler subroutine. If I can solve the TSO/ATTN issue, real testing can begin on the actual program, which is a sophisticated piece of software (8500 lines of Fortran).
The evolution of MVS/TSO since those days must hold the reason why execution results for TSO ATTN interruption are not the same.
userid.FORTATTN.OBJ has the object of the Assembler program, which was prepared separately. I got the "assembler" listing just out of curiosity, which actually gave me some insight as to why compiled code differs from Assembler code, which I understood, in part, from earlier analysis, but this code expanded my understanding. To run it, just
call attn.load(attn)
after allocating FT06F001.
If you had 2 assembler subroutines to link, would you concatenate the OJB files?
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
mxgdontmics wrote:
If you had 2 assembler subroutines to link, would you concatenate the OJB files?
That's one way of doing it. Another way is to put them into a Link edit SYSLIB data set and put the data set into the Link edit SYSLIB DD statement.
Since this was just an experiment, I did it the simplest and most obvious way.
I do have a few library type routines. Lately I haven't been using them, but I use SYSLIB when I do use them. See CBT files 956 or another one I couldn't quickly find.
I ran a test on z/OS where I work. The STAX exit behaves the same as on the MVS3.8j system under Hercules. The PA1 is queued in the type-ahead buffer until a screen-full (***) or a TGET from the program occurs. I don't know how to get around this.
This is slightly more elaborate. Rather than a CPU loop it waits for either an attention or a timer pop, and it writes the time of day in the message.
Code:
INLOOPW CSECT
USING *,12
SAVE (14,12),,*
LR 12,15
LA 15,SAVEAREA
ST 13,4(,15)
ST 15,8(,13)
LR 13,15
LA 2,60
STAX ATTNEXIT
LOOP MVI TIMEECB,X'00'
STIMER REAL,ITIMEUP,BINTVL==F'50' (1/2 SECOND)
XLOOP WAIT 1,ECBLIST=ECBLIST
TM ATTNECB,X'40'
BO EXIT
TM TIMEECB,X'40'
BZ XLOOP
TIME DEC
ST 0,12(,13)
MVC TIME,TPATT
ED TIME,12(13)
MVI TIME,C' '
LA 0,L'MSG
LA 1,MSG
TPUT (1),(0),R
BCT 2,LOOP
B LOOP
EXIT L 13,4(,13)
RETURN (14,12),RC=0
DROP ,
CNOP 0,8
USING *,15
ITIMEUP LR 2,14
POST TIMEECB
BR 2
CNOP 0,8
USING *,15
ATTNEXIT LR 2,14
POST ATTNECB
BR 2
ECBLIST DC A(TIMEECB,X'80000000'+ATTNECB)
TIMEECB DC F'0'
ATTNECB DC F'0'
SAVEAREA DC 9D'0'
LTORG ,
TPATT DC 0C' HH:MM:SS.SS',C'0',X'2120',C':',X'2020',C':',X'2020',>
C'.',X'2020'
MSGX DC C'HELLO'
TIME DC CL(L'TPATT)' '
MSG EQU MSGX,*-MSGX
END INLOOPW
Even your clear example here queues the PA1 in the type-ahead buffer until the screen becomes full of "HELLO" and the "***" appears. Only then does the interrupt manifest itself. So if one's program isn't doing any screen filling, it will simply never receive the PA1 unless and until a READ/TGET is executed.
Maybe this is a problem with the 3270 emulator. All of the x3270/c3270 emulators work the same way. Even if you toggle "aidWait" which is supposed to change the behavior of terminal commands like ENTER, PA1, etc., the keys marked with an * in the documentation (ENTER, PA1, etch.) all say that these keys are queued in the type-ahead "until the terminal is unlocked". "aidWait" disabled throws the handling of these key presses to whatever emulator macro (user-written presumably) might be coded to address them under a "terminal locked" condition.
I looked at the documentations for PCOMM, Vista and QWS emulators, all of which say they support type-ahead, but I don't know if it can be disabled or if it is even the problem to begin-with.
None of the vintage nor current TSO application programming guides talk about there being any kind of problems like this. If you use STAX, your program is PA1-interruptible and that's it. No pitfalls or problems like this are mentioned anywhere.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Well, when I ran it, the screen shot in the post is exactly what I got. Exactly. Are you 100% certain you replicated the program as listed, with the POST macro (for its own ECB) in each exit? I ask this because you had mentioned at least one of the exits you coded as just BR 14.
You mentioned, too, that you removed the AMODE and RMODE statements from the Assembler functions you ran with your Fortran program. I put them there because I assumed you would be using it with a modern Fortran that compiles & links with AMODE 31 / RMODE ANY. With an OS/360 Fortran its moot as the object (and load module) default to AMODE 24 / RMODE 24. The Assembler code is actually AMODE ANY / RMODE ANY.
Well, when I ran it, the screen shot in the post is exactly what I got. Exactly. Are you 100% certain you replicated the program as listed, with the POST macro (for its own ECB) in each exit? I ask this because you had mentioned at least one of the exits you coded as just BR 14.
You mentioned, too, that you removed the AMODE and RMODE statements from the Assembler functions you ran with your Fortran program. I put them there because I assumed you would be using it with a modern Fortran that compiles & links with AMODE 31 / RMODE ANY. With an OS/360 Fortran its moot as the object (and load module) default to AMODE 24 / RMODE 24. The Assembler code is actually AMODE ANY / RMODE ANY.
Apologies for any confusion. I actually replied to your second INLOOP example when I actually tested the first INLOOP example.
I was backtracking through the discussion to see if I missed anything and became interested in your TIMER interrupt example. I wondered if an internal interrupt would somehow bring the program up for air (so to speak) to allow the external interrupt (PA1) to be detected.
I copied and assembled your code verbatim which contained no explicit AMODE/RMODE directives.
The assembly output on MVS3.8j is identical to the assembly on z/OS (02.02.00). For each test I used the x3270 emulator. The behavior of the program on both platforms is identical.
INLOOP begins printing "HELLO" down the screen. When I press PA1, it continues printing "HELLO" but you can see the "T" in the status bar of the 3270 emulator, indicating that the PA1 key press went into the type-ahead buffer. Once the screen becomes full of the "HELLO" messages, the screen full symbol is printed (***) after which the screen refreshes without pressing the ENTER key. Immediately the "|" interrupt symbol prints and then immediately, READY. Program done.
Without any real understanding of what is happening, I'm inclined to suspect my 3270 emulator. But I don't really know. This doesn't seem to be happening when you run INLOOP.
After some communication with the code maintainer for the x3270 family of emulators, it was determined that the actual labeled ATTN key works under z/OS (with Steve's INLOOP program). But under MVS3.8j, it does nothing (as mentioned before), but then neither do the PA keys when using the x3270 emulator. One would assume it's because MVS3.8j predates the advent of terminal keyboards that featured the ATTN key. Prior to that, an attention key was a PA key (1-3).
The early IBM TSO guides to writing terminal monitor programs and command processors (circa 1972, 1985), which can be found on the internet, only talk about the necessity for establishing exits when the user presses "the attention key". The actual key names (PA1, etc.) are never mentioned.
But the latest version of this guide says, "the PA1 or attention key". So when MVS3.8j was the latest thing, the PA keys were the attention keys (as Steve has already said). But x3270 doesn't treat them as attention keys, only the ATTN key itself.
I don't imagine that IBM has changed the status of the PA keys in all this time, but the code maintainer did say that, "The 3270 programmer's reference is more a collection of hints than a reference."
I did mention to the maintainer that anecdotal information suggested that other emulators behaved differently regarding the PA keys, e.g. Steve has no trouble with the PA key interrupting the code examples in this thread.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
mxgdontmics wrote:
...
The early IBM TSO guides to writing terminal monitor programs and command processors (circa 1972, 1985), which can be found on the internet, only talk about the necessity for establishing exits when the user presses "the attention key". The actual key names (PA1, etc.) are never mentioned.
OS/360 TSO was designed for teleprinter terminals. The IBM 2741, in other words. The 2741 DID have an attention key. The 3270 was just a dream in 1970, though some 2260 models were supported. I remember using a 2260 with TSO, very vaguely. It was much like the 3270. I do not recall how to do an attention.
The z/OS manuals are very similar to the MVT manuals. In fact you can take an OS/360 command processor assembled with the OS/360 macros and the command processor will run on z/OS, possibly slower because you use LINK rather than CALLTSSR to run IKJPARS, and macros like PUTLINE use the LINK macro to call the service routine; the z/OS macros use the equivalent of CALLTSSR to run the service routine. In fact you can take the same source code, reassemble it with z/OS macros, and the command will run OK. Unless there are other AMODE/RMODE issues, a command processor assembled with OS/360 macros will not run AMODE 31 RMODE ANY, but the same code assembled with z/OS macros will run AMODE 31 / RMODE ANY. The PCL uses 4 byte internal adcons in z/OS, where it uses 3 byte adcons in MVT. I know. I've tried it.
...
The early IBM TSO guides to writing terminal monitor programs and command processors (circa 1972, 1985), which can be found on the internet, only talk about the necessity for establishing exits when the user presses "the attention key". The actual key names (PA1, etc.) are never mentioned.
OS/360 TSO was designed for teleprinter terminals. The IBM 2741, in other words. The 2741 DID have an attention key. The 3270 was just a dream in 1970, though some 2260 models were supported. I remember using a 2260 with TSO, very vaguely. It was much like the 3270. I do not recall how to do an attention.
The z/OS manuals are very similar to the MVT manuals. In fact you can take an OS/360 command processor assembled with the OS/360 macros and the command processor will run on z/OS, possibly slower because you use LINK rather than CALLTSSR to run IKJPARS, and macros like PUTLINE use the LINK macro to call the service routine; the z/OS macros use the equivalent of CALLTSSR to run the service routine. In fact you can take the same source code, reassemble it with z/OS macros, and the command will run OK. Unless there are other AMODE/RMODE issues, a command processor assembled with OS/360 macros will not run AMODE 31 RMODE ANY, but the same code assembled with z/OS macros will run AMODE 31 / RMODE ANY. The PCL uses 4 byte internal adcons in z/OS, where it uses 3 byte adcons in MVT. I know. I've tried it.
RESOLVED
The software context of the problem in this thread was the use of the x3270-family of terminal emulators (x3270, c3270, ws3270, wx3270, etc.) and TSO on the operating systems, z/OS_2.2 on a z/Series mainframe and MVS3.8j under Hercules emulation. Also, the free trial version of QWS3270 was tested to help rule out possible issues with x3270.
The resolution is as follows:
For contemporary versions of z/OS, the ATTN key works with STAX attention exits. The PA keys (program attention keys, PA1, PA2, etc.) do not work to provide asynchronous program attention interruption, even in combination with RESET.
For legacy MVS that predates the standardization of the ATTN key on 3270 keyboards (e.g. MVS3.8j circa 1981), PA (program attention) keys would seem to be the only option (PA1, PA2, etc).
On the aforementioned version of legacy MVS, The PA keys will only work by themselves (without any other key involved) AFTER the problem-mode program initiates a terminal read (TGET) OR the program fills the screen with output, initiating a screen-full attention (***). Pending either of those two events, PA key activations will languish in the type-ahead buffer of the terminal emulator.
RESOLUTION: For asynchronous attention activations to work on legacy MVS, PA key activation (e.g. PA1) must be prefaced by the RESET key (RESET then PA1). Only with the RESET-PA1 sequence will the attention exit be activated asynchronously in the same way that the ATTN key works on z/OS.
As mentioned already, this behavior was tested on x3270-family emulators AND the free trial version of QWS3270 5.1 (Jolly Giant Software).
Thanks to steve-meyers for his patience and highly instructive code examples that vastly increased my understanding of the issue, and to x3270 code maintainer, Paul Mattes, for suggesting the solution to this problem.
P.S. This may not be the only possible solution for this issue, it's just "a solution". One question suggests itself: Did say, a period 3277 terminal user have to use the RESET-PA1 key sequence to do program interrupts?
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
mxgdontmics wrote:
... Did say, a period 3277 terminal user have to use the RESET-PA1 key sequence to do program interrupts?
To tell the truth, I'm no longer certain about my statement that 3270 keyboards did not have an ATTN key. While I could not find a clear picture on the net, at the top of the column of keys on the left side the keyboard a key does seem to be labeled ATTN.
For a brief period of time during my time with a <large defense contractor> I used a 3270 PC with the 24 function key keyboard. In fact it was my first time with a directly attached PC based emulator although I had used a couple of dialup emulators in the 1980s. This was '90 / '91 and maybe into '92 or even '93. Subsequently I used several IBM emulators with coax based LAN and OS/2. Very late I used the PCOMM emulator bundled into OS/2 Warp 4 with TCPIP. Then the <large defense contractor> sold most of us mainframe types off to IBM who fired most of us after about 18 months.
The COAX based emulators saved my b*** one day when the MVS IP stack broke and I was one of the few people that could still get into TSO to look over things.
... Did say, a period 3277 terminal user have to use the RESET-PA1 key sequence to do program interrupts?
To tell the truth, I'm no longer certain about my statement that 3270 keyboards did not have an ATTN key. While I could not find a clear picture on the net, at the top of the column of keys on the left side the keyboard a key does seem to be labeled ATTN.
For a brief period of time during my time with a <large defense contractor> I used a 3270 PC with the 24 function key keyboard. In fact it was my first time with a directly attached PC based emulator although I had used a couple of dialup emulators in the 1980s. This was '90 / '91 and maybe into '92 or even '93. Subsequently I used several IBM emulators with coax based LAN and OS/2. Very late I used the PCOMM emulator bundled into OS/2 Warp 4 with TCPIP. Then the <large defense contractor> sold most of us mainframe types off to IBM who fired most of us after about 18 months.
The COAX based emulators saved my b*** one day when the MVS IP stack broke and I was one of the few people that could still get into TSO to look over things.
I could not find an ATTN key on this image of a 3277.
The first terminal I could find with an ATTN key is the 3278 which was introduced in 1980. MVS 3.8, where the ATTN key seems to be ignored under TSO, was introduced ~1981.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Your 3270 image is the best I've seen. I agree the top left key does not seem to say ATTN. It might even say Clear! I had access to a real 3290 from 2000 through 2007, but never once used it.
I think MVS 3.8 might have been earlier than '81. By then the TCAM based TSO was pretty much history; we had switched to TSOVTAM by the late 1970s. I don't know whether your MVS 3.8 uses VTAM or TCAM. Prejudice says TCAM, but I don't know. I think VTAM was always an addon, but I don't know. If it is an addon, then it likely is not in the free 3.8.
MVS3.8j can use both (default is VTAM) but I don't know how much it has been modified or enhanced to bring it back alive. A lot of software has been written to reverse-engineer non-public-domain features. There are two SPF-like options that are very nice, for example. The SPF editor is an excellent work-alike.
Hi guys,
not sure if you've resolved this but please take a look at the CLSTATTN operand of the STAX macro.
Trying to wade through doc and memories from 2004 but I think the gist of it is that your application STAX needs to be at the top of the pile using this parm.
Otherwise you are at the mercy of whatever CLIST, TSO and ISPF processing has occurred before your program has even loaded - let alone received control.
Hope that's of use.
