Conference azur::mcc

V1.0 of MCC_GRAPH is available now. It is available from the same location
as mentioned in 1287.0 and is called:

MCC_GRAPH_V1_0.BCK

See 1287.0 for instructions how to install it and getting started.

Changes compared with FT1.0:

-It appeared that there was a bug when the mapfile had missing icon_file
 labels. This has been solved.
-new qualifiers have been added to set the left and bottom margin
-When you run mcc_graph, you will get some informational output about
 the map size and how many pages are required to print it. This can be set off
 with the /INFO qualifier.

See for more details, the updated documentation MCC_GRAPH_DOC.PS and 
MCC_GRAPH_DOC.TXT.

Timo

For those that have copied FT1.0 and now want to use (or already copied) V1.0.

The version numbers of the files in the FT1.0 saveset were not reset to 1, but
the ones in the V1.0 saveset were. This means , that if you restore the V1.0
saveset in the same directory where you had stored the FT1.0 saveset, you'll
end up with the wrong version. To avoid this problem, you have to delete
the FT1.0 files first, before restoring the V1.0 saveset. If everything is ok,
you should end up with the MCC_GRAPH.EXE;1 file that is dated 31-jul-1991.

Hope this helps

Timo

    The utility seems very usefull. Thanks for the effort.
    
    The FT version (we couldn't get the V1 to work) blew up on a few
    of my maps. It lost the top of a tall one in /onepage mode
    and didn't generate valid postscript for another.
    
    A suggestion to make it easier to use...
    Use the MCC_MAPS logical for the map location and the MCC_ICONS logical
    for the icon locations by default. From the EXE, look up the directory
    spec from where you ran to find the location of the rest of the files
    needed by the program. That will avoid having to copy files around
    and setting default to run it.
    
    Thanks.
    
    s/rob
    

    
>    The FT version (we couldn't get the V1 to work) blew up on a few

What happened when you tried V1.0. Did you first got rid off FT1.0?

> It lost the top of a tall one in /onepage mode
>    and didn't generate valid postscript for another.
 
Maybe you could mail me the maps that didn't came out as expected ,and
the options you used to generate it. I'll can have a look at it. Did you
use the right papersize?

>    A suggestion to make it easier to use...
>    Use the MCC_MAPS logical for the map location and the MCC_ICONS logical
>    for the icon locations by default. From the EXE, look up the directory
>    spec from where you ran to find the location of the rest of the files
>    needed by the program. That will avoid having to copy files around
>    and setting default to run it.

I don't really understand this, because this is exactly how it is supposed
to work. All files that the utility requires (.CLD, temporary files etc.)
are referenced by using the MCC_GRAPH_DIRECTORY logical. When you type

$MCC_GRAPH domainname    

The domainfile IS looked up in MCC_MAPS and the icon files ARE searched for
in MCC_ICONS. From your comments I deduct that this doesn't seem to work.
So what are the exact symptoms?

Thanks

Timo    

Timo,

Rob and Claudia just brought up a sample of your wares.  **Great Job!!!**

BTW what language did you write it in?  Does it have a callable interface?

Fred

Fred, MCC_GRAPH is written in C and doesn't have a callable interface.


Some more remarks on V1.0:

- I thought that all references to the MCC_GRAPH files were made by using the
  logical MCC_GRAPH_DIRECTORY. Unfortunately I forgot one file, which means
  that if you run mcc_graph from another directory then the one where the
  code is stored, you'll get a 'missing file message'. To solve this, add
  the line:
  
  $def/sys MCC_GRAPH_BUILD MCC_GRAPH_DIRECTORY:MCC_GRAPH_BUILD

  to the MCC_GRAPH_LOGICALS.COM file. Now you should able to run the utility
  without changing the default.

- Clipping problems:

  If you do

  $MCC_GRAPH/ONE domain

  a graph will be produced using the standard European A4 paper size. This
  means that if you print such a graph on paper that has another size than
  8.25*11.6 inch, the PRINTER will clip of a part of the graph. To avoid
  this you have to specify the /HEIGHT_OF_PAPER and /WIDTH_OF_PAPER
  qualifier. 
  How to use these: A lot of the qualifiers that I used, I took from the
  ENIM_GRAPH utility that I wrote some time ago. At that time I decided, to
  define the paper height and width as the VIRTUAL size that would be usable 
  for the graph , and not the physical size of the sheet of paper. 
  So what MCC_GRAPH does is the following.
  - create the map in a frame that has the height and width that are specified
    by the /HEIGHT and /WIDTH qualifiers. 
  - Then the whole frame will be moved up and right, specified by the 
    qualifiers /LEFT_MARGIN and /BOTTOM_MARGIN.

  So there are several things you can do:

  1. Specify the /left_margin and /bottom_margin as zero and specify the
     /height and /width as the physical size of the paper.

    In theory, this would give you a frame that should EXACTLY fit the complete
    page. Howver, from previous experience I  noticed, that it depends on
    the physical device (e.g. the printer), if the (0,0) point of the graph
    will be placed EXACTLY on the bottom left corner of the sheet of paper.
    In practice this is not the case, and this means that with this specification
    of the qualifiers, the PRINTER will cut off a small part of your graph.
    That's why I introduced the /LEFT_MARGIN and /BOTTOM_MARGIN to compensate
    for printer inaccuracy.

 2. Specify the /LEFT_MARGIN and /BOTTOM_MARGIN for example as 0.5 and 0.25
    inch (these are the defaults). Now you have to specify the paper height
    and paper width as paper_height=physical_paper_height - bottom_margin and
    the same for the width. Again this would mean that in theory , the top
    of your graph would match EXACTLY the top of the sheet of the paper. But
    as stated above, this depends on the accuracy of the printer.
    Therefore I suggest to use for the paper height to use

    /HEIGHT_OF_PAPER=physical_height_of_paper - bottom_margin - a_little_bit

    For example the default setting for European A4 size of paper is:

    /HEIGHT = 11.6 (physical size) - 0.25 (default bottom margin)  - 0.35 = 11
    /WIDTH  = 8.25      "          - 0.5           "               - 0.25 = 7.5 

    and for A3 sized paper these defaults are 11 * 16.

   I agree that it had been easier to let the tool do these calculations
   for you, but as I said, this is a left over from history.
   I might change it in a future version (if any).


Hope this helps

Well, I answered a little bit to fast in the previous reply, and the 
definition of the logical doesn't solve all the problems. Therefore
I have created a new kit with this one problem solved (Yes, I have tested
it now). The saveset name is the same:

MCC_GRAPH_V1_0.BCK;2  2-AUG-1991

Delete the previous version if you restore this new saveset.

Sorry for the inconvenience.


Timo

-Some more problems have been reported and solved. Therefore I have created
a new kit that includes all changes that are mentioned in the previous notes,
plus:

-Changed scaling of text.
-Multiple text lines didn't work. This has been solved.
-MCC_GRAPH now generates encapsulated postscript, so that you can include
 the maps in your decwrite documents (as long as it is one page. )
-Internal error from mapping of multiple objects with the same icon onto
  one postcriptt call. This didn't cause any problems in the output, but the
  postscript file was larger than necessary. The generated postscript files
  will now be more compact.

Notice that the limitation of clipped text at the borders of the map, as
described in the documentation, hasn't been solved. I don't have much more
time for the moment to have a look at this.

The new kit can be copied from

CLARID::[HOFSTEE.MCC_GRAPH_DISTRIBUTION]MCC_GRAPH_V1_1.BCK;1 (9-AUG-91)

Have fun

Timo

PS -1: It's still on disk ASDPO1$ .

    Nice utility!
    
    I have a suggestion to make it easier to use.
    
    How about a logical (or something) that changes the default paper
    size and margins and everything so it works right on LPS40s and LN03Rs
    loaded with US size 8.5x11 paper?
    
    That way the definitions can be done once and then left alone?
    
    thanks
    s/rob

A couple of problems have been reported since the release of V1.1 . I have
solved them and released a new saveset.

 MCC_GRAPH_V1_2.BCK.

Changes:

-When using lots of different icons with different sizes, somtimes the wrong
 size was used for an icon. This problem has been solved.
-The default settiongs for the paper size and margins, can now be specified
 by changing the MCC_GRAPH.CLD file. So if you are using US paper size,
 edit the default settings in the MCC_GRAPH.CLD file and they will be used
 from then on.
-Some internal modifications have been made, like improving speed, trace output
 etc.


Keep the suggestions coming

Have fun

Timo


PS: Somebody reported a problem with linewidth that would not be interpreted
    correctly by MCC_GRAPH. I have checked and double checked the code, but
    as far as I can see, MCC_GRAPH maps exactly what is contained in the map
    file. However, during some playing around with mapfiles , I noticed that
    sometimes it happens that the line width that is contained in the map file
    is not the same as the one that is shown on the screen in the iconic map!
    Do other people have experienced problems with line width in the iconic
    map and/or MCC_GRAPH?

    Hi
    My Name is Matthias Oswald and I work in a Network Management Service
    Delivery Unit in Zuerich /Switzerland. At a Customer Site I have the
    following Problem:
    
    I tried to print out different maps (not very large, about 60 Icons)
    created with the following command:
    $mcc_graph/one_page domain
    
    The Printer (a DEClaser 2250) returns the following Error Message
    
    %LPS-W-STKOFLO, stackoverflow: Operand stack overflow - offending
    command is 2.0
    
    Then I tried to print out a map created with the suggested command
    for stackoverflow problems;
    $mcc_graph/one_page/dict=20000
    
    Then the Printer returns the following Error Message:
    
    %LPS-W-VMERROR, VMerror: PostScript virtual memory exhausted -
    offending command is dict.
    
    I have tried the commands with different Dict sizes. Everithing greater
    than 13000 results in a VMerror, with a value smaller than 13000 I
    receive a stackoverflow.
    
    I use the mcc_graph v12.
    
    Has anybody any idea wath is wrong with the printer/the files/the tool
    or with me ????
    
    Thanks   Matthias
      
    

    	Very good job Timo.
    I have some problems with the last release of mcc_graph. Look the
    example:
    
    			CED
    			---
    
    	 ----					----
    	| N4 | .DNA_NODE.FRIDA		       | N4 | .DNA_NODE.GUDRUN
    	 ----                                   ----
    	   |                                      |
    -----------------------------------------------------
                     |
                   ----
                  |DOM.|
                   ----
                  DOMAIN_X
    
    The mcc_graph paints the whole map but in that case the words CED, 
    DOMAIN_X, and .DNA_NODE.GUDRUN won't appear in the .PS file. The
    peripheral alfabetic descriptions of the entities won't be included in
    the .PS file.
    
    Thanks
    
    Domenico

    Timo,
    
    
    	I'have just started using your tool here in Nijmegen and it looks
    very good, but we also seem to have some problems with printing out
    maps. 
    
    We are printing the MAPS on an LPS-40 and sometimes it works,sometimes
    we get an empty page and sometimes we get an error message that looks
    like:
    
    Stackoverflow:Operand stack overflow - effending command is 4.0
    
    Rest of Job will be ignored.
    
    Can you help us solving this problem?
    
    Regards/Rob

re .12,.14:

If you get a stackoverflow on your printer, it means that your printer
doesn't have enough memory to store a (big) procedure on the operand stack.
I have build in some features to keep the sizes of postscript procedures
small, but maybe I can optimize this a little bit more. You are likely
to get this type of error if you have LOTS of symbols on your graph, like
Linesegments and icons.

If you send me your mapfile, I can maybe have a look if and how to optimize
the postscript code, and use them as example/test file.

re.13:

As stated in the manual, MCC_GRAPH cuts of everything that is above , or
right of the highest/rightmost linesegment/icon. In  other words, TEXT that
is  higher on the map than the highest icon/linesegment and TEXT that
extends right of the rightmost icon/linesegment will be clipped of. 
This explains why you are missing some text. Simple workaround is, to
move your text down/left or draw a very tiny linesegment above everything
and/or to the right of everything.

Hope this helps

Timo

I new version of MCC_GRAPH is available:

CLARID::ASDPO1$:[HOFSTEE.MCC_GRAPH_DISTRIBUTION]MCC_GRAPH_V1_3.BCK

See note 0. for installation instructions. 

!Warning ! : Remove the previous version if you have one, before restoring 
             the new version, otherwise version numbers will be mixed up!


Changes :

-The produced postscriptcode is more compact, so that stackoverflow errors
 like mentioned in previous notes, should not occur anymore (or at least be
 less frequent)

-A /ROTATE qualifier allows you to rotate the complete picture so that you
 can print in landscape format.

Have fun.

Timo

As some people have noticed, the /ROTATE qualifier doesn't work 100%. For
some reason, pages are clipped the wrong way. I'll have a look at it.

Timo

Are there any changes in the mapfile format in V1.2. Any new objects than
the 7 types defined at the moment in V1.1? 

If so, can somebody post a new specification that describes the new format
and types, so that we can adapt MCC_GRAPH.

Thanks

Timo

    
    thanks to John Egolf, the specification (updated version) of V1.2
    map file can be found in:
    
    Directory BSYBEE::DUA0:[PUBLIC]
    
    MAP_FORMAT.PS;6      86   5-DEC-1991 11:49:37.00 (RWE,RWED,RWE,RWE)
    
    \david.
    

I am planning to update MCC_GRAPH so that it works with the new objects in
MCC V1.2. I read the MAP_FORMAT.PS that explains something about the MCC
map file formats,but certain things are not clear to me. Can somebody
answer the following questions:

1. All object_type 1 (icons) contain an extra line "ident_dt 0". 
   What is its use, and can I assume that this line will always be there for
   an object_type 1?

2. A new label "background_pixmap" can be stored in the mapfile. This points
   to a .XBM file. How is this data mapped into the mcc map window.(Which
   coordinates correspond with what data in the file?)

3. If I include a "reference" icon on my map, my map file contains 

   object_type 1
   mcc_code 332
   center_x 0.068607   center_y 4.536383
   text_x 0.031185   text_y 4.460083
   ident_dt 0
   name   .jansen
   
   in which never an "icon_file" label seems to be included. Why is this
   different than other icons that always seem to have an icon_file label?
   Can I savely assume that mcc_code 332 is a special case and therefore
   always use the icon file MCC_REFERENCE_ICON.DAT
   (At the moment when I encounter a object_type 1 without icon_file label,
   I use the question mark icon. Should I follow this approach?)

4. Object type 17. Child entity Pipe box (same for object type 11)

   -With what points of the rectangle do the points (x1,y1)(x2,y2) correspond?
   -What is the width (in MCC map file units) of the box (eg. distance between
    inner and outer box)  
   -what is the difference between the "name" and the "icon_name" label? In
    the examples that I created, these labels always contain the same strings.
    Can they be different and if so, which string is displayed on the map?
   -The box seems to have some 3D effect. Is that right?
   
5. Object type 12. Pipe Line. 

   - With which points do the (start_x,start_y) (stop_x,stop_y) coordinates
     correspond on the map. Are they in the middle of the two lines that
     are shown on the map?
   - The interpretation of the "width" value seems to be interpreted different
     for Line and a Pipe Line. For example, if I select a thick linewidth
     (0.0275) and I draw a line and a pipe line, the single line comes out
     MUCH thicker on the map than the individual lines of the pipe line, 
     although both have stored 0.0275 as width in the map file.

6. Object type 9

   - What is the distance (in mcc map units) between the inner and outer
     circle, and does the radius in the file  correspond with the inner or
     the outer circle?

7. object type 16. pipe line child entity

   -similar questions as for object type 12, with respect to coordinates.
   -same question as for object type 17 with respect to the labels "name"
    and "icon_name".

   (BTW :why is the sequence of the labels like "mcc_code" ,"ident_dt" etc.
         different for different objects like 16 and 17?)

8. what is the meaning of the "var" label? It always seems to be 0 except for
   object type 2.

Thanks

Timo
    

    
    >> 1. All object_type 1 (icons) contain an extra line "ident_dt 0".
          What is its use, and can I assume that this line will always be
          there for an object_type 1?
    
    'ident_dt' is new in V1.2.  For the things that u're doing, u may
    ignore it; however, don't assume it'll always be there because there
    are V1.1 map files out there.
    
    >> 2. A new label "background_pixmap" can be stored in the mapfile. This
    	  points to a .XBM file. How is this data mapped into the mcc map
    	  window.(Which coordinates correspond with what data in the file?)
    
    'background_pixmap' is an un-documented feature.  if you want to
    support it, i can look into it (the person who did this left the
    group).
    
    >> 3. If I include a "reference" icon on my map, my map file
          contains...
    
    I tried it on my system with a "reference" icon and "icon_file 
    mcc_reference_icon.dat" is include in the map file.  Are u sure
    u have mcc_reference_icon.dat in MCC_ICONS directory when u ran
    IMPM?
    
    >> 4. Object type 17. Pipe box
    
    (x1,y1) = lower lefthand corner of the box.
    (x2,y2) = upper righthand corner of the box.
    
    width can be either 0.0225 or 0.0275 (the two fattest line width in 
    Toolbox Options).  the width of the line inside the pipe (invisible
    line) is always 0.0175.
    
    >> difference between the "name" and the "icon_name" label?
    
    in your case, don't worry about "name".  Use "icon_name" because that's
    what get displayed on the map.
    
    >> box seems to have 3D effect.
    
    yup, that's just how Gobe does it.  don't worry about it.
    
    >> 5. Object type 12. Pipe Line.
    
    (start_x, start_y) starting point of a line.
    (stop_x, stop_y) ending point of a line.  
    Their meanings are same as 'regular' line.  So what ever u do with 
    'regular' line, do the same here.  See '4.' for explanation on width.
    
    >> 6. Object type 9.
    
    distance between the circle -- see '4.' for explanation on width.
    
    does the radius in file correspond with inner or outer...?
    
    not sure... probably corresponds with outer.
    
    >> 7. i think u can find the answers from above.
    
    >> 8. meaning of the "var" label...  
    
    in your case, don't worry about it.
    
    
    hope this helps, david.
    
    
    

I have created a new version of MCC_GRAPH (V2.0) which is compatible with
MCC T1.2.4 (and hopefully V1.2). It is also backwards compatible with MCC
V1.1. This new version is a VMS installable kit . It can be copied from:

CLARID::ASDPO1$:[HOFSTEE.MCC_GRAPH_DISTRIBUTION]MCC_GRAPH020.A

Some of the changes are:

-/ROTATE works now (for printing in landscape)
-updated documentation
-VMS installable
-Uses a startup file MCC_GRAPH$STARTUP.

VMS only for the moment.

The doc is included in the kit (MCC_GRAPH_DOC.PS)

Timo

    Thank you Timo!!!
    
    s/rob

    A few problems seen so far.
    
    In the install proceedure when it asks for the device for the
    [mcc_graph] directory, if you supply a colon (ie; DUA0:), the procedure
    adds a second one and fails in the file open (trys DUA0::[mcc_graph]
    for example).
    
    In the mcc_graph_startup file I am not sure that the SET COMMAND is
    going to propogate to other processes?
    
    It would seem that the logical name definition should be a startup
    file issue but the set command is a login.com issue?
    
    s/rob

    
>    In the mcc_graph_startup file I am not sure that the SET COMMAND is
>    going to propogate to other processes?
    

Yep, call the MCC_GRAPH$STARTUP file from your login.com instead of
SYSTARTUP_V5.COM

Timo

    Hello,
    
    I'm here to ask a question about the paper size
    
    What do you think to put the /A0, /A1, /A2, in the MCC_GRAPH
    to select the paper size, avoiding to select manually the Right/left
    margins or to modify the MCC_GRAPH.CLD?                                
    
    This is why there are plotters that accept Postscipt files.
    
    

There are no plans (=time=money) to extend the functionality of mcc_graph.
Use the width_of_page and height_of_page qualifiers instead.

Maybe some day in the future...:)

Timo    

I have made a new version of MCC_GRAPH. V2.1 
This version has only one improvement. In the previous versions, when no
iconfile label was detected for an icon, the utility just gave a message and
used the 'unknown' icon (question mark). In this version, it will use the
MCC_CODE label and work out the filename for the default icon, using the
information in the dictionary. So for example, if an icon with MCC_CODE 1
has no icon_file label, the file MCC_ICONS:MCC_NODE4_ICON.DAT will be used.

Have fun

Timo

PS:Saveset still on same location :

CLARID::ASDPO1$:[HOFSTEE.MCC_GRAPH_DISTRIBUTION]MCC_GRAPH021.A;2

MCC_GRAPH V2.1

I installed MCC_GRAPH this morning.  Great tool!  I printed a 13 sheet by 4 sheet
grid on a LN08, and got:

%LPS-W-VMERROR, VMerror: PostScript virtual memory exhausted - offending
 command is ]

This error occurred while printing page 48 of 52.

I can provide more information about the printer (amount of memory) and the file
that generated the error, if necessary.

Thanks!
tl

Well, as stated in the documentation under "known limitations", when your 
graph is very complicated and has LOTS of lines (like the world map), then
the printer may run out of memory. You can try some qualifier that is explained
in the documentation. (/DICT or something). 
I am not doing support anymore for this tool. I've handed over the code to
engineering and it may be included in V1.3 I've been told.

Hope this helps

Timo

    
    Thanks for posting your reply Timo... I thought that qualifier
    might help, but I wasn't sure...

    According to the documentation, the qualifier is
    /DICTIONARY_SIZE=<value>.  The documentation recommends that 
    <value> be at least 30000.

    This qualifier will help adjust the dictonary stack size.
    The documentation mentions the error "dict full", but
    says nothing of the error mentioned in note .29.  I
    am not sure if the two errors are related.
    
    Regards,                                  
    
    Ulla
     

    DECmcc v1.3 doesn't have the capability to output maps to postscript.
    And MCC_GRAPH doesn't work with v1.3,  nor are there plans by anyone
    to update it, reason "its an orphaned & unsuported tool".
    
    Another three steps forward and one back, well I guess we will just 
    have to learn to live without being able to print our maps.
    
    Darn shame .....hope the our clients don't scream too loudly........
    Anyway it could be worse DECmcc itself may become "an orphaned &
    unsuported tool" (-;
    
    Gil

Gil:

  I understand the frustration evident in your comments, but please be 
  patient.

  NSM management is currently working on the LRP (long range plan) for the
  group.  Once we know what our long range plans are then we (engineering) 
  can decide how important this functionality is compared to the hundreds of 
  other requirements that exist in this product space.

  We have limited resources these days, so these decisions are even harder to
  make.

                                                                       - Jerry

Now if you can find a volonteer that would like to take over the sources and
make it work with V1.3, let me know and I'll ship the sources.

Timo

  Well, I can't commit myself to doing this (especially since I am not privy
  to the group's LRP), but I wouldn't mind taking a look at the sources.  Can
  you post a note with the location of the files?

                                                                        - Jerry  

    What about an ultrix version?  Or can the sources be compiled easily
    under Ultrix?
    
    Or can the map files be moved over from Ultrix to any VMS and applied
    against the program?
    
    -- cheers,
       Guy
    

> What about an ultrix version?  Or can the sources be compiled easily
>    under Ultrix?
 
It depends what you call easily. If I remember well, the only VMS "specific"
part, is the parsing of the commandline for which I use some RTL routines.
For the rest it is "standard" C. I think it wouldn't be a big deal for an
experienced C programmer. If you know any volunteers let me know and I'll ship
you the code. 
BTW, I already send the sources to someone (don't remember who), who said
he was going to check , and modify if necessary, V1.3 compatibility. 
    
>    Or can the map files be moved over from Ultrix to any VMS and applied
>    against the program?
  
Although I never tried it, I think this will work, since the map files are 
straight ASCII files. 



Timo

PS:I am not modifying/updating/maintaining/supporting this utility anymore