Re: Remote Unconnected

Al

<This is a vendor response.>

We have a product that can read POP3 mailboxes and put the emails into the IFS 
or into PF members. Then your 400 program could process them. The idea is to 
have a sufficiently-formatted email sent by a browser or a PC app, so that you 
could parse it out in an application.

If this sounds interesting, please feel free to call me (or anyone) at 
888.rjs.soft

Thanks
Vern

-------------- Original message -------------- 
From: Al Mac <macwheel99@xxxxxxxxxxx> 

> What's Al's question? 
> What all is needed on PC end and on 400 end to do data entry to 400 
> applications on a PC not connected to the 400? 
> I think it is doable, but I think it would be frightfully expensive to 
> implement, unless I am missing something about existing readily available 
> resources. 
> 
> I got an odd question from work. 
> "Al, is it possible to have a 400 session without having an AS/400" 
> I mumbled about in theory various AS/400 languages could also run on a PC, 
> and reminisced about my old punched card days, like "key to diskette", with 
> equipment that went off the market 40 years ago ... whatcha looking to do 
> on it? 
> 
> Transpires they looking for data entry alternatives to sending a file over 
> e-mail or direct communications attachment, where a PC gets a 400 session 
> like via VPN ... is it practical to key in a data batch on a PC, then have 
> the transaction batch arrive in person or snail mail on some media then 
> stick it into the 400 as input, and what equipment and software needed to 
> do that? 
> 
> There's already a CD Rom drive on the 400, intended for IBM OS upgrades, I 
> suppose there must be some way for normal 400 software to access normal 
> data there, I just have never worked with any. However, it probably would 
> be more efficient, from a performance perspective, to copy whatever is on 
> the CD to hard disk, then have 400 software process it there. 
> 
> You can only put 1/2 a Gig on a CD. You can put much more on a tape, but 
> CD drives are standard on PCs, and I seriously doubt PC tape drives are 
> compatible with what the 400 needs for backup. 
> 
> The PC application would have to know what layout is needed for the data in 
> the file. There would have to be conversion of the data format from 
> PC--ASCII to 400-EBCDIC, all the stuff taken care of thru Client Access and 
> Data Transfers ... Oh, say the data could go from PC-unconnected then 
> PC-connected-to-400 data transfer, on PC media whether CD Rom or Diskette, 
> although I have had some troubles with CD formats can only be read by 
> certain CD software. 
> 
> The 400 application would have to be modified to be able to accept a batch 
> of transactions this way, simulating a real human being, where normally the 
> user keys in some vendor # or order #, and the data is accepted if it meets 
> certain valid combinations, and there is no provision for handling data 
> entered that is not valid, which includes incomplete input where some 
> mandatory field is not filled in with something valid, and the data to the 
> 400 application results from a combination of what the user entered, and 
> what happened when the control #s are validated. 
> 
> I did such a modification on the old System/36 where they wanted scrap 
> transactions recorded, but felt they were too much trouble to key in. I 
> got the scrap data from another application, cloned the data entry program 
> then simulated what it did with human keystrokes, only supplied the data 
> stream from my work file instead of a real human being. 
> 
> - 
> Al Macintyre 
> http://en.wikipedia.org/wiki/User:AlMac 
> http://www.ryze.com/go/Al9Mac 
> BPCS/400 Computer Janitor ... see 
> http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html 
> -- 
> 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. 
>