SSG for Microsoft Windows
Mark
Once you convince Microsoft IE that you really, really, really don't
mind downloading the file despite the dire security implications, you
will get the executable, most if not all of the necessary library
parts (DLLs), a sample skeleton, a sample SGS file, and a file XQT.BAT
that runs the mess together to produce output.
My version of SSG implements close to the documented SYMSTREAM
language. Certainly, there are bugs and limitations. It does not
handle merging of PERM COR and TEMP COR or do anything with SIRASM
correction images. The 20-somethings would probably laugh their asses
off at the very idea of correction images in that it mires old fogeys
in the age of IBM cards. However, DOWNDATER was a very nice tool for
keeping track of changes that I haven't seen anybody reproduce without
getting all wrapped around an unnecessary GUI.
Feel free to pass this around among friends. If there is any money to
be made, please make checks payable to me.
It is written in C++. I'd like to rewrite it C#, which should cut
down on the internal complexity and the time it takes to reclaim
storage once the program exits. But there are other pressing projects
at the moment.
sjm
know what's supported and what isn't. I suspect Mark implemented an
SSG older than the 23R9A that I use on my 2200.
Trial-and-error showed that:
- comments in SGSs are not supported.
- two single quotes in SGSs (e.g., ''Law and Order'') are not
supported.
- in-line skeleton comments (e.g., "*LOOP . J") are not supported.
- *ACCEPT and *DISPLAY are not supported
- I could input a text file of SGSs on parameter #2 of the SSG call,
but could find no way to implement a second set. *ADD is not
supported, nor is 'SGS' data card.
- *SET X TO 7 is supported but the legal variant *SET X = 7 is not.
- It does not support converting # in column 1 to masterspace. Some
would say this is undesirable in Windows but others would say, "Not if
I'm generating ECL to upload to my 2200!" There doesn't seem to be a
categorically correct answer to such debates.
- This legal SSG sequence is not supported:
*SET X TO 2
*SET Y[*X] TO 4
The second line should create a variable Y2 and set it to 4 (numeric)
but drew the error message, "The variable (Y[*X]) is not of the proper
form for the dictionary."
At this point, I stopped testing features and started thinking about
how very hard it is to implement Symstream on PC. Some of the issues:
- Symstream is not well documented, particularly the error handling.
Some errors are immediately fatal whereas others are not and there is
no list and, as far as I can tell, no rhyme nor reason.
- It's hard to know where Symstream stops and SSG starts. Are built-
in SGSs such as SYSTEM$ part of Symstream or part of SSG? What about
TOC (Table-of-Contents) SGSs?
- Some Symstream (or SSG?) features are 2200-specific. The classic
example is probably the conversion of # in column 1 to masterspace.
But there are others (e.g., TOC SGSs).
- When 2200-specific features are removed, should they be replaced
with analgous Windows features? I use TOC SGSs a lot, but the idea of
elements in a program file does not translate well to Windows. On a
Windows version of SSG, I'd like TOC entries for directories but, of
course, directories have different attributes than elements in program
files, and directories can contain other directories which leads to
the requirement for recursive TOC SGSs. By the time I'm satisifed,
some purists might says, "Well, that's not Symstream anymore."
- Symstream has the ability to modify the skeleton's directives
dynamically at execution time. The *SET Y[*X] TO 4 I cited above is
an example. I'm not sure this makes it a good candidate for
implementation with labor-saving tools such as lex and yacc.
Cheers,
Steve J. Martin
Marc Wilson
<1176735193.3...@l77g2000hsb.googlegroups.com>::
>- Some Symstream (or SSG?) features are 2200-specific. The classic
>example is probably the conversion of # in column 1 to masterspace.
>But there are others (e.g., TOC SGSs).
Could actually be useful when building MS-DOS batch streams- @ at the
beginning of a line suppresses any echo.
--
Marc Wilson
Cleopatra Consultants Limited - IT Consultants
Fernrhoyd, Chester Road, Alpraham, Tarporley, Cheshire CW6 9JE
Tel: (44/0) 1829 262696 Tel: (44/0) 161 408 6449
Fax: (44/0) 871 236-1531 Mobile: (44/0) 7973 359850
Skype: cleo-marc Mail: enqu...@cleopatra.co.uk
Web: http://www.cleopatra.co.uk
Registered in England and Wales no: 2599843 VAT Reg: 561 1182 69
Registered office: National Westminster House,
21/23 Stamford New Road, Altrincham Cheshire WA14 1BN
_________________________________________________________________
Try MailTraq at https://my.mailtraq.com/register.asp?code=cleopatra
Mark
HTTP://WWW.MDRSESCO.BIZ/SSGDOC.DOC
is your source for SSG for PC documentation. Unfortunate that I did
not send it out with the S/W.
Mark Rockman
lc...@my-deja.com
Why does www.mdrsesco.biz take me to a Dunkin Donuts page?
Dollarbang
Marc Wilson
<1176495629....@e65g2000hsc.googlegroups.com>::
>I have put SSG.EXE on my website at http://www.mdrsesco.biz/ssg.zip
>
>Once you convince Microsoft IE that you really, really, really don't
>mind downloading the file despite the dire security implications, you
>will get the executable, most if not all of the necessary library
>parts (DLLs), a sample skeleton, a sample SGS file, and a file XQT.BAT
>that runs the mess together to produce output.
>My version of SSG implements close to the documented SYMSTREAM
>language. Certainly, there are bugs and limitations. It does not
>handle merging of PERM COR and TEMP COR or do anything with SIRASM
>correction images. The 20-somethings would probably laugh their asses
>off at the very idea of correction images in that it mires old fogeys
>in the age of IBM cards. However, DOWNDATER was a very nice tool for
>keeping track of changes that I haven't seen anybody reproduce without
>getting all wrapped around an unnecessary GUI.
>
>Feel free to pass this around among friends. If there is any money to
>be made, please make checks payable to me.
>
>It is written in C++. I'd like to rewrite it C#, which should cut
>down on the internal complexity and the time it takes to reclaim
>storage once the program exits. But there are other pressing projects
>at the moment.
Marc Wilson
Cleopatra Consultants Limited - IT Consultants
Fernrhoyd, Chester Road, Alpraham, Tarporley, Cheshire CW6 9JE
Tel: (44/0) 1829 262696 Tel: (44/0) 161 408 6449
Registered in England and Wales no: 2588943 VAT Reg: 561 1182 69
Registered office: St George's House, 215-219 Chester Road
Manchester M15 4JE
https://plus.google.com/100816173414569062406
Marc Wilson
<19550fe6-3205-4ef8...@googlegroups.com>::
>Anyone know if SSG for Windows still exists?
address works, if you want a copy- seems the site is long gone.
Stephen Fuld
> In comp.sys.unisys, (Mark) wrote in
> <1176495629....@e65g2000hsc.googlegroups.com>::
>
>> I have put SSG.EXE on my website at http://www.mdrsesco.biz/ssg.zip
>>
>> Once you convince Microsoft IE that you really, really, really don't
>> mind downloading the file despite the dire security implications, you
>> will get the executable, most if not all of the necessary library
>> parts (DLLs), a sample skeleton, a sample SGS file, and a file XQT.BAT
>> that runs the mess together to produce output.
>
> I don't get any of that- just a 404.
>>
>> My version of SSG implements close to the documented SYMSTREAM
>> language. Certainly, there are bugs and limitations. It does not
>> handle merging of PERM COR and TEMP COR or do anything with SIRASM
>> correction images. The 20-somethings would probably laugh their asses
>> off at the very idea of correction images in that it mires old fogeys
>> in the age of IBM cards. However, DOWNDATER was a very nice tool for
>> keeping track of changes that I haven't seen anybody reproduce without
>> getting all wrapped around an unnecessary GUI.
>>
>> Feel free to pass this around among friends. If there is any money to
>> be made, please make checks payable to me.
>>
>> It is written in C++. I'd like to rewrite it C#, which should cut
>> down on the internal complexity and the time it takes to reclaim
>> storage once the program exits. But there are other pressing projects
>> at the moment.
Program file TOCs, etc.) what is the reason people want it? Except for
familiarity with the Symstream language, there seems to be no reason.
For pure Windows stuff, I would think that something like Python would
be far more capable and it is pretty easy to use. In fact, I once
thought about trying to port Python to 2200s and add some of the 2200
unique stuff, but I never got into it.
If Windows SSG is just for curiosity or it was developed as a hobby
project, I understand. But for more general use????
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
Marc Wilson
<jtlk6p$37q$1...@dont-email.me>::
1) Simple one: if you're already familiar with a language, why learn
another one just to do something you can do already?
Python, perl, even (*shudder*) VBScript can do a lot of the things SSG
can do- but not in quite the same way. SSG is unique in the way that
the parameters are automatically arranged into a tree, and while you
could do something in a different way to achieve the same ends, it would
certainly not be a straight translation.
2) If you're doing a migration from 2200 to Windows (an increasing
trend, especially in my field, MAPPER), it means you can migrate other
functionality as well. I've written hundreds of SYMSTREAM skeletons in
the past, and I've never used or needed to use the TCF/PCF mechanism-
it's always been for automating some process based on a parameter file.
3)
Marc Wilson
<qsatv7l0p32b730qm...@4ax.com>::
sjm
> For pure Windows stuff, I would think that something like Python would
> be far more capable and it is pretty easy to use. In fact, I once
> thought about trying to port Python to 2200s and add some of the 2200
> unique stuff, but I never got into it.
I had the same idea to port Python to the 2200 and add some "2200 unique stuff" but also never got around to it (and never will).
Easier than a complete port of C-Python to the 2200 would be to install the JVM and then install Jython. I haven't tried this, so I don't know whether there are any gotchas. If anyone has/gets this working, I'd love to hear about it.
Cheers,
Steve J. Martin
Stephen Fuld
problem I found was that they are all written to use the GNU C compiler.
This makes sense, as there are versions of that compiler for lots of
different systems. However, that compiler supports a fair number of
extensions to the C standard that are widely used. But at least at the
time, these extensions were not supported by the Unisys C compiler. The
task of finding all of the extensions and recoding them, or worse yet,
porting the GNU compiler itself to the 2200 architecture was far more
than I wanted to take on. So starting with Jython would reduce the
amount of code you needed to port, but doesn't really address the big
issue.