Download Notepad File

SNA Distribution Services
SNA Distribution Services
Introduction
1 com05
APPC provides support for Systems Network Architecture Distribution Services (SNADS). This
permits the use of AS/400 CL commands (e.g. SNDNETSPLF, SNDNETF) for copying objects
between peer systems (called object distribution), and is also fundamental to AS/400 Office Mail.
APPN makes the configuration of SNADS simpler, and its running more efficient and resilient,
but is required nowhere in the SNADS network.
© Pacific Associates
Page 4 - 1
DO NOT COPY
SNA Distribution Services
2 com06
SNADS support also enables the AS/400 to participate in
•mainframe document distribution networks, using the RSCS/PROFS Bridge (part of the
AS/400 Communications Utilities licensed program)
•TCP/IP Mail
We will not be giving details of these facilities; the relevant IBM manuals (DSN Admin Guide
and TCP/IP Guide) should be consulted for further information if required.
Page 4 - 2
© Pacific Associates
DO NOT COPY
SNA Distribution Services
Implementation
3 com44
The distribution process
•A user sends a distribution, using Office or one of the object distribution commands, to a
recipient identified by a user id andaddress, each up to 8 characters long
•The recipient is looked up on the system directory to find out whether he is local or remote
•If local, the recipient's user profile is identified, and the distribution is queued for that recipient
as is appropriate to the type of distribution
•If remote, the distribution is placed on a distribution queue
•The SNADS sender job for that distribution queue will eventually forward the distribution
along the first hop in a manually configured route to the remote system; the endpoint of
the first hop will forward the distribution along the next hop, and so on until the correct
remote system is reached
•The remote system's system directory is searched for the recipient
•If found locally, the user profile is identified and the distribution is queued for the recipient on
the remote system
© Pacific Associates
Page 4 - 3
DO NOT COPY
SNA Distribution Services
•If found but remote, the distribution is forwarded
•If not found at all, a distribution failure message is routed to the originator
Route configuration
A SNADS network is configured in a distributed and cooperative manner. Each system needs to
know only the first hop in a route to a remote system it must distribute to; the endpoint of that hop
is responsible for knowing the next hop. Thus the network will need overall management. A fully
APPN network can have this management done automatically by making all routes single-hop
and allowing class of service support to choose the physical route; see later for details.
Describing users
The sender and the recipient must have entries in the system directory.
Entries for local users give their user profiles.
Entries for remote users give the name of the remote system they inhabit, and may be generic (see
later). The remote system name may be an alias called a secondary system name.
Distributions may have multiple recipients, and for convenience these may be collected into a
distribution list.
For AS/400 Office Mail, a user may also have his own personal list ofnicknames for recipients;
we will not be covering these further.
Routing remote distributions
A remote user's system name will be looked up on the SNADS routing table, which gives the
name of the distribution queue relevant to the first hop on the route to the remote system.
This distribution queue is configured using the next system table, which gives all the information
necessary for SNADS to request an APPC session along this hop.
The APPC conversation that processes the distribution queue runs in a SNADS sender job - see
later.
Page 4 - 4
© Pacific Associates
DO NOT COPY
SNA Distribution Services
Hop limit
A particular distribution may be forwarded only until a maximum number of hops has been
reached. This avoids looping. This maximum is kept as a network attribute, but may be
overridden on a particular routing table entry; a system considering forwarding will not allow it if
its relevant locally stored hop limit would be exceeded by the number of hops this distribution
would then have made altogether.
Store-and-forward
One of SNADS' most important attributes is its ability to store distributions at any point along the
route and to forward them when the necessary resources are available. Thus, if an APPC session
cannot be established, or if it terminates abnormally, distributions will simply wait on the
distribution queue until a successful retry is made. Responsibility for such retries is shared;
SNADS will make some retry attempts automatically, but eventually it will be necessary for an
operator to send the queue manually. Further details of the need for such manual intervention are
given later.
This resilience makes SNADS extremely reliable, but the other side of the coin is SNADS'
reputation as a black hole into which distributions disappear, not to be seen again for a very long
time. SNADS uses many objects that are invisible to OS/400, and a user sending a distribution
'successfully' may become concerned when his distribution has not even appeared on a
distribution queue after some little time. Familiarity with SNADS, and faith in its ability to deliver,
help considerably with this, but it must be explained to users that SNADS cannot be expected to
send anything instantly. It is also essential that SNADS is operated properly, in particular that
manual intervention occurs when necessary - see later. Use of a fully APPN network will avoid
a lot of these problems.
Scheduling distributions
Distribution queues may be configured so that transmission occurs only between specified times
of day, and also so that transmission does not start until the queue reaches a specified send depth
(i.e. number of entries). This facility can be used to avoid the use of comms resources for SNADS
during periods of high passthrough use, for example (remember that, however many simultaneous
APPC sessions you allow, SDLC frames are sent down the line one at a time).
© Pacific Associates
Page 4 - 5
DO NOT COPY
SNA Distribution Services
QSNADS subsystem
The IBM-supplied QSNADS subsystem must be started before distribution can occur. It contains
•the QZDSTART job, which starts all the others
•a sender job for each distribution queue
•transaction jobs to handle recipient queuing as appropriate to different types of distribution
•a router job (QROUTER) which carries out system directory lookup and routes a distribution to
a distribution queue (remote) or to a transaction job (local)
SNADS receiver jobs are communications jobs started by program start requests received from
remote senders. They would normally run in QCMN.
It is advisable to make QSNADS start automatically at IPL.
*DLS queues
These are used by AS/400 Office document library services (see later).
*RPDS queues
These are used for the RSCS/PROFS bridge and for TCP/IP Mail.
Auxiliary storage considerations
SNADS will not receive any distribution if the local auxiliary storage threshold would thereby be
exceeded - a useful bargaining counter for the operator!
Page 4 - 6
© Pacific Associates
DO NOT COPY
SNA Distribution Services
Configuration
Authority considerations
SNADS configuration requires *SECADM special authority. If the user does not have this, he is
allowed to change only certain non-fundamental fields of his own directory entry, and may not
change the network configuration at all.
Describing users
System directory
To maintain the system directory, the WRKDIR command is used:
Work with Directory
Position to . . . . .
User ID
Type options, press Enter.
2=Change 4=Delete 5=Display details 6=Print details
7=Assign different ID to description 9=Add new description
Opt User ID Address Description
*ANY NHBVM7 IBM North Harbour
*ANY PACIFIC1 Catch-all for PACIFIC1.
*ANY PACIFIC2 Catch-all for PACIFIC2.
*ANY PACIFIC4 Catch-all for PACIFIC4
*ANY S44A1980 Catch-all for New York.
*ANY WARVM8 West London Commercial
*ANY WINVMD IBM Winchester
*ANY LOND01 Clerkenwell Road.
ARNOLDG PACIFIC3 Graham Arnold on PACIFIC3.
ARNOLDG S44A1980 Graham again
ATHERTR PACIFIC3 Richard Atherton
More...
F3=Exit F5=Refresh F6=Add entry F11=Sort by description F12=Previous
F15=Print directory
4 snads.008
The important fields of the directory entry are
•user id/address
•local user profile name, specified for a local user
•remote system name or alias, specified for a remote user
© Pacific Associates
Page 4 - 7
DO NOT COPY
SNA Distribution Services
•description, which cannot be changed, although you may have more than one description for
the same user id/address
In one special case only, the user profile and remote system name must be specified - see the
Office section later; normally, the user profile field is left blank for a remote user.
There are other fields in the directory entry - address lines, etc. These are provided for user
information only, and a user without *SECADM authority may change them on his own directory
entry.
Generic entries
For remote users, the *ANY option is provided. This has two forms:
•*ANY *ANY, providing a catch-all where all distributions for locally unknown recipients are
forwarded to the same remote system for processing
•*ANY <address>, doing the same for all locally unknown recipients whose address field
matches that specified
The order of checking is: first specific entries, then *ANY <address> entries, then *ANY *ANY
entry.
Directory design
It is necessary to plan carefully how you will configure remote users, since you need to trade off
ease of use for the sender against complexity of configuration and maintenance. Three possible
arrangements are given here, with notes on their advantages and disadvantages.
The low cost option
This involves minimal configuration and maintenance, and hinges on the address field being set
to the system name on which the user is local.
We will use our sample network as an example. One system (Southsea) is central and forwards
distributions as required.
Page 4 - 8
© Pacific Associates
DO NOT COPY
SNA Distribution Services
5 com22
6 com23
Note that Charles Dickens causes problems; because his directory entry is nonstandard, he has to
be configured at Southsea as well as Swindon.
This arrangement has the major advantage of information not being duplicated, involving very
easy directory maintenance. It also minimises the configuration of the network (see later), since
routes are limited to those between the central system and outlying systems; a newly added system
need be configured at the central system only.
© Pacific Associates
Page 4 - 9
DO NOT COPY
SNA Distribution Services
However, it has disadvantages:
•an incorrectly specified recipient with a valid address may not be notified to the sender for
some time, as it will involve looping until the maximum hop count is reached
•if a system name changes, all the local directory entries must be deleted and recreated, which
process involves major Office problems
IBM's suggestion
IBM recommend the following arrangement, where PACIFIC3 is the central system and contains
entries for every user in the network; other systems configure only their own users and route
everything else to the central system for processing, as in the first suggested arrangement.
7 com43
This has the following advantages:
•the same minimal network configuration as in the first arrangement
•the address field is not limited to the system name
•an incorrectly specified recipient will be notified to the sender more quickly than in the first
arrangement
but has this disadvantage:
Page 4 - 10
© Pacific Associates
DO NOT COPY
SNA Distribution Services
•the central directory must be kept up to date, though this can be done automatically using the
API and submitted network jobs (see later for details of these facilities)
Complete directories
In some situations it may be advisable to keep complete directories on all systems in the network.
This is helpful to the user, especially of Office (descriptions are available for remote users, and
incorrectly specified recipients will be notified at send time). However, the maintenance of the
directories, even if automated, can become a major headache, and network configuration becomes
much more complex, since all routes must be configured.
Distribution lists
Distribution lists have names whose format is similar to that of system directory entries. To
maintain them, the WRKDSTL command is normally used:
Work with Distribution Lists
Position to . . . . . __________
List ID
Type options, press Enter.
2=Change entries 4=Delete list 5=Display entries 6=Print entries
Opt ------List ID------ Description
_ ADMIN DEPT Administration department
_ BASING DEV Basingstoke development
_
BASING OFFICE Basingstoke office
_
TELEX TEAM
TX38
development
_
MEMOS HAYLOCR Internal distribution list
2
CONS
DEPT
Consultancy department
_
DEV
DEPT
Development department
_
LONDON OFFICE London Office
_
PACIFIC ALL
Everyone in Pacific
_
SALES
DEPT
Sales and marketing department
_
SALESMTG
SALESMTG List for attendees at Sales Meetings
_
SECURITY OFFICERS Security Officers on
PACIFIC3.
_
STEVENAG
OFFICE
Stevenage office
More...
F3=Exit F5=Refresh F6=Create new lists F12=Cancel
8 wrkdstl
The entries in a distribution list are system directory entries (though they need not be given
explicitly in the local system directory) or the names of other distribution lists.
© Pacific Associates
Page 4 - 11
DO NOT COPY
SNA Distribution Services
Change Distribution List Entries
List ID . . . . . . . . : CONS DEPT
Description . . . . . . : Consultancy department
Position to . . . . .
User ID
Type options, press Enter.
4=Delete entry 5=Display details 6=Print details
Opt User ID Address Description
DAYD PACIFIC3 Drogo Day at PACIFIC1.
HAYLOCA PACIFIC3 Alison Haylock at PACIFIC3
PACIFIC1
NEWMANP PACIFIC3 Paul Newman at PACIFIC1.
SHAWM PACIFIC3 Mandy Shaw at PACIFIC1.
WARBURB PACIFIC3 Bill Warburton at PACIFIC
WEBSTEK PACIFIC3 Karen Webster.
WHEADOM PACIFIC3 Mark Wheadon at PACIFIC1.
LAMBEC
PACIFIC3 Cliff Lambe at
Bottom
F3=Exit F5=Refresh F6=Add entries F12=Previous
9 chgdstl
Interactive maintenance of distribution lists is simplified by the provision of an option to select
from the system directory:
Select Directory Entries
Position to . . . . .
User ID
Type options, press Enter.
1=Select 5=Display details
Opt User ID Address Description
ARNOLDG PACIFIC3 Graham Arnold on PACIFIC1.
ATHERTR PACIFIC3 Richard Atherton
BACONR PACIFIC3 Roger Bacon at PACIFIC1
BANCROD PACIFIC3 Dennis Bancroft
BATAVIS PACIFIC3 Shailesh Batavia
BATESW PACIFIC3 Wendy Bates at PACIFIC3
BENSONJ PACIFIC3 Jeff Benson at PACIFIC1
BERNARJ PACIFIC3 Jenny Bernard
BERRISI PACIFIC3 Ian Berrisford at PACIFIC1.
BERRYE PACIFIC3 Edwin Berry at PACIFIC1.
BESTT PACIFIC3 Tim Best at PACIFIC1.
BLACKI PACIFIC3 Ian Black at PACIFIC1.
More...
F3=Exit F5=Refresh F11=Sort by description F12=Cancel
10 sltdire
Note that
Page 4 - 12
© Pacific Associates
DO NOT COPY
SNA Distribution Services
•you may send to a remotely stored distribution list, if there is an explicit or generic entry
matching its name in your local system directory; the SNADS jobs on the remote system
can handle routing of a received distribution to a distribution list
•the same entry may appear more than once in a distribution list
•if the sender of a distribution himself appears on the distribution list he uses, he will receive a
copy
•distribution lists are system-wide - there is no provision for personal distribution lists
API
The following non-interactive CL commands are provided as an Application Programming
Interface:
•ADDDIRE, CHGDIRE, RMVDIRE for the system directory
•CRTDSTL, DLTDSTL, ADDDSTLE, RMVDSTLE for distribution lists
Configuring the SNADS network
This involves setting up three tables, and must be done using the interactive command
CFGDSTSRV (Configure Distribution Services). The configuration can be viewed but not
changed using the DSPDSTSRV command.
© Pacific Associates
Page 4 - 13
DO NOT COPY
SNA Distribution Services
11 com07
Configure Distribution Services
Type choice, press Enter.
Type of distribution services
information to configure . . . 1
1=Distribution queues
2=Routing table
3=Secondary system name table
F3=Exit
F12=Cancel
12 snads.001
Next system table
This configures distribution queues. For each one, the remote location must be specified as
described in an earlier topic. Distribution queue names are remote location names. APPN and
nonnetworking links are equally acceptable; see later for a discussion of the impact of APPN on
SNADS.
Page 4 - 14
© Pacific Associates
DO NOT COPY
SNA Distribution Services
Configure Distribution Queues
Type options, press Enter.
2=Change 4=Delete 5=Display details
Remote
Remote
Opt Queue Name
Queue Type Location Name Mode Name Net ID
NEWYORK
*SNADS
S44A1980 *NETATR *NONE
PARIS
*SNADS
PARIS
DSPT *LOC
GBIBMH00
*SNADS
D77ZPEMS LU62SYS1 *NONE
PACIFIC1
*SNADS
PACIFIC1 *NETATR *LOC
PACIFIC2
*SNADS
PACIFIC2 *NETATR *LOC
5 PACIFIC4
*SNADS
PACIFIC4 *NETATR *LOC
SYSTEM38
*DLS
PACIFIC1 *NETATR *LOC
LOND01
*SNADS
LOND01 BLANK CITY
F3=Exit F5=Refresh
F6=Add distribution queue
F10=Work with distribution queues
F12=Cancel
13 snads.002
There are two distribution queues for each remote location, a normal priority queue and a high
priority queue. SNADS distributions have four service levels:
•fast, used for user messages
•status, used for SNADS-generated messages (distribution failure messages (see later), Office
delivery confirmations, etc.)
•data high, used for priority Office mail distributions (except messages)
•data low, used for all other distributions
The normal priority queue is used for data low distributions, the high priority queue for all others
(in FIFO order irrespective of service level).
When SNADS is ready to transmit a distribution, it will always take one from the high priority
queue in preference to one from the normal priority queue; but a large normal priority distribution
being transmitted cannot be interrupted by a high priority distribution.
If this is unacceptable, or if you want to subdivide the high priority queue by service level, you
will have to use different distribution queues, i.e. different (physical or logical) remote locations
(see the routing table section, later).
© Pacific Associates
Page 4 - 15
DO NOT COPY
SNA Distribution Services
Display Details of Distribution Queue
Queue name . . . . . . . . : PACIFIC4
Queue type . . . . . . . . : *SNADS
Remote location name . . . : PACIFIC4
Mode name . . . . . . . . . : *NETATR
Remote net ID . . . . . . . : *LOC
Local location name . . . . : *LOC
Normal priority:
Send time:
From/To . . . . . . . . : 0:00 23:59
Force . . . . . . . . . : :
Send depth . . . . . . . : 1
High priority:
Send time:
From/To . . . . . . . . : 0:00 23:59
Force . . . . . . . . . : :
Send depth . . . . . . . : 1
Press Enter to continue.
F3=Exit
F12=Cancel
14 snads.003
Note the distribution scheduling fields on this display. The default is for distribution to occur 24
hours a day and to be initiated as soon as a distribution appears on the queue (i.e. send depth 1).
You can leave the scheduling fields untouched, and will then get these defaults.
The force time is a time at which the queue will be sent completely anyhow, whatever its current
depth.
If you specify a blank send depth and no force time, transmission will never occur automatically,
and you must use the SNDDSTQ command or its equivalent (see later).
There is a second distribution queue detail display (PAGE DOWN from the first one) allowing
you to specify retry information (see later), and also to specify that the queue should be sent fully
automatically when a distribution is received from the relevant remote location (useful with a
switched connection).
Page 4 - 16
© Pacific Associates
DO NOT COPY
SNA Distribution Services
Routing table
Configure Routing Table
Type options, press Enter.
2=Change 4=Delete 5=Display details
------System-----Opt Name Group
Description
PARIS
5 GBIBMH00
Screenmail.
PACIFIC1 PACIFIC S/38.
PACIFIC2 PACIFIC B30.
PACIFIC4 PACIFIC B20.
S44A1980
LOND01
Clerkenwell Road.
F3=Exit F5=Refresh
F12=Cancel
F6=Add routing table entry
15 snads.004
This defines the initial hop of the route to each remote system mentioned in the system directory.
Display Details of Routing Table Entry
Destination system
name/Group . . . . . : PACIFIC4 PACIFIC
Description . . . . . : B20.
Service level:
Fast:
Queue name . . . . : PACIFIC4
Maximum hops . . . : *DFT
Status:
Queue name . . . . : PACIFIC4
Maximum hops . . . : *DFT
Data high:
Queue name . . . . : PACIFIC4
Maximum hops . . . : *DFT
Data low:
Queue name . . . . : PACIFIC4
Maximum hops . . . : *DFT
Press Enter to continue.
F3=Exit
F12=Cancel
16 snads.005
The initial hop is specified by giving the relevant distribution queue name. You have the option
of configuring different routes for different service levels (see earlier). At this point you may also
override the hop limit on the network attributes.
© Pacific Associates
Page 4 - 17
DO NOT COPY
SNA Distribution Services
The effect of APPN
APPN links within a SNADS network allow you to configure hops between non-adjacent systems.
It will be seen that in a fully APPN network each remote system can be reached in one hop; thus
routing is under APPN control and need not be configured manually.
In our sample network, there is only one route from Swindon to Southsea:
17 com24
so network configuration will be the same whether or not the link between these two systems is
APPN-capable.
Page 4 - 18
© Pacific Associates
DO NOT COPY
SNA Distribution Services
However, there are two possible routes from Southsea to Ipswich. If we assume that the direct
route uses a switched link, the other route two nonswitched links, then obviously the only sensible
non-APPN network configuration is:
18 com26
If the Margate system goes down, routing from Swindon or Southsea to Ipswich is not possible in
the non-APPN case unless the network configuration of the Southsea machine is changed
manually.
© Pacific Associates
Page 4 - 19
DO NOT COPY
SNA Distribution Services
However, if the network is fully APPN, APPN class of service support for the route to Ipswich
will select the switched link when it needs to:
19 com25
Secondary system names
Configure Secondary System Name Table
System: PACIFIC3
To add, type choices, press Enter.
To delete, blank system name and group, press Enter.
--Secondary System-Name Group Description
PACIFIC3 PACIFIC B50.
F3=Exit
F5=Refresh
F12=Cancel
20 snads.006
Configuring secondary (alternative) system names for your system allows remote systems to refer
to your system using an alias rather than the system name in your network attributes. You need not
Page 4 - 20
© Pacific Associates
DO NOT COPY
SNA Distribution Services
set up any secondary system names.
© Pacific Associates
Page 4 - 21
DO NOT COPY
SNA Distribution Services
Object distribution
21 com08
Objects that may be distributed are:
•messages
•spool files
•files
•documents
•job streams
Page 4 - 22
© Pacific Associates
DO NOT COPY
SNA Distribution Services
22 com09
Messages
Messages are sent using the SNDNETMSG command or the AS/400 Office mail message
facility. They are distributed using a service level of fast, and are placed on the recipient's user
profile message queue. If the user profile has no message queue (unusual on the AS/400), the
distribution fails and the sender is notified of the failure.
Received messages can therefore be processed using the DSPMSG command, and can be
displayed automatically to the user on receipt if the user profile message queue has break delivery.
Office mail messages are placed on the Office incoming mail log as well.
Messages generated by SNADS itself (e.g. distribution failure) undergo similar recipient queuing
(except for Office delivery confirmations, which are used to update the Office outgoing mail log).
Here, however, an absent user profile message queue results in the message being placed on the
default message queue from the network attributes.
Spool files
These are sent using the SNDNETSPLF command, and are distributed using a service level of
data low. They are placed on the recipient's user profile output queue (N.B. the user profile printer
device is not used by SNADS), or on the default output queue (from the network attributes) if the
user profile has no output queue. Status messages will be sent to the sender and to the recipient
notifying them of the spool file's arrival.
© Pacific Associates
Page 4 - 23
DO NOT COPY
SNA Distribution Services
Attributes describing the physical output (form type, number of copies, lines per inch, etc.) are
passed across with the spool file. Attributes describing the system's handling of the spool file
(hold, save, etc.) are not passed across and are obtained from the QSYS/QSYSPRT printer file on
the recipient's system.
Received spool files can always be found using the WRKSPLF QSNADS command if
necessary.
Note that spool files containing special device requirements cannot be distributed. This will be
found to apply to printed Office documents where, for instance, typestyle changes are present. If
Office is installed on the recipient system, it is possible to get round this problem using the Office
indirect user facility - indirect users have no interactive access to Office and their mail is placed
on an output queue automatically.
Documents
AS/400 Office mail allows you to send documents and notes (memos). These are distributed
using a service level of data low, and are placed on the recipient's incoming mail log. See the
Office Setting Up and Administering Guide for further details.
Distributing files
Files (network files) are sent using the SNDNETF command, and are distributed using a service
level of data low. Status messages will be sent to the sender and to the recipient notifying them of
the file's arrival.
Note that only raw data is sent, i.e. no access paths, no record format/field information, no
file/member descriptions, no source member SEU types. Only physical file members and
savefiles (see later) may be sent. The maximum file size is 2GB - but note that on the S/38 and on
AS/400 before release 2 the maximum was 16MB, and this may be relevant to your network.
Files queued for a recipient must be received using the RCVNETF command into an already
existing file (members can be replaced or added automatically). Savefiles must be received into
savefiles, physical file members into physical file members.
Network files have the name of the sent file, but are also given a unique identifier (to some extent
analogous to that on a spool file), to allow exact specification of the file to be received on the
RCVNETF command. The user may use the WRKNETF command to list any files sent to him
that are ready for receiving; this command has a RCVNETF option, and also allows display or
deletion of distributions. The security officer may work with any user's network files, but other
users may work with their own network files only. Alternatively, receipt can be automated,
typically using a submitted network job (see later) immediately following the file distribution.
Page 4 - 24
© Pacific Associates
DO NOT COPY
SNA Distribution Services
Distributing savefiles
This is an extraordinarily powerful facility. It will be seen that it in fact allows distribution of any
AS/400 object that can be saved to a savefile.
It is possible to maintain software on remote sites without operator intervention - application
objects can be downloaded using savefile distribution, and received and restored automatically
using a submitted network job (see later). PTFs can be distributed, loaded and applied
automatically. Operator intervention would be required only for installation of new OS/400
releases.
It must always be remembered, however, that distribution of large savefiles takes a long time. A
line running at 9600 bps would transfer only about 4MB in an hour; even if there were only the
one APPC session running, only perhaps 3MB could be savefile data, because of the SDLC, LU
6.2 and SNADS overheads. Use of DTACPR(*YES) on the save command may help
considerably, and may make it worth saving even physical file members to savefiles for
transmission.
Of course all the usual limitations on restoring saved information apply. You will find that you
cannot even receive a nonempty savefile into one created on a backwards incompatible release
(though you can use the save command TGTRLS parameter to permit downloading of objects to
a system with the previous release installed).
Running jobs remotely
Job streams may be distributed using the SBMNETJOB command, and are sent using a service
level of data low. Their handling on the recipient's system depends on two things:
•the JOBACN network attribute
•the network job entry table
© Pacific Associates
Page 4 - 25
DO NOT COPY
SNA Distribution Services
JOBACN
This has three settings:
•*FILE (the default) - the job stream is treated like any other received physical file member, i.e.
queued as a network file for processing by the recipient
The recipient can process the job stream using the WRKNETF command. He may receive it as
described earlier, or may submit it to a job queue, where it runs under the user profile of
the interactive job that invoked WRKNETF, unless the BCHJOB command in the job
stream overrides this; unless the job queue to be used is specified explicitly in the job
stream BCHJOB command, the job description stored on this interactive job user profile
gives the job queue to be used.
•*REJECT - the distribution fails
•*SEARCH - the network job entry table is used for all job stream handling
Network job entry table
This is relevant only with the JOBACN(*SEARCH) setting, and is processed using the
WRKNETJOBE command (API CL commands, e.g. ADDNETJOBE, are also provided).
Work with Network Job Entries
Network job action . . . . . . . . : *SEARCH
Type options, press Enter.
2=Change network job entry
4=Remove network job entry
Opt User ID Address Action User
*ANY *ANY *SUBMIT QPGMR
F3=Exit F5=Refresh
F11=Display job queue
----Message Queue---*USRPRF
F6=Add network job entry
F12=Cancel
23 wrknetj.001
Page 4 - 26
© Pacific Associates
DO NOT COPY
SNA Distribution Services
It describes the handling of job streams sent to different recipients. For each recipient (*ANY
address and *ANY *ANY are allowed) jobs may be
•*REJECT - rejected (as for the JOBACN(*REJECT) setting)
•*FILE - filed (as for the JOBACN(*FILE) setting)
•*SUBMIT - submitted automatically to a job queue; the sender and recipient are notified of this
via status messages; the user profile and job queue for the submitted job are obtained from
the network job entry unless overridden by the BCHJOB command in the job stream
© Pacific Associates
Page 4 - 27
DO NOT COPY
SNA Distribution Services
SNADS operation and error handling
As mentioned previously, SNADS will require operator intervention at times, although this can
be minimised by careful directory design and network configuration and by making the QSNADS
subsystem start automatically.
SNADS sender retries
When a link fails, the relevant SNADS sender job will retry transmission a configured number of
times at configured intervals of minutes. If APPN class of service support is active, a new route
will be activated, if appropriate, only at the next retry opportunity. Once the retry limit is reached,
transmission will start again only if forced by the operator. This forcing can be done using
WRKDSTQ/SNDDSTQ (see later), or by ending and restarting the QSNADS subsystem, or by
varying the APPC device off and on again.
Distribution queue processing
The WRKDSTQ command displays the current status of the configured distribution queues:
12/04/90 14:52:39
Work with Distribution Queues
Type options, press Enter.
2=Send queue 3=Hold queue 5=Work with queue entries
6=Release queue 7=Reroute queue
Queue -----Send Time------ -Queue DepthOpt Queue Name
Priority From To Force Send Current Status
NEWYORK
Normal : - : : 1 0 Ready
NEWYORK
High
: - : : 1 0 Ready
PARIS
Normal : - : : 1 0 Ready
PARIS
High
: - : : 1 0 Ready
GBIBMH00
Normal : - : : 1 0 Ready
GBIBMH00
High
: - : : 1 0 Ready
PACIFIC1
Normal 0:00 - 23:59 : 1 0 Ready
PACIFIC1
High
0:00 - 23:59 : 1 0 Ready
5 PACIFIC2
Normal : - : : 1 5 Ready
PACIFIC2
High
: - : : 1 1 Ready
PACIFIC4
Normal 0:00 - 23:59 : 1 0 Ready
PACIFIC4
High
0:00 - 23:59 : 1 0 Ready +
F3=Exit
F5=Refresh
F12=Cancel
24 dstq.001
Page 4 - 28
© Pacific Associates
DO NOT COPY
SNA Distribution Services
12/04/90 14:52:48
Work with Queue Entries
Distribution queue name . . . . . . . . . . . : PACIFIC2
Distribution queue priority . . . . . . . . . : Normal
Type options, press Enter.
2=Move to high priority queue
6=Release 7=Reroute
3=Hold 4=Delete
---Originating---Sequence
Opt User ID Address Date Time Number Status
KENNEDR PACIFIC3 06/03/90 17:34:55 0070 Ready
KENNEDR PACIFIC3 06/03/90 17:27:29 0065 Ready
KENNEDR PACIFIC3 06/03/90 17:27:44 0066 Ready
KENNEDR PACIFIC3 06/03/90 17:31:41 0068 Ready
KENNEDR PACIFIC3 06/03/90 17:31:59 0069 Ready
F3=Exit
F5=Refresh
F12=Cancel
25 dstq.002
and can be used to force sending of queues, to delete distributions, etc.
SNDDSTQ, HLDDSTQ and RLSDSTQ API commands are also provided.
Distribution logging
QSNADS journal
All distributions, successful and unsuccessful, are logged in a special journal. The format of
QSNADS journal entries is given in the DSN Admin Guide, and the journal may be accessed by
application programs. Note that the journal receiver is not changed automatically.
© Pacific Associates
Page 4 - 29
DO NOT COPY
SNA Distribution Services
DSPDSTLOG
This command formats the SNADS journal into more operator-friendly displays:
Display Distribution Services Log
Type options, press Enter.
5=Display details
Function Entry ------Logged---------Originator---- Seq
Opt Type Type Date Time Job Name User ID Address Nbr
5 *RCV *NRM 12/04/90 12:30:13 MSAS1
CRV/SYS PARIS 0001
*RTR *NRM 12/04/90 12:30:33 QROUTER CRV/SYS PARIS 0001
5 *RTR *ERR 12/04/90 12:30:57 QROUTER GRIBBLD PACIFIC3 2553
*RTR *NRM 12/04/90 12:30:57 QROUTER GRIBBLD PACIFIC3 2553
F3=Exit
F12=Cancel
26 dstq.003
Display Distribution Services Log Entry
Function . . . . . . . . . . : Distribution received
Job . . . . . . . . . . . . : 286850/QUSER/PARIS
Date/Time . . . . . . . . . : 12/04/90 12:30:13
Originator:
User ID/Address . . . . . : CRV/SYS PARIS
System name/Group . . . . : PARIS
Sequence number . . . . . . : 0001
Origin date/Time . . . . . . : 12/04/90 12:25:05
Press Enter to continue.
F3=Exit
F12=Cancel
F14=Display correlation IDs
27 dstq.004
Page 4 - 30
© Pacific Associates
DO NOT COPY
SNA Distribution Services
Display Error Log Entry
Function . . . . . . . . . . : Routing distribution
Job . . . . . . . . . . . . : 286523/QSNADS/QROUTER
Date/Time . . . . . . . . . : 12/04/90 12:30:57
Originator:
User ID/Address . . . . . : GRIBBLD PACIFIC3
System name/Group . . . . : PACIFIC3
Sequence number . . . . . . : 2553
Origin date/Time . . . . . . : 12/04/90 12:30:56
SNADS status
code . . . . . . . . . . . : 0002 Invalid user ID
Error recipient:
User ID/Address . . . . . : CRV/SYS PARIS
System name/Group . . . . :
Press Enter to continue.
F3=Exit
F12=Cancel
F14=Display correlation IDs
28 dstq.005
© Pacific Associates
Page 4 - 31
DO NOT COPY
SNA Distribution Services
AS/400 Office
For interest, a very brief summary of Office functions relevant to SNADS is given here - we
cannot cover them in detail, and you are advised to consult the relevant IBM manual (Office
Setting Up and Administering Guide) for further information if required.
Mail
Distributions (messages, notes (memos) or documents) may be sent from Office either
interactively or using the CL SNDDST (Send Distribution) or SNDDOC (Send Document)
command.
Recipient queuing involves placing distributions in the user's Office incoming mail log; messages
will also be placed on the user profile message queue.
Document library services
It is possible to access the documents on a remote system from AS/400 Office using the document
library services facility. A document library services queue (distribution queue type *DLS) is
created. Document search requests can then be placed on this queue for distribution to the remote
system. The remote system produces a document list which is then sent back to the local system
for review by the user. The user can also request an actual remote document. Because these
automatic reply operations need a remote sender, the user must have a user profile in his remote
system directory entry as well as the system name. (This is the only case where both should be
specified.)
Users may request a local document to be filed remotely - this also uses the *DLS queue.
Page 4 - 32
© Pacific Associates
DO NOT COPY
SNA Distribution Services
References
SC41-9588
IBM AS/400 Communications: Distribution Services Network Guide
SC41-9626
IBM AS/400 Office: Planning for and setting up OfficeVision/400
SNA: IBM's networking solution, James Martin and Kathleen Kavanagh Chapman, Prentice-Hall,
1987
© Pacific Associates
Page 4 - 33
DO NOT COPY