@SSG SKEL --- your skeleton --- @EOF @EOFuse
@SSG SKELFILE.YOURSKEL @EOFThe 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.
@SSG SKELFILE.YOURSKEL,SGSFILE.ELT1,,,,,SGS/4,SGSFILE.ELT2,SGSFILE.ELT3,; SRCFILE./BASE,CHGFILE./CHG @EOFBut I suggest that the following is better:
@SSG SKELFILE.YOURSKEL SGS SGSFILE.ELT1 SGS SGSFILE.ELT2 SGS SGSFILE.ELT3 SGS SRCFILE./BASE SGS CHGFILE./CHG @EOFThere 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.
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!
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).
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 *ENDIF *SET DATE = '[*CC][FILE,F,4,1]' . YYYYMMDD format *. Live happily ever after *LOOP . F
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.