[hercules-390] CPU running crazy using FTP with TK4- on VM machine

[[e-mail] [hercules-390]]

Hello everybody,


I use Hercules 4.00 and TK4- on a VM machine working with Windows 2012 R2.
I use CTCI-WIN 3.3.3 with Fishpack dll included and Winpcap 4.1.3.
I start the FTP deamon and have a working FTP connection.


Problem: CPU goes to 60-70% constantly and after about 1 hour the FTP deamon abends. Here is some output from Hercules:


11.39.13 STC 140 IRB101I MF/1 REPORT AVAILABLE FOR PRINTING
11.39.13 $HASP160 PRINTER1 INACTIVE - CLASS=A
11.39.16 $HASP000 OK
11.42.39 IRA100I SQA SHORTAGE
11.43.46 IRA101I CRITICAL SQA SHORTAGE
11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128
11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128
11.44.32 STC 145 IEC999I IFG0TC0A,IFG0TC0B,FTPD ,FTPD ,DEB ADDR = 9A50D4
11.44.32 STC 145 IEF450I FTPD FTPD - ABEND S80A U0000 - TIME=11.44.32
11.44.32 IRA102I SQA SHORTAGE RELIEVED
11.44.33 STC 145 IEF404I FTPD - ENDED - TIME=11.44.33
11.44.33 STC 145 $HASP395 FTPD ENDED
11.44.33 STC 145 $HASP150 FTPD ON PRINTER2 36,738 LINES
11.44.33 $HASP160 PRINTER2 INACTIVE - CLASS=Z
11.44.33 STC 145 $HASP250 FTPD IS PURGED


Any help will be appreciated.



Best regards
Nicholas Schott

[[e-mail] [hercules-390]]

Hi Nicholas


First of all: What role would CTCI-WIN have to play in the environment you are describing? If you are really using TK4-, your IP connectivity will always be through your host system's IP stack. MVS 3.8j as it comes with TK4- doesn't have it's own IP stack and consequently cannot make use of devices that provide IP connectivity. So, you can safely remove the CTCI devices.



However, the CTCI devices don't hurt when they are present. So, cleaning up that misconception will not solve your problem.


For further analysis: Please provide the files prt\prt00e.txt, prt\prt00f.txt, log\3033.log, log\hardcopy.log from a TK4- run showing the problem, in full (no excerpts please).


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Hello everybody,


I use Hercules 4.00 and TK4- on a VM machine working with Windows 2012 R2.
I use CTCI-WIN 3.3.3 with Fishpack dll included and Winpcap 4.1.3.
I start the FTP deamon and have a working FTP connection.


Problem: CPU goes to 60-70% constantly and after about 1 hour the FTP deamon abends. Here is some output from Hercules:


11.39.13 STC 140 IRB101I MF/1 REPORT AVAILABLE FOR PRINTING
11.39.13 $HASP160 PRINTER1 INACTIVE - CLASS=A
11.39.16 $HASP000 OK
11.42.39 IRA100I SQA SHORTAGE
11.43.46 IRA101I CRITICAL SQA SHORTAGE
11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128
11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128
11.44.32 STC 145 IEC999I IFG0TC0A,IFG0TC0B,FTPD ,FTPD ,DEB ADDR = 9A50D4
11.44.32 STC 145 IEF450I FTPD FTPD - ABEND S80A U0000 - TIME=11.44.32
11.44.32 IRA102I SQA SHORTAGE RELIEVED
11.44.33 STC 145 IEF404I FTPD - ENDED - TIME=11.44.33
11.44.33 STC 145 $HASP395 FTPD ENDED
11.44.33 STC 145 $HASP150 FTPD ON PRINTER2 36,738 LINES
11.44.33 $HASP160 PRINTER2 INACTIVE - CLASS=Z
11.44.33 STC 145 $HASP250 FTPD IS PURGED


Any help will be appreciated.



Best regards
Nicholas Schott

[[e-mail] [hercules-390]]

Hi Jürgen



I’ve attached a zip-file with the files.



I am not able to answer your question about CTCI-WIN. As far as I could
understand, I had to install CTCI-WIN in order to get connectivity to ‘the
outside world’.



Regards,

Nicholas





CLASSIFICATION: INTERNAL

From: hercules-***@yahoogroups.com <hercules-***@yahoogroups.com>
Sent: 21. september 2018 20:27
To: hercules-***@yahoogroups.com
Subject: [hercules-390] Re: CPU running crazy using FTP with TK4- on VM
machine





Hi Nicholas



First of all: What role would CTCI-WIN have to play in the environment you
are describing? If you are really using TK4-, your IP connectivity will
always be through your host system's IP stack. MVS 3.8j as it comes with
TK4- doesn't have it's own IP stack and consequently cannot make use of
devices that provide IP connectivity. So, you can safely remove the CTCI
devices.



However, the CTCI devices don't hurt when they are present. So, cleaning up
that misconception will not solve your problem.



For further analysis: Please provide the files prt\prt00e.txt,
prt\prt00f.txt, log\3033.log, log\hardcopy.log from a TK4- run showing the
problem, in full (no excerpts please).



Cheers

Jürgen

---In hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> ,
<***@... <mailto:***@...> > wrote :

Hello everybody,



I use Hercules 4.00 and TK4- on a VM machine working with Windows 2012 R2.

I use CTCI-WIN 3.3.3 with Fishpack dll included and Winpcap 4.1.3.

I start the FTP deamon and have a working FTP connection.



Problem: CPU goes to 60-70% constantly and after about 1 hour the FTP deamon
abends. Here is some output from Hercules:



11.39.13 STC 140 IRB101I MF/1 REPORT AVAILABLE FOR PRINTING

11.39.13 $HASP160 PRINTER1 INACTIVE - CLASS=A

11.39.16 $HASP000 OK

11.42.39 IRA100I SQA SHORTAGE

11.43.46 IRA101I CRITICAL SQA SHORTAGE

11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128

11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128

11.44.32 STC 145 IEC999I IFG0TC0A,IFG0TC0B,FTPD ,FTPD ,DEB ADDR =
9A50D4

11.44.32 STC 145 IEF450I FTPD FTPD - ABEND S80A U0000 - TIME=11.44.32

11.44.32 IRA102I SQA SHORTAGE RELIEVED

11.44.33 STC 145 IEF404I FTPD - ENDED - TIME=11.44.33

11.44.33 STC 145 $HASP395 FTPD ENDED

11.44.33 STC 145 $HASP150 FTPD ON PRINTER2 36,738 LINES

11.44.33 $HASP160 PRINTER2 INACTIVE - CLASS=Z

11.44.33 STC 145 $HASP250 FTPD IS PURGED



Any help will be appreciated.



Best regards

Nicholas Schott







[Non-text portions of this message have been removed]

[Harold Grovesteen [e-mail] [hercules-390]]

The CTCI-WIN software is designed to allow, on Windows, an operating
system that supports its own TCP/IP stack to communicate with the
network through devices that connect to it.  In the case of Hercules,
the emulation of those devices uses the CTCT-WIN software to perform
the connection to the outside network.

MVS 3.8J has no support for a TCP/IP stack nor support for any devices
that would be required by the stack.  The implementation of network
applications, such as FTP, on MVS 3.8J takes a different route.  A
special instruction, TCPIP, is implemented within Hercules allowing a
MVS program to operate with the host's TCP/IP stack to communicate with
the outside world.  No network device is used.

So, CTCT-WIN is required for connectivity to the outside world when the
operating system supports _a resident TCP/IP stack_.

The nature of the TCPIP instruction, allowing an application program to
directly interact with the host, was the source of the controversy
around its failed inclusion within Hercules for many years.  The same
applied to the related NFILE instruction.

I personally support the inclusion of these two instructions within
Hercules with appropriate user controls.

Harold Grovesteen

Post by ***@mainframe-soft.com [hercules-390]
 
 
I am not able to answer your question about CTCI-WIN. As far as I could
understand, I had to install CTCI-WIN in order to get connectivity to
‘the
outside world’.
 
Regards,
Nicholas
 
 

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Harold Grovesteen wrote:

[...]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
The nature of the TCPIP instruction, allowing an
application program to directly interact with the host,
was the source of the controversy around its failed
inclusion within Hercules for many years. The same
applied to the related NFILE instruction.

Quite right.

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
I personally support the inclusion of these two instruc-
tions within Hercules with appropriate user controls.

I'll admit I'm much more open to this idea than I was before.

If done right.

(i.e. "with appropriate user controls")

But then that's the trick, isn't it? Implementing "appropriate" user controls.

How does one determine what is "appropriate" and what isn't when it comes to directly interacting with such a key/critical part of the host operating system?

To be completely honest the idea still to this day scares the hell out of me which is why I'm still hesitant to implement it.

Still, it would certainly be nice if current Hyperion could somehow support TK4- (MVS 3.8J with networking support).

I'd personally RATHER see LCS or CTCI device support be *added* to MVS 3.8j than to implement Jason's TCPIP instruction hack in Hercules. But I fully understand the difficulty of doing that and thus why the much easier TCPIP instruction technique was chosen.

[[e-mail] [hercules-390]]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
I'd personally RATHER see LCS or CTCI device
support be *added* to MVS 3.8j than to implement
Jason's TCPIP instruction hack in Hercules. But I
fully understand the difficulty of doing that and
thus why the much easier TCPIP instruction
technique was chosen.

What about the possibility of using a pair
(or do we only need one? or do we need
more than two?) of 3270s defined in MVS
for send and receive, and have a mod to
Hercules to define them as special
devices that convert operations into
TCP/IP calls? Would that be less hacky
and still work?

BFN. Paul.

[Mike Schwab [e-mail] [hercules-390]]

Like a TSO READY Mode? Sure wouldn't want 3270 screens / attributes.

Post by ***@yahoo.com.au [hercules-390]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
I'd personally RATHER see LCS or CTCI device
support be *added* to MVS 3.8j than to implement
Jason's TCPIP instruction hack in Hercules. But I
fully understand the difficulty of doing that and
thus why the much easier TCPIP instruction
technique was chosen.

What about the possibility of using a pair
(or do we only need one? or do we need
more than two?) of 3270s defined in MVS
for send and receive, and have a mod to
Hercules to define them as special
devices that convert operations into
TCP/IP calls? Would that be less hacky
and still work?
BFN. Paul.
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

[Gregg Levine [e-mail] [hercules-390]]

Hello!
We are talking about an appropriately customized release of MVS/370
also known as MVS 3.8J? Then 3270 screens and attributes such as how
the screen shows characters. Including how to properly emphasize ones

I'm not at all sure where I came across all of this, but both
VM/370rel6 and the MVS one we have access to, all worked with a 3270
family terminal directly, and in fact their descendants won't even IPL
without one attached.

-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."

Post by Mike Schwab ***@gmail.com [hercules-390]
Like a TSO READY Mode? Sure wouldn't want 3270 screens / attributes.

Post by ***@yahoo.com.au [hercules-390]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
I'd personally RATHER see LCS or CTCI device
support be *added* to MVS 3.8j than to implement
Jason's TCPIP instruction hack in Hercules. But I
fully understand the difficulty of doing that and
thus why the much easier TCPIP instruction
technique was chosen.

What about the possibility of using a pair
(or do we only need one? or do we need
more than two?) of 3270s defined in MVS
for send and receive, and have a mod to
Hercules to define them as special
devices that convert operations into
TCP/IP calls? Would that be less hacky
and still work?
BFN. Paul.
------------------------------------
------------------------------------

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
------------------------------------
------------------------------------

And this message is sponsored by the Paul Drake Detective Bureau, in
the Brent Building in LA.

['Dave Wade' [e-mail] [hercules-390]]

Mike,
You can do what you want. Conventionally 3270 terminals on MVS are driven by VTAM or TCAM because this allows them to be connected to a variety of sub-systems without any need for a sysgen. However, whilst I haven't done it, its possible to access screens via BTAM. When connected in such a way you can drive them in whatever way you want, in a similar way to IND$FILE....
Dave

-----Original Message-----
Sent: 04 November 2018 03:18
Subject: Re: [hercules-390] Re: CPU running crazy using FTP with TK4- on VM
machine
Like a TSO READY Mode? Sure wouldn't want 3270 screens / attributes.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
I'd personally RATHER see LCS or CTCI device support be *added* to
MVS 3.8j than to implement Jason's TCPIP instruction hack in
Hercules. But I fully understand the difficulty of doing that and
thus why the much easier TCPIP instruction technique was chosen.

What about the possibility of using a pair (or do we only need one? or
do we need more than two?) of 3270s defined in MVS for send and
receive, and have a mod to Hercules to define them as special devices
that convert operations into TCP/IP calls? Would that be less hacky
and still work?
BFN. Paul.
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

[[e-mail] [hercules-390]]

Hi Nicholas

Post by ***@mainframe-soft.com [hercules-390]
I am not able to answer your question about CTCI-WIN. As far as I could
understand, I had to install CTCI-WIN in order to get connectivity to ‘the
outside world’.

As I said, and as Harold pointed out in even more detail, you _don't_ need CTCI-WIN. It will not hurt if you have it configured, but it will also not help. It will just do nothing.

Post by ***@mainframe-soft.com [hercules-390]
I’ve attached a zip-file with the files.

I just took a look at the files. In the JES2 job log of the FTP daemon one can see some 12.000 temporary datasets getting allocated before the system runs out of SQA and the FTP daemon consequently abends with S806-4. All of this happens _before_ the FTP daemon even starts listening for a control connection coming in (which is why I'm really skeptical concerning your statement that you had been able to connect to FTPD -- are you sure it was the MVS FTPD you connected to, or was there an FTP daemon running on your host system?).


Normally you should see exactly one of these allocations per volume mounted on the system. As I don't assume that you're having more that 12.000 volumes mounted, there must be something going terribly wrong.


So, my questions are:
How many volumes are mounted on your system, and how many of them are listed in VATLST00?
How many non VSAM datasets are totally on all mounted volumes, regardless whether they are cataloged or not (rough estimated suffices, if you don't know how to get the exact number).
Next thing I'd like you to try is doubling the value of the SQA parameter in IEASYS00 and re-IPL the system. Then start FTPD. One of the following should happen:
FTPD abends with S806 roughly after double the time it did originally. In this case I'd assume a bug in FTPD and we would have to nail this down.
FTPD comes up to normal operations after a time period longer than it originally took to abend, but shorter than double this time. In this case simply the amount of volumes and/or datasets on your system is causing the problem and it would be necessary to decide whether to reduce the number of volumes/datasets visible to FTPD, or to accept the long startup time and equally long root refresh times.
Please let me the outcome of this test, and the answers to the above questions.


Cheers
JÃŒrgen



---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi JÃŒrgen



I’ve attached a zip-file with the files.



I am not able to answer your question about CTCI-WIN. As far as I could
understand, I had to install CTCI-WIN in order to get connectivity to ‘the
outside world’.



Regards,

Nicholas





CLASSIFICATION: INTERNAL

From: hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com <hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com>
Sent: 21. september 2018 20:27
To: hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com
Subject: [hercules-390] Re: CPU running crazy using FTP with TK4- on VM
machine





Hi Nicholas



First of all: What role would CTCI-WIN have to play in the environment you
are describing? If you are really using TK4-, your IP connectivity will
always be through your host system's IP stack. MVS 3.8j as it comes with
TK4- doesn't have it's own IP stack and consequently cannot make use of
devices that provide IP connectivity. So, you can safely remove the CTCI
devices.



However, the CTCI devices don't hurt when they are present. So, cleaning up
that misconception will not solve your problem.



For further analysis: Please provide the files prt\prt00e.txt,
prt\prt00f.txt, log\3033.log, log\hardcopy.log from a TK4- run showing the
problem, in full (no excerpts please).



Cheers

JÃŒrgen

---In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com> ,
<***@... <mailto:***@...> > wrote :

Hello everybody,



I use Hercules 4.00 and TK4- on a VM machine working with Windows 2012 R2.

I use CTCI-WIN 3.3.3 with Fishpack dll included and Winpcap 4.1.3.

I start the FTP deamon and have a working FTP connection.



Problem: CPU goes to 60-70% constantly and after about 1 hour the FTP deamon
abends. Here is some output from Hercules:



11.39.13 STC 140 IRB101I MF/1 REPORT AVAILABLE FOR PRINTING

11.39.13 $HASP160 PRINTER1 INACTIVE - CLASS=A

11.39.16 $HASP000 OK

11.42.39 IRA100I SQA SHORTAGE

11.43.46 IRA101I CRITICAL SQA SHORTAGE

11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128

11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128

11.44.32 STC 145 IEC999I IFG0TC0A,IFG0TC0B,FTPD ,FTPD ,DEB ADDR =
9A50D4

11.44.32 STC 145 IEF450I FTPD FTPD - ABEND S80A U0000 - TIME=11.44.32

11.44.32 IRA102I SQA SHORTAGE RELIEVED

11.44.33 STC 145 IEF404I FTPD - ENDED - TIME=11.44.33

11.44.33 STC 145 $HASP395 FTPD ENDED

11.44.33 STC 145 $HASP150 FTPD ON PRINTER2 36,738 LINES

11.44.33 $HASP160 PRINTER2 INACTIVE - CLASS=Z

11.44.33 STC 145 $HASP250 FTPD IS PURGED



Any help will be appreciated.



Best regards

Nicholas Schott







[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

Hi Nicholas

I was wondering whether you were able to solve the problem, and if so, how you did it.


Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :

Hi Nicholas

Post by ***@mainframe-soft.com [hercules-390]
I am not able to answer your question about CTCI-WIN. As far as I could
understand, I had to install CTCI-WIN in order to get connectivity to ‘the
outside world’.

As I said, and as Harold pointed out in even more detail, you _don't_ need CTCI-WIN. It will not hurt if you have it configured, but it will also not help. It will just do nothing.

Post by ***@mainframe-soft.com [hercules-390]
I’ve attached a zip-file with the files.

I just took a look at the files. In the JES2 job log of the FTP daemon one can see some 12.000 temporary datasets getting allocated before the system runs out of SQA and the FTP daemon consequently abends with S806-4. All of this happens _before_ the FTP daemon even starts listening for a control connection coming in (which is why I'm really skeptical concerning your statement that you had been able to connect to FTPD -- are you sure it was the MVS FTPD you connected to, or was there an FTP daemon running on your host system?).


Normally you should see exactly one of these allocations per volume mounted on the system. As I don't assume that you're having more that 12.000 volumes mounted, there must be something going terribly wrong.


So, my questions are:
How many volumes are mounted on your system, and how many of them are listed in VATLST00?
How many non VSAM datasets are totally on all mounted volumes, regardless whether they are cataloged or not (rough estimated suffices, if you don't know how to get the exact number).
Next thing I'd like you to try is doubling the value of the SQA parameter in IEASYS00 and re-IPL the system. Then start FTPD. One of the following should happen:
FTPD abends with S806 roughly after double the time it did originally. In this case I'd assume a bug in FTPD and we would have to nail this down.
FTPD comes up to normal operations after a time period longer than it originally took to abend, but shorter than double this time. In this case simply the amount of volumes and/or datasets on your system is causing the problem and it would be necessary to decide whether to reduce the number of volumes/datasets visible to FTPD, or to accept the long startup time and equally long root refresh times.
Please let me the outcome of this test, and the answers to the above questions.


Cheers
JÃŒrgen



---In hercules-***@yahoogroups.com, <***@...> wrote :


Hi JÃŒrgen



I’ve attached a zip-file with the files.



I am not able to answer your question about CTCI-WIN. As far as I could
understand, I had to install CTCI-WIN in order to get connectivity to ‘the
outside world’.



Regards,

Nicholas





CLASSIFICATION: INTERNAL

From: hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com <hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com>
Sent: 21. september 2018 20:27
To: hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com
Subject: [hercules-390] Re: CPU running crazy using FTP with TK4- on VM
machine





Hi Nicholas



First of all: What role would CTCI-WIN have to play in the environment you
are describing? If you are really using TK4-, your IP connectivity will
always be through your host system's IP stack. MVS 3.8j as it comes with
TK4- doesn't have it's own IP stack and consequently cannot make use of
devices that provide IP connectivity. So, you can safely remove the CTCI
devices.



However, the CTCI devices don't hurt when they are present. So, cleaning up
that misconception will not solve your problem.



For further analysis: Please provide the files prt\prt00e.txt,
prt\prt00f.txt, log\3033.log, log\hardcopy.log from a TK4- run showing the
problem, in full (no excerpts please).



Cheers

JÃŒrgen

---In hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com> ,
<***@... <mailto:***@...> > wrote :

Hello everybody,



I use Hercules 4.00 and TK4- on a VM machine working with Windows 2012 R2.

I use CTCI-WIN 3.3.3 with Fishpack dll included and Winpcap 4.1.3.

I start the FTP deamon and have a working FTP connection.



Problem: CPU goes to 60-70% constantly and after about 1 hour the FTP deamon
abends. Here is some output from Hercules:



11.39.13 STC 140 IRB101I MF/1 REPORT AVAILABLE FOR PRINTING

11.39.13 $HASP160 PRINTER1 INACTIVE - CLASS=A

11.39.16 $HASP000 OK

11.42.39 IRA100I SQA SHORTAGE

11.43.46 IRA101I CRITICAL SQA SHORTAGE

11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128

11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128

11.44.32 STC 145 IEC999I IFG0TC0A,IFG0TC0B,FTPD ,FTPD ,DEB ADDR =
9A50D4

11.44.32 STC 145 IEF450I FTPD FTPD - ABEND S80A U0000 - TIME=11.44.32

11.44.32 IRA102I SQA SHORTAGE RELIEVED

11.44.33 STC 145 IEF404I FTPD - ENDED - TIME=11.44.33

11.44.33 STC 145 $HASP395 FTPD ENDED

11.44.33 STC 145 $HASP150 FTPD ON PRINTER2 36,738 LINES

11.44.33 $HASP160 PRINTER2 INACTIVE - CLASS=Z

11.44.33 STC 145 $HASP250 FTPD IS PURGED



Any help will be appreciated.



Best regards

Nicholas Schott







[Non-text portions of this message have been removed]

['Nicholas Schott (Mainframe-Soft)' [e-mail] [hercules-390]]

Sorry. I’ve not solved it. Been too busy at work ... I’ll look into it soon! And I am very greatfull that you take the time to help me!

Post by ***@id.ethz.ch [hercules-390]
Hi Nicholas
I was wondering whether you were able to solve the problem, and if so, how you did it.
Cheers
JÃŒrgen
Hi Nicholas

Post by ***@mainframe-soft.com [hercules-390]
I am not able to answer your question about CTCI-WIN. As far as I could
understand, I had to install CTCI-WIN in order to get connectivity to ‘the
outside world’.

As I said, and as Harold pointed out in even more detail, you _don't_ need CTCI-WIN. It will not hurt if you have it configured, but it will also not help. It will just do nothing.

Post by ***@mainframe-soft.com [hercules-390]
I’ve attached a zip-file with the files.

I just took a look at the files. In the JES2 job log of the FTP daemon one can see some 12.000 temporary datasets getting allocated before the system runs out of SQA and the FTP daemon consequently abends with S806-4. All of this happens _before_ the FTP daemon even starts listening for a control connection coming in (which is why I'm really skeptical concerning your statement that you had been able to connect to FTPD -- are you sure it was the MVS FTPD you connected to, or was there an FTP daemon running on your host system?).
Normally you should see exactly one of these allocations per volume mounted on the system. As I don't assume that you're having more that 12.000 volumes mounted, there must be something going terribly wrong.
How many volumes are mounted on your system, and how many of them are listed in VATLST00?
How many non VSAM datasets are totally on all mounted volumes, regardless whether they are cataloged or not (rough estimated suffices, if you don't know how to get the exact number).
FTPD abends with S806 roughly after double the time it did originally. In this case I'd assume a bug in FTPD and we would have to nail this down.
FTPD comes up to normal operations after a time period longer than it originally took to abend, but shorter than double this time. In this case simply the amount of volumes and/or datasets on your system is causing the problem and it would be necessary to decide whether to reduce the number of volumes/datasets visible to FTPD, or to accept the long startup time and equally long root refresh times.
Please let me the outcome of this test, and the answers to the above questions.
Cheers
JÃŒrgen
Hi JÃŒrgen
I’ve attached a zip-file with the files.
I am not able to answer your question about CTCI-WIN. As far as I could
understand, I had to install CTCI-WIN in order to get connectivity to ‘the
outside world’.
Regards,
Nicholas
CLASSIFICATION: INTERNAL
Sent: 21. september 2018 20:27
Subject: [hercules-390] Re: CPU running crazy using FTP with TK4- on VM
machine
Hi Nicholas
First of all: What role would CTCI-WIN have to play in the environment you
are describing? If you are really using TK4-, your IP connectivity will
always be through your host system's IP stack. MVS 3.8j as it comes with
TK4- doesn't have it's own IP stack and consequently cannot make use of
devices that provide IP connectivity. So, you can safely remove the CTCI
devices.
However, the CTCI devices don't hurt when they are present. So, cleaning up
that misconception will not solve your problem.
For further analysis: Please provide the files prt\prt00e.txt,
prt\prt00f.txt, log\3033.log, log\hardcopy.log from a TK4- run showing the
problem, in full (no excerpts please).
Cheers
JÃŒrgen
Hello everybody,
I use Hercules 4.00 and TK4- on a VM machine working with Windows 2012 R2..
I use CTCI-WIN 3.3.3 with Fishpack dll included and Winpcap 4.1.3.
I start the FTP deamon and have a working FTP connection.
Problem: CPU goes to 60-70% constantly and after about 1 hour the FTP deamon
11.39.13 STC 140 IRB101I MF/1 REPORT AVAILABLE FOR PRINTING
11.39.13 $HASP160 PRINTER1 INACTIVE - CLASS=A
11.39.16 $HASP000 OK
11.42.39 IRA100I SQA SHORTAGE
11.43.46 IRA101I CRITICAL SQA SHORTAGE
11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128
11.44.32 STC 145 IEA700I 80A- 1 40E020BE FTPD 80 F5000138 00000128
11.44.32 STC 145 IEC999I IFG0TC0A,IFG0TC0B,FTPD ,FTPD ,DEB ADDR =
9A50D4
11.44.32 STC 145 IEF450I FTPD FTPD - ABEND S80A U0000 - TIME=11.44.32
11.44.32 IRA102I SQA SHORTAGE RELIEVED
11.44.33 STC 145 IEF404I FTPD - ENDED - TIME=11.44.33
11.44.33 STC 145 $HASP395 FTPD ENDED
11.44.33 STC 145 $HASP150 FTPD ON PRINTER2 36,738 LINES
11.44.33 $HASP160 PRINTER2 INACTIVE - CLASS=Z
11.44.33 STC 145 $HASP250 FTPD IS PURGED
Any help will be appreciated.
Best regards
Nicholas Schott
[Non-text portions of this message have been removed]

[[e-mail] [hercules-390]]

What they mean is, there is no TCP/IP on MVS 3.8J. It is therefore impossible for you to be running an FTP daemon on that system. Where did that FTPD proc come from that you are running, because it didn't come with MVS 3.8J. If you just copied the modules from a z/OS or OS/390 image, it won't work.


You only need CTCI if you are running OS/390 or z/OS and want to use TCP/IP. It has no use and will do nothing for an MVS 3.8J system.





---In hercules-***@yahoogroups.com, <***@...> wrote :

Hi JÃŒrgen



I’ve attached a zip-file with the files.



I am not able to answer your question about CTCI-WIN. As far as I could
understand, I had to install CTCI-WIN in order to get connectivity to ‘the
outside world’.



Regards,

Nicholas

[[e-mail] [hercules-390]]

Post by ***@sympatico.ca [hercules-390]
What they mean is, there is no TCP/IP on MVS 3.8J.
It is therefore impossible for you to be running an FTP
daemon on that system.

Most people use TK4- rather than a pure
MVS 3.8j, and via a kludge, TCP/IP has
been added to TK4-, so FTP is available.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by ***@sympatico.ca [hercules-390]
What they mean is, there is no TCP/IP on MVS 3.8J.
It is therefore impossible for you to be running an FTP
daemon on that system.

Most people use TK4- rather than a pure
MVS 3.8j, and via a kludge, TCP/IP has
been added to TK4-, so FTP is available.

BFN. Paul.

---

Well, dyn75 is TCP/IP in a rather "weak meaning".

We have "sockets" available, under MVS3.8j, with J.Winter
dyn75, actually TCP sockets, connected sockets.

The "socket calls" are dispatched to the host system TCP/IP stack,
where the hercules emulator is running.

Better than nothing, still NOT TCP/IP ;-(

Peppe.