First, begin recording the transaction.  You'll find that where the splash screen appears, Composer will record a Map Screen with no field counts and no Screen Actions.  In fact, there may be more than one of these "empty" Map Screens generated.  If that's the case, you can delete all but one of them.  Continue recording through the next screen (you could actually continue recording the entire component at this point if you'd like). 

(Action model as generated during record - highlighted area is splash screen)

After you've stopped recording, place a map action in the splash screen.  You'll want to map the entire screen to a temporary DOM, or log.  The idea being, that you will need to identify the value of a field, or a key word that makes the splash screen unique.  Once identified, you will be able to tell Composer to "ignore" any screen that matches the criteria.  Below is an example of the map action required to map the entire screen to a Temp DOM.

Animate or run the component, and check (in this case) the Temp DOM for the contents of the splash screen.

In our example, by double clicking the data portion of the first FIELD we would see the following message (which appears only as a quick flash on the screen):

Choose a field with values that are unique to this screen.  Copy the contents (or a substring) to the clipboard.  Next, disable (or delete) the entire Map Screen (splash screen) from the action model.  Save and exit the component, then open the connection resource the component uses, and press the ADVANCED button.

When the following screen appears, press the plus (+) sign to add a row.  What we want to accomplish, is to identify the splash screen, and send (any) key in response.  You may need to experiment a little to see which dispatch key works best.  Future releases of Composer will have the option of not sending any key at all (which makes the most sense for this type of "self clearing" screen). 

The full value of the expression above is:

ScreenDoc.XPath("SCREEN/FIELD[1]").toString().indexOf("PUBLICACCESS@",0) >-1

I've chosen in this example to search for a sub-string on field number 1, but if the value was smaller, I might have coded something like:

ScreenDoc.XPath("SCREEN/FIELD[1]")=="some value"

Save and close the connection resource.  Now, Composer will automatically send an <enter> whenever it comes across a screen containing the text "PUBLICACCESS@" in field number one.  Although it doesn't seem logical to send a dispatch key to a screen that dispatches itself, the keystroke will be "ignored" by most systems.

If the technique described above doesn't work on your target system, there is one other simple approach to try.  The idea is to identify a constant screen value (label) on either the splash screen or the screen you actually want to be positioned at, then create a loop that checks the value of the field before continuing. 

For instance, many systems have a transaction or program name in the upper left corner of every screen - possibly something like (SKU3).  If there is a splash screen before getting to the SKU3 screen, you would record as normal, then delete or disable the Map-Screen(s) that represent splash screens.  Next, remove the screen-field count on the Map-Screen by double-clicking the Map-Screen action, and un-checking the check box.  Finally, place a "while" loop as the first action of that screen.  The condition of the while will check the value of a field on the screen.  In the example below, the screen will wait until field one has the value "(SKU3)".  The while loop doesn't require any actions, but I've included a counter in my example.  To avoid an endless loop (and wait for a time-out), I will often create a "safety net" by including a raise-error in the loop when the counter reaches a number representing several seconds or minutes of processing time.

There are other methods of handling splash screens, such as timer loops, adjusting the "Delay (ms) / Small Size (bytes)" setting, and other complex logic within components.  Each of these has serious drawbacks, usually in terms of performance, and should be avoided when possible.

To handle any type of unwanted screen, use the Advanced Screen Handling feature found in the connection dialog.  Identify a field (or string within a field) that makes the screen unique, and assign a key to be sent when the field is received.  In the case of a splash screen, the key sent is usually ignored but varies by installation.  An alternative approach of using a while-loop inside your Map-Screen (to test for screen field values) can also be effective.  Try to avoid approaches like timer loops, because amount of time a splash screen is displayed usually varies depending on things like mainframe load.