Remote OUTQ to another AS/400
John Dunn
We use Broderick Data Systems Spool Organizer/400 to
bundle/distribute/archive spool output on our production AS/400. The
dilemma: When jobs run on our second production system are sent via
remote OUTQ/SNADS to our main production system running Broderick, the
job looses it's name and becomes QPRTJOB, just like SNDNETSPLF (which
remote SNADS outqs use). Broderick is keyed to look at the job name
(which was AR_STMTS) and determine how to bundle/distribute/archive the
spool files. How do I preserve the job name "AR_STMTS" that came from
the second system when SNADSing it via remote outq to the Broderick
production system??
This came about because we migrated non-updating jobs for our
daily/weekly/monthly jobstream from our main production system to our
second production system to speed up processing. We are using OMS/400
to mirror data to the second system and once the daily/weekly/monthly
updating jobs finish, the nonupdating jobs kick off on the mirror
system, freeing up the main production system. The output is then
SNADSed back to the main production system for
bundling/distributing/archiving, but lacks the correct job name which
Broderick keys on.
OSITim
To solve your dilemma you are going to have to bypass SNADS altogether as the
transport mechanism for you spooled files. The method we use in our shop
follows the steps.
1. On one AS/400 you will need to have a server job polling an output queue.
2. When an entry arrives on the queue, use the spooled file API's to retrieve
the spooled file attributes into a user space and the spooled file data into
another user space.
3. Use the SAVRSTOBJ command to save the user spaces to the remote AS/400
4. Then use the SBMRMTCMD to execute the SBMJOB command. The job name and user
name should be what you want the spooled files to be created under. The RQSDTA
should invoke a program that receives the user space names as parameters.
5. The program called on the RQSDTA of the SBMJOB command that was executed by
the SBMRMTCMD. Should then use the spooled file API's to create spooled files
with the attributes of the original and to copy the data from the user space.
If you want details of this method send me an e-mail and I can send you some CL
examples of a program that does something similar to what you are needing.
Charles R. Pence
OSITim wrote:
>
> To solve your dilemma you are going to have to bypass SNADS altogether as the
Sure... but wouldn't it be easier to just ask Broderick for a change to
enable keying from the USRDTA value instead <for example>? Seems like a
lot less work for everyone if their provider is willing to make the
change. Then all they have to do is override or change their spool file
to have the USRDTA value equate with the JOB name.
Regards, Chuck
-- Comments provided "as is" with no warranties of any kind whatsoever.
OSITim
Have you ever asked a software vendor for a change? In addition to waiting for
six months for it, there are ususally exorbitant costs.
Furthermore, the change you are suggesting doesn't really fix the problem, he
still has to go modify all his programs to plug the USRDTA correctly. And what
if they are using the USRDTA for something else?
Finally, the solution I offer is generalized, it works now, and requires no
change to how reports are generated.
John Dunn
Broderick DOES allow you to key on USRDTA. The problem is the sheer volume of
changes required to our production programs to put something into USRDTA and then
the sheer volume of modifications to Broderick. In talking to Broderick, they
made me aware of another package they sell called Remote Spool Print 3X/400/370
which (probably) uses the method specified by OSITim to preserve User Name/Job
Name. I have presented both options to my boss (write something in-house or
purchase the Broderick offering).
Charles R. Pence wrote:
> OSITim wrote:
> >
> > To solve your dilemma you are going to have to bypass SNADS altogether as the
> > transport mechanism for you spooled files. <<SNIP>>
>
Charles R. Pence
OSITim wrote:
>
> Have you ever asked a software vendor for a change? In addition to waiting
Heh heh... Good point. Code around it and keep their software...
everybody is happy <enough> and making money, or otherwise getting stuff
done <g>. Strange that it seems to always work that way. :-(
However the provider maybe can give a solution via USRDTA, spool file
owner, or perhaps USRDFNOPT; and so possibly still worth the asking.
Could be they already have the feature and it's just too new or
difficult to find.
Charles R. Pence
John Dunn wrote:
>
> Broderick DOES allow you to key on USRDTA. The problem is the sheer volume
> of changes required to our production programs to put something into USRDTA
If you can use a data queue method vs the SNA/DS remote OUTQ, you could
have a program which gets the job name and modifies the USRDTA to match
and then SNDNETSPLF to the production system for receipt by the
Broderick app keyed on the USRDTA. Does the Broderick app allow you to
setup a separate environment whereby one is keyed by USRDTA and the
other by JobName? If so then this saves a lot of extra data movement
<still just the send>, programming <only the monitor OUTQ, mod USRDTA,
and SND vs rtv/rtv/savrstsnd/sbm/spl>, and program mods to production
code; leave the current setup and add the new one keyed by USRDTA.?.?
FWiW.
Kevin Drewett
John Dunn wrote:
> We use Broderick Data Systems Spool Organizer/400 to
> bundle/distribute/archive spool output on our production AS/400. The
> dilemma: When jobs run on our second production system are sent via
> remote OUTQ/SNADS to our main production system running Broderick, the
> job looses it's name and becomes QPRTJOB, just like SNDNETSPLF (which
> remote SNADS outqs use).
What version OS/400 are running? We have this problem on our version 2.3
system
but have eliminated it on oour V3/V4 systems.
If you are running V3 and above check that you have entries in your system
distribution
directories for user QNETSPLF for both your systems, and also we changed
the default
from *recdata to *alldata on the sndnetsplf command.
All our reports sent via remote outq's or the sndnetsplf command maintain
all their
attributes on the target machine including report names, userid's user data
etc.
regards
Kevin
Kevin Drewett
Kevin Drewett
Kevin Drewett
Kevin Drewett
Charles R. Pence
Kevin Drewett wrote:
>
> John Dunn wrote:
>
> > We use Broderick Data Systems Spool Organizer/400 to
> > bundle/distribute/archive spool output on our production AS/400. The
> > dilemma: When jobs run on our second production system are sent via
> > remote OUTQ/SNADS to our main production system running Broderick, the
> > job looses it's name and becomes QPRTJOB, just like SNDNETSPLF (which
> > remote SNADS outqs use).
>
>
> All our reports sent via remote outq's or the sndnetsplf command maintain
> all their attributes on the target machine including report names, userid's > user data etc.
> regards
> Kevin
But the noted concern was the JOB name which becomes as noted:
QPRTJOB.?.?