Discussion:
[hercules-390] presumed Hercules bug - append not appending
kerravon86@yahoo.com.au [hercules-390]
2017-03-14 20:14:19 UTC
Permalink
I discovered this issue in Hercules 3.07
but I looked at the Hercules 3.12 code
and it looks the same.

I suspect that this code:

if (dev->notrunc != 1)
{
open_flags |= O_TRUNC;
}

needs to have an:

else
{
open_flags |= O_APPEND;
}


Full code fragment is this:

(printer.c)
/*-------------------------------------------------------------------*/
/* Subroutine to open the printer file or pipe */
/*-------------------------------------------------------------------*/
static int
open_printer (DEVBLK *dev)
{
pid_t pid; /* Child process identifier */
char pathname[MAX_PATH]; /* file path in host format */
int open_flags; /* File open flags */
#if !defined( _MSVC_ )
int pipefd[2]; /* Pipe descriptors */
int rc; /* Return code */
#endif

/* Regular open if 1st char of filename is not vertical bar */
if (!dev->ispiped)
{
int fd;

/* Socket printer? */
if (dev->bs)
return (dev->fd < 0 ? -1 : 0);

/* Normal printer */
hostpath(pathname, dev->filename, sizeof(pathname));
open_flags = O_BINARY | O_WRONLY | O_CREAT /* | O_SYNC */;
if (dev->notrunc != 1)
{
open_flags |= O_TRUNC;
}
fd = open (pathname, open_flags,
S_IRUSR | S_IWUSR | S_IRGRP);


The symptom I am seeing is that
with this printer definition:

000F 1403 prt/prt00f.txt crlf noclear

(noting that "noclear" sets the
notrunc is set to true)


Anyway, if JOB 1 runs and has an
abend, and that abend output
goes to the printer and produces
a 1 MB file, and then I restart
Hercules and re-IPL MVS and
run JOB 2, which only produces
200 KB of data, then what I see
is that my output file remains
at 1 MB.

The first 200 KB is fine, it's the
data from JOB 2. But the last
800 KB is the last 800 KB of
JOB 1. ie the JOB 1 data has
been truncated.

What I actually expected, with
the noclear option in force, was
to get a 1.2 MB file, ie the first
1 MB contains the dump, and
the next 200 KB contains the
new output.

I can't see any possible use for
the current behavior which is to
just overwrite the beginning of
the file, leaving the last bit full
of old rubbish.

Let me know if you need me to
submit anything further.

Thanks. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-03-14 20:49:04 UTC
Permalink
O_APPEND is not supported on all filesystems. For instance, NFS does not
support O_APPEND.

So probably not a good thing to be coding options on opens that are not
supported.

Joe
Post by ***@yahoo.com.au [hercules-390]
I discovered this issue in Hercules 3.07
but I looked at the Hercules 3.12 code
and it looks the same.
if (dev->notrunc != 1)
{
open_flags |= O_TRUNC;
}
else
{
open_flags |= O_APPEND;
}
(printer.c)
/*----------------------------------------------------------*/
/* Subroutine to open the printer file or pipe */
/*----------------------------------------------------------*/
static int
open_printer (DEVBLK *dev)
{
pid_t pid; /* Child process identifier */
char pathname[MAX_PATH]; /* file path in host format */
int open_flags; /* File open flags */
#if !defined( _MSVC_ )
int pipefd[2]; /* Pipe descriptors */
int rc; /* Return code */
#endif
/* Regular open if 1st char of filename is not vertical bar */
if (!dev->ispiped)
{
int fd;
/* Socket printer? */
if (dev->bs)
return (dev->fd < 0 ? -1 : 0);
/* Normal printer */
hostpath(pathname, dev->filename, sizeof(pathname));
open_flags = O_BINARY | O_WRONLY | O_CREAT /* | O_SYNC */;
if (dev->notrunc != 1)
{
open_flags |= O_TRUNC;
}
fd = open (pathname, open_flags,
S_IRUSR | S_IWUSR | S_IRGRP);
The symptom I am seeing is that
000F 1403 prt/prt00f.txt crlf noclear
(noting that "noclear" sets the
notrunc is set to true)
Anyway, if JOB 1 runs and has an
abend, and that abend output
goes to the printer and produces
a 1 MB file, and then I restart
Hercules and re-IPL MVS and
run JOB 2, which only produces
200 KB of data, then what I see
is that my output file remains
at 1 MB.
The first 200 KB is fine, it's the
data from JOB 2. But the last
800 KB is the last 800 KB of
JOB 1. ie the JOB 1 data has
been truncated.
What I actually expected, with
the noclear option in force, was
to get a 1.2 MB file, ie the first
1 MB contains the dump, and
the next 200 KB contains the
new output.
I can't see any possible use for
the current behavior which is to
just overwrite the beginning of
the file, leaving the last bit full
of old rubbish.
Let me know if you need me to
submit anything further.
Thanks. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-03-14 21:06:37 UTC
Permalink
Then what do you suggest is done
when the "noclear" option is given?
If append is not supported then the
"noclear" option should not be
supported either.

Regardless, I see that it is already
in the Hercules code base:

C:\devel\hercules>grep O_APPEND *.h

C:\devel\hercules>grep O_APPEND *.c
scedasd.c: ((scediov_bk->type == SCCB_SCEDIOV_TYPE_CREATE) ? (O_CREAT|O_TRUNC) : O_APPEND), sto, length);
w32util.c: { "a", "abc", _O_WRONLY | _O_CREAT | _O_APPEND | _O_BINARY },
w32util.c: { "a+", "a+bc", _O_RDWR | _O_CREAT | _O_APPEND | _O_BINARY },
w32util.c: { "a+b", "a+bc", _O_RDWR | _O_CREAT | _O_APPEND | _O_BINARY },
w32util.c: { "ab+", "a+bc", _O_RDWR | _O_CREAT | _O_APPEND | _O_BINARY },

C:\devel\hercules>


and I didn't notice any conditional
compilation for a system that
doesn't have it.

BFN. Paul.




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

O_APPEND is not supported on all filesystems. For instance, NFS does not support O_APPEND.

So probably not a good thing to be coding options on opens that are not supported.


Joe



On Tue, Mar 14, 2017 at 4:14 PM, ***@... mailto:***@... [hercules-390] <hercules-***@yahoogroups.com mailto:hercules-***@yahoogroups.com> wrote:
I discovered this issue in Hercules 3.07
but I looked at the Hercules 3.12 code
and it looks the same.

I suspect that this code:

if (dev->notrunc != 1)
{
open_flags |= O_TRUNC;
}

needs to have an:

else
{
open_flags |= O_APPEND;
}

Full code fragment is this:

(printer.c)
/*---------------------------- ------------------------------ */
/* Subroutine to open the printer file or pipe */
/*---------------------------- ------------------------------ */
static int
open_printer (DEVBLK *dev)
{
pid_t pid; /* Child process identifier */
char pathname[MAX_PATH]; /* file path in host format */
int open_flags; /* File open flags */
#if !defined( _MSVC_ )
int pipefd[2]; /* Pipe descriptors */
int rc; /* Return code */
#endif

/* Regular open if 1st char of filename is not vertical bar */
if (!dev->ispiped)
{
int fd;

/* Socket printer? */
if (dev->bs)
return (dev->fd < 0 ? -1 : 0);

/* Normal printer */
hostpath(pathname, dev->filename, sizeof(pathname));
open_flags = O_BINARY | O_WRONLY | O_CREAT /* | O_SYNC */;
if (dev->notrunc != 1)
{
open_flags |= O_TRUNC;
}
fd = open (pathname, open_flags,
S_IRUSR | S_IWUSR | S_IRGRP);

The symptom I am seeing is that
with this printer definition:

000F 1403 prt/prt00f.txt crlf noclear

(noting that "noclear" sets the
notrunc is set to true)

Anyway, if JOB 1 runs and has an
abend, and that abend output
goes to the printer and produces
a 1 MB file, and then I restart
Hercules and re-IPL MVS and
run JOB 2, which only produces
200 KB of data, then what I see
is that my output file remains
at 1 MB.

The first 200 KB is fine, it's the
data from JOB 2. But the last
800 KB is the last 800 KB of
JOB 1. ie the JOB 1 data has
been truncated.

What I actually expected, with
the noclear option in force, was
to get a 1.2 MB file, ie the first
1 MB contains the dump, and
the next 200 KB contains the
new output.

I can't see any possible use for
the current behavior which is to
just overwrite the beginning of
the file, leaving the last bit full
of old rubbish.

Let me know if you need me to
submit anything further.

Thanks. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-03-15 02:24:09 UTC
Permalink
noclear doesn't mean append.

noclear just means that when the file is opened, it is not truncated.

Joe
Post by ***@yahoo.com.au [hercules-390]
Then what do you suggest is done
when the "noclear" option is given?
If append is not supported then the
"noclear" option should not be
supported either.
Regardless, I see that it is already
C:\devel\hercules>grep O_APPEND *.h
C:\devel\hercules>grep O_APPEND *.c
scedasd.c: ((scediov_bk->type == SCCB_SCEDIOV_TYPE_CREATE) ?
(O_CREAT|O_TRUNC) : O_APPEND), sto, length);
w32util.c: { "a", "abc", _O_WRONLY | _O_CREAT | _O_APPEND | _O_BINARY },
w32util.c: { "a+", "a+bc", _O_RDWR | _O_CREAT | _O_APPEND | _O_BINARY },
w32util.c: { "a+b", "a+bc", _O_RDWR | _O_CREAT | _O_APPEND | _O_BINARY },
w32util.c: { "ab+", "a+bc", _O_RDWR | _O_CREAT | _O_APPEND | _O_BINARY },
C:\devel\hercules>
and I didn't notice any conditional
compilation for a system that
doesn't have it.
BFN. Paul.
O_APPEND is not supported on all filesystems. For instance, NFS does not support O_APPEND.
So probably not a good thing to be coding options on opens that are not supported.
Joe
I discovered this issue in Hercules 3.07
but I looked at the Hercules 3.12 code
and it looks the same.
if (dev->notrunc != 1)
{
open_flags |= O_TRUNC;
}
else
{
open_flags |= O_APPEND;
}
(printer.c)
/*---------------------------- ------------------------------ */
/* Subroutine to open the printer file or pipe */
/*---------------------------- ------------------------------ */
static int
open_printer (DEVBLK *dev)
{
pid_t pid; /* Child process identifier */
char pathname[MAX_PATH]; /* file path in host format */
int open_flags; /* File open flags */
#if !defined( _MSVC_ )
int pipefd[2]; /* Pipe descriptors */
int rc; /* Return code */
#endif
/* Regular open if 1st char of filename is not vertical bar */
if (!dev->ispiped)
{
int fd;
/* Socket printer? */
if (dev->bs)
return (dev->fd < 0 ? -1 : 0);
/* Normal printer */
hostpath(pathname, dev->filename, sizeof(pathname));
open_flags = O_BINARY | O_WRONLY | O_CREAT /* | O_SYNC */;
if (dev->notrunc != 1)
{
open_flags |= O_TRUNC;
}
fd = open (pathname, open_flags,
S_IRUSR | S_IWUSR | S_IRGRP);
The symptom I am seeing is that
000F 1403 prt/prt00f.txt crlf noclear
(noting that "noclear" sets the
notrunc is set to true)
Anyway, if JOB 1 runs and has an
abend, and that abend output
goes to the printer and produces
a 1 MB file, and then I restart
Hercules and re-IPL MVS and
run JOB 2, which only produces
200 KB of data, then what I see
is that my output file remains
at 1 MB.
The first 200 KB is fine, it's the
data from JOB 2. But the last
800 KB is the last 800 KB of
JOB 1. ie the JOB 1 data has
been truncated.
What I actually expected, with
the noclear option in force, was
to get a 1.2 MB file, ie the first
1 MB contains the dump, and
the next 200 KB contains the
new output.
I can't see any possible use for
the current behavior which is to
just overwrite the beginning of
the file, leaving the last bit full
of old rubbish.
Let me know if you need me to
submit anything further.
Thanks. Paul.
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-03-15 03:16:58 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
noclear doesn't mean append.
noclear just means that when the file is opened, it is not truncated.
I suspect that's NOT what the original author intended however!

Having noclear behave as it does is completely illogical. The whole purpose of not clearing the output file is because it already contains data you DON'T want to be lost. You wish to preserve (keep) it, and simply APPEND new data to the end of it.

This is without question a bug.

I'm currently working on fixing several other printer bugs and will see to it that this also gets fixed in my version. I can't say how long it'll take me but I *assure* you it *will* be fixed.

Whether or not it also gets fixed (and when) in 3.12 or the other Hyperion I cannot of course say.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
Joe Monk joemonk64@gmail.com [hercules-390]
2017-03-15 10:00:04 UTC
Permalink
The "feature" doesn't just exist in the printer code. It is also in the
punch code.

:)

Joe

On Tue, Mar 14, 2017 at 11:16 PM, ''Fish' (David B. Trout)'
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
noclear doesn't mean append.
noclear just means that when the file is opened, it is not truncated.
I suspect that's NOT what the original author intended however!
Having noclear behave as it does is completely illogical. The whole
purpose of not clearing the output file is because it already contains data
you DON'T want to be lost. You wish to preserve (keep) it, and simply
APPEND new data to the end of it.
This is without question a bug.
I'm currently working on fixing several other printer bugs and will see to
it that this also gets fixed in my version. I can't say how long it'll take
me but I *assure* you it *will* be fixed.
Whether or not it also gets fixed (and when) in 3.12 or the other Hyperion
I cannot of course say.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-03-15 14:42:27 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
The "feature" doesn't just exist in the printer code.
It is also in the punch code.
:)
Yep. Saw that too. It too will be fixed. Thanks.

("feature" indeed!)

;-)
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
kerravon86@yahoo.com.au [hercules-390]
2017-03-15 18:55:00 UTC
Permalink
Thankyou for acknowledging the bug so that
I don't need to explain why applications
should not be producing corrupt files as a
"feature".

BFN. Paul.
Post by Joe Monk ***@gmail.com [hercules-390]
noclear doesn't mean append.
noclear just means that when the file is opened, it is not truncated.
I suspect that's NOT what the original author intended however!

Having noclear behave as it does is completely illogical. The whole purpose of not clearing the output file is because it already contains data you DON'T want to be lost. You wish to preserve (keep) it, and simply APPEND new data to the end of it.

This is without question a bug.

I'm currently working on fixing several other printer bugs and will see to it that this also gets fixed in my version. I can't say how long it'll take me but I *assure* you it *will* be fixed.

Whether or not it also gets fixed (and when) in 3.12 or the other Hyperion I cannot of course say.

--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com http://www.softdevlabs.com
mail: ***@... mailto:***@...
Joe Monk joemonk64@gmail.com [hercules-390]
2017-03-15 21:46:26 UTC
Permalink
In a real life scenario, you can't open a unit record output device (punch,
printer) for append, so there is no such thing in real life as noclear.

Im not sure what the purpose of noclear is anyway. Why would you want to
maintain a printer file between hercules runs? Why not just rename the old
file and then open the new one... if you need to append the two files
together just do copy A+B.

Joe
Post by ***@yahoo.com.au [hercules-390]
Thankyou for acknowledging the bug so that
I don't need to explain why applications
should not be producing corrupt files as a
"feature".
BFN. Paul.
Post by Joe Monk ***@gmail.com [hercules-390]
noclear doesn't mean append.
noclear just means that when the file is opened, it is not truncated.
I suspect that's NOT what the original author intended however!
Having noclear behave as it does is completely illogical. The whole
purpose of not clearing the output file is because it already contains data
you DON'T want to be lost. You wish to preserve (keep) it, and simply
APPEND new data to the end of it.
This is without question a bug.
I'm currently working on fixing several other printer bugs and will see to
it that this also gets fixed in my version. I can't say how long it'll take
me but I *assure* you it *will* be fixed.
Whether or not it also gets fixed (and when) in 3.12 or the other Hyperion
I cannot of course say.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com http://www.softdevlabs.com
kerravon86@yahoo.com.au [hercules-390]
2017-03-15 22:24:34 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
In a real life scenario, you can't open a
unit record output device (punch, printer)
for append, so there is no such thing in
real life as noclear.
It's the other way around. In real life,
MVS has no way to vaporize paper
that is sitting uncollected on the
printer. It requires a user to move
the paper away.
Post by Joe Monk ***@gmail.com [hercules-390]
Im not sure what the purpose of
noclear is anyway. Why would you
want to maintain a printer file
between hercules runs?
For the same reason people normally
do warm starts of JES2 rather than
cold between runs. When a
user/operator decides it is time to
clear a printout, that is on their
schedule, not something that
happens automatically at IPL time.
Post by Joe Monk ***@gmail.com [hercules-390]
Why not just rename the old file
and then open the new one... if
you need to append the two files
together just do copy A+B.
That is one option the user/operator
has to clear away old printer output,
yes. Their decision. Their method.
Their timing. The hardware (Hercules)
may not be the thing they wish to
use to clear printer output. Hercules
hardware has the ability to vaporize
old paper, something you don't see in
a typical MVS shop.

BFN. Paul.
Ken Whitesell KenWhitesell@comcast.net [hercules-390]
2017-03-15 22:41:40 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
That is one option the user/operator
has to clear away old printer output,
yes. Their decision. Their method.
Their timing. The hardware (Hercules)
may not be the thing they wish to
use to clear printer output. Hercules
hardware has the ability to vaporize
old paper, something you don't see in
a typical MVS shop.
BFN. Paul.
Wait a minute, are you telling me that MVS doesn't support the HCF (Halt
and Catch Fire) IOCP?

I would think _that_ would be capable of vaporizing old paper - and
punch cards, too.

(Ok, crawling back under my rock now.)

Ken
Kevin Monceaux Kevin@RawFedDogs.net [hercules-390]
2017-03-15 22:59:07 UTC
Permalink
Post by Ken Whitesell ***@comcast.net [hercules-390]
Wait a minute, are you telling me that MVS doesn't support the HCF (Halt
and Catch Fire) IOCP?
I would think _that_ would be capable of vaporizing old paper - and
punch cards, too.
No, that would just produce smoke and leave ash behind, until the halon
system dumped the halon. I don't think that would produce the amount of
energy required for vaporization.
--
Kevin
http://www.RawFedDogs.net
http://www.Lassie.xyz
http://www.WacoAgilityGroup.org
Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-03-15 22:44:41 UTC
Permalink
I think you're missing the point.

For instance, take a payroll check run. Once the payroll checks are on the
printer and printing, you can't go back and add payroll checks to that
check run. You have to generate another check run.

Joe
Post by ***@yahoo.com.au [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
In a real life scenario, you can't open a
unit record output device (punch, printer)
for append, so there is no such thing in
real life as noclear.
It's the other way around. In real life,
MVS has no way to vaporize paper
that is sitting uncollected on the
printer. It requires a user to move
the paper away.
Post by Joe Monk ***@gmail.com [hercules-390]
Im not sure what the purpose of
noclear is anyway. Why would you
want to maintain a printer file
between hercules runs?
For the same reason people normally
do warm starts of JES2 rather than
cold between runs. When a
user/operator decides it is time to
clear a printout, that is on their
schedule, not something that
happens automatically at IPL time.
Post by Joe Monk ***@gmail.com [hercules-390]
Why not just rename the old file
and then open the new one... if
you need to append the two files
together just do copy A+B.
That is one option the user/operator
has to clear away old printer output,
yes. Their decision. Their method.
Their timing. The hardware (Hercules)
may not be the thing they wish to
use to clear printer output. Hercules
hardware has the ability to vaporize
old paper, something you don't see in
a typical MVS shop.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-03-15 22:49:09 UTC
Permalink
I think it's you that is missing the point.

Although MVS has no concept of
opening a printer in "append" mode,
it doesn't need to. That is something
Hercules does, emulating a real
printer, which does exactly that.
New paper is added to the old paper
on the floor below the printer.

Your example of check runs - the
old check run will stay there, sitting
on the floor, until someone comes
and collects it. If no-one collects it,
then the new check run will sit on
top of the old check run, in a
predictable order from the floor.

At no point does old paper ever get
vaporized by the printer hardware,
which is exactly what Hercules is
emulating - a printer.

BFN. Paul.




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

I think you're missing the point.


For instance, take a payroll check run. Once the payroll checks are on the printer and printing, you can't go back and add payroll checks to that check run. You have to generate another check run.


Joe
Post by Joe Monk ***@gmail.com [hercules-390]
In a real life scenario, you can't open a
unit record output device (punch, printer)
for append, so there is no such thing in
real life as noclear.
It's the other way around. In real life,
MVS has no way to vaporize paper
that is sitting uncollected on the
printer. It requires a user to move
the paper away.
Post by Joe Monk ***@gmail.com [hercules-390]
Im not sure what the purpose of
noclear is anyway. Why would you
want to maintain a printer file
between hercules runs?
For the same reason people normally
do warm starts of JES2 rather than
cold between runs. When a
user/operator decides it is time to
clear a printout, that is on their
schedule, not something that
happens automatically at IPL time.
Post by Joe Monk ***@gmail.com [hercules-390]
Why not just rename the old file
and then open the new one... if
you need to append the two files
together just do copy A+B.
That is one option the user/operator
has to clear away old printer output,
yes. Their decision. Their method.
Their timing. The hardware (Hercules)
may not be the thing they wish to
use to clear printer output. Hercules
hardware has the ability to vaporize
old paper, something you don't see in
a typical MVS shop.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-03-15 23:03:02 UTC
Permalink
Your conflating apples and oranges.

Youre saying the paper will continue to cumulate. That is true, but what is
on that paper? Separate jobs (files), with header and trailer separator
pages.

In your comparison, the computer disk holding the print file would be the
box of paper, and the print file would be each job.

Joe
Post by ***@yahoo.com.au [hercules-390]
I think it's you that is missing the point.
Although MVS has no concept of
opening a printer in "append" mode,
it doesn't need to. That is something
Hercules does, emulating a real
printer, which does exactly that.
New paper is added to the old paper
on the floor below the printer.
Your example of check runs - the
old check run will stay there, sitting
on the floor, until someone comes
and collects it. If no-one collects it,
then the new check run will sit on
top of the old check run, in a
predictable order from the floor.
At no point does old paper ever get
vaporized by the printer hardware,
which is exactly what Hercules is
emulating - a printer.
BFN. Paul.
I think you're missing the point.
For instance, take a payroll check run. Once the payroll checks are on the
printer and printing, you can't go back and add payroll checks to that
check run. You have to generate another check run.
Joe
Post by Joe Monk ***@gmail.com [hercules-390]
In a real life scenario, you can't open a
unit record output device (punch, printer)
for append, so there is no such thing in
real life as noclear.
It's the other way around. In real life,
MVS has no way to vaporize paper
that is sitting uncollected on the
printer. It requires a user to move
the paper away.
Post by Joe Monk ***@gmail.com [hercules-390]
Im not sure what the purpose of
noclear is anyway. Why would you
want to maintain a printer file
between hercules runs?
For the same reason people normally
do warm starts of JES2 rather than
cold between runs. When a
user/operator decides it is time to
clear a printout, that is on their
schedule, not something that
happens automatically at IPL time.
Post by Joe Monk ***@gmail.com [hercules-390]
Why not just rename the old file
and then open the new one... if
you need to append the two files
together just do copy A+B.
That is one option the user/operator
has to clear away old printer output,
yes. Their decision. Their method.
Their timing. The hardware (Hercules)
may not be the thing they wish to
use to clear printer output. Hercules
hardware has the ability to vaporize
old paper, something you don't see in
a typical MVS shop.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-03-15 23:10:41 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Your conflating apples and oranges.
For the first time in my life, I don't appear
to be in a minority group on this one. You are.
I'm thinking of contacting the Guiness
Book of Records.
Post by Joe Monk ***@gmail.com [hercules-390]
Youre saying the paper will continue to cumulate.
Yep.
Post by Joe Monk ***@gmail.com [hercules-390]
That is true, but what is on that paper? Separate
jobs (files), with header and trailer separator pages.
Yep, all in a pile on the floor, needing a
human to separate them. None of it
magically vaporizing.
Post by Joe Monk ***@gmail.com [hercules-390]
In your comparison, the computer disk
holding the print file would be the box
of paper,
Yes, free space on the disk is your
supply of paper.
Post by Joe Monk ***@gmail.com [hercules-390]
and the print file would be each job.
The print file is *every* job, all in one
pile on the floor or prt00e.txt depending
on what hardware you are using to print.

BFN. Paul.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-03-15 23:44:20 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Your conflating apples and oranges.
For the first time in my life, I don't appear
to be in a minority group on this one. You are.
I'm thinking of contacting the Guiness
Book of Records.
I'll mark that one with a white stone :P

--Ivan



[Non-text portions of this message have been removed]
Kevin Monceaux Kevin@RawFedDogs.net [hercules-390]
2017-03-15 23:38:46 UTC
Permalink
The print file is *every* job, all in one pile on the floor or prt00e.txt
depending on what hardware you are using to print.
In the 4245s and/or 6262s we used in the shop I work at the paper would have
remained in the printer until an operator removed it. It rarely, if ever,
ended up in a pile on the floor. :-)
--
Kevin
http://www.RawFedDogs.net
http://www.Lassie.xyz
http://www.WacoAgilityGroup.org
Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.
Gerhard Postpischil gerhardp@charter.net [hercules-390]
2017-03-15 22:27:42 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
In a real life scenario, you can't open a unit record output device
(punch, printer) for append, so there is no such thing in real life as
noclear.
But in a real life scenario, the operator can decide when and how to
remove paper from the printer or punch cards from stackers, which is
closer to the wanted Hercules behavior. Starting MVS doesn't destroy
outpout in either of those machines.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com
Vince Coen vbcoen@gmail.com [hercules-390]
2017-03-15 22:23:54 UTC
Permalink
I would have thought that the o/p for punch should be the same as the
printer.

I.e., produce a file as JOBnnnnn .( pch may be ) for each job stream.

I have noticed how ever that some times when I send punch o/p it does
not turn up.

I just find other ways around it - mostly time consuming :(
Post by Joe Monk ***@gmail.com [hercules-390]
In a real life scenario, you can't open a unit record output device
(punch, printer) for append, so there is no such thing in real life as
noclear.
Im not sure what the purpose of noclear is anyway. Why would you want
to maintain a printer file between hercules runs? Why not just rename
the old file and then open the new one... if you need to append the
two files together just do copy A+B.
Joe
Thankyou for acknowledging the bug so that
I don't need to explain why applications
should not be producing corrupt files as a
"feature".
BFN. Paul.
Post by Joe Monk ***@gmail.com [hercules-390]
noclear doesn't mean append.
noclear just means that when the file is opened, it is not
truncated.
I suspect that's NOT what the original author intended however!
Having noclear behave as it does is completely illogical. The
whole purpose of not clearing the output file is because it
already contains data you DON'T want to be lost. You wish to
preserve (keep) it, and simply APPEND new data to the end of it.
This is without question a bug.
I'm currently working on fixing several other printer bugs and
will see to it that this also gets fixed in my version. I can't
say how long it'll take me but I *assure* you it *will* be fixed.
Whether or not it also gets fixed (and when) in 3.12 or the other
Hyperion I cannot of course say.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com http://www.softdevlabs.com
--
- IMPORTANT –

This email and the information in it may be confidential, legally privileged
and/or protected by law.
It is intended solely for the use of the person to whom it is addressed.
If you are not the intended recipient, please notify the sender immediately
and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium.

Please also delete all copies of this email & any attachments from your system.

If this is an encrypted email it is your responsibility to maintain the 1024
byte key system even for one-use keys. Once mail has been sent the sending key
is not kept and therefore a replacement mail cannot be resent.

We cannot guarantee the security or confidentiality of non encrypted email
communications.
We do not accept any liability for losses or damages that you may suffer as a
result of your receipt of this email including but not limited to computer
service or system failure, access delays or interruption, data non-delivery
or mis-delivery, computer viruses or other harmful components.

Copyright in this email and any attachments belongs to Applewood Computers.
Should you communicate with anyone at Applewood Computers by email,
you consent to us monitoring and reading any such correspondence.

Nothing in this email shall be taken or read as suggesting, proposing or
relating to any agreement concerted practice or other practice that could
infringe UK or EC competition legislation (unless it is against Security
requirements).

This Email and its attachments (if any) are scanned for virii using Clamd
and ClamAV 0.99.2 or later (Linux x64).

Dykegrove Limited T/A Applewood Computers is a company registered in England
(no. 01681349) whose registered office is at Applewood House,
17 Stag Green Avenue, Hatfield, Hertfordshire, AL9 5EB, UK.
kerravon86@yahoo.com.au [hercules-390]
2017-03-15 22:53:43 UTC
Permalink
Post by Vince Coen ***@gmail.com [hercules-390]
I would have thought that the o/p for punch
should be the same as the printer.
Sure, that isn't under dispute.
Post by Vince Coen ***@gmail.com [hercules-390]
I.e., produce a file as JOBnnnnn .( pch may be ) for each job stream.
Automated separation of job output
into different bins is not something
that the hardware I am used to was
capable of doing. It all went onto the
same pile.
Post by Vince Coen ***@gmail.com [hercules-390]
I have noticed how ever that some times
when I send punch o/p it does
not turn up.
I suggest you try to reproduce the problem
and post it here for diagnosis.
Post by Vince Coen ***@gmail.com [hercules-390]
I just find other ways around it - mostly time consuming :(
I send my output datasets to tape, not
the punch, and I have never noticed
a problem with the tape drive. Or the
printer for that matter. I never use
the punch so don't know how reliable
it is or isn't.

BFN. Paul.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-03-15 23:03:02 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
In a real life scenario, you can't open a unit record output device
(punch, printer) for append, so there is no such thing in real life as
noclear.
Im not sure what the purpose of noclear is anyway. Why would you want
to maintain a printer file between hercules runs? Why not just rename
the old file and then open the new one... if you need to append the
two files together just do copy A+B.
Joe
Uh ?

In real life you cannot open an output UR - EXCEPT for append ! There is
no magical way to have a printer or punch re-absorb the cards or paper,
clear it and overwrite the cards or paper !

--Ivan


[Non-text portions of this message have been removed]
Richard Chycoski myyahoo@chycoski.com [hercules-390]
2017-03-17 00:53:40 UTC
Permalink
Back to the original issue - O_APPEND is *not* unsupported (yeah, double
negative!) on NFS. It's just not atomic, if two clients both choose to
O_APPEND at the same time, the result is probably not what was intended.
*O_APPEND *may lead to corrupted files on NFS filesystems if more than
one process appends data to a file at once. This is because NFS does
not support appending to a file, so the client kernel has to simulate
it, which can't be done without a race condition.
Basically, the kernel seeks to the end of the file.

So you can use it, but beware that it may mess up if there's more than
one client writing to the file.

- Richard, VE7CVS
somitcw@yahoo.com [hercules-390]
2017-03-17 01:11:26 UTC
Permalink
Post by Richard Chycoski ***@chycoski.com [hercules-390]
Back to the original issue - O_APPEND is *not* unsupported (yeah,
double negative!) on NFS. It's just not atomic, if two clients both
choose to O_APPEND at the same time, the result is probably not
what was intended.
- - - remainder snipped - - -

So the issue that NFS does not prevent two programs from
appending to the same file at the same time which causes issues.

So NFS can append too much which is different than not at all.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-03-17 11:10:52 UTC
Permalink
"Most NFS clients, including the Linux NFS client in kernels newer than
2.4.20, support "close to open" cache consistency, which provides good
performance and meets the sharing needs of most applications. This style of
cache consistency does not provide strict coherence of the file size
attribute among multiple clients, which would be necessary to ensure that
append writes are always placed at the end of a file."

Like I said, it is unsupported, because you can't guarantee that a file
write is going to placed at the end of the file.

Joe
Post by Richard Chycoski ***@chycoski.com [hercules-390]
Back to the original issue - O_APPEND is *not* unsupported (yeah, double
negative!) on NFS. It's just not atomic, if two clients both choose to
O_APPEND at the same time, the result is probably not what was intended.
*O_APPEND *may lead to corrupted files on NFS filesystems if
more than one process appends data to a file at once. This is
because NFS does not support appending to a file, so the
client kernel has to simulate it, which can't be done without
a race condition.
Basically, the kernel seeks to the end of the file.
So you can use it, but beware that it may mess up if there's more than one
client writing to the file.
- Richard, VE7CVS
Richard Chycoski myyahoo@chycoski.com [hercules-390]
2017-03-18 04:40:18 UTC
Permalink
Yes, I would agree that for most uses of Hercules, the vast majority of
users are not going to share these files over NFS with other computers.
Anyone who does, deserves what he or she gets!

For everyone else (99 and 44/100% of Hercules users) - this is a non-issue.

- Richard

Loading...