Hello Frank,
I agree with Bradley. An email message mostly can be in either text or HTML formats, and all other file types can only be attached to the message (although many email clients show icons for attached files inside the message, they still need to be clicked on to be opened).
We are in the process of introducing a web based tool called Re-Distribute, if you would like to take a look, that will format your spool file into a PDF file, which can be overlayed with logos or form / letterhead layouts, and then the files can be emailed either manually or automatically. The spool file can be split into multiple parts as well, and then each part emailed separately.
It is a web based tool, and besides PDF, we can also convert spool files to Charts & Excel CSV files, that can be viewed online in the browser as well. It is designed to be much simpler to use than Infoprint.
Please take a look at www.systsoft.com/redistribute and let me know if you have any questions.
Thanks & Regards,
Vaibhav Jabulee
Vice President
Systems & Software (www.systsoft.com)
Mobile: + 91 - 98208 80525
Phone: + 91 - 22 - 2829 0075, 2829 0803
Unit 123, SDF 4, SEEPZ, Mumbai - 400096, India.
----- Original Message -----
From: midrange-l-request@xxxxxxxxxxxx
To: midrange-l@xxxxxxxxxxxx
Sent: Thursday, April 02, 2009 12:09 AM
Subject: MIDRANGE-L Digest, Vol 8, Issue 567
Send MIDRANGE-L mailing list submissions to
midrange-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/midrange-l
or, via email, send a message with subject or body 'help' to
midrange-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
midrange-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MIDRANGE-L digest..."
*** NOTE: When replying to this digest message, PLEASE remove all text unrelated to your reply and change the subject line so it is meaningful.
Today's Topics:
1. Re: Removing a message from the job log (Vern Hamberg)
2. Fwd: Infoprint (fbocch2595@xxxxxxx)
3. Re: Capturing expect session (Scott Klement)
4. Re: Non displayable characters in a PF (CRPence)
5. Re: Fwd: Infoprint (Bradley V. Stone)
6. Re: Fwd: Infoprint (rob@xxxxxxxxx)
7. Re: Removing a message from the job log
(Dean.Eshleman@xxxxxxxxxxxxxx)
8. Re: Infoprint (fbocch2595@xxxxxxx)
----------------------------------------------------------------------
message: 1
date: Wed, 01 Apr 2009 12:17:39 -0500
from: Vern Hamberg <vhamberg@xxxxxxxxxxx>
subject: Re: Removing a message from the job log
Dean
An old but venerable technique is to send a message before a process
with a msg key, do the process, then send another message with a msg key
- you have to receive both to get the keys. Then you loop between the
keys and check for the ID you want to remove - very fast, cuz it
encompasses very few messages. It doesn't matter where the messages came
from.
Here is a link to the IBM document with how to do this. It has examples
in CL and C - use the C example to see how to call the QMHRCVPM API by
key for this process.
*
http://tinyurl.com/d4a6xx
*HTH
Vern
Dean.Eshleman@xxxxxxxxxxxxxx wrote:
> I have an SQLRPGLE program that executes a close cursor instruction at the
> beginning of the program. Sometimes, this generates a message in the job
> log "Cursor SQL_EXTRACT not open." I would like to remove the message
> from the job log when this happens. However, I'm not sure if I can. When
> I look at the details of the message, the from program and to program are
> both QSQRUN4 which is probably below my program in the call stack. I
> tried using the QMHRCVPM API to retrieve the message, but no luck. Can I
> remove this message?
>
> I guess my other option is to prevent the message in the first place. I
> guess I'll look into that as well.
>
> Dean Eshleman,
> MMA, Inc.
>
> ______________________________________________________________________
> Confidentiality Notice: This information is intended only for the individual or entity named. If you are not the intended recipient, do not use or disclose this information. If you received this e-mail in error, please delete or otherwise destroy it and contact us at (800) 348-7468 so we can take steps to avoid such transmissions errors in the future. Thank you.
>
------------------------------
message: 2
date: Wed, 01 Apr 2009 13:48:50 -0400
from: fbocch2595@xxxxxxx
subject: Fwd: Infoprint
Hello, I'm working on a project to?embed pdf's in emails and have been told that infoprint can accomplish this.? Is that true and?does anyone have experience in using infoprint to do that?? What should happen is that a pdf gets emailed and when the user?opens?the email the report appears (we don't want them to click on an attachement).
Thanks, Frank???
------------------------------
message: 3
date: Wed, 01 Apr 2009 13:00:55 -0500
from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
subject: Re: Capturing expect session
Hi John,
So the problem is that expect isn't returning enough information, and
you can't see what's going on? That being the case, I'd add the -d
switch to expect... that should make it report more information. A word
of warning, though: You'll see the information the way Expect receives
it, and the way expect "thinks" of it... which might be a little
confusing if you're not used to the way expect "thinks."
You currently invoke expect like this:
build_script | /usr/local/bin/expect -f -
Change it to
build_script | /usr/local/bin/expect -df -
I would also remove the -v from the sftp line -- because you're going to
get waaaaay too much output with -v... it'll be like a needle in a
haystack trying to find what you're looking for. That's my experience,
anyway.
As an aside.. I wonder why you're using sftp instead of scp? Since all
you're doing is sending two files -- really nothing sophisticated at all
-- why not just use the simpler tool?
John McKee wrote:
> All I see so far are the commands being sent by the send command. I
> would like
> to see everything being received. I thought about wrapping the entire script
> with a shell, but I am doubtful that will work. I am thinking that the expect
> program might not pass on received data. I wonder if there is some way
> to pipe
> the sessio through tee so that expect can do wht it needs to do but I would
> still have the original stream.
>
> I am not sure how to have the script run and capture what expect is
> receiving. What adds to the mess is if I try to run the script, the
> other side may run a
> process to sweep the received file to another location. I have been told that
> files are swept and that they aren't. My coworker has been tying up his
> computer using FileZilla. And, when he looks oments later, the files are not
> there. A straight answer from them would be nice. All I can get is what
> minimal information that is being captured by the standard event log - which I
> learned was not much in previous conversations.
>
> Is there any issue with attempting to send multiple large files?
> Tomorrow, I am
> going to try this thing with only one file. If that works, I might
> just invoke
> two sftp sessions to get the files transferred, one after the other. Would
> have been nice to have had both go in a single sFTP session. I was
> told that a
> single file transfer seemed to work, at least one time. But, that was had to
> prove due to the file sweeping that may or my not have been suspended. The
> best contact I have had there was somebody who had a script tht could be used
> to invoke FileZilla. He did not create it. He claims that all their
> users use
> FileZilla. When I hear the word "all", I get suspicious as to what is really
> going on on their end.
>
> John McKee
>
> John McKee
>
> Quoting Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>:
>
>> What sort of troubles are you having capturing the session?
>>
>>
>> John McKee wrote:
>>> I am still having problems with communicating with this Windows box
>>> using sFTP.
>>> I put different exit values in the script for each expect instruction.
>>>
>>> The files that need to be sent are 500+ MB each, and there are two
>>> of them. The
>>> expect script is doing one of two things now: 1) exiting with a
>>> return code I
>>> have assigned to the last expect, where I am just looking for the
>>> sftp> to send
>>> a quit, or 2) exiting waiting for the password prompt.
>>>
>>> I had thought that the size of the files might have been a factor in
>>> the wait
>>> time. More an act of desperation than anything else approaching rational
>>> thinking. I bumped it up to an insanely high numer. Only thing that gets
>>> effected is how long I have to wait for the script to error out. I also
>>> thought the jobq might be a factor. Normally, I have been sending this to
>>> QBATCH. I don't recll the upper limit on active jobs in that jobq,
>>> but do know
>>> it is high enough that a number of jobs start and end. Last night,
>>> I submitted
>>> to QTXTSRCH, which, as far as I can remember, has no limit set on
>>> active jobs.
>>> Same results.
>>>
>>> I was wondering if I can capture the session in a log. I want to be
>>> able to see
>>> what expect is receiving as well as what is being sent. Is it possible to
>>> redirect the session to a log file and still have expect work?
>>>
>>> The people at the remote site are positive this is on my end. Something is
>>> getting lost, that is obvious. Why FileZilla works and this script
>>> does not is
>>> becoming a hassle. A coworker has been running FileZilla and has
>>> told me that
>>> transfer time is inexcess of two hours.
>>>
>>> Any ideas on how to get a handle on what is going on?
>>>
>>> John McKee
>>>
>> --
>> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>> To subscribe, unsubscribe, or change list options,
>> visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
>> or email: MIDRANGE-L-request@xxxxxxxxxxxx
>> Before posting, please take a moment to review the archives
>> at
http://archive.midrange.com/midrange-l.
>>
>>
>
>
>
------------------------------
message: 4
date: Wed, 01 Apr 2009 13:12:30 -0500
from: CRPence <CRPbottle@xxxxxxxxx>
subject: Re: Non displayable characters in a PF
David FOXWELL wrote:
> I'd like to be able to understand why when the characters are
> pasted to the screen by the user, they are not visible.
> However, when validated, the unwanted data is available to
> the RPG program and get written to the file. <<SNIP>>
The EBCDIC bytes of data that are 5250DS control characters take a
position in the data stream, but each is not manifest as\with a visible
glyph; for lack of a glyph, its position might appear to be a space
character, regardless that it is in fact neither a 0x40 nor 0x41 in
EBCDIC [both /space/ characters; x'41' is for most CCSIDs]. Some ASCII
control characters will translate into mapped /equivalence/ characters
or simply paste as the untranslated code point; i.e. the ASCII tab may
become an EBCDIC tab, but an ASCII byte which has no specific mapping to
EBCDIC may paste as the same hex byte value.
An earlier question about why DSPPFM /shows/ them is a simple case of
that program [QNFBROWS] using the translate instruction to convert all
non-displayable [i.e. mostly the control characters] into a /blob/
character [I do not recall its hex value]. Thus instead of showing no
glyph, the equivalent of a space, the DSPPFM purposely represents each
non-display-capable character [position] with a glyph which is basically
all points of the block being lit; i.e. the /blob/ versus any typical
keyboard character which might more easily be confused with real data.
An emulator may provide a translation table to enable changing the
characters that are pasted. There may also be a /paste as text/ feature
for an emulator which would automate such a translation with its own
pre-defined translation table.
Regards, Chuck
------------------------------
message: 5
date: Wed, 01 Apr 2009 13:11:32 -0500
from: "Bradley V. Stone" <bvstone@xxxxxxxxxxxx>
subject: Re: Fwd: Infoprint
The only way this would work is if the PDF was converted to am image and
inserted into the email, or converted to HTML.
PDF "as" the email is something that, even if it did work, would rely
heavily on the email client of the user.
So if PDF is what you want, attachment is what you'll most likely end up
with. But, if you want to make emails "pretty" then HTML is your best
bet. Even that opens up another can of worms.
Bradley V. Stone
BVSTools, Inc.
www.BVSTools.com
www.eRPGSDK.com
fbocch2595@xxxxxxx wrote:
Hello, I'm working on a project to?embed pdf's in emails and have been told that infoprint can accomplish this.? Is that true and?does anyone have experience in using infoprint to do that?? What should happen is that a pdf gets emailed and when the user?opens?the email the report appears (we don't want them to click on an attachement).
Thanks, Frank???
------------------------------
message: 6
date: Wed, 1 Apr 2009 14:23:51 -0400
from: rob@xxxxxxxxx
subject: Re: Fwd: Infoprint
It will be an attachment. To do what you want sounds sort of like html
formatted email or some such thing.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From:
fbocch2595@xxxxxxx
To:
midrange-l@xxxxxxxxxxxx
Date:
04/01/2009 02:03 PM
Subject:
Fwd: Infoprint
Sent by:
midrange-l-bounces@xxxxxxxxxxxx
Hello, I'm working on a project to?embed pdf's in emails and have been
told that infoprint can accomplish this.? Is that true and?does anyone
have experience in using infoprint to do that?? What should happen is that
a pdf gets emailed and when the user?opens?the email the report appears
(we don't want them to click on an attachement).
Thanks, Frank???
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
------------------------------
message: 7
date: Wed, 1 Apr 2009 14:37:55 -0400
from: Dean.Eshleman@xxxxxxxxxxxxxx
subject: Re: Removing a message from the job log
Vern,
Thanks for the tip. I never would have thought of that option. I'll
check it out.
Dean Eshleman,
MMA, Inc.
On Wed, 01 Apr 2009 12:17:39 -0500, in midrange.midrange-l you wrote:
>Dean
>
>An old but venerable technique is to send a message before a process
>with a msg key, do the process, then send another message with a msg key
>- you have to receive both to get the keys. Then you loop between the
>keys and check for the ID you want to remove - very fast, cuz it
>encompasses very few messages. It doesn't matter where the messages came
>from.
>
>Here is a link to the IBM document with how to do this. It has examples
>in CL and C - use the C example to see how to call the QMHRCVPM API by
>key for this process.
>
>*
http://tinyurl.com/d4a6xx
>
>*HTH
>Vern
>
>Dean.Eshleman@xxxxxxxxxxxxxx wrote:
>> I have an SQLRPGLE program that executes a close cursor instruction at
the
>> beginning of the program. Sometimes, this generates a message in the
job
>> log "Cursor SQL_EXTRACT not open." I would like to remove the message
>> from the job log when this happens. However, I'm not sure if I can.
When
>> I look at the details of the message, the from program and to program
are
>> both QSQRUN4 which is probably below my program in the call stack. I
>> tried using the QMHRCVPM API to retrieve the message, but no luck. Can
I
>> remove this message?
>>
>> I guess my other option is to prevent the message in the first place. I
>> guess I'll look into that as well.
>>
>> Dean Eshleman,
>> MMA, Inc.
>>
>> ______________________________________________________________________
>> Confidentiality Notice: This information is intended only for the
individual or entity named. If you are not the intended recipient, do not
use or disclose this information. If you received this e-mail in error,
please delete or otherwise destroy it and contact us at (800) 348-7468 so
we can take steps to avoid such transmissions errors in the future. Thank
you.
>>
______________________________________________________________________
Confidentiality Notice: This information is intended only for the individual or entity named. If you are not the intended recipient, do not use or disclose this information. If you received this e-mail in error, please delete or otherwise destroy it and contact us at (800) 348-7468 so we can take steps to avoid such transmissions errors in the future. Thank you.
------------------------------
message: 8
date: Wed, 01 Apr 2009 14:38:35 -0400
from: fbocch2595@xxxxxxx
subject: Re: Infoprint
Thanks Bradley.
-----Original Message-----
From: Bradley V. Stone <bvstone@xxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Wed, 1 Apr 2009 2:11 pm
Subject: Re: Fwd: Infoprint
The only way this would work is if the PDF was converted to am image and
inserted into the email, or converted to HTML.
PDF "as" the email is something that, even if it did work, would rely
heavily on the email client of the user.
So if PDF is what you want, attachment is what you'll most likely end up
with. But, if you want to make emails "pretty" then HTML is your best
bet. Even that opens up another can of worms.
Bradley V. Stone
BVSTools, Inc.
www.BVSTools.com
www.eRPGSDK.com
fbocch2595@xxxxxxx wrote:
Hello, I'm working on a project to?embed pdf's in emails and have been told
that infoprint can accomplish this.? Is that true and?does anyone have
experience in using infoprint to do that?? What should happen is that a pdf gets
emailed and when the user?opens?the email the report appears (we don't want them
to click on an attachement).
Thanks, Frank???
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
------------------------------
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
End of MIDRANGE-L Digest, Vol 8, Issue 567
******************************************
---------------------------------
Systems & Software, Mumbai, India
midrange.com
