In the IBM i world, when dealing with High Availability and Disaster Recovery, the history started with software replication, no matter which product you started or are still using, starting the printers has always been one of my concerns. I only wanted the printers to be starting on the production system.
Over the years I have noticed that I am not the only one having this concern. On several occasions I have seen this being solved by not starting the subsystem QSPL on the HA/DR system, but what if you need something to be printed on the HA/DR system? This is where the command CHGIPLA STRPRTWTR(*NONE) comes into place.
As the help text is clearly showing printers are not started when this parameter is set to *NONE. Nonetheless I have seen jobs becoming active in the subsystem QSPL after an IPL of the system. When investigating, the answer was that these jobs were Remote Output Queues.
When defining a Remote Output Queue, the parameter AUTOSTRWTR(1), this causes these jobs to start regardless of the CHGIPLA parameter STRPRTWTR value specified.
In order to get complete control over these Remote Output Queues here is what I did.
Navigator for i helped me getting the SQL statement to retrieve all the Remote Output Queues. 
With this SQL statement as a starting point, I used the following SQL statement in order check where AUTOSTRTWTR(1) was used:
SELECT *
FROM QSYS2.OUTPUT_QUEUE_INFO
WHERE NETWORK_CONNECTION_TYPE = '*IP'
AND WRITERS_TO_AUTOSTART >= 1
AND writer_job_name IS NOT null
With this selection I soon realised I might as well use the active job information SQL service present in the subsystem QSPL to get the job done.
This resulted in:
SELECT JOB_NAME_SHORT,
JOB_TYPE_ENHANCED,
qsys2.qcmdexc('endwtr WTR(' CONCAT JOB_NAME_SHORT CONCAT ') OPTION(*IMMED)'),
qsys2.qcmdexc('DLYJOB 10'), -- give time to end the writer
qsys2.qcmdexc('chgoutq outq(' CONCAT JOB_NAME_SHORT CONCAT ') autostrwtr(*NONE)').
FROM TABLE (
QSYS2.ACTIVE_JOB_INFO(SUBSYSTEM_LIST_FILTER => 'QSPL', DETAILED_INFO => 'WORK')
)
WHERE JOB_TYPE_ENHANCED = 'WRITER'
FETCH FIRST 1 ROWS ONLY
The last statement was added to check first with only one record. Once satisfied with the result you can remove it.
When getting all Remote Writes to start I wanted to use the command STRRMTWTR OUTQ(*ALL). Due to the fact that AUTOSTRWTR was set to *NONE, this no longer works. The *ALL value is linked to that number.
This forced me to go back to the drawing board and resulted in the following SQL procedure which I have added to the startup program of the production system only:
Create Procedure Sqlscripts.Strrmtwtr ()
Language Sql
Specific Sqlscripts.Strrmtwtr
Not Deterministic
Modifies Sql Data
Called On Null Input
Set Option Alwblk = *Allread,
Alwcpydta = *Optimize,
Commit = *None,
Decresult = (31,
31,
00),
Dyndftcol = *No,
Dynusrprf = *User,
Srtseq = *Hex
Begin
/* Declare Command variable */
Declare Fullcmd Varchar(100);
Declare Continue Handler For Sqlexception
Begin
Call Systools.Lprintf(
'Error detected in command ' Concat Trim(Fullcmd) Concat ''
);
End;
Set Fullcmd = 'Nothing done yet.';
/* -------Processing-----------------------------------------------------------------------*/
/* Process Table */
For Vl As C1 Cursor For
Select Output_Queue_Name,
Output_Queue_Library_Name
From Qsys2.Output_Queue_Info
Where Network_Connection_Type = '*IP'
And Number_Of_Writers <> 1
Do
Set Fullcmd = 'STRRMTWTR OUTQ(' Concat Output_Queue_Library_Name Concat '/' Concat
Output_Queue_Name Concat ')';
Call Qsys2.Qcmdexc(Fullcmd);
Call Systools.Lprintf(
Trim(Fullcmd)
);
End For;
End;
Label On Routine Sqlscripts.Strrmtwtr Is 'Start Remote Writers (Remote Output Queues)';
The call to this procedure can be combined with the command STRPRTWTR DEV(*ALL) allowing you to take complete control over what is started in QSPL on the production system and the HA/DR system.
If you do need some printed output on the HA/DR system, now at least you are able to start QSPL and an individual Printer or Remote Output Queue. If you stay away from those used in the Production environment it also opens up the option to replicate spoolfiles.
The worry about things being printed twice is under control.
Being in control! is that not what we are all after as a system manager?
Leave a Reply