Configure AS/400 to Ethernet printer

15 pts.
Tags:
AS/400
AS/400 Configuration
Ethernet printer
How to configure two AS/400 systems to print to one Ethernet printer.

Software/Hardware used:
as400 mod 270 and as400 720

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    Create device descriptions on the two AS/400s that reference the printer. Vary the devices on, start the writers and put spooled files into the associated output queues. It's not clear what the question is asking (unless the printer is directly attached to one of the AS/400s). Configuring two is the same as configuring one, except you do it twice. Tom
    125,585 pointsBadges:
    report
  • Billb54
    Thats what i did, but in order for one printer to work, i have to vary off the other.
    15 pointsBadges:
    report
  • WoodEngineer
    We have one printer configured on two AS/400's just as Tom describes. The printers are on an ethernet WAN.  The printer configs only use an output queue definition without a device description.

    6,435 pointsBadges:
    report
  • TomLiotta
    A printer definition is always used for programs, even if it isn't created for the actual printer. An output queue is for writers. Some definition attributes of both printer devices and of output queues cross over and define the same things, particularly remote locations. It can take some thought to separate those attributes appropriately. When a program generates the data stream for printer output, it uses the printer definition to know how to insert printer control characters and to know what types of data can be printed. The definition might just be some generic "PRT01" in which case there are more limitations on how well printing can work. It can identify a physical printer by location, though it doesn't have to be correct unless it's the actual location that is used by a writer. A printer definition is almost always needed whether it accurately describes the physical printer or not. An output queue usually simply allows you to organize multiple spooled files into a single area to feed a writer and to control authorities for the entries on the queue. A 'remote' output queue should also identify the location of an entry point for another spooler queue. The cross-over between the two location kinds of attributes is where things often get messed up. If a printer device definition includes a remote location address, it might indicate that there is no effective queueing mechanism in the printer and that only one system should be communicating with the printer at a time. In order for multiple systems to use the printer concurrently, it may be that time-out settings on the systems and on the printer need to be complementary. The systems need to wait long enough for the printer communication port to become available, and the printer needs to close communication with the systems relatively quickly after a file is received. The systems also might need to close the connections on their ends relatively quickly when they finish sending a file. The same timing consideration is less important when 'printer server' functions are available in the printer. Multiple connections can be handled concurrently. Files from multiple systems are queued in the printer's memory and handled by an internal printer spooler. Memory is still used without printer server capability, but the files can usually only be received through a single connection at a time. Until that connection is ended at the printer, a second system can't effectively be accepted by the printer. This kind of printer is usually less expensive and isn't usually intended for access by multiple systems, and almost always it's difficult to manage multiple system connections. As an alternative, one potential way to resolve conflicts is to have only one system actually communicating with the printer. Set up a well defined definition on one system and have a second system route files through the first system. For that configuration, on system A, set up a definition for a printer device that includes remote location. On system B, set up a printer device that defines the general printer characteristics but use a remote output queue that routes to the printer output queue in system A. That lets system A effectively act as the 'printer server' for the printer. That can give both systems the availability of logical printer characteristics for generating a printer data stream plus continuous availability of the physical printer device. It also reduces or eliminates the need for detailed tuning of communication parameters such as time-outs. However, it can require more detailed attention to the attributes that need to be passed between the two systems B to A. Those are at least more likely to be understood by IBM Support. For this question, we need to know at least what kind of printer is used and what its connectivity is. It might also help to know what OS versions are involved. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following