On Wed, Aug 27, 2014 at 7:27 AM, Elardus Engelbrecht <[email protected]> wrote: > John McKown wrote: > >>YASI -> Yet Another Strange Idea. > > Ah, YASA (Yet Another Strange Acronym!) ;-D > > >>A legacy program can read or write a z/OS UNIX file via QSAM via a normal DD >>statement by using the PATH= instead of DSN=. > > Define 'legacy'. That is a dirty word for me. I don't really like it 'they' > say mainframe is 'legacy'. :-[
What is a good word for "like we did it on OS/360". I.e. something which is designed to run in z/OS batch using sequential data sets (versus z/OS UNIX files). > > With quotes and with upper/lower case taken in account, it should not be a > PITA. > > >>I really wonder if this would be of any use in a z/OS environment. >>//INPUT DD URL='file:///etc/resolv.conf' >>//INPUT DD URL='http://some.web.site/download/filedata.txt' >>//INPUT DD URL='ftp://user:password@host/download/filedata.txt' > > It would be useful if you used it in READ mode, but then the files must be in > the right format. I'm just a little uneasy about write mode (see below). Yes, I should have stated that. This would basically be conceptually similar to reading z/OS UNIX files via the SAM interface in programs which use DCBs. (aka "legacy" programming). > > >>and so on. It might even be interesting if someone would create a "CURL" >>subsystem which could do the above. This could be modeled after the cURL >>ported command. > >>Well, back into my hole for a time. > > No, come back! That is an order! :-) > > Before you go hiding and leaving all of us , tell me how are we all going to > apply *proper* security on these cURL objects? What security does the z/OS UNIX "curl" command use? This would duplicate that. Which basically defers security to the "remote" site and whatever _it_ uses. Normal ftp uses userid/password, although some use digital certs. http either uses none (unsecured) or asks for a userid/password or a digital cert. > > What about translating domain names into IP addresses? Metadata? Firewalls? > RACF SERVAUTH profiles? ASCII / EBCDIC translation? Codepages, etc? For all the above: the same way curl does. This would require that the subsystem accept parameters specified in the JCL. The subsystem would also be sensitive to the LRECL=, RECFM= on the DD statement. Just as is done for a z/OS UNIX file accessed via SAM. Thing of this as if it replaced a step doing a curl command to copy from a "site" into a z/OS UNIX file, and the next step then reading that z/OS UNIX file. Or like piping the results of a curl into another program. > > If RACF for example allows it, how will the machine which hosts those remote > files, react on such requests? Perhaps with 200 (hopefully), or with 404 or > 403 results? How the remote host reacts is up to the remote host. Interpreting the data returned by the remote host would need to depend on it properly implementing the appropriate RFC. I.e. send the proper HTTP code, or ftp return code when the z/OS system tries to connect and access. If there is any problem, the CURL subsystem will need to issue some sort of abend, or maybe an RC, and not actually OPEN the DCB. > > If RACF is the deciding authority, will it honor the contents of > 'robots.txt'? [1] I don't know how "robots.txt" fits into this scheme. This is not what I would consider a robot. It isn't used to scan random web/ftp/??? sites looking for things. It is more like a user sitting in front of a browser and typing in the URL. It is a specific "person" asking for a specific, known, data source. > > Now you may go back to your hole. And I'm hiding under my rock. ;-) > > Groete / Greetings > Elardus Engelbrecht > > [1] - Sample contents, this one simply disallow all and everything including > subfolders too: > > User-agent: * > Disallow: / > Having been forced to think a bit deeper on this, what might be simplest would be to implement a subsystem called CURL. This subsystem basically reads the information in the SUBSYS=. It then sets up a UNIX pipe, runs the actual UNIX curl command, customized with the parameters on the SUBSYS=, and reads from the pipe. This would be relatively easy to implement. The better way is to get the current source to curl and modify it to be a real z/OS subsystem. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
