Part 4: At last, something useful!

As we learned last time, the abt.cnf file is really just a Smalltalk script. However, it’s executed when the image is first started; that is, before any code has really been loaded by the VM. I’ll be referring to the abt.cnf file created by AbtStartupApp class>>#setupUpEnvironment for the rest of this discourse.

I like to start with a virgin image. Since we all load our images fresh on a daily basis, we’re all intimately familiar with the drill: First we have to identify the owner of the image (usually it’s you), and then we have to let the image pointers get recached. Then we can get down to some useful work. Since this script is generic, we’ll make no assumptions about what users might be in the repository. We know that every repository has a Library Supervisor, so we’ll just assign image ownership to her for now.

The first two lines of code are:

EmLibraryInterface startUp.
EtTools recacheImage: false.

These initialize the ENVY interface and make sure we don’t recache the image pointers until we’re ready for it. Then, we set the image owner:

(EmUser classPool declareVariable: ‘CurrentUser’)
value: (EmUser called: ‘Supervisor’).

and force the pointer recache operation:

System image
connectImageToDefaultLibraryReportProgressTo: EmInterface current.

Now comes the first bit of magic, loading some code to make our lives easier. In this case, we’re going to load the latest version of the config map “Abt Image Startup”. First, we find the latest version of the map:

configMapName := ‘Abt Image Startup’.
(map := (EmConfigurationMap editionsFor: configMapName)
detect: [:each | each isVersion] ifNone: [nil]) notNil
ifFalse: [System logError: (‘No version can be found for “%1″‘ bindWith: configMapName).
^false].

Having obtained the map, we load it:

map loadWithRequiredMapsAndTracing: true.

I have a deep and abiding hatred for the Application Organizer, so I like to ensure that it won’t offend me with its presence:

StsAbtApplicationsOrganizerView okToRestart: false.

Finally, we execute the startUp code in the application we just loaded, AbtStartupApp, to continue the remainder of the processing.

(Smalltalk at: #AbtStartupApp) startUp

If you were a Melissa user, you could use a similar technique to load up a virgin image and start processing command line arguments. In other words, you’ve just been freed of the need to ever pre-load an image again.

We’ve now set the stage for doing all kinds of things in an unattended fashion, at least if you’re a Windows user. Our next installment looks at some extra hoops that UNIX users have to jump through before they’re ready to start automating. Windows folks, feel free to take a day off!

Advertisements

7 Responses to “Part 4: At last, something useful!”


  1. 1 Claus 2011-04-04 at 08:13

    If you are using config maps, this does sound very very useful.
    My old shop never used them unfortunately, so loading was a disaster bound to happen each and every single time.

    I might forward this blog to my old shop. They are using VS and Envy, so this might perhaps work for them as well.

    • 2 Tom Koschate 2011-04-04 at 11:59

      Sounds like a screw-up waiting to happen. Without using configuration maps, there’s no way to control the versions of applications being loaded short of explicitly specifying them in a script and putting the script under version control.

  2. 3 Marten Feldtmann 2011-09-28 at 05:43

    I tried your published code and under VA 8.5 I get very interesting problems – after creating abt.cnf.

    The virgin image connects to the default server (my server – and this works) and then the code in abt.cnf gets executed and the first command is EmLibraryInterface startUp (actually I thought it is already initialized – due to the GUI connection squence before) and there I get values I have never seen before and they produce errors:

    The path of my default dat file goes to:

    /vabuild/build/850/output/cd_m/manager/manager/mgr85.dat

    and the ip address of the repository server becomes:

    stbldvmx.

    I’ve never seen these values before …. will be interesting to see, where they come from.

  3. 4 Marten Feldtmann 2011-09-28 at 06:18

    Ok, I’ve found a solution:

    it only works with an already saved (and therefore connected) image. It does not work with the delivered unconnected image (from directory newimage).

    Marten

    • 5 Tom Koschate 2011-09-28 at 07:28

      Marten, thanks for trying this and reporting it. I’m just starting to gear up for a VA8.5 migration, but I’ve been banging my head on #vaVersion and Deprecation issues and haven’t gotten to automation yet.

      In previous versions at least, the Abt.Cnf was run before library startup. Also, I wanted to force connection and set the user programmatically. Unfortunately, we’re playing in undocumented territory, and I’m sure Instantiations reserves the right to change without notice.

      Tom

      • 6 Marten Feldtmann 2011-09-28 at 07:32

        No, I would say, that you are right: abt.cnf IS executed BEFORE library startup (I tested with 8.5). But the execution path is different, when executing the code with an unconnected image – it is not clear for me, what is going on in this case.


  1. 1 The manual that never was written (but should have)… | Joachims Small World Trackback on 2011-03-31 at 17:01

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: