SSG Tips & Techniques

Skeleton Design

Separate skeletons and ECL

Unless the skeleton is very small, place it in its own element rather than on input cards following the @SSG processor call. That is, instead of
        --- your skeleton ---
The reason for this is that when the skeleton is in its own elements it's easier to call it with different options. Even if the only alternate options are 'BEY' to get a listing, it's better not to have to modify the your production ECL: You might forget to change it back.

You're already doing this with your MASM, C and Fortran programs. Programmers who would never think to include MASM source in-line following the '@MASM' card will often supply a long, complex skeleton in-line following the '@SSG' card.

Use SGS file-id cards rather than processor call fields

Assume that your skeleton takes five separate SGS inputs. It might be tempting to code:
But I suggest that the following is better:
        SGS   SGSFILE.ELT1
        SGS   SGSFILE.ELT2
        SGS   SGSFILE.ELT3
        SGS   CHGFILE./CHG
There are three reasons for this suggestion. First, it's easier to read. In the original version above, the filenames are crowded together. In the improved version, it's easy to see at a glance what SGSs are input. When you can choose between compactness and clarity, choose clarity. Second, it's easier to write (and to copy!). In the original version above, the author had to count over to the seventh field and place the 'SGS/4' card there; it's very easy to get this wrong. And the author had to count the number of fields (4) that follow on the eighth and following fields. Why count when you don't have to? Third, it's less error prone. In the original version above, an extra comma accidentally inserted after the skeleton name will cause SSG to overwrite what should be input SGSs (SGSFILE.ELT1). This kind of error cannot happen in the improved version.

Don't get hyped up on performance

I've seen some of the best 2200 minds I know intentionally restrict the usefulness of the features in their MASM programs because doing otherwise "will hurt performance." But rather than think of performance as something to be maximized, programmers should think of it as a constraint: A program's performance must be adequate for its purposes but otherwise performance should take a backseat to features, ease of use, maintainability, code reuse, etc.

If you're really hyped up on performance, you won't use SSG at all because it's an interpreter. But you'll miss out on one of the most exciting 2200 development tools and you'll waste a lot of your time developing in an 'efficient' language like MASM or C.

Write your programs for the machines of the future, not the machines of the past!

Reuse code with *COPY procs

If you develop a self-contained piece of code that can be used in other skeletons, split it out into a *COPY proc. Doing this saves you from re-inventing the wheel next time, saves maintenance (you can make a change in one place--the proc), and guarantees that you code common code sequences consistently. Because SSG is an interpreter, a new version of a proc will automatically be picked up the next time the skeletons that use it are invoked.

Use *DEFINE packets in long skeletons

A *DEFINE packet is closely analogous to a paragraph in COBOL. It's a set of statements that can be invoked by name. Like a COBOL paragraph, a *DEFINE packet can access all variables that are active when it's called (neither language has a useful variable scoping mechanism).

If your skeleton is long, split it into several *DEFINE packets rather than code the logic monolithically. Each *DEFINE packet should perform a small set of related functions (or ideally a single function). You should be able to state a *DEFINE packet's purpose in a single sentence (and I suggest including that sentence as a comment at the top of the packet).

Use eight-digit dates internally

The so-called Year 2000 Problem is the shame of the computer industry (or should be). Beginning in release 23R1, SSG supplies the date in eight-digit formats (YYYYMMDD, MM/DD/YYYY) formats as well as in the traditional formats (YYMMDD, MM/DD/YY). Beginning in 23R3 this is extended to the long Table-of-Content (TOC) SGS format. There is no excuse for using a two-digit year.

I suggest storing all dates internally in International Standard Organization (ISO) 8601 internal format, which is YYYYMMDD. That is, I suggest using [DATIME$,1,7,1] and [DATE$,1,5,1] for dates that are included in SGSs or generated into output files. Beginning with release 23R3 you can reference [toclabel,t,8,1] to get an eight-digit element creation date.

If you must process six-digit dates supplied by files whose format you don't control, apply the Unisys Standard of 2027 to create an eight-digit date. For example, if the fourth field of input SGS label FILE is a date in YYMMDD format:

    *INCREMENT F TO [FILE]                    . for each file
    *IF +[FILE,F,4,1,LSTR$,2]  >  27          . if year is 28 to 99
    *SET CC = '19'                            .  century is 19
    *ELSE                                     . year is 00 to 27
    *SET CC = '20'                            .   century is 20
    *SET DATE = '[*CC][FILE,F,4,1]'           . YYYYMMDD format
    *.  Live happily ever after
    *LOOP . F

Display dates in a consistent, unambiguous format

Quick, what date is 02/01/03? The answer depends on whether the date is displayed in American (MM/DD/YY), British (DD/MM/YY) or international (YY/MM/DD) format. Unisys software shows little consistency in how it displays dates and this will cause confusion beginning in 2001. Since British dates are almost never used in Unisys software, you can figure out a two-digit year in context as long as it's 31 to 99 or 00. But beginning in 2001 this won't be so easy because, for example, 01 can be a year, a month or a day.

There are two things you can do to avoid being part of the problem. First, always display a four-digit year. Second, choose a site-standard date display format and stick to it. I prefer ISO 8601 external format (YYYY-MM-DD) but this is a matter of personal or corporate choice. Many American sites will prefer MM/DD/YYYY.

If you write skeletons that might run on a variety of 2200 systems around the world (as I do), make the date display format site-modifiable. I wrote a *COPY proc that translates my preferred internal date format (YYYYMMDD) to the site's desired external (display) format. By changing two SGSs I can modify the date display format for all my skeletons. This is a very impressive feature not offered by software costing tens of thousands of dollars. In SSG it's a snap.

Revised 1998-04-23