Resolving The Problem

The Microsoft Windows 2000/XP Task Scheduler runs as a service. It appears to launch the scheduled task under the ID specified in the task properties. It also appears to load that user's registry hive before launching. Note that this behavior is controlled by the Windows Task Scheduler service and, therefore, may not be the same in all versions of Windows or at all service pack levels.

What this implies for Client Access or IBM iSeries Access functions called by the scheduler is that user ID and password must be specified on the Client Access or iSeries Access function (such as a system object) or that Client Access or iSeries Access must be able to read a default user and valid cached password for the specified system. This information is read by accessing HKEY_CURRENT_USER which, for the current version of scheduler, is the user hive for the user that the task is configured to run under. For many other services that do not load the user hive or in cases where no user hive exists for the specified user, HKEY_CURRENT_USER is resolved to the .default hive. The password is cached on the first successful sign-on and is cleared when the hive is unloaded (for example, the user logs off).

Because of the complications involved with cached passwords and Windows services, consider using only functions that accept a user profile and password (such as the Microsoft ActiveX automation objects and APIs). See Rochester Support Center Technote document N1017618, Alternatives to Batch Data Transfer: Data Transfer Automation Objects; Import files with FTP/QNTC; ActiveX Data Objects. To link to document N1017618 immediately, click here.

For iSeries Access batch data transfer to work correctly from the scheduler, a default user profile for the target system must be defined while logged on with the Windows user profile the scheduled task runs under. Do not use Use windows user and password. If that user has not logged on, no password is available. Note that this may appear to work if the user logs on, then off, because logging off does not clear this specific Client Access or iSeries Access cache. Once the default user is defined, create a batch file that first runs cwblogon. Specify the same user ID that is configured as the default user for the target system and the same system name as shown in the iSeries Navigator configuration. This caches the correct password in the registry if the user has write authority to the key (users should have write authority to their own hive). Follow the cwblogon with a call to RTOPCB. Pipe the output to a log file to aid in debug. An additional option is to use RXFERPCB instead of cwblogon with RTOPCB or RFROMPCB.

If an error occurs in this process and the task cannot interact with the desktop, a hidden Client Access or iSeries Access sign-on dialog is generated. This causes the scheduled task to hang and also causes a hang in any other Client Access or iSeries Access function that attempts to sign on that system. The PC must be rebooted or the failing process manually ended.

Example

rem
rem myxfer.bat file for use with Windows scheduler
rem
rem Scheduled task was configured to run under Windows profile NT1
rem While logged on to desktop as NT1, OpNav was used to create a connection to MYAS400
rem MYAS400 was then configured with default user DDILLING
rem

c:\progra~1\ibm\client~1\cwblogon MYAS400  /u DDILLING /p mypwd >> C:\mylog.txt
c:\rtopcb c:\qcustcdt.dtf >> C:\mylog.txt

or (the following command can be run instead of the two lines above)

c:\rxferpcb c:\qcustcdt.dft DDILLING mypwd  >>C:\mylog.txt