Forms (printed) processing on VMS? - VMS

This is a discussion on Forms (printed) processing on VMS? - VMS ; Hi. Many years back I used JetForm for printed form processing on VMS (mVAX 3100/90 at the time). This works just OK. JetForm Design was used on a Windows PC to "design" the forms and then JetForm Merge was run ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Forms (printed) processing on VMS?

  1. Forms (printed) processing on VMS?

    Hi.

    Many years back I used JetForm for printed form
    processing on VMS (mVAX 3100/90 at the time).
    This works just OK. JetForm Design was used on
    a Windows PC to "design" the forms and then
    JetForm Merge was run on the VMS box to "merge"
    the application data with the forms and printed
    on standard lasers, usualy HP LaserJet 4's at the
    time.

    As far as I have found out, JetForm was bought
    by Adobe and VMS support was dropped some years ago.

    Now, is there anything available today similar
    to this tools ?

    Jan-Erik.

  2. Re: Forms (printed) processing on VMS?



    Jan-Erik Söderholm wrote:
    > Hi.
    >
    > Many years back I used JetForm for printed form
    > processing on VMS (mVAX 3100/90 at the time).
    > This works just OK. JetForm Design was used on
    > a Windows PC to "design" the forms and then
    > JetForm Merge was run on the VMS box to "merge"
    > the application data with the forms and printed
    > on standard lasers, usualy HP LaserJet 4's at the
    > time.
    >
    > As far as I have found out, JetForm was bought
    > by Adobe and VMS support was dropped some years ago.
    >
    > Now, is there anything available today similar
    > to this tools ?
    >
    > Jan-Erik.


    If the data is test you can write the form in Postscript and put it into
    the device control library. The postscript reads the rest of the print
    stream as data and controls printing. I can give you samples if you are
    interested.

    Jeff Coffield
    www.digitalsynergyinc.com

  3. Re: Forms (printed) processing on VMS?

    Jeffrey H. Coffield wrote:
    >
    >
    > Jan-Erik Söderholm wrote:
    >> Hi.
    >>
    >> Many years back I used JetForm for printed form
    >> processing on VMS (mVAX 3100/90 at the time).
    >> This works just OK. JetForm Design was used on
    >> a Windows PC to "design" the forms and then
    >> JetForm Merge was run on the VMS box to "merge"
    >> the application data with the forms and printed
    >> on standard lasers, usualy HP LaserJet 4's at the
    >> time.
    >>
    >> As far as I have found out, JetForm was bought
    >> by Adobe and VMS support was dropped some years ago.
    >>
    >> Now, is there anything available today similar
    >> to this tools ?
    >>
    >> Jan-Erik.

    >
    > If the data is test you can write the form in Postscript and put it into
    > the device control library. The postscript reads the rest of the print
    > stream as data and controls printing. I can give you samples if you are
    > interested.
    >
    > Jeff Coffield
    > www.digitalsynergyinc.com


    Yes, as an alternative method it might be intersting.
    The problem might be producing the PS "source" to put
    into the devctl lib, I guess.

    If you have someting you'd like to mail, you can find
    my email adress here : http://www.jescab.se/Kontakt1.htm

    I can add that the "form printing" is run directly
    from COBOL apps using simple text format with some
    PCL "commands" today. It's a lot of application
    changes for any changes to the "forms". The whole
    form is in the DATA DIVISION...

    Jan-Erik.

  4. Re: Forms (printed) processing on VMS?

    Jan-Erik Söderholm wrote:
    > Hi.
    >
    > Many years back I used JetForm for printed form
    > processing on VMS (mVAX 3100/90 at the time).
    > This works just OK. JetForm Design was used on
    > a Windows PC to "design" the forms and then
    > JetForm Merge was run on the VMS box to "merge"
    > the application data with the forms and printed
    > on standard lasers, usualy HP LaserJet 4's at the
    > time.
    >
    > As far as I have found out, JetForm was bought
    > by Adobe and VMS support was dropped some years ago.
    >
    > Now, is there anything available today similar
    > to this tools ?
    >
    > Jan-Erik.


    I don't know of any.

    How about just designing your own form on your own printer? Then ask a
    printing company to print nice colored lines and tints around where your
    laser printer will fill in the blanks?

    This would only work if you wanted preprinted forms in large quantities.
    No good if you need five copies each of a hundred different forms!

  5. Re: Forms (printed) processing on VMS?

    How complex are the forms ?

    What I have done in the past was to design it on Freehand/Illustrator.
    Then I created it in postscript myself using the point positions that I
    obtained from the graphic program (click on object and gets its info
    which includes position, size etc).

    Then, I would add the potscript logic to add my data to the form.

    At run time, you have a clean poscript that draws the form, and clean
    logic that takes arguments and puts your data up on the form.

    the postscript code generated by drawing packages is way too bloated and
    complex to be usable "manually".

  6. Re: Forms (printed) processing on VMS?

    JF Mezei wrote:

    > How complex are the forms ?


    Not that complex at all, when printed on paper... :-)

    But the COBOL code uses a lot of hardcoded PCL ESC-
    sequences. There is a lot of code like :

    *------------------------------------------------------
    * THIN LINES VERTICAL
    * SET CURSOR POSITION (DOTX 480 DOTY 3800) /720 inch
    05 FILLER PIC X VALUE ESC.
    05 FILLER PIC X(6) VALUE "&a480H".
    05 FILLER PIC X VALUE ESC.
    05 FILLER PIC X(7) VALUE "&a3800V".
    * HORIZONTAL RULE/PATTERN (3 DOTS)
    05 FILLER PIC X VALUE ESC.
    05 FILLER PIC X(4) VALUE "*c3H".

    That snippet is from a COBOL source that by itself has
    close to *650* lines with "FILLER PIC X VALUE ESC." :-)
    And that is not the only source...

    It would be quite a lot of work if they'd ask for
    some major revision of the printouts...

    >
    > What I have done in the past was to design it on Freehand/Illustrator.
    > Then I created it in postscript myself using the point positions that I
    > obtained from the graphic program (click on object and gets its info
    > which includes position, size etc).
    >
    > Then, I would add the potscript logic to add my data to the form.


    Today just a few of the 60-70 printers are PS printers,
    but I'm trying to get "PS" into the picture when
    getting new or replacing old printers.

    >
    > At run time, you have a clean poscript that draws the form, and clean
    > logic that takes arguments and puts your data up on the form.
    >
    > the postscript code generated by drawing packages is way too bloated and
    > complex to be usable "manually".


    Yes, I guess so.
    I'd rather use some packaged solution like the JetForm
    Design/Merge combo. We'll see what the folks at Flexform
    (www.flexform.com) says...

    Thanks anyway !
    Jan-Erik.

  7. Re: Forms (printed) processing on VMS?

    Richard B. Gilbert wrote:
    > Jan-Erik Söderholm wrote:
    >> Hi.
    >>
    >> Many years back I used JetForm for printed form
    >> processing on VMS (mVAX 3100/90 at the time).
    >> This works just OK. JetForm Design was used on
    >> a Windows PC to "design" the forms and then
    >> JetForm Merge was run on the VMS box to "merge"
    >> the application data with the forms and printed
    >> on standard lasers, usualy HP LaserJet 4's at the
    >> time.
    >>
    >> As far as I have found out, JetForm was bought
    >> by Adobe and VMS support was dropped some years ago.
    >>
    >> Now, is there anything available today similar
    >> to this tools ?
    >>
    >> Jan-Erik.

    >
    > I don't know of any.
    >
    > How about just designing your own form on your own printer? Then ask a
    > printing company to print nice colored lines and tints around where your
    > laser printer will fill in the blanks?
    >
    > This would only work if you wanted preprinted forms in large quantities.
    > No good if you need five copies each of a hundred different forms!


    Preprinted old-style forms is not an option. They uses
    simple single-tray printers and more then one "form".


  8. Re: Forms (printed) processing on VMS?

    Jan-Erik Söderholm wrote:

    > Yes, I guess so.
    > I'd rather use some packaged solution like the JetForm
    > Design/Merge combo. We'll see what the folks at Flexform
    > (www.flexform.com) says...



    One of the advantages of cook-your-own-Postscript is that you can embed
    some of the display logic in the postcript to separate it from the
    application.

    For instance, when printing a statement for a customer, the application
    could just include a "language" field, and let the postcript then
    include the form background applicable to that language as well as
    "word" translatiosn for different codes (eg: for an english customer,
    the province code "BC" might get printed as "British Columbia" while for
    a french customer, it would be "Colombie Britanique".

    When using shrinkwarpped software for forms, you may have less
    felexibility and may have to include more of the display logic in the
    application itself.

    Postscript is a pretty powerful language.

    For istance, to print a mailing label, postscript code can format the
    address different ways depending on the country that is specified, and
    the application doesn't have to worry about building the address label
    correctly.

    And while display postscript is gone on VMS, there is ghostscript on
    VMS, and on a MAC, the "display postscript" functionality is embedded in
    the OS.

    With postscript, you can also convert it to .pdf and mail the statements
    to the customers. I think this is a big plus compared to that PCL stuff.

+ Reply to Thread