77
newsletter
EOM News and Views
Issue 23, Summer 2011
Print from Win Apps .. 1
DDA Tip............................................1
Sending SMS msgs .......3
PDF Creation #2 ..................4
Quick Hits.......................................5
Contact information ........5
PGCG
Pretty Good Consulting Group
Got a problem? We create solutions.
If you have been reading this newsletter
for a while, then you know that there are
multiple ways to ¤feed¤ EOM from Win-
dows applications. A quick refresher on
how Windows applications can submit data
to EOM:
Ÿ Drop files into directories that EOM
monitors (local or on a network)
Ÿ ¤Print¤ to a Windows printer that is
configured to send to EOM via TCP
(LPD/LPR or Raw)
Ÿ Use the COM or .Net API program-
matic interfaces
Ÿ Microsoft Message Queuing (MSMQ)
Ÿ HTTP post (see Fall 2009 Newslet-
ter)
Ÿ Your program opens a TCP connec-
tion to EOM (Raw, or LPD if your
program handles the protocol).
So how do you decide which method to
use? In most cases the question be-
comes ¤What options are available and
which is easiest to use?¤. If you wrote
the application, then any of the options
above could work, if not then usually
having the application write to a directory
or ¤printing¤ are typical options and
sometimes the most expedient. For
example, the gurus at the Building Indus-
try Bargaining Council in Cape Town were
able to use Windows BIS to create an
output file format, write the file to a
directory (with an unique naming conven-
tion), create an electronic form, define a
Directory Monitor attribute, Print Attribute
and Data Dependent Attribute and produce
a PDF output in less than 2 hours - and
they were new to EOM.
Sometimes it isn®t practical to write a file,
so the next usual choice is to ¤print¤ to a
Windows printer that ¤points¤ at EOM.
The Windows printer is defined using a
TCP port (LPR or not) with the remote IP
address of the PC/server EOM runs on -
even if it is the same PC/server as the
application. The application prints to the
Windows printer, the Windows printer
sends the print stream to EOM.
(continued on next page)
Printing from Windows applications
DDA Tip: What should a DDA look like?
The structure of the DDA depends on multiple variables like input data and output
formatting. The following is a structure that has worked for many customers and is
maintainable for future changes. We will consider an easy case where all data for a page
(or set of pages) is on a single line. This general format breaks the DDA commands into
callable DDA Items and one DDA item to handle the input data:
to set up any global variables and initial values
to put the $CurrentData data into unique variables for later use
to modify the variables set in ParseData, usually formatting strings
to output the data, form, graphics and so on to the page(s)
to process the input file, calling the DDA Items listed above
Note that LineData is the only DDA item enabled for data identification. This DDA items
uses a simple technique of checking if a global variable is not defined, then call the
InitializeDDA DDA item to do so - hence, it happens only once, when the first record of
the input file is processed. It calls the other DDA items for each record. . Example DDA
58
EOM News & Views
Issue 23, Summer 2011
Page [ 116 ]
[ 116 ]
Most Windows applications have some mechanism to print. Now the question is ¤What does the printed data look like?¤ If the appli-
cation writes complicated (or ¤pretty¤) output including font changes, graphics, and such then the Windows printer usually has to be
configured with a driver capable of outputting that print format. EOM will recognize the print stream as
¤P
assthru
¤
because it is
composed into a printer definition language (PCL, Postscript,...) and just route the stream without DDA modification.
In most cases when sending print streams to EOM the Windows printer is defined with the Generic / Text Only driver. We want to
use EOM as the print engine (i.e. use DDA) so it needs to receive text. The application writes simple text to the Windows printer,
the Windows printer sends the print stream to EOM where the Print Attribute and DDA configurations can then manipulate the print
stream.
Great - except that there may be issues if you are trying to use the EOM embedded email sequences. These sequences require the
escape character (ASCII hex 1B), which MAY be replaced by the Windows Generic / Text Only driver before delivery to EOM. George
McGowan of McGowan Computer Associates, Inc., with help from Andrew Champion, Thomasville Utilities, found that EAE wrote the
sequences properly using standard EAE print commands but the escape characters where replaced with a period as the Windows printer
delivered the print stream to EOM. So, he changed the type of printer used via EAE (an LPR printer instead) and that sent the data as
is.
Notes - Replacing the escape character with a printable character can be avoided if the application uses the Windows API Escape()
function to print, as long as the printer driver defined on the Windows printer supports
¤passthrough printer escape¤ (which the
Generic / Text only driver does).
George had a few notes for EAE users:
Printing from Windows applications continued...
1. In EAE Development create a report with a default device of DI - Direct or TP - Terminal Printer
2. In the CODE of the report
MV; (EMAIL) GLB.STN ROC Alias could be ANYTHING
MV: (TP) GLB.DEVICE
For escape character use @27@
Set up your EA - Address(ees)
EX=TXT - Attachment extension (or use ED for full display name)
ES - The email Subject
EE - Error notification email address
EF - From address to be displayed in received email
MV; (EMAIL) GLB.STN
MV; (TP) GLB.DEVICE
MV; (@27@60@27@S DC-EA=) F30ADDR
ATT; POHD.EMAIL F30ADDR
MV; (@27@60@27@S DC-EX=TXT) F30FILEEXT
MV; (@27@60@27@S DC-ES=) F30SUBJECT
MV; (@27@60@27@S DC-EE=) F30EERR
MV; (@27@60@27@S DC-EF=) F30EFROM
(this example uses UserTags to pass additional information)
MV; ($DEPHDR$) F30DEPCON
ATS; (PURCHASE ORDER) F30DEPCON :EOM USERTAG1 and USERTAG2
ATS; SD-CONBR F30DEPCON :EOM USERTAG3
ATS; SD-PONBR F30DEPCON :EOM USERTAG4
4. ROC define alias by going to AL screen
EMAIL
Defintion LINCLP -S<SERVERNAME of EOM> -P<printer/device set up in EOM> -d
The report runs - directs the OUTPUT to TP which will use the Windows LPR command to send output to EOM.
The report finds the ROC ALIAS (EMAIL) looks at the definition LINCLP is converted to LPR sends the output to EOM Server (this must be EOM Server) and
the device within EOM -P in the defintion of the ALIAS.
ALL of the above are required to insure the output is sent from the report to LPR, to device in EOM, and finally email to appropriate person.
19
EOM News & Views
Issue 23, Summer 2011
Page [ 117 ]
[ 117 ]
Sending SMS messages with EOM
. You have
probably used the EOM email capability to send reports, parts of reports, and possibly even simple messages to notify the
recipient that some event occurred. You can also use that same mechanism to send SMS text messages. Most cell phone
carriers provide an SMS gateway, which means you send the gateway a properly formatted email and it sends out the SMS
message.
The ¤properly formatted email¤ is usually an address consisting of cell phone number to receive the SMS message followed by
the provider address (i.e. "5551234567@txt.att.net") and text in the email subject and/or body. So, you configure an Email
Attribute in EOM with a static email address or you can send the email address via the data stream received by EOM.
There are many resources on the web to find your carrier®s information, a great start is the Wikipedia page ¤List of SMS
Gateways¤ (http://en.wikipedia.org/wiki/List_of_SMS_gateways).
Email Attribute SendSMS1
5551239876@tmomail.net
: EOMSMSNotification@ProdEOM.com
: *** Monthly payroll data has been received by EOM ***
43
EOM News & Views
Issue 23, Summer 2011
Page [ 118 ]
[ 118 ]
PDF creation software - Take two
Last newsletter we briefly described 3 different 3rd party PDF solutions for EOM, boldly stating that the software from Amyuni
was our favorite at this time. Well, we ran into a few problems at a recent customer site visit...
It turns out that if you are running the Amyuni software on a Windows server operating system (2003, 2008) you cannot use
the desktop PDF Creator software. The licensing requires that you purchase the PDF Converter Single Application Server license
($689.00 as of this article). This software allows one application (i.e. EOM) to create PDF files. Getting the PDF Converter
Single Application Server software installed and configured required a few steps on a Windows 2008 64-bit server, thanks to
Kevin Cole from the State of North Dakota and the Amyuni Tech Support team to get this worked out:
1. Order and download the PDF Converter Single Application Server software (do not install yet). You will be required to
submit an application name to be used with this license (¤EomService.exe¤)
2. You will receive an email from Amyuni confirming your order and string values for ¤License to¤ and ¤Activation code¤.
3. The download in our case was a ZIP file. You must unzip this file into a directory that is to remain on the server
(read: do not delete the directory after the installation is done).
4. Verify that the login used to run the EOM service has access rights to the directory. You may need to add the usercode
to the file access privileges for that directory.
5. Open the install.ini file found in the directory, provide an appropriate printer name for the ¤PrinterName¤ property, copy
the ¤License¤ to¤ value into the ¤Licensee¤ property, copy the ¤Activation code¤ value from the email into the ¤LicCode¤
property.
6. Execute the install.exe program from the directory. You will be presented with a simple status of the install.
7. Verify that the login used to run the EOM service has full control rights to the Windows Registry
HKEY_CURRENT_CONFIG / Software / <Printer name> entry. Apparently the PDF driver accesses these registry settings
when executing.
8. Run the ¤config.vbs¤ script from a command prompt, using administrator privileges.
Ÿ For 64-bit servers the command line is: C:\Your_Amyuni_Folder_Location>c:\windows\syswow64\cscript.exe config.vbs
Ÿ For 32-bit servers the command line is: C:\Your_Amyuni_Folder_Location>c:\windows\system32\wscript.exe config.vbs
9. The printer name can now be found in the Windows Devices & Printers. Make sure you modify the properties of this
printer to set the margin to 0.0 inches and 300 DPI. Under Control Panel / Printers and Faxes. Select the printer,
then right-click and select Properties. On the General tab select the Printing Preferences... button, then select the Paper
Settings tab to change the two parameters. Next, select Ok, select the Advanced tab, Printing Defaults... Button then
select the Paper Settings tab to change the two parameters.
10. Finally, you do the EOM configuration steps to define the PDF printer in the EOM Configuration Explorer, Physical
Printers. Note - you may need to stop and then start the EOM service to get the Amyuni printers to function (first
try to print).
This may look like a lot of manual steps ... you are correct. However, once installed the PDF files are created quickly and
appear to be very efficient. Now the really good news - this license allows you to create multiple PDF printers that EOM can
print to simultaneously. This is useful if you are creating a lot of PDF files or have large PDF output files that keep smaller
PDF files waiting. To create additional PDF printers, get to the Amyuni directory, using Administrator privileges, run the
install.exe with a new printer name, as in ¤install.exe PDFPrinterName2¤. Then, define the printer to EOM and likely create a
Logical Printer in EOM to flow control across the PDF printers.
70
EOM News & Views
Issue 23, Summer 2011
Page [ 119 ]
[ 119 ]
Highly skilled, creative, solution provider
focused on the Unisys Enterprise Output
Manager product (formerly known as
DEPCON) with a sense of urgency sums up
who we are and what we do. We provide
general Enterprise Output Manager
consulting,
migrations,
upgrades,
configuration, training, and custom
programming.
On-site services, remote services, and
general consulting are available now.
Why use PGCG? Deep knowledge of the
EOM product integrated into a variety of
customer environments sets us apart. Our
customer’s production environment depends
on solid, working solutions that we provide.
Who are we?
The last Newsletter noted that EOM
supported
SSL/TLS
communication
connections, but failed to note that these
connections are supported from the
ClearPath MCP system too. See section 2.1.6
of the EOM for ClearPath Config & Ops
guide
LOCALSSLSOCKETDEF,
RemoteSSLSOCKEDEF and SSL option on
PrintS device.
Wow. We were pleasantly surprised when an
astute Unisys watcher brought a YouTube
video to our attention. The video does a
great job of defining what EOM is and what
it does. Kudos to Unisys Marketing for
making it happen. View the video vialink
.
DDA gurus - The $CurrentYCoordinate value
is set after a PrintData command, but be
careful: The values returned when using
Print Preview are not accurate. The
workaround is to print to TIF, PDF, or real
printer to get the correct coordinate values.
Need a really good editor? There are many
to choose from, one we like is Notepad++.
There are numerous plugins available, one
of particular interest is the Hex editor. This
editor displays the carriage return, linefeed,
and formfeed characters - makes counting
lines for DDA consumption MUCH easier.
Write
a brief description and send it to
SteveD@PrettyGoodConsultingGroup.com for
future newsletter discussion.
Quick Hits
Both the EOM Basic and Advanced Workshops have been
scheduled. The EOM Basic Workshop, starting September 13th, spans 4 days of 4-hours per day of
remote training. The EOM Advanced Workshop, starting October 3rd, spans 5 days of 4-hours per day
remote training. On-site classes can also be arranged via Unisys Customer Education (800-222-0966 or
email at UnisysCustomerEducation@Unisys.com).
Training is available
Pretty Good Consulting Group, LLC
4235 Ivy Court
Lake Elmo, MN 55042
www.prettygoodconsultinggroup.com
59
newsletter
EOM News and Views
Issue 24, Fall 2011
Compose & Xfer ..................1
DDA Tip............................................1
Interfaces .......................................3
Quick Hits.......................................7
Contact information ........7
PGCG
Pretty Good Consulting Group
Got a problem? We create solutions.
We have been working with an EOM
customer that has over 1,500 remote
printers defined in EOM as type TCP.
They have set up a very nice way to take
advantage of Windows printer features
while still printing to TCP printers. By
the way, it is possible to define all 1,500
of those printers to the Windows Print
Manager, but it sounds like a painful
endeavor.
What this customer did was define a
single Windows printer in EOM, setting
the ¤Print Output file option¤ to ¤Print to
file¤ and the ¤Action to perform¤ to ¤Apply
to File Masks¤. A File Mask identifies the
original file and then ¤prints¤ to the
Windows printer. EOM writes a composed
print stream to a file and then runs the
file back through the File Masking process.
Note that the driver defined on the
Windows Print Manager printer composes
the print stream - so if the printer is
defined with a PCL driver then the print
stream is PCL, if it is defined with
PostScript then the print stream is Post-
Script, and so on. Also note that the
second File Mask used to identify the
loopback composed file might include a
File Mask, File Selection Criteria of ¤Trans-
port Type equal to Loopback¤ to help
identify the returned file.
When the composed file is returned, the
File Mask can either use a Transfer Job to
the remote printer IP address, or a Print
Job to the TCP defined EOM printer. In
both cases the composed file will be
recognized as a Passthru file, but if it
makes you feel better you can set the
loopback File Mask File Type to ¤Passthru¤.
The Print Attribute used for the Print Job
really does not do much because the file
is Passthru.
One of the cool aspects of this approach
is that most of the File Mask criteria
values are identical between the files (not
Transport Type as noted previously).
Thus, the File Masking logic is still based
Using Windows to compose, TCP printer to send
Documents you may be interested
Documents you may be interested
