Did you also install the SPX_005 one-off?
And did you by chance install the SPX_005, run JDEUPDATE, then instal F1,
run JDEUPDATE again?
I have found that the above order of operations caused the JDENET_K to fail
to start with E1.
However, reversing the order of installation, E1, JDEUPDATE, SPX_005,
JDEUPDATE works without a hitch.
It has to do with the fact that the JDEUPDATE following E1 updates all
'appropriate' *SRVPGM objects in B7334SYS library with new information
(program signatures or some such nonsense). One of the updated *SRVPGM
objects is JDENET_K.
Now, when E1 was installed, it delivered a new JDENET_K. This new JDENET_K
knows nothing about the SPX_005 enhancements that were communicated via the
previous JDEUPDATE. The E1 JDEUPDATE utility updates all the 'appropriate'
*SRVPGM objects with new information about the JDENET_K.
BUT it fails to consider those objects delivered with SPX_005, as not all
customers install this little gem. Therefore, when the E1 JDENET_K program
attempts to start and use the SPX_005 objects, it pukes due to unexpected
patched code.
Reversing the installation order, allows the E1 JDENET_K process to receive
the 'knowledge' about the SPX_005 enhancements prior to starting.
I can only assume this is the same problem you encountered with F1.
Determined this during some gut wrenching, anxious moments examining the job
log produced by the JDENET_K.
The good news is that, if done properly, this WILL solve the printing
problems you are experiencing.
Brent Marxhausen
DBT, Inc.
Independent CNC Consultant
email:
[email protected]