×
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.
In our shop, we develop on one i5 and must distribute to several others when
we're ready to install changes in production. Development libraries vary by
programmer and project, but the production libraries into which we install
are always the same. Because of the overhead needed to get updates to all
our locations, we're working to make things more modular and have started
using service programs whenever we can reasonably do so in new development.
In doing this, though, we've run into a problem that I was hoping y'all
could help with.
We had one project developed in JKLIB that added a new module to an existing
service program, PRICESRV, and as such created a new version of the service
program with older modules from our the production mirror library on our
development machine and the one new module from the development library. At
the same time, we were adding a module to the ORDERSRV service program for a
project that was being developed in RFLIB. Some procedures in this service
program call procedures in PRICESRV. When each of these projects was
installed, we replaced the *SRVPGM objects in the production libraries there
with saved copies from our development machine. Everything worked fine, but
the next time we needed to update a module in ORDERSRV at stores, we got the
following error on UPDSRVPGM:
Message ID . . . . . . : CPF5D0D
Date sent . . . . . . : 01/25/10 Time sent . . . . . . : 09:51:22
Message . . . . : Service program PRICESRV not found in library JKLIB.
A little more background if it's needed: we create service programs using
binder source with PGMLVL(*CURRENT) and a signature that matches the service
program name. On our development box, we also have a binding directory
containing all our service programs, and all entries in that have *LIBL
specified for the library. The only time I've ever seen this problem
before, it was because a development library was specified in a binding
directory when modules were created.
All suggestions as to what we might do to correct or get around this problem
are more than welcome. Thanks!
As an Amazon Associate we earn from qualifying purchases.
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.