AS/400 Macros causing program crash/lockup

85 pts.
Tags:
AS/400
AS/400 errors
AS/400 macros
My IT guy at my company is not familiar with using macros, so has been of limited help on this issue. I have some macros setup just to insert a string of letters for item#. Example, LUDCSS4. I have the macro set on the keyboard to Alt+A. They worked fine until the session was changed to fix another problem I was having. With the new session it will periodically crash when using the macros. It will input the keys for that macro, then lockup the program. I have waited quite some time to see if it would catch up, but eventually just had to manually shut it down in Task Manager. So far, we have tried making all new macros, moving the keyboard to the same folder as the macros, and finally making a new keyboard file. Each of those seemed to work fine for a short period of time, but within an hour or so, it was back to causing the crash every 5-10 times a macro was used.


Software/Hardware used:
5.9 for Windows
0

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.

Discuss This Question: 16  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.
  • TheRealRaven
    With the new session it will ... crash ... It will input the keys for that macro, then lockup the program.

    Does it "crash"? Or is it just a "lockup"? The two are very different and would indicate different troubleshooting.

    A "crash" is going to have an *ESCAPE message, possibly with one or more *DIAGs.
    34,465 pointsBadges:
    report
  • ToddN2000
    Why was the session changed for the other problem? That seemed to be the start of your issues. Are these macros defined in Client Access? Are there any custom keyboard maps they may have been corrupted?
    131,645 pointsBadges:
    report
  • randyatDL
    It is locking up with no message. The session was primarily changed because the original session was accidentally set as the same one my manager uses((sparingly)) which was causing the server side of it to lock me out when he was accessing it. I created the macros in the client in VBSscript file format. When I remade the macros, it seemed to work fine for an hour or so when used on the old keyboard file. My IT guy moved the file to be in the same folder, and that seemed to fix it for most of a day or two. When it started happening again, I started a new keyboard and redid all my shortcuts under a new keyboard file. 
    85 pointsBadges:
    report
  • ToddN2000
    Do both sessions now have unique names or are they still using the same device name? It may be that one is locking a file even when they log off. Sometimes connections will remain QZDASOINIT to boost performance on future requests for data. What type of connection is your script using?
    131,645 pointsBadges:
    report
  • randyatDL
    I typically only use one session at a time. 

    Here is the text from one of the macros. I am not a programmer, just handy with the hardware side of things.

    [PCOMM SCRIPT HEADER]
    LANGUAGE=VBSCRIPT
    DESCRIPTION=
    [PCOMM SCRIPT SOURCE]
    OPTION EXPLICIT
    autECLSession.SetConnectionByName(ThisSessionName)

    REM This line calls the macro subroutine
    subSub1_

    sub subSub1_()
       autECLSession.autECLOIA.WaitForAppAvailable
       
       autECLSession.autECLOIA.WaitForInputReady
       autECLSession.autECLPS.SendKeys "LUDSTS4"
    end sub

    85 pointsBadges:
    report
  • TheRealRaven
    Neither WaitForAppAvailable() nor WaitForInputReady() has a timeout value, so both default to "infinite". And neither is tested for success/failure.

    You might consider something like:
    if (autECLSession.autECLOIA.WaitForAppAvailable (10000)) then
        msgbox "Application is available"
    else
        msgbox "Timeout Occurred"
    end if
    That's not a particularly useful coding variant, but it should lead to ideas. Without more info, there's no way we can know the difference between "lockup" and "infinite wait for an event that isn't going to happen".
    34,465 pointsBadges:
    report
  • ToddN2000
    Adding the timeout parameter like Raven mentioned is a good way of debugging a runaway procedure. It allows you to verify whether the step was successful or not. Try it and report your findings back when you can.
    131,645 pointsBadges:
    report
  • randyatDL
    I mentioned not being a programmer, so I am unsure where would be the best place to insert that code.

    I am guessing it would go where  "autECLSession.autECLOIA.WaitForAppAvailable" is locacated.

    Would I just insert it in over this line and between the next line ( autECLSession.autECLOIA.WaitForInputReady)? 
    85 pointsBadges:
    report
  • randyatDL
    Also thanks for the input so far. 
    85 pointsBadges:
    report
  • ToddN2000
    Just replace your 1 line of code listed below

    autECLSession.autECLOIA.WaitForAppAvailable

    with the code Raven listed in their post.

    if (autECLSession.autECLOIA.WaitForAppAvailable (10000)) then
        msgbox "Application is available"
    else
        msgbox "Timeout Occurred"
    end if
    131,645 pointsBadges:
    report
  • randyatDL
    OK. I will give it a try and see what happens. 
    85 pointsBadges:
    report
  • randyatDL
    That causes a popup saying application is available. WIll have to test and see if it crashes it. 
    85 pointsBadges:
    report
  • TheRealRaven
    Note that a similar change should also be made for the WaitForInputReady() line to check its status.

    There might be other changes needed. These are not intended to be permanent in the example forms. At some point, the 'success' branch will no longer be useful. Only the failure would need to be handled, and how it should be handled should be determined by a developer.

    For now, the '
    available' branch of the IF-test is simply a positive indication of success of the function. It doesn't add anything to the purpose of your macro. But the 'Timeout' branch should always be handled in some way. Had it been there in the beginning, the history of this question could be very different.
    34,465 pointsBadges:
    report
  • ToddN2000
    If the timeout occurs you could put in a delay and then loop back to try again as an example. If you continue to have issues, talk to your programmer or IT staff. They might have better debugging skills to resolve your conflict.
    131,645 pointsBadges:
    report
  • randyatDL
    It took a while, but I finally managed to get around to testing the macro((was sent on pickup out of town)). It took a large number of attempts, but it finally locked up. It consistently had the popup for application available, but did not have the Timeout message box. 
    85 pointsBadges:
    report
  • randyatDL
    Tried what the program calls macro format which does this: 

    Description =
    [wait app]
    [wait inp inh]
    "lud#1ro

    instead of the longer program. Main difference seems to be it inputs keys one at a time, and have yet to cause a lockup. 
    85 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.

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

Following

Share this item with your network: