presumed Hercules bug - append not appending

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

presumed Hercules bug - append not appending

Hercules390 - General mailing list
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.
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
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, [hidden email] [hercules-390] <
[hidden email]> 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.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
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 [hidden email], <joemonk64@...> 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, kerravon86@... mailto:kerravon86@... [hercules-390] <[hidden email] mailto:[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
noclear doesn't mean append.

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

Joe

On Tue, Mar 14, 2017 at 5:06 PM, [hidden email] [hercules-390] <
[hidden email]> wrote:

>
>
> 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 [hidden email], <joemonk64@...> 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, kerravon86@... mailto:kerravon86@...
> [hercules-390] <[hidden email] mailto:hercules-390@
> 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.
>
>
Reply | Threaded
Open this post in threaded view
|

RE: presumed Hercules bug - append not appending

Hercules390 - General mailing list
Joe Monk wrote:

> 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: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
On 14/03/17 21:00, Joe Monk [hidden email] [hercules-390] 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.

But the same person is requesting noclear/append in the same place as
he's specifying the path to the file. The appropriate response is an
error message, not a partially-overwritten file.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]


------------------------------------

------------------------------------

Community email addresses:
  Post message: [hidden email]
  Subscribe:    [hidden email]
  Unsubscribe:  [hidden email]
  List owner:   [hidden email]

Files and archives at:
  http://groups.yahoo.com/group/hercules-390

Get the latest version of Hercules from:
  http://www.hercules-390.org


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/hercules-390/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/hercules-390/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
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)'
[hidden email] [hercules-390] <[hidden email]> wrote:

>
>
> Joe Monk wrote:
>
> > 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: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: presumed Hercules bug - append not appending

Hercules390 - General mailing list
Joe Monk wrote:

> 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: [hidden email]




Reply | Threaded
Open this post in threaded view
|

RE: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
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.




---In [hidden email], <david.b.trout@...> wrote :

 Joe Monk wrote:
 
 > 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: fish@... mailto:fish@...
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
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



On Wed, Mar 15, 2017 at 2:55 PM, [hidden email] [hercules-390] <
[hidden email]> wrote:

>
>
> 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.
>
> ---In [hidden email], <david.b.trout@...> wrote :
>
> Joe Monk wrote:
>
> > 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: fish@... mailto:fish@...
>
>
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
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 :(



On 15/03/17 21:46, Joe Monk [hidden email] [hercules-390] wrote:

> 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
>
>
>
> On Wed, Mar 15, 2017 at 2:55 PM, [hidden email]
> <mailto:[hidden email]> [hercules-390]
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     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.
>
>     ---In [hidden email]
>     <mailto:[hidden email]>, <david.b.trout@...> wrote :
>
>     Joe Monk wrote:
>
>     > 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: fish@... mailto:fish@ <mailto:fish@>...
>
>
>


--
- 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.

Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
---In [hidden email], <joemonk64@...> wrote :

> 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.

> 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.

> 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.
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
On 3/15/2017 5:46 PM, Joe Monk [hidden email] [hercules-390] wrote:
> 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

Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
On 3/15/2017 6:24 PM, [hidden email] [hercules-390] wrote:

>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
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

On Wed, Mar 15, 2017 at 6:24 PM, [hidden email] [hercules-390] <
[hidden email]> wrote:

>
>
> ---In [hidden email], <joemonk64@...> wrote :
>
> > 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.
>
> > 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.
>
> > 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.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
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 [hidden email], <joemonk64@...> 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

 
 On Wed, Mar 15, 2017 at 6:24 PM, kerravon86@... mailto:kerravon86@... [hercules-390] <[hidden email] mailto:[hidden email]> wrote:
   ---In [hidden email] mailto:[hidden email], <joemonk64@...> wrote :
 
 > 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.
 
 > 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.
 
 > 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.
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
---In [hidden email], <vbcoen@...> wrote :

> I would have thought that the o/p for punch
> should be the same as the printer.

Sure, that isn't under dispute.

> 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.

> 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.

> 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.
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
On Wed, Mar 15, 2017 at 06:41:40PM -0400, Ken Whitesell [hidden email] [hercules-390] wrote:
 
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list


On 3/15/2017 10:46 PM, Joe Monk [hidden email] [hercules-390] wrote:

>
>
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: presumed Hercules bug - append not appending

Hercules390 - General mailing list
In reply to this post by Hercules390 - General mailing list
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

On Wed, Mar 15, 2017 at 6:49 PM, [hidden email] [hercules-390] <
[hidden email]> wrote:

>
>
> 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 [hidden email], <joemonk64@...> 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
>
> On Wed, Mar 15, 2017 at 6:24 PM, kerravon86@... mailto:kerravon86@...
> [hercules-390] <[hidden email] mailto:hercules-390@
> yahoogroups.com> wrote:
> ---In [hidden email] mailto:[hidden email],
> <joemonk64@...> wrote :
>
> > 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.
>
> > 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.
>
> > 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.
>
>
12