RE: SOLVED: QIBM_QPWFS_FILE_SERV - V6R1 - Fails to call(?)

[Narayanan Pillai <strqst400@xxxxxxxxx>]

Gary, 

One more piece of wonderful advise. So currently this is the design that is going in. 

   1. Write a "Controller" Program that receives the initial call
   2. Read a Table with the ServerID from the DS passed ( 11-20 )
   3. Use values in the table to call programs
   4. Register the controller with the QIBM_QPWFS_FILE_SERV endpoint
   5. Stop TCP Server *NETSVR, Stop SBS QSERVER, Stop Host Server *FILE
   6. Restart QSERVER, *NETSVR and *FILE Server

Once again, 

Thanks all for your wonderful insights. 

Regards, 
Narayanan

--- On Tue, 2/8/11, Monnier, Gary <Gary.Monnier@xxxxxxxxx> wrote:

> From: Monnier, Gary <Gary.Monnier@xxxxxxxxx>
> Subject: RE: QIBM_QPWFS_FILE_SERV - V6R1 - Fails to call(?)
> To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
> Date: Tuesday, February 8, 2011, 10:59 AM
>
> Narayanan,
>
> If memory serves for performance reasons the exit point
> program is
> determined when subsystem QSERVER starts.  This means
> you will have to
> end the host servers, end subsystem QSERVER, restart
> subsystem QSERVER
> and restart the host servers.
>
> A "quick" way to get your exit programs recognized by the
> servers is to
> bring the system to a restricted state and then restart
> your controlling
> subsystem.  This may seem heavy handed but it works.
>
> The host servers are listed by function at IBM's InfoCenter
> for V6R1.
>
> Connecting to System i
>    System I Access for Windows
>       Administration 
>         Host server administration
>            Identify
> i5/OS host servers and associated programs
>               Host
> servers by function
>
> Also, think about adding some form of auditing to your exit
> program.  It
> will greatly aid in determining what is occurring. 
> This can be as
> simple as sending yourself a message saying "Exit program
> ABC was
> called." or as complex as you feel is needed.
>
> Hope this helps.
>
> Gary Monnier
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]
> On Behalf Of Chris Bipes
> Sent: Tuesday, February 08, 2011 7:18 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: QIBM_QPWFS_FILE_SERV - V6R1 - Fails to
> call(?)
>
> Do you have to register your exit program?  WRKREGINF
> option 8 next to
> the exit point.  Do not use library list but specify
> the actual library.
> Verify the program name.  Check authority to the
> program and any objects
> that it references.  Looks like the jobs run under
> QUSER but adopt
> authority to the actual user.  Give public full access
> as a test, then
> figure out the proper authority and please document your
> findings on
> this list.
>
> -- 
> Chris Bipes
> Director of Information Services
> CrossCheck, Inc.
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]
> On Behalf Of Narayanan R Pillai
> Sent: Monday, February 07, 2011 5:25 PM
> To: Midrange Systems Technical Discussion
> Subject: QIBM_QPWFS_FILE_SERV - V6R1 - Fails to call(?)
>
> Any pointers would be appreciated:
>
> 1. I have a very simple RPGLE Exit Program that does an
> allow = '0' 
> attached to the QIBM_QPWFS_FILE_SERV Exit Point on a V6R1
> box.
>
> 2. After adding the exit program, I ENDTCPSVR *NETSVR and
> killed the 
> following Pre-start jobs in QSERVER
> PGM(QSYS/QZLSFILE), PGM(QSYS/QPWFSERVSO),
> PGM(QSYS/QPWFSERVSS), 
> PGM(QSYS/QPWFSERVS2), PGM(QSYS/QPWFSTP0),
> PGM(QSYS/QPWFSTP1), 
> PGM(QSYS/QPWFSTP2). Then a ENDHOSTSVR *FILE
>
> 3. Then Restarted in the reverse order.
>
> Now when I attempt to map a folder, I expect the request to
> be rejected.
>
> This does not seem to be happening. Messages sent from the
> program to my
>
> message queue do not seem to go as well.
>
> Where do I start the debugging procedure ? And what do I do
> to debug
> this ?
>
> Thanks and regards,
> Pillai
> -- 
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
>
> -- 
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
>
> -- 
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.