Re: Preventing Programs from using TEST files

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

Well, in the case of a CGI program, the program ends when the page is 
written back to the browser. That usually should not leave open files. 
And if running your own stuff with remote command, again, you shouldn't 
leave open files out there. This is a stateless situation, I believe.

I suppose there is more risk when you write your own sockets program - 
the system ones do clean up nicely, in my experience here.

Vern

Carel Teijgeler wrote:
> In that case you have to do more than CHGLIBL: do not forget RCLACTGRP
> and/or RCLRSC to close opened files before accessing those again in the new
> environment.
>
> With regards,
> Carel Teijgeler
>
> *********** REPLY SEPARATOR  ***********
>
> On 28-2-2010 at 22:08 Vern Hamberg wrote:
>
>   
> > Carel
> >
> > If the OP was running his own jobs, yes, a JOBD could take care of things.
> >     
> I went beyond that and started to talk about server jobs, like 
>   
> > the remote command host server and HTTP servers with CGI programs. Those
> >     
> can't benefit from a single JOBD, to my knowledge, since different users 
>   
> > can connect to them. So for those, one has to manage the library list in a
> >     
> program - at least that is a reasonable procedure.
>   
> > Vern
> >
> > Carel Teijgeler wrote:
> >     
> > > Just curious:
> > >
> > > would the problem of the OP not have been solved with a correct JOBD for
> > > each the test environment and the production one?
> > >
> > > No bother with exit points/programmes, LPARs, etc.
> > >
> > > Just my thought and 2 euro cents.
> > >
> > > With regards,
> > > Carel Teijgeler
> > >
> > > *********** REPLY SEPARATOR  ***********
> > >
> > > On 26-2-2010 at 18:02 Vern Hamberg wrote:
> > >
> > >   
> > >       
> > > > The exit points or programs are defined with parameters = the command
> > > >         
> > in 
> >     
> > > > question is part of a document management product, where search keys
> > > >         
> > are 
> >     
> > > > stored - like IBM's Content Manager - the programs are for customers to
> > > >         
>
>   
> > > > work with their own data in this context. So the product library
> > > >         
> > doesn't 
> >     
> > > > come into play - if we used it (there are reasons we choose not to), it
> > > >         
>
>   
> > > > would only be our library, not the customer's data library.
> > > >
> > > > Hope that is clearer - I see I was rather vague and elliptical. And now
> > > >         
>
>   
> > > > I'm awaiting guests for a pot luck supper - can't think straight now, 
> > > > either!
> > > >
> > > > Vern
> > > >
> > > > CRPence wrote:
> > > >     
> > > >         
> > > > >    A "command" can establish the "product library" as part of the 
> > > > > *LIBL during its invocation, such that the CPP would not need to 
> > > > > ADDLIBLE.  Or maybe you did not mean *CMD object, or I just do not 
> > > > > understand what is being explained.
> > > > >
> > > > > Regards, Chuck
> > > > >
> > > > > Vern Hamberg wrote:
> > > > >   
> > > > >       
> > > > >           
> > > > > > Along the lines of "never say never" - there are contexts other
> > > > > > than the regular end-user daily applications. As an example, we
> > > > > > have exit points in one of our commands. This command is used in
> > > > > > several places, including being called from a browser or from
> > > > > > some other client. It is often called in a batch server context,
> > > > > > where library lists are not established in the same way as for
> > > > > > interactive applications and batch processes called from those
> > > > > > applications. So it is necessary to use ADDLIBLE in the program
> > > > > > that will be called at the exit point.
> > > > > >
> > > > > > Bryce Martin wrote:
> > > > > >     
> > > > > >         
> > > > > >             
> > > > > > > Do not let a program set its own library list.  Why would a program
> > > > > > >               
> have code in it to add a test library to begin with?
>   
> > > > > > > <<SNIP>>
> > > > > > >       
> > > > > > >           
> > > > > > >               
> > > > --
> > > >         
>
>
>