HP3000-L Archives

March 1999, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Zoltak <[log in to unmask]>
Reply To:
John Zoltak <[log in to unmask]>
Date:
Thu, 18 Mar 1999 13:43:27 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (226 lines)
Rich,

The output redirect is a *tricky* way to keep a writer on the message
file for as long as the input is waiting for a record to be posted. But
it still doesn't do the timeout. Does it timeout for you?

John Zoltak
North American Mfg Co

> -----Original Message-----
> From: [log in to unmask]
> [mailto:[log in to unmask]]
> Sent: Thursday, March 18, 1999 1:19 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] message files
>
>
> Ok,
>   I assumed you meant to add ;MSG onto the :BUILD.  Once I
> did that it worked!
> Now...I SEE it, but I don't BELIEVE it!
>
>   Can someone (Jeff Vance?) explain why this works?  My
> assumption is that the
> process is going to hang on the read (& not return) because
> the MSG file is
> empty.  This is true even if the file is being access for
> write (and the writer
> doesn't write to it or close it).
>
>    If I don't redirect the output to the msg file, it acts as
> I expects.  Why
> does redirecting the output change this?  Does INPUT act
> differently if it's
> output is being redirected?
>
> Rich (I thought I knew MSG file pretty well, but now I'm
> doubting my manhood)
> Trapp
>
> ______________________________________________________________
> _________
>  Rich Trapp "RAT"
>  Managed Business Solutions   [log in to unmask]
> http://www.mbsnav.com
>  Assigned to: TMO Design Automation Support at HP Loveland, CO
>  (Telnet) or (970) 679-2221   [log in to unmask]
> ______________________________________________________________
> _________
>
>
> -----Original Message-----
> From: [log in to unmask] [mailto:[log in to unmask]]
> Sent: Thursday, March 18, 1999 9:09 AM
> To: [log in to unmask]
> Cc: [log in to unmask]
> Subject: Re: message files
>
>
> Hi David
> Here is another alternative, which is crude but effective.
> The command waits for the specified time, or until a
> record is written to the ipc file :-
>
> BUILD MSGFILE;REC=-256,1,V,ASCII
>  FILE X=MSGFILE,OLD;REC=-256,1,V,ASCII;SHR;GMULTI;MSG
> INPUT REPLY;WAIT=30 > *X < *X
>
> Regards,
> Tad.
>
>
>
>
>
> [log in to unmask] on 18/03/99 16:52:26
>
> Please respond to [log in to unmask]
>
> To:   [log in to unmask]
> cc:    (bcc: Tad BOCHAN/Securities_Services/FR/PARIBAS)
> Subject:  Re: message files
>
>
>
>
> David,
>
> First problem, End of file in input, occurs because the input does not
> open the message file with extended wait and the fact that
> ECHO must be
> doing multiple opens on the message file. When ECHO opens and
> closes the
> file, the INPUT gets an end of file since it's not opened
> with extended
> wait. INPUT never gets a chance to read the record that ECHO
> eventually
> posts to the message file. Instead of ECHO use FCOPY and that
> will cure
> the end of file in input message and leave no records in the file.
>
> Second, it appears that INPUT does not enable timeouts in a job. They
> probably didn't expect INPUT to be used on message files, only on
> terminal input, so didn't enable the timeout in a job.
>
> Solution, create a quick program to open the message file for
> input with
> a timeout.
>
> You could also have the job launch another scheduled job for
> 60 seconds
> to post a record to the message file so it continues. I know
> that is not
> so elegant, but there's not many other options here.
>
> Hope this helps,
> John Zoltak
> North American Mfg Co
>
> > -----Original Message-----
> > From: Maclary, David [mailto:[log in to unmask]]
> > Sent: Thursday, March 18, 1999 10:13 AM
> > To: [log in to unmask]
> > Subject: Re: [HP3000-L] message files
> >
> >
> > Oops. There is a typeo in my example All references should be
> > to file "x".
> > The problem remains, however...
> >
> > > Session A:
> > >
> > > :build msgfile;msg
> > > :file x=msgfile,old;semi;gmulti
> > > :input response;wait=60 < *x
> > >
> > > Session B:
> > > :file x=msgfile,old;semi;gmulti
> > > :echo OK >> *x
> > >
> > > ----------
> > > From:         Maclary, David
> > > Sent:         Thursday, March 18, 1999 9:54 AM
> > > To:   'HP-3000 Systems Discussion'
> > > Subject:      message files
> > >
> > > I need to have a batch job wait for n seconds, but I'd also
> > like it to
> > > "wake up" immediately if needed. I was thinking that a
> > message file would
> > > do the trick.
> > >
> > > When I do the following interactively...
> > >
> > > Session A:
> > >
> > > :build msgfile;msg
> > > :file x=msgfile,old;semi;gmulti
> > > :input response;wait=60 < *x
> > >
> > > Session B:
> > > :file x=msgfile,old;semi;gmulti
> > > :echo OK >> *x
> > >
> > > Session A says...
> > >
> > > End of file on input. (CIERR 900)
> > >
> > > and msgfile now has an eof of 1, and record 1 contains the
> > string "OK".
> > >
> > > Figuring that GMULTI was allowing the file pointer to move
> > on me, I tried
> > > ;MULTI, but that get me...
> > >
> > > Couldn't open output redirection file, command failed.
> (CIERR 9425)
> > > DEVICE UNAVAILABLE  (FSERR 55)
> > >
> > > In any event, I can work around the end of file error
> message easily
> > > enough, except, when I try running
> > > "Session A" as a batch job, the INPUT;WAIT=60 does not
> time out !!!
> > >
> > > Want I'd like to have happen is, in batch, for the :INPUT
> command to
> > > either read a record
> > > from msgfile (if one gets ECHOed to it), or, timeout after
> > 60 seconds.
> > >
> > > Any help would be greatly appreciated.
> > >
> > > Thank you,
> > > David Maclary
> > >
> > >
> >
>
>
>
>
>
>
>
>
> --------------------------------------------------------------
> ---------------
> This message is confidential; its contents do not constitute a
> commitment by Paribas except where provided for in a written agreement
> between you and Paribas. Any unauthorised disclosure, use or
> dissemination, either whole or partial, is prohibited. If you are not
> the intended recipient of the message, please notify the sender
> immediately.
>
> Ce message est confidentiel ; son contenu ne représente en
> aucun cas un
> engagement de la part de Paribas sous réserve de tout accord
> conclu par
> écrit entre vous et Paribas. Toute publication, utilisation ou
> diffusion, même partielle, doit être autorisée préalablement. Si vous
> n'êtes pas destinataire de ce message, merci d'en avertir
> immédiatement
> l'expéditeur.
>

ATOM RSS1 RSS2