Search the Community
Showing results for tags 'IBM'.
Found 3 results
Hi all, this is very specific. I'm an administrator for several IBM i Power mainframe servers that run i5/OS and people use the Client Access Software. For now I've been using the Host Access Class Lib in my AutoIt Scripts on Client Access to automate most of my tasks. The essential code lines are this: After this you can use the methods listed here to remote-control your Client Access session. Much like a macro. This worked fine for the Client Access software. Now IBM released their new IBM i Access Client Solutions and I can't get it to work with it. Does anyone have any experience with this already by chance?
Hey guys! Here are some informations on how to automate AS400 tasks with AutoIT. AS400 are mainframes made by IBM and used mainly in professional workplaces. First you need to launch an IBM Iseries console to the AS400. It looks like this: As it is a regular window, you can use the "AutoIT Window Info" tool and functions like "ControlSetText", "ControlClick" to automate the login process. Notice that the name of the window (in the top left of the above screenshot) is "Session A". This is because it is the first Iseries window that is opened on the client computer. If you do not close it and open another one, the next one will be named "Session B". The third one "Session C"... Once you're logged into the Iseries console interface, the OS400 login window shows up: Use this code to create an autoIT object linked to the iseries console: global $oOIA = ObjCreate("PCOMM.autECLOIA") $oOIA.SetconnectionByName("A") global $oPS = ObjCreate("PCOMM.autECLPS") $oPS.SetConnectionByName("A") The letter "A" is a reference to the name of the session displayed in the iseries console window, as explained before. Change it to another letter if you have multiples iseries console windows opened at the same time. Then there are 3 main functions that you can use to interact with the interface: $oOIA.WaitForInputReady() ;waits for the interface to be ready for input. $oPS.SetCursorPos(6, 53) ;put the cursor of the interface to position X = 6, Y = 53 $oPS.SendKeys("hello world[enter]") ;write the text "hello world" where the cursor of the interface is then press the enter/return key $result = $oPS.SearchText("banana") ;search for the text "banana" on the interface screen. Returns "True" if found, "False" if not. The function "WaitForInputReady" is badfully not very reliable. For better results, use the fuction "SearchText" in a while loop to wait for a specific text to appear on the interface if you want to be sure that the interface is ready for input. With these 3 functions you can pretty much do anything you would do manually on an Iseries console. Special keys for the "SendKeys" function can be found using the virtual keyboard included in the iseries console software. Enjoy
I'm actually really proud of myself today. I'm always keen on using AutoIT wherever I can, as I've been developing in it since the age of 14 and whenever I meet any new technical staff or developers at the different clients I visit it always gets a mention and a demonstration. So we had a minor problem today at one of our clients, whereby they had an existing Windows Service implemented with a config file but the source-code was missing, which limited the ability of our company to enhance the interface in any way. Now considering the fact that I was paid to develop this I will refrain from divulging any company names or "secrets" as, of course, there are clauses in my contract that state that my work belongs to them. I am however a SAP ABAP developer by trade so anything that falls outside of the defined limits of this trade I can technically share, but regardless I'll keep the information limited. So the requirement was to pull data from IBM Websphere, write it out to a file and post it into SAP through a custom built RFC. It turned out to be much less complicated than I imagined and through the research on these forums, I had discovered that similar things had been attempted but that nothing concrete had been written for AutoIT specifically (The MQ part, not the SAP part). So without further adieu I present my thinking. I started out with the IBM Websphere dll using DllOpen and DllCall. After a few frustrating attempts at creating COM objects through the DLL Call. I finally discovered that there was another dll that I could register using regsrv32. It was called MQAX200.dll Once this dll was registered on the system I could access the following piece of code; EnvSet("MQSERVER", $iniServer) ;MQ Server Environment Variable $MQSess = ObjCreate("MQAX200.MQSession") $QMgr = ObjCreate("MQAX200.MQQueueManager") $QMgr = $MQSess.AccessQueueManager($iniQM) ;Queue Manager ConsoleWrite("Connected" & @CRLF) After this was complete and I successfully tested my connection I added the following to read from MQ; $Queue = $QMgr.AccessQueue($iniQueue, 2) ;Queue (2=MQOO_INPUT, 16=MQOO_OUTPUT) While 1 $GetMsg = $MQSess.AccessMessage $GetOptions = $MQSess.AccessGetMessageOptions $Queue.Get($GetMsg, $GetOptions) If $Queue.ReasonCode = 2033 Then ;When there aren't any new messages sleep for 2 seconds. Sleep(2000) Else #EndRegion Accessing MQ #Region Write File $MsgData = $GetMsg.MessageData .... I then wrote this out to a file and attempted my SAP connection using the following code; Dim $LoggedIn = False $oConnection = $LogonControl.NewConnection $oConnection.System = $System $oConnection.ApplicationServer = $AppServer $oConnection.SystemNumber = $SysNumb $oConnection.User = $User $oConnection.Password = $Password $oConnection.Client = $Client $oConnection.Language = $Language $LoggedIn = $oConnection.Logon(0, True) Return $LoggedIn which resulted in failure as the SAP COM object wasn't registered on the system. After attempting to register the correct object without installing SAP GUI, I ended up with a slightly different solution for an executable supplied by SAP called startrfc.exe; $foo = Run(@ComSpec & " /c " & $RFCExec & " -3 -h " & $AppServer & " -s " & $SysNumber & " -F " & $RFC & " -u " & $User & " -p " & $Password & " -c " & $Client & " -l " & $Language & " -E FNAME=" & $FilePath & " -E PNAME=" & $Program, "", @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD) While 1 $line = StdoutRead($foo) If @error Then ExitLoop ConsoleWrite($line) $LogFile = FileOpen(StringReplace($FilePath, "\In\","\Logs\"), 2) FileWrite($LogFile, $Line) FileClose($LogFile) FileMove($FilePath, StringReplace($FilePath, "\In\","\Out\")) WEnd While 1 $line = StderrRead($foo) If @error Then ExitLoop ConsoleWrite($line) $ErrFile = FileOpen(StringReplace($FilePath, "\In\","\Errors\E"), 2) FileWrite($ErrFile, $Line) FileClose($ErrFile) FileMove($FilePath, StringReplace($FilePath, "\In\","\Errors\")) WEnd One last piece of code that you should keep in mind if you attempt this so that your program doesn't stop when a COM error is returned (MQ returns an error that indicates there is no data available on the queue as you see with the reason code check earlier); Global $oErrorHandler = ObjEvent("AutoIt.Error", "_ErrFunc") ;Catch COM errors In conclusion, I really enjoyed implementing something that'll be used for the foreseeable future at a powerful company and writing it in my favorite language. I hope you find some use in these snippets. This will be running as a Windows Service from now on using srvany.exe.