(See the manual starting around page 271 and take note of the ASCII file
processing rules. If it looks like this may work, give me an e-mail and
I'll lend you a hand.)
Dave Dick
CSI International
www.csi-international.com (powered by Entree)
1-800-795-4914
da...@csi-international.com
Catch the WAVV!
World Alliance of VSE and VM conference
WAVV 2009 Orlando, Florida
May 15-19, 2009
Allan Peterson wrote:
> What options have I got in extracting printout from the Power Q and converting it to XML.
>
> Noting no TCP/IP stack, only BIM PC File Transfer and HIS Servers
> VSE/ESA 2.3.1
>
> TIA
>
> Allan
>
>
> ________________________________
>
> From: owner...@Lehigh.EDU on behalf of Jan Canavan
> Sent: Thu 7/3/2008 8:35 AM
> To: VSE Discussion List
> Subject: Anyone have a Job Analyst-scheduler description?
>
>
>
> Anyone have a Job Analyst-scheduler description?
> They are looking more for the type of technical experience that this position would
> require.
>
> tia
>
>
> Jan Canavan
> j_ca...@earthlink.net
> VSE/VM SYSTEMS PROGRAMMER
>
> Allan Peterson
> Network/Infrastructure Specialist Team Leader
> DDI: 09 442 8615 | Mobile: 021 750 529 | Fax: 09 442 8601
> Email: Allan.P...@revera.co.nz | Web: www.revera.co.nz
> --------------------------------------------------------
>
> WARNING:This email and any attachments contain private communications. If you are not the intended recipient, you are not entitled to read, use, disseminate, distribute or copy this email and/or its attachments (if any). If you have received this email in error, please immediately notify the sender by return email and delete this email and any attachments from your system.
> P Please consider the environment before printing this e-mail
>
>> but it could potentially be useful on VSE since the source code is
provided. <<
I went to the cited page...it is a solution that works NOT in VSE.
--
Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de
Here are my assumption:
You need it to process the data on another platform.
The other platform accepts data in XML to make available all kind of
possibilities which you will not use.
-----------------------------------------------
Here is an answer under above assumptions:
Dicks solution is a usable way (MHO).
I have a program (PRT2CSV) sitting here somewhere that converts a
printout to a CSV-file. All lines are converted to a CSV with an extra
indication of a new page and an extra indication of number of fields.
The program was originaly written for an MVS site and ment to be
adjusted after first use (because the ideas of what they needed was a
little fuzzy). But then first attempt filled already all needs.
-----Original Message-----
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of
Allan Peterson
Sent: Thursday, July 03, 2008 5:58 PM
To: VSE Discussion List
I agree with Kevin; it's no great shakes! I started creating XML
from COBOL over 6 years ago. The output file was variable in length. It
is easiest if you have a sub-routine that will remove imbedded blanks.
Otherwise, you just need to pair up the "tags" to the "data".
In truth, it MIGHT even be easier to create using Rexx - since
string manipulation is much easier there.
Ask for the schema & you'll see it's simpler than it sounds.
David Wakser
Without getting into the whys and wherefores ...
Replacing a Cobol program that generates customer facing printout using
DJDE's with one that puts out effectively the same in XML to a vsam
file.
We currently have to poweroffload the DJDE stuff to a reel tape (yes
really...) the reel tape gets sent to a print house where the XEROX has
a tape drive ...there are no spares for this tape drive.
Thus with the vsam file we can transfer/ftp it to any print house , the
customer etc etc
Noting that there are more than 10 such programs that would need to be
converted.
There are literally hundreds of print programs that generate "greenbar"
reports and hundred thousand pages of A4, these are not in scope at this
point for XML and vsam.
I'd be happy to help you; send me some specs (not via the list) and I'll
see what I can put together.
David Wakser
The funny thing about XML it that it's intentions were not as a method of
creating large files for output. Basically, it's designed as a document
interface, not a file interface. Of course, that doesn't mean that people
aren't using it as a file interface. At one shop we get a file from the
Options Clearing Corp. in XML (BTW, it's predesessor was about 20% of the
size in bytes) that requires a Sun server with a 1/2 gigabyte of memory to
parse since the entire document, in this case a file, needs to be in memory
to actually work. So, it may be that XML is being suggested as a panacea
for portability as opposed to really wanting to do anything with it. To say
"XML the report" is really nonsense without an understanding of the need to
create a schema that defines the content. The cases where we had to do this
had a pretty well defined schema requirement from the vendor that we were
going to send the data to describing the content they expected to receive.
If the goal is to be able to use another vendor for printing you may find
that using an good PDF generator with flash overlays actually makes more
sense. If it's mining the content of the reports as XML then someone needs
to provide a schema for the data they wish to obtain.
Kevin P Corkery
Independent Consultant
Voorhees, New Jersey
-----Original Message-----
From: owner...@Lehigh.EDU [mailto:owner...@Lehigh.EDU] On Behalf Of
Allan Peterson
Sent: Thursday, July 03, 2008 9:09 PM