Can anyone suggest what to do next, please? I'm trying to understand the various options for TCP/IP links
between MVS and the host. I'm mostly ignorant of the Herc options for sockdev devices and CTCs etc, and I
did do a SYSGEN a few times many years ago, but most of the details are forgotten.

I don't think it's a configuration problem on the host, as I can connect to
port 3505 (RDR) and submit jobs just fine, although it shows as a 2540 in MVS (00c).
Given this result from /D U in the Hercules console, I was assuming that there are two 3211 printers in the IOGEN, 002 and 003.

HHC00008I /d u
15.36.56?????????? IEE450I 15.36.56 UNIT STATUS 447
?UNIT TYPE STATUS? VOLSER VOLSTATE?? UNIT TYPE STATUS? VOLSER VOLSTATE
?002? 3211 A???????????????????????? 003? 3211 OFFLINE
?009? 3215 C???????????????????????? 00C? 2540 A
?00D? 2540 A???????????????????????? 00E? 1403 A
?00F? 1403 A???????????????????????? 010? 3277 OFFLINE
?011? 3277 OFFLINE?????????????????? 01F? 3215 OFFLINE
?070? 2703 OFFLINE?????????????????? 071? 2703 OFFLINE
?072? 2703 OFFLINE?????????????????? 073? 2703 OFFLINE
?074? 2703 OFFLINE?????????????????? 075? 2703 OFFLINE
?076? 2703 OFFLINE?????????????????? 077? 2703 OFFLINE
?080? 2703 OFFLINE?????????????????? 081? 2703 OFFLINE
?082? 2703 OFFLINE?????????????????? 083? 2703 OFFLINE
?084? 2703 OFFLINE?????????????????? 085? 2703 OFFLINE
?086? 2703 OFFLINE?????????????????? 087? 2703 OFFLINE

If I hit Esc to view hardware from Hercules' POV, 003 is missing. So I added 003 in the TK4-.cnf :-

# unit record devices
#
0002 3211 prt/prt002.txt ${TK4CRLF}
0003 3211 127.0.0.1:4444 sockdev

And now it appears in the Hercules hardware list (below), but I can't connect to it on port 4444 from
Win64 telnet, a simple socket client I bashed together, or using telnet from Linux. For comparison,
I /can/ connect to Hercules port 21 if I start FTPD.

Roops
Enc:-
U Addr Modl Type Assignment

A 0002 3211 PRT? prt/prt002.txt crlf print fcbck IO[2]

B 0003 3211 PRT? 127.0.0.1:4444 sockdev print fcbck IO[4]

C 000E 1403 PRT? prt/prt00e.txt crlf print fcbck IO[21]

D 000C 3505 RDR? 3505 sockdev ascii trunc eof IO[4]

E 000D 3525 PCH? pch/pch00d.txt ascii IO[2]

F 0480 3420 TAPE * IO[4] maxsize=0 eotmargin=128K deonirq=N

G 010C 3505 RDR? jcl/dummy ascii trunc eof IO[2]

H 010D 3525 PCH? pch/pch10d.txt ascii IO[2]

I 000F 1403 PRT? prt/prt00f.txt crlf print fcbck IO[117]

J 030E 1403 PRT? log/hardcopy.log crlf print fcbck IO[449]

K 0009 3215 CON? *syscons cmdpref(/) IO[237]

L 00C0 3270 DSP? * IO[4]

M 00C1 3270 DSP? * IO[4]

N 00C2 3270 DSP? * IO[4]

O 00C3 3270 DSP? * IO[4]

P 00C4 3270 DSP? * IO[4]

Q 00C5 3270 DSP? * IO[4]

R 00C6 3270 DSP? * IO[4]

S 00C7 3287 DSP? * IO[2]

T 03C0 3270 DSP? GROUP=TCAM IO[4]

U 03C1 3270 DSP? GROUP=TCAM IO[4]

V 03C2 3270 DSP? GROUP=TCAM IO[4]

W 03C3 3270 DSP? GROUP=TCAM IO[4]

X 03C4 3270 DSP? GROUP=TCAM IO[4]

Y 03C5 3270 DSP? GROUP=TCAM IO[4]

Z 03C6 3270 DSP? GROUP=TCAM IO[4]

. 03C7 3270 DSP? GROUP=TCAM IO[4]

. 0610 3088 CTCA 127.0.0.1:18610 IO[1]

. 0611 3088 CTCA 127.0.0.1:18611 IO[1]

. 0660 3705 LINE Read count=39, Write count=37 IO[77]

. 0661 3705 LINE Read count=39, Write count=37 IO[77]

. 0662 3705 LINE Read count=39, Write count=37 IO[77]

. 0663 3705 LINE Read count=39, Write count=37 IO[77]

. 0664 3705 LINE Read count=30, Write count=27 IO[58]

. 0665 3705 LINE Read count=30, Write count=27 IO[58]

. 0666 3705 LINE Read count=30, Write count=27 IO[58]

. 0667 3705 LINE Read count=30, Write count=27 IO[58]

On 2020-11-20 9:13 AM, marcoxa@... wrote:

I assume that for Fortran and PL/1 you would have to deal with similar issues.

Real FORTRAN types will know the unit number assignments better than I do, but unit 5 was traditionally the card reader and unit 6 was traditionally the line printer.? (Unit numbers for paper tape reader and card punch, anyone?)

This means that most OS FORTRAN programs require a DD of FT06F001 to be allocated - to the terminal in TSO is usually good, while to SYSOUT in batch is usually good.

For TSO, FT05F001 would also be allocated to the terminal in the usual case.

IIRC, SUPRTREK will not run unless FT06F001 is allocated.

For PL/I, SYSPRINT is the default print/report DD name, although for "modern" levels other DD names may be used for the underlying Language Environment input (default options etc.) and output (abends. etc.).? Even so, the default "print" output from the application goes to SYSPRINT unless another DD is specifically requested.

If a PL/I programmer gets thirsty, does he/she drink a SYSPINT of their favourite beverage?

(A reference to PL/I's habit of first 4 plus last 3 characters of an external reference making up the 7-character-linited name used by PL/I internally.? I suppose I'm the only one who thinks that's funny... :(? )

Cheers,
Greg

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