× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Clare...

If it were me... I'd write a separate CL program to accomplish the task, 
then allow that program to adopt the appropriate authorities.  Once 
written and tested the call to that separate program could be added to 
QSTRUP. 
I have a couple of concerns with having QSTRUP adopt authority, first, 
while not extremely volatile, the program does change periodically, and 
everybody that touches it must know to compile it with the correct adopted 
authority, and second, someone could add a call that when started with 
this adopted authority allows an unacceptable level of access to other 
users because of how the initial call was invoked.

Anyway..that's my 2 cents.

Phil



"Clare Holtham" <clare.holtham@xxxxxxxxxxxxxx> 
Sent by: bpcs-l-bounces+phil.catlin=formica.com@xxxxxxxxxxxx
08/25/2006 03:56 AM
Please respond to
"SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>


To
"SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>
cc

Subject
[BPCS-L] QSTRUP and BPCS






Hello fellow BPCS-nauts,

Does anyone have any advice on the prevailing standards for setting up 
security in QSTRUP for access to BPCS? By default QSTRUP runs under QPGMR, 

which doesn't have access to BPCS if the BPCS files library is SSA owned 
but 
Public *Exclude. Or even if it isn't *exclude. If I want a program 
launched 
by QSTRUP to check a data area, say, in the BPCS library, what is the best 

way to allow this? Is it to use adopted authority for QSTRUP using the SSA 

group profile?

thanks,

Clare


----- Original Message ----- 
From: "Al Mac" <macwheel99@xxxxxxxxxxx>
To: "BPCS_L discussion" <bpcs-l@xxxxxxxxxxxx>
Sent: Wednesday, August 23, 2006 6:50 PM
Subject: [BPCS-L] ACP Check Printing Problem


  As I understand the process, before printing on checks whose check #s 
are
  pre-printed on the check stock, our accounting lady tells BPCS what 
check
  # range will be used to pay what vendors, then if everything works
  perfectly, the data on the printed checks agrees with the data in 
BPCS.

  But sometimes she has a printing problem, leading to the check #s that 

got
  printed on, being say a few digits after what BPCS thinks they are.
  Apparently how she has been dealing with this is to scribble on the 
BPCS
  print-outs what check #s end up as, with the data in BPCS never being
  corrected.

  This way of handling things was apparently acceptable until a change 
in
  management, and the need to send copies of some of our BPCS data to
  another system that would appreciate getting correct data.

  How do other companies deal with this scenario?
  Do you void the whole run & start over?  Does BPCS support start over,
  without a big hassle?
  Is there some program option we have overlooked where we can tell BPCS 

...
  all the checks from 45321 onwards dated today need to be incremented 
by 
2.

  If I have to go in there with DFU and muck with the check #s, is there 
a
  list of files affected?

  We are on 405 CD.

  -
  Al Macintyre
  http://en.wikipedia.org/wiki/User:AlMac
  http://www.ryze.com/go/Al9Mac
  BPCS/400 Computer Janitor ... see
  
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
-- 
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

Delivered-To: Clare.Holtham@xxxxxxxxxxxxxx




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.