An interesting thread.
I have only ever used DISPLAY which outputs to the SYSOUT DD card, or DISPLAY UPON CONSOLE which outputs to the operator console.
I understand that there is also DISPLAY UPON SYSPUNCH which outputs to the SYSPUNCH DD card.
Displaying on SYSPRINT is a new one for me, but I'm certainly not going to contradict the experts in this group.
By the way, DISPLAY in PL/1 (F) outputs to the operator console.
JJ

On 2020-11-20 4:08 AM, M. Khalid Khan wrote:

When running TSO on a non-SNA terminal, does it use SNA/VTAM at all? Can one use TSO in this configuration with VTAM not running?

Again, I am not a network guy, but VTAM is an access method. Programmers code up VTAM macros in their VTAM application programs in a way such that users who have access to the VTAM network can elect to logon to that VTAM application (assuming it is running and VTAM deems the application to be? active etc. etc.).

SNA is a protocol - a series of layers IIRC - to allow application data to be transferred over the network.

VTAM applications such as TSO/VTAM could be logged on to by users from terminals that connect to the system via connections to the VTAM network.? Such connections might be SNA or non-SNA.? The VTAM application itself might not even be aware if a particular session is SNA or non-SNA.

The SNA protocol may enable a facility such that an ATTN key on a 3270 terminal can be transmitted inbound even if input is inhibited, but that does not mean that a non-SNA protocol supports the same thing.

For a channel-attached non-SNA connection - which is what most of us appear to use for our MVS 3.8 under Hercules TSO sessions - all we have to do is hit RESET and hit PA1, and then an attention interrupt is registered by our TSO session.

This scenario is what we used to call local non-SNA.? What we used to call remote non-SNA was usually BSC connections, but IIRC the reset-and-PA1 scenario used to work there as well.

With an SNA session, RESET will not clear the input-inhibited status, or at best will convert an X-SYSTEM to a "clock", meaning that a normal AID such as from PA1 cannot be sent inbound - hence the need for ATTN.

Perhaps a real network guy will step in and explain it properly...

Cheers,
Greg

On 11/19/20 4:13 PM, marcoxa@... wrote:

Thank you Chris
I did notice that the examples were referencing CONSOLE, but I did not imagine that that would make a difference between SYSOUT and SYSPRINT.
Would you have any pointer to manuals that explained this use of the different DDNAMES?? I assume that for Fortran and PL/1 you would have to deal with similar issues.

Here is some information that I added to my site several years ago for COBOL that applies to the MVT era COBOL:



There is also a pdf that contains some expansion on what I have summarized. It came from a textbook from that era so it matches the compiler.

Marco,

Our Cobol is lacking in any documentation.

I suggest you look at page 62-3 in


which is a bit older (for OS360/MFT & MVT), but as far as I recall still
stood in later Cobol versions. Our Cobol is a MVT Cobol, which has been
ported to MVS.

Chris
--
<cjar1950@...>



----------------------------------------------------------------------------------------------------------------------------------
On Thu, 19 Nov 2020 14:13:06 -0800
marcoxa@... wrote:

Thank you Chris

I did notice that the examples were referencing CONSOLE, but I did not imagine that that would make a difference between SYSOUT and SYSPRINT.

Would you have any pointer to manuals that explained this use of the different DDNAMES?? I assume that for Fortran and PL/1 you would have to deal with similar issues.

All the best

--
Marco Antoniotti
Somewhere over the rainbow

Thank you Chris

I did notice that the examples were referencing CONSOLE, but I did not imagine that that would make a difference between SYSOUT and SYSPRINT.

Would you have any pointer to manuals that explained this use of the different DDNAMES?? I assume that for Fortran and PL/1 you would have to deal with similar issues.

All the best

--
Marco Antoniotti
Somewhere over the rainbow

Marco,

In TK4-, look in SYS2.JCLLIB, at TESTCOB, and PRIMCOB1 etc

Chris.

--
<cjar1950@...>



----------------------------------------------------------------------------------------------------------------------------------
On Thu, 19 Nov 2020 11:57:23 -0800
marcoxa@... wrote:

Thanks.

That did it.? The

```
//GO.SYSOUT DD SYSOUT=*
```

is what was missing.

Somehow I could not find any example mentioning it.? I should have thought about it.

All the best

Marco

--
Marco Antoniotti
Somewhere over the rainbow

Marco,

Hopefully to add to what others have advised:

If you
DISPLAY "TEST".
then you need a
GO.SYSOUT DD SYSOUT=*

If you have
0065 SPECIAL-NAMES.
0066 CONSOLE IS CNSL
and
DISPLAY "TEST" UPON CNSL.

then your current JCL will work, with a
//GO.SYSPRINT DD SYSOUT=A

Chris
--
<cjar1950@...>



----------------------------------------------------------------------------------------------------------------------------------
On Thu, 19 Nov 2020 11:12:48 -0800
marcoxa@... wrote:

Hi

apologies for the probably stupid newbie question.? I get an error while trying to execute the attached job, which is a pretty standard (AFAIU) COBOL Hello World job.
The problem appears to be an error dealing with SYSOUT.? I am running on an unmodified (except for the new user) TK4-.

19.38.14 JOB 26 IEC130I SYSOUT DD STATEMENT MISSING
19.38.14 JOB 26 +IKF999I UNSUCCESSFUL OPEN FOR SYSOUT

Any help is appreciated, as I obviously do not quite understand what is going on.

Of course, you all can expect more questions like this in the future :)

Thank you

All the best

Marco

--
Marco Antoniotti
Somewhere over the rainbow

Thanks.

That did it.? The

```
//GO.SYSOUT DD SYSOUT=*
```

is what was missing.

Somehow I could not find any example mentioning it.? I should have thought about it.

All the best

Marco


--
Marco Antoniotti
Somewhere over the rainbow

The COBOL DISPLAY statement outputs to the file defined by the SYSOUT DD card.
JJ

开云体育

"If in doubt, give it what it wants" :-)

In this case, it wants a //SYSOUT DD statement. I nothing of COBOL, but how about

//SYSOUT DD SYSOUT=*

Roops

Hi

apologies for the probably stupid newbie question.? I get an error while trying to execute the attached job, which is a pretty standard (AFAIU) COBOL Hello World job.
The problem appears to be an error dealing with SYSOUT.? I am running on an unmodified (except for the new user) TK4-.

19.38.14 JOB 26 IEC130I SYSOUT DD STATEMENT MISSING
19.38.14 JOB 26 +IKF999I UNSUCCESSFUL OPEN FOR SYSOUT

Any help is appreciated, as I obviously do not quite understand what is going on.

Of course, you all can expect more questions like this in the future :)

Thank you

All the best

Marco



--
Marco Antoniotti
Somewhere over the rainbow

When running TSO on a non-SNA terminal, does it use SNA/VTAM at all? Can one use TSO in this configuration with VTAM not running?

Just curious

Khalid

Gentles,

I am with Patrik on this. This is about helping people to run MVS on whatever platform they chose, be it Linux, Windows, MacOS, Solaris, OpenVMS or whatever OS.
How do you know the user isn't constrained by corporate policy? I have both windows and Linux boxes (Lubunto & Raspian)
The Linux boxes seem to be more work than the windows ones. I recently had to re-build the Lubunbto box because of a failed update.
It failed to start USB services and it has a USB keyboard and just refused to talk to it. Nightmare.
At this point you will probably say I should try a different distribution. If I have to mess around with different distributions what is the point?

So please keep things on topic, which is running MVS on Hercules.
There are plenty of places to conduct OS wars

Dave

Hello Rahim,

Am 18.11.2020 um 18:13 schrieb Rahim Azizarab via groups.io <rahimazizarab@...>:

Emancipate yourself by switching to Linux. You can move forward much quicker with Linux mint than with Windows. Windows is for the corporate folks that have a lot of money to burn and time to waste; the rest of us need to be a little bit more efficient.

Besides your post being largely off topic in here… Most people are using Windows for a reason. Also, efficiency is tightly paired with knowledge, skill and routine.

(I don’t know why you followed up to my remark. Maybe you’ve meant to answer Peter?)

:wq! PoC

On 2020-11-18 9:08 PM, Rupert Reynolds wrote:

Attn could interrupt any TSO program

I think ATTN button functionality depends on having an SNA session.

If your TSO terminal is an MVS 3270 I/O device with its own device address, then that is a non-SNA session and so ATTN does not function.? PA1 will perform the TSO attention function - use RESET first to undo an input-inhibited state first if necessary.

Given the limited number of I/O addresses and the growth of networks over the years, as time went on a greater percentage of TSO connectivity came under the SNA and SNA-like umbrella, with ATTN often working even for modern TSO sessions over TCP/IP (depending on the TN3270 parameters used for Communication Server).

When a 3270 terminal is an I/O device, ATTN may not be an AID-generating key - or so I imagine, but I'm not really a network guy.

Cheers,
Greg

On Wed, 18 Nov 2020 09:33:15 -0300, Jo?o Reginato
<jb.reginato@...> wrote:

Try PA1 twice

It is very common to have the TSO prompt right after the first PA1.
At the prompt an "END" command should finish the execution.

HTH

De: [email protected] <mailto:[email protected]>
<[email protected] <mailto:[email protected]> > Em nome de Rupert
Reynolds Enviada em: quarta-feira, 18 de novembro de 2020 07:08 Para:
[email protected] <mailto:[email protected]> Assunto: [H390-MVS]
Attn does not interrupt



When I worked on MVS/XA via VTAM in the 1990s, Attn could interrupt
any TSO program doing terminal I/O using Attn. PA1 produced a similar
response from TSO, with the vertical bar on screen, except that it
could not be sent while the terminal was locked.



With Vista, x3270 and wc3270, Attn gives me nothing, even at a READY
to prompt. Yet if i press it a few times, I suddenly go to the VTAM
logon screen. Meanwhile, PA1 will sometimes interrupt, and sometimes
not.



Is this expected behviour in MVS 3.8j, please?



Roops

Roxo

--
---------------- Non luctari, ludare -------------------+ WYSIWYG
Fernando M. Roxo da Motta <mvs@...> | Editor?
Except where explicitly stated I speak on my own behalf.| VI !!
PU5RXO | I see text,
------------ Quis custodiet ipsos custodes?-------------+ I get text!