Neutro

AS400 tasks automation

6 posts in this topic

#1 ·  Posted

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:

example1.png

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:

example2.png

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 ;)

4 people like this

Share this post


Link to post
Share on other sites



#2 ·  Posted

This is great -  It's cool to see someone else interested in AS400 automation!

A few years ago I developed an application for my employer that automated iSeries and wrote a massive library to operate on these PCOMM classes. I found that using the AutScreenDesc class was a very reliable way of waiting for a screen by first describing it then calling the WaitForScreen() method. Alternatively, the WaitForString() and WaitForStringInRect() methods work just as well.

I also found the SetConnectionByHandle() method was a bit more reliable when dealing with multiple sessions.

I wish I could share the lib, but unfortunately it technically doesn't belong to me :(

Though IBM provides a wealth of knowledge on these classes here and even provide VB example code which makes it super easy to translate into AU3.

2 people like this

Share this post


Link to post
Share on other sites

#3 ·  Posted

Not sure what I will need this for yet, but  I know I will.

Just got assigned t he AS400 and do not know a thing about it.

First things first, gotta go figure out where to get the PTF's and how to install them.

1 person likes this

Share this post


Link to post
Share on other sites

#4 ·  Posted

Welcome to the AS400 world :D

PTFs are the windows updates of AS400, so IBM are providing them ;)

Fyi all moderns AS400 are virtual and run on an IBM hypervisior (the same way a VM runs on ESXi), so I recommend you backup your virtual AS400 image before trying anything ;) 

1 person likes this

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

5 hours ago, Neutro said:

Welcome to the AS400 world :D

PTFs are the windows updates of AS400, so IBM are providing them ;)

Fyi all moderns AS400 are virtual and run on an IBM hypervisior (the same way a VM runs on ESXi), so I recommend you backup your virtual AS400 image before trying anything ;) 

Not ours.  Not one but 2 physical machines :)

and we have a TON of other servers and services that interface it.

Some of those might be virtual, not sure yet.

Edited by ViciousXUSMC

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

13 hours ago, ViciousXUSMC said:

Not ours.  Not one but 2 physical machines :)

and we have a TON of other servers and services that interface it.

Some of those might be virtual, not sure yet.

When you have 2 physical machines, 1 is usually dedicated to business operations and the other one to backup/test.

I find it unlikely that your 2 physical machines are not hypervisors. If they are not then your hardware is most likely kinda old ^^

As i told you by PM you should try to contact IBM support :)

Edited by Neutro

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Similar Content

    • Bennet
      By Bennet
      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.