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

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.