Re: Authorized functions
Correct, although I'm not sure whether TSO/E supports setting REXX variables from an authorized program. You can set rexx variables from an authorized TSO command. For example, the rmm tso commands all do that. However, one of the difficulties we had was when those commands were issued from a rexx environment - all variables to be accessed by the autorized command had to start SYSAUTH. Variables created in the command could be accessed once back in the exec. Rexx does some storage isolation, I believe, between the environments, so that we have seen the authorized command complete successfully - all variables created - but on return to the exec, the storage for the variables is duplicated/moved to another subpool to allow access from the exec. Even the PROFILE VARSTOR(HIGH) didnt help with that one. Mike Wood -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Batch process VS Started task
I would divide the problem into two: 1. how to make the file be transactional. to do this, you can use MQ as the mechanism to write into a file. 2. where to fire the transaction. You can write the message into a queue managed by CICS and LINK to the application program (not START TRAN that will cause a lot of overhead on CICS). CICS will give you fine recovery and error handling and minimize the changes you need to make in the current program (is you run in under OTE). other alternatives are MQ to DB2 and define a trriger on the table to fire a Cobol (or other language) stored procedure. ITschak On Mon, Feb 20, 2012 at 9:03 AM, Magen Margalit syste...@gmail.com wrote: Hi. The records arrives from a few sources to a few seq files The collection process collect the records from the files and then the batch process begins. In the new situation, the batch process or STC will handle each record and the collection process will be eliminated. Regarding the maintenance gap, I'm not concern from a complicated code, but from using functions that IBM will someday will no longer support, i.e. LE functions. When you upgrade a zOS version you contact all the software vendors and check for compatibility to the new zOS version, on a self developed STC you cann't do that... Magen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: If somebody knows this:SysBinLog ?
sysbinlog was an SQL table created by StuxNET worm/virus/malicious code. Part of the virus code was stored in that table. There is an IBM document from 2010 available: An inside look at Stuxnet. Cheers Michael Von:Miklos Szigetvari miklos.szigetv...@isis-papyrus.com An: IBM-MAIN@bama.ua.edu Datum: 2012-02-17 16:32 Betreff:If somebody knows this:SysBinLog ? Gesendet von: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi One of our customer is speaking about SysBinLog in z/OS Maybe somebody knows what is this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
On Sun, 19 Feb 2012 18:11:13 -0600, Joel C. Ewing wrote: Under Windows, a directory is closer functionally to the MVS/DOS concept of a VTOC, as each volume has its own directory and you have to somehow know which volume to consult -- although admittedly in a windows system the number of volumes is typically very low. In Linux, if all volumes are mounted, the directory plays a similar functional role to that of the MVS catalog(s) and VTOCs combined. But in either case they are obviously structurally different: finding an file entry in Windows or Linux requires a progressive search through multiple directory levels rather than just a single lookup of the full path name as with a data set name in an MVS catalog. There's some hint here that the single-level catalog lookup should have a performance advantage over a multi-level directory search. In practice, I find the opposite. Deleting several dozen catalogued data sets takes orders of magnitude longer than deleting a similar number of z/OS UNIX files. Admittedly, our lab configuration precludes a sysplex configuration that might otherwise greatly optimize catalog operations, I am told. In practice, the z/OS search is not single-level; perhaps four: master catalog; user catalog; VTOC; PDS directory. And not mentioned here as yet is that the catalog can index offline volumes and automatically generate mount requests as needed. But this distinction seems to be vanisning. I have become accustomed on Solaris to receiving, infrequently, a message on my terminal that some file is temporarily unavailable; I must wait for it. I take this to mean that something analogous to HSM recall is in progress. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Batch process VS Started task
On Sun, 19 Feb 2012 15:25:32 -0600, Magen Margalit syste...@gmail.com wrote: One idea that came up is to convert the process to a self developed STC which will be triggered by a record on an MQ queue and will run as STC all the batch process programs I think MQ is indeed a very good way to collect these records. You have plenty of configuration options in there to cater for recoverability (or not, if you don't need it), etc. And CICS or IMS can be used at the other end to drain the queue; using MQ triggering it becomes even simpler to start these processing transactions. Both CICS and IMS can easily handle the number of transactions and offer excelent recoverability. To me it seems like a bad idea because having a self developed STC in production create a maintenance gap (and where there is one STC a second one will soon to follow...)... I agree on that. Most shops I know are working to eliminate as much as possible the home-grown stuff for exactly that reason: maintenance headache... Are there any self developed STC's at your shop? We do have one. It caters for a very specific need of authentication in a client/server context. And each time we upgrade z/OS, we spend a lot of time testing... Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: If somebody knows this:SysBinLog ?
Hi Thank you, Hope not so dangerous, they refer I think something like JOBLOG or SYSLOG or JESMSGLG , but they are using this phrase. We will ask On 2/20/2012 10:08 AM, Michael Klaeschen wrote: sysbinlog was an SQL table created by StuxNET worm/virus/malicious code. Part of the virus code was stored in that table. There is an IBM document from 2010 available: An inside look at Stuxnet. Cheers Michael Von:Miklos Szigetvarimiklos.szigetv...@isis-papyrus.com An: IBM-MAIN@bama.ua.edu Datum: 2012-02-17 16:32 Betreff:If somebody knows this:SysBinLog ? Gesendet von: IBM Mainframe Discussion ListIBM-MAIN@bama.ua.edu Hi One of our customer is speaking about SysBinLog in z/OS Maybe somebody knows what is this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: If somebody knows this:SysBinLog ?
Do you have a file called /Sys/Bin/Log by any chance ? Jim McAlpine On Mon, Feb 20, 2012 at 12:02 PM, Miklos Szigetvari miklos.szigetv...@isis-papyrus.com wrote: Hi Thank you, Hope not so dangerous, they refer I think something like JOBLOG or SYSLOG or JESMSGLG , but they are using this phrase. We will ask On 2/20/2012 10:08 AM, Michael Klaeschen wrote: sysbinlog was an SQL table created by StuxNET worm/virus/malicious code. Part of the virus code was stored in that table. There is an IBM document from 2010 available: An inside look at Stuxnet. Cheers Michael Von:Miklos Szigetvarimiklos.szigetvari@**ISIS-PAPYRUS.COMmiklos.szigetv...@isis-papyrus.com An: IBM-MAIN@bama.ua.edu Datum: 2012-02-17 16:32 Betreff:If somebody knows this:SysBinLog ? Gesendet von: IBM Mainframe Discussion ListIBM-MAIN@bama.ua.edu Hi One of our customer is speaking about SysBinLog in z/OS Maybe somebody knows what is this. --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
On Mon, 2012-02-20 at 08:42 +0100, R.S. wrote: snip What is cool is that SMS storage group. Usually users do not see the volumes, they see dasd space. In case of shortage you can simply add some volumes to the group. You can even buy new box and simply add it to the group. And that's really cool IMHO. You'd like LVM2 on Linux. You assign your physical disk partitions to a physical volume group (conceptually like an SMS volume group). You can then divvy up the space in that group into various sized logical volumes. This is then initialized with a filesystem with mkfs (equivalent to ICKDSF, I guess). If the filesystem runs out of space, and you used the proper type of filesystem (there are many), you simply expand the size of the logical volume into unused space in the group. You then resize the filesystem. If you used ext4 or btrfs, I think you can do this while it is in use. If you used ext3, I think you need to unmount it (take it offline) to resize it. If you're out of space in the volume group, buy another disk and initialize it into the physical volume group, then expand. logical volume space does not need to be physically contiguous. -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: R.S. r.skoru...@bremultibank.com.pl wrote in message news:4f41f979.3010...@bremultibank.com.pl... deleted What is cool is that SMS storage group. Usually users do not see the volumes, they see dasd space. In case of shortage you can simply add some volumes to the group. You can even buy new box and simply add it to the group. And that's really cool IMHO. And SMS's granularity is also cool. If you add your 1TB disk to a storage group, you cannot use this space in anther SG anymore. If you have 1TB of 3390-54's, you can give to and take from SMS storage groups any required amounts at any time. You don't have to empty the volumes? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
Mike Schwab mike.a.sch...@gmail.com wrote in message news:cajtoo5_brjh+-ojaqd9jq17cojfbbjuzddhi35yuk33zj_n...@mail.gmail.com ... On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: R.S. r.skoru...@bremultibank.com.pl wrote in message news:4f41f979.3010...@bremultibank.com.pl... deleted What is cool is that SMS storage group. Usually users do not see the volumes, they see dasd space. In case of shortage you can simply add some volumes to the group. You can even buy new box and simply add it to the group. And that's really cool IMHO. And SMS's granularity is also cool. If you add your 1TB disk to a storage group, you cannot use this space in anther SG anymore. If you have 1TB of 3390-54's, you can give to and take from SMS storage groups any required amounts at any time. You don't have to empty the volumes? -- Mike A Schwab, Springfield IL USA Details, details. I *can* take 100GB from this SG which I can't from a 1TB single volume. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
glen herrmannsfeldt g...@ugcs.caltech.edu writes: It would seem less likely that they would use the exact same replacement algorithm, but could eventually lock, anyway. re: http://www.garlic.com/~lynn/2012b.html#98 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012b.html#100 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012c.html#16 5 Byte Device Addresses? least recently used is well studied characteristic ... that says that of all the current virtual pages ... the current least recently used page is the least likely to be used in the future. since the least recently used page is the least likely to be used in the future it becomes the basis for LRU replacement algorithms ... trying to select the least likely to be used page (based on being the least recently used). so lots of systems have implemented LRU replacement algorithms based on well studied program behavior ... although they all may have slightly different code implementations ... they would tend to select approximately the same virtual page for replacement. so running a LRU strategy under a LRU strategy ... vm370 will look at all the virtual machine pages and select the least recently used for replacement. The guest operating system will be looking at all its virtual pages and select the least recently used for replacement. The issue is that the guest virtual page that is selected for replacement occupies a guest virtual machine page ... and useage patterns are based on the same criteria. The result is vm370 will remove/replace a virtual machine page when it hasn't been used while the guest operating system will select the contents of the same virtual machine page for its replacement and start using that same virtual machine page with a different guest operating system virtual page. The effect is from the vm370 stand-point, the guest operating system is violating all the studies that have shown that the least recently used (virtual machine) virtual page is the least likely to be used in the future (because the guest operating system wants to select that same virtual machine page for use for replacement). There are other ways of treaking the algorithms. Lots of the AOS protype stuff for what would become OS/VS2 SVS came from cp67 ... like cp67's channel program translator, CCWTRANS was cobbled into the side of EXCP processing. However the POK performance group came up with a tweak for SVS LRU-replacement algorithm, before it first shipped. They observed if they selected/replaced non-changed LRU pages before changed pages ... they wouldn't first have to write the current virtual page to disk before being able to fetch the replacement page into the location. I argued strongly against it since it significantly distorted the LRU relationship ... but they went ahead anyway. Well late into the MVS release cycle, they discovered that the strategy resulted in choosing for replacement; higher-use, shared, non-changed linkpack virtual pages before lower-use, non-shared, private, changed application specific virtual pages. The cast had changed in POK and new people got awards for fixing the earlier work having done it wrong ... and somebody eventually contacted me if something similar could be fixed in vm370. My reply was that I had never done it that way since I was undergraduate in the 60s. lots of past posts mentioning virtual memory management and page replacement algorithms http://www.garlic.com/~lynn/subtopic.html#clock My 60s undergraduate work got me sucked into an academic uproar ... Jim Gray had left for Tandem but at 14-16Dec1981 ACM SIGOPS meeting asked me if I could lend a hand with somebody trying to get their Stanford PHD. It involved an area that I had originally worked on as undergraduate in the 60s. I had done something different than what was being done in the academic circles in the 60s. The primary person behind the 60s academic work was violently objecting to the Stanford PHD being awarded (because it was in conflict with his work). My work was being shipped in cp67. However, in the early 70s, the Grenoble Science Center had modified their version of cp67 to correspond with the 60s academic strategy. The Cambridge Science Center 360/67 with 768k memory (104 pageable pages after fixed kernel storage requirements) with my strategy gave about the same performance with 80 users as the Genoble Sicence Center 360/67 with 1mbyte memory (154 pageable pages after fixed kernel storage requirements) with 35 users (almost identical workloads). CSC 360/67, with my strategy could support approx. twice the number of users as GCS 360/67 with the academic strategy (and 50% more pageable storage). It was possibly the only direct apples-to-apples comparison of my strategy and the 60s academic strategy. Past post on the subject http://www.garlic.com/~lynn/2006w.html#46 the above contains this response that I was finally allowed to send nearly a year later (after the request at ACM SIGOPS)
Linux LVM vs z/OS SMS Storage Group
On 2/20/2012 5:34 AM, John McKown wrote: On Mon, 2012-02-20 at 08:42 +0100, R.S. wrote: snip What is cool is that SMS storage group. Usually users do not see the volumes, they see dasd space. In case of shortage you can simply add some volumes to the group. You can even buy new box and simply add it to the group. And that's really cool IMHO. You'd like LVM2 on Linux. You assign your physical disk partitions to a physical volume group (conceptually like an SMS volume group). You can then divvy up the space in that group into various sized logical volumes. This is then initialized with a filesystem with mkfs (equivalent to ICKDSF, I guess). If the filesystem runs out of space, and you used the proper type of filesystem (there are many), you simply expand the size of the logical volume into unused space in the group. You then resize the filesystem. If you used ext4 or btrfs, I think you can do this while it is in use. If you used ext3, I think you need to unmount it (take it offline) to resize it. If you're out of space in the volume group, buy another disk and initialize it into the physical volume group, then expand. logical volume space does not need to be physically contiguous. We use LVM on Linux for System z. Unfortunately, it can't handle physical disks that dynamically grow in size. :-( On z/OS, we have two options for enlarging the space available in an SMS storage group: a) we can define new volumes and add them to the group or b) we can dynamically increase the size of the volumes already in the group. We have used the latter approach many times because device addresses are at a premium here, fewer, larger volumes are easier for us to manage, and we don't have to mess with the z/OS IODF, IOCDS, SCDS/ACDS, etc. The new space is just magically available. To grow LVM physical volumes in Linux for z (RHEL6) we had to one-by-one drain (pvmove) the volumes to be resized, remove from LVM, vary offline, dynamically grow, vary online, reformat and add back to LVM. If not enough free space is available in the LVM group to hold the contents of one physical volume, you must temporarily add another appropriately-sized volume to the group before beginning this process and then remove it at the end. Whew! It was so involved that the last time we had a Linux on z space issue, we bit the bullet and just added a new physical volume to the LVM group (after first updating the IODF/IOCDS). :-( -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Batch process VS Started task
IMHO, doing a STC wont make your processing Online. STC is just a STC - making your process running under a STC wont turn it online. If you plan to process the records one by one, I would advice to use a transaction system, such as CICS or IMS. Using a STC like you described will just turn your current process into a batch process that processes a record at time. There are several ways to trigger transactions based on events - just choose one that you have on your installation If you plan to process the records in batches - I would advice do that in batch. You can trigger batch jobs on most of Scheduling softwares based on events - even on record arrival or file creation. You can take a look at your Scheduling software to see what options it has available. Personally i would use the second approach - doing a batch triggered job. A batch job can process any kind of file (seq, vsam, databases) and you can program nice recovery without creating a maintenance nightmare. The only exception to this is if you have a business need to process each record as soon it arrives. ET Lima Mensagem Original From: Jan MOEYERSONS jan.moeyers...@adelior.be To: IBM-MAIN@bama.ua.edu Sent: Seg, Fevereiro 20, 2012 9:47 am Subject: Re: Batch process VS Started task On Sun, 19 Feb 2012 15:25:32 -0600, Magen Margalit syste...@gmail.com wrote: One idea that came up is to convert the process to a self developed STC which will be triggered by a record on an MQ queue and will run as STC all the batch process programs I think MQ is indeed a very good way to collect these records. You have plenty of configuration options in there to cater for recoverability (or not, if you don't need it), etc. And CICS or IMS can be used at the other end to drain the queue; using MQ triggering it becomes even simpler to start these processing transactions. Both CICS and IMS can easily handle the number of transactions and offer excelent recoverability. To me it seems like a bad idea because having a self developed STC in production create a maintenance gap (and where there is one STC a second one will soon to follow...)... I agree on that. Most shops I know are working to eliminate as much as possible the home-grown stuff for exactly that reason: maintenance headache... Are there any self developed STC's at your shop? We do have one. It caters for a very specific need of authentication in a client/server context. And each time we upgrade z/OS, we spend a lot of time testing... Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
was: Abend S0C4 in an internal sort
I wish to continue this thread as it's related. I'm now running my program with internal calls to DFSORT and it works fine except for one issue that I have, namely that I get a lot of job log messages generated as a result of dynamic allocation of VIO sortwork files. DFSORT is invoked 1000's of times by the program (yes, I know but there is nothing I can do about that) and each time it creates a bunch of job log messages for VIO allocations. For performance I want all sorting to be performed in memory, and I don't really care at the moment whether it's in hiperspace or dataspace or whatever. I successfully used the FILSZ=Ennn parameter until I ran out of space, so I increased the value to match the reality and since then I cannot get rid of the dynamic allocation messages. I've tried DYNALLOC=OFF, HIPRMAX=0, DSPSIZE=0, DSA=0, FILSZ=U0, you name it! in all sorts of combinations in an attempt to prevent dynamic allocation of work files, all in vain. I've tried region sizes far! too big including REGION=0M. I've also tried preallocating SORTWKxx to VIO data sets, but DFSORT then allocates its own SORTDKxx data sets instead :( So how can I successfully sort my records in storage without using dynamic allocation with all the rubbish job log messages as a result? Many thanks, Staffan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
On 2/20/2012 at 08:34 AM, John McKown joa...@swbell.net wrote: If the filesystem runs out of space, and you used the proper type of filesystem (there are many), you simply expand the size of the logical volume into unused space in the group. You then resize the filesystem. If you used ext4 or btrfs, I think you can do this while it is in use. If you used ext3, I think you need to unmount it (take it offline) to resize it. To shrink an ext3 file system it has to be offline. To expand it, that limitation was removed some time ago. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
Nope. The DSNs on the volumes will stay on the volumes, and be fully accessable. If they need to be extended onto a new volume, still no problem. If they are every migrated recalled, they will go to other volumes in the old storage group. Assuming nothing has been done to affect that. Unless, of course, the storage class is guaranteed space, in which case I think the recall will fail. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Monday, February 20, 2012 8:24 AM To: IBM-MAIN@bama.ua.edu Subject: Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) ) On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: R.S. r.skoru...@bremultibank.com.pl wrote in message news:4f41f979.3010...@bremultibank.com.pl... deleted What is cool is that SMS storage group. Usually users do not see the volumes, they see dasd space. In case of shortage you can simply add some volumes to the group. You can even buy new box and simply add it to the group. And that's really cool IMHO. And SMS's granularity is also cool. If you add your 1TB disk to a storage group, you cannot use this space in anther SG anymore. If you have 1TB of 3390-54's, you can give to and take from SMS storage groups any required amounts at any time. You don't have to empty the volumes? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: was: Abend S0C4 in an internal sort
There may well be a facility for suppressing unwanted DFSORT messages, particularly informational ones. If there is, FY will provide you and the rest of us with information about it here (unless perchance he is in Timbuktu today). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: was: Abend S0C4 in an internal sort
On 2/20/2012 12:32 PM, John Gilmore wrote: There may well be a facility for suppressing unwanted DFSORT messages, particularly informational ones. If there is, FY will provide you and the rest of us with information about it here (unless perchance he is in Timbuktu today). I don't think this is what he is asking to suppress. I think he wants to eliminate the allocation messages for the dynamically allocated SORTWKxx DD's. Lat time we had SYNCSORT, it didn't allocate SORTWK's unless they were needed, so an in-core sort never allocated them. Last time I checked, DFSORT seems to allocate them when it starts, so you can't eliminate them. One option may be to allocate the SORTWKxx in JCL, so there is only one set of them. Make sure DFSORT is not setup to dynamically re-allocate them. This assume you do not have multiple sorts running at the same time. Maybe Frank knows some way to cause DFSORT to not allocate them for in-core sorts. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Avoiding DFSORT dynamic allocatoin, was: Abend S0C4 in an internal sort
I can't give specific recommendations without knowing more about these sorts being executed and the environment. But perhaps I can offer a little info that will be useful. The reason the JCL SORTWKxx data sets get reallocated to SORTDKxx is because VIO=NO is in effect. This is the installation default we recommend. So when the work data sets are allocated to VIO, DFSORT attempts to re-allocate them to SORTDKxx data sets using a different unit name in hopes they will be directed to disk instead of VIO. Unfortunately, VIO cannot be specified as a run time option so you cannot change it for just this job. But perhaps you can code JCL SORTWKs using a unit that is not directed to VIO. I don't know how your ACS routines are set up but usually a VIO storage class is assigned based on the primary space allocation size. So perhaps if you allocated 1 or 2 SORTWK dds with a larger storage size, they'd be assigned to disk and thus DFSORT would not try to re-allocate them. When no JCL sortwks are present, then DFSORT's dynamic allocation is used. Usually, even if the sort is expected to complete in memory, work data sets are still allocated since we can't be entirely sure of the file size being passed. You could at least reduce the number of work data sets being passed by using an OPTION statement with DYNALLOC=(,2) which would reduce the number of work data sets allocated. There might be some other options we can come up with if we had more info. Perhaps you can send the entire joblog from an execution of this program to our DFSORT hot line, dfs...@us.ibm.com and we can take a look. Have a nice day, Dave Betten DFSORT Development, Performance Lead IBM Corporation email: bet...@us.ibm.com DFSORT/MVSontheweb at http://www.ibm.com/storage/dfsort/ IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 02/20/2012 12:22:44 PM: [image removed] was: Abend S0C4 in an internal sort Staffan Tylen to: IBM-MAIN 02/20/2012 12:23 PM Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Please respond to IBM Mainframe Discussion List I wish to continue this thread as it's related. I'm now running my program with internal calls to DFSORT and it works fine except for one issue that I have, namely that I get a lot of job log messages generated as a result of dynamic allocation of VIO sortwork files. DFSORT is invoked 1000's of times by the program (yes, I know but there is nothing I can do about that) and each time it creates a bunch of job log messages for VIO allocations. For performance I want all sorting to be performed in memory, and I don't really care at the moment whether it's in hiperspace or dataspace or whatever. I successfully used the FILSZ=Ennn parameter until I ran out of space, so I increased the value to match the reality and since then I cannot get rid of the dynamic allocation messages. I've tried DYNALLOC=OFF, HIPRMAX=0, DSPSIZE=0, DSA=0, FILSZ=U0, you name it! in all sorts of combinations in an attempt to prevent dynamic allocation of work files, all in vain. I've tried region sizes far! too big including REGION=0M. I've also tried preallocating SORTWKxx to VIO data sets, but DFSORT then allocates its own SORTDKxx data sets instead :( So how can I successfully sort my records in storage without using dynamic allocation with all the rubbish job log messages as a result? Many thanks, Staffan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
John, You. Hit the nail on the head Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 19, 2012, at 8:35 PM, Fred Hoffman fhoff...@tad.org wrote: Amen John!! From: IBM Mainframe Discussion List on behalf of John Gilmore Sent: Fri 2/17/2012 6:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Archaic allocation in JCL (Was: Physical record size query) Frank Swabrick wrote: begin snippet | No, I'm not expecting a real answer to that question. | Just trying to point out why it's hard, to say the least, | to know how to size files of this type. /end snippet The question itself has not been very well formulated. No one, I hope and suppose, sizes files directly in cylinders, tracks or megabytes. These are derived quantities. One begins with record types, their individual sizes, and their expected volumes/counts. Initially one has only estimates, often poor ones, of transaction/processing volumes, but these estimates can be improved incrementally by collecting statistics of the volumes actually experienced during processing and then analyzing these data.. That this is not much done does not been that it cannot or should not be done. Adequate capacity planning and even many design decisions are impossible without the systematic collection and analysis of such information. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
Hey John, That quite a new and surprising approach! My point was to (indeed) empty several volumes, reformat/relabel them (to predefined volumes in the new SG) and therewith add them to a new SG, where I need the extra space. With your way of handling, I can remove the volumes from the old SG, add them to the new SG and with the flip of a finger, I have the free space of those volumes added to the new SG. If space management is set up will, the datasets on the volumes will be moved back to their proper SG in due time, but I do not have to wait for that before I can add the free space to the new SG. Never looked at this that way. Kees. McKown, John john.mck...@healthmarkets.com wrote in message news:a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom. .. Nope. The DSNs on the volumes will stay on the volumes, and be fully accessable. If they need to be extended onto a new volume, still no problem. If they are every migrated recalled, they will go to other volumes in the old storage group. Assuming nothing has been done to affect that. Unless, of course, the storage class is guaranteed space, in which case I think the recall will fail. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Monday, February 20, 2012 8:24 AM To: IBM-MAIN@bama.ua.edu Subject: Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) ) On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: R.S. r.skoru...@bremultibank.com.pl wrote in message news:4f41f979.3010...@bremultibank.com.pl... deleted What is cool is that SMS storage group. Usually users do not see the volumes, they see dasd space. In case of shortage you can simply add some volumes to the group. You can even buy new box and simply add it to the group. And that's really cool IMHO. And SMS's granularity is also cool. If you add your 1TB disk to a storage group, you cannot use this space in anther SG anymore. If you have 1TB of 3390-54's, you can give to and take from SMS storage groups any required amounts at any time. You don't have to empty the volumes? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
I used to do that on rare occasion. I then got told off by management. They associated the volser to the storage group and did their reporting based on it. So my mixing things up messed up their reports. I'm not allowed to do that any more. We have offline volumes with a specific starting character. I will get dinged if any dataset ever shows up on any volume with that character. All offline volumes __must__ remain unused at all times. If I need space, even if only for a few hours, I must request it. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Monday, February 20, 2012 2:32 PM To: IBM-MAIN@bama.ua.edu Subject: Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) ) Hey John, That quite a new and surprising approach! My point was to (indeed) empty several volumes, reformat/relabel them (to predefined volumes in the new SG) and therewith add them to a new SG, where I need the extra space. With your way of handling, I can remove the volumes from the old SG, add them to the new SG and with the flip of a finger, I have the free space of those volumes added to the new SG. If space management is set up will, the datasets on the volumes will be moved back to their proper SG in due time, but I do not have to wait for that before I can add the free space to the new SG. Never looked at this that way. Kees. McKown, John john.mck...@healthmarkets.com wrote in message news:a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.ui cnrh.dom. .. Nope. The DSNs on the volumes will stay on the volumes, and be fully accessable. If they need to be extended onto a new volume, still no problem. If they are every migrated recalled, they will go to other volumes in the old storage group. Assuming nothing has been done to affect that. Unless, of course, the storage class is guaranteed space, in which case I think the recall will fail. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mike Schwab Sent: Monday, February 20, 2012 8:24 AM To: IBM-MAIN@bama.ua.edu Subject: Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) ) On Mon, Feb 20, 2012 at 1:58 AM, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: R.S. r.skoru...@bremultibank.com.pl wrote in message news:4f41f979.3010...@bremultibank.com.pl... deleted What is cool is that SMS storage group. Usually users do not see the volumes, they see dasd space. In case of shortage you can simply add some volumes to the group. You can even buy new box and simply add it to the group. And that's really cool IMHO. And SMS's granularity is also cool. If you add your 1TB disk to a storage group, you cannot use this space in anther SG anymore. If you have 1TB of 3390-54's, you can give to and take from SMS storage groups any required amounts at any time. You don't have to empty the volumes? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Batch process VS Started task
On Feb 19, 2012, at 5:27 PM, Joel C. Ewing wrote: The described record arrival rate averages at just under 58 records per second. Somehow I don't think XBM was designed with that high of transaction arrival rate in mind, processing each record as a separate transaction. I would think that a high-speed transaction processing environment (CICS, IMS) would do better than XBM, although those would probably still involve more overhead than a specialized transaction-processing STC optimized just for your own peculiar transactions (but I agree a separate specialized STC would be more of a maintenance headache). There is also an intermediate approach where you collect records by some means and then periodically fire off a process or transaction to process records collected since the last time the process was run. Another consideration: If the current batch processing is done at a time of lower system system load and involves significant work per record, moving this processing into peak processing times could have significant impact on your peak MSU requirement and a significant impact on your costs. I suspect your record arrival rate is not a constant throughout the day but also has its peaks. If those peak record arrival rates actually correspond to current periods of peak system load, then the impact on the peak system MSU requirements of moving this load would be even greater than one would expect from the average record rate alone. In other words, if there is a perceived business need to process the records in a more timely manner, be sure those footing the bill are aware it may not be a free lunch. JC Ewing Joel: I think a LOT depends on how much processing is needed for each transaction. If it is just syntax checking and minimal editing then maybe XBM is a possibility. Although your scenario is valid as well. It is hard to give out much information without a lot more detail. We did XBM jobs and the number varied all over the place. Typically each job took about 5 minutes of CPU time (168 slow I know) it was both cpu and IO intensive (essentially Assembler H compiles and with Major macros). I did not want to suggest that XBM is a final answer in any case. It was used by us in a highly unusual manner. I hope the original questioner comes back with a little bit more information. CICS or IMS is (like you suggested) viable alternative but it is complicated (bother suggestions) and hard to say this way or the otherway. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Do what to get C strftime %z to work?
I am reading the FM and I am lost in a sea of environment variables and POSIX and gosh knows what. If I would like the strftime() format character %z to return -0500 or + or whatever, what do I have to do? I know the system knows what time zone it is in, because for a given timeb, localtime() and gmtime() return the proper times. But the %z flag in strftime() returns no characters. The trouble starts in localtime() because it sets tm_isdst to -1. But even if I set tm_isdst to 0 manually strftime %z still returns nothing. As a side note, the PG says The time zone external variables, tzname, timezone, and daylight, declarations remain feature test protected in time.h. Definition of these external variables are only known to the C/C++ run-time library if the z/OS UNIX System Services C/C++ signature CSECT is link edited with your C/C++ application. What the heck is the signature CSECT and how the heck do you link it with your application? I found no other references in the docs to signature CSECT. Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Do what to get C strftime %z to work?
Should have said that the environment is z/OS batch (started task, actually). Charles -Original Message- From: Charles Mills [mailto:charl...@mcn.org] Sent: Monday, February 20, 2012 3:01 PM To: IBM Mainframe Discussion List Subject: Do what to get C strftime %z to work? I am reading the FM and I am lost in a sea of environment variables and POSIX and gosh knows what. If I would like the strftime() format character %z to return -0500 or + or whatever, what do I have to do? I know the system knows what time zone it is in, because for a given timeb, localtime() and gmtime() return the proper times. But the %z flag in strftime() returns no characters. The trouble starts in localtime() because it sets tm_isdst to -1. But even if I set tm_isdst to 0 manually strftime %z still returns nothing. As a side note, the PG says The time zone external variables, tzname, timezone, and daylight, declarations remain feature test protected in time.h. Definition of these external variables are only known to the C/C++ run-time library if the z/OS UNIX System Services C/C++ signature CSECT is link edited with your C/C++ application. What the heck is the signature CSECT and how the heck do you link it with your application? I found no other references in the docs to signature CSECT. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Batch process VS Started task
Both CICS and IMS have (rather different) facilities for mini-batching, triggering FIFO processing of all of them after an waiting-transactions queue reaches a specified length L 0. This processing threshold L can be varied without making other changes, and doing so provides a mechanism for balancing initialization and transaction-processing path lengths in a way that minimizes their sum. This optimizing machinery is very important , and even if a RYO scheme is used it should be provided. Limiting the design alternatives considered to just 1) batch, all at the same time, or 2) one-at-a-time processing is unwise. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Avoiding DFSORT dynamic allocatoin, was: Abend S0C4 in an internal sort
... DFSORT is invoked 1000's of times by the program ... Once upon a time, at a previous job, I ran into a similar situation. The job ran for hours and hours. Analysis showed that SORT was invoked to sort 1 record (yes, that's ONE record!) most of the time and between 2 and about 100 records the rest of the time. A programmer had tried to cobble something together, quick-and-dirty-like, and overlooked the fact that his approach would require several thousands of SORT invocations. SORT invocations take time, especially DYNALLOC, and there's no way (that I know of) around it. You may be able reduce the overhead a bit by adding a //DFSPARM DD * OPTION DYNALLOC=(3390,2) to the JCL, as recommended earlier. The programmer eventually changed the program logic to output all the records to be sorted to a file, then called SORT and finally processed all sorted records ... the job now ran in under 5 minutes. So, my question to the original poster is: Is it really necessary to invoke SORT thousands of times or could the program logic be changed to avoid or reduce the number of SORT invocations? Regards, Ulrich Krueger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
In 4f418fa1.4040...@acm.org, on 02/19/2012 at 06:11 PM, Joel C. Ewing jcew...@acm.org said: Under Windows, a directory is closer functionally to the MVS/DOS concept of a VTOC, as each volume has its own directory ITYM each volume has its own root directory; a typical DOS or 'doze volume has many directories. and you have to somehow know which volume to consult Much like MVS before IBM pulled the plug on user catalogs. But in either case they are obviously structurally different Just like CVOL, VSAM catalog and ICF catalog were structurally different from each other. Just like directories in FAT are structurally different from directories in NTFS. Just like directories in ext2 are structurally different from directories in reiserfs. finding an file entry in Windows or Linux requires a progressive search through multiple directory levels rather than just a single lookup of the full path name as with a data set name in an MVS catalog. There is no single lookup of the full path name except in a shop with no user catalogs, which you'd be hard pressed to find. And in both Windows and Linux, in many cases the user thinks of a file by its file name and not its full path, and the onus in on the user to remember under what directory the file was placed. That's true for MVS as well. That issue does not arise in MVS It certainly does. because dataset names are always referenced by the full name No. In fact, there are cases where attempting to refer to a data set by its full name will cause an error. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
In af2ee1ca5139d947b1ccdbf226607e8e02b9d...@tad03.tad.org, on 02/19/2012 at 07:36 PM, Fred Hoffman fhoff...@tad.org said: I thought os/vs1 was MFT with virtual storage. That doesn't conflict with what anybody wrote in this thread, although it is an oversimplification. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Authorized functions
In m3obsuwa9v@garlic.com, on 02/19/2012 at 08:42 PM, Anne Lynn Wheeler l...@garlic.com said: folklore is that *IX (and numerous *IX work-alikes) came from simplification of MULTICS. That's why I spell it EUnix, but they're really fundamentally different. Multics was built around the concept of a single-level store and Unix was not. Multics had a PL/I run-time environment built in. The Multics shell made heavy use of active functions while the Bourn shell was oriented to filters. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: O/T but curious (Re: Archaic allocation in JCL (Was: Physical record size query) )
In 1329705063.29591.54.ca...@mckown5.johnmckown.net, on 02/19/2012 at 08:31 PM, John McKown joa...@swbell.net said: Just to play the Devil's advocate for a bit, it depends on how you define dataset name. I agree, in Linux (and as a stretch, Windows), if you specify the entire file path, starting from the root, you don't need a catalog. The directory is a catalog, and the path may include links. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Authorized functions
In 0fcef8d8-ed56-4e67-97b4-34a32d5b6...@yahoo.com, on 02/19/2012 at 11:05 PM, Scott Ford scott_j_f...@yahoo.com said: Yep I agree with both of you, I learned assembler first I learned assembler[1] first, but that didn't prevent me from picking up new languages freely. I don't feel any nostalgia for my first few languages and would never want to go back to them. [1] Well, they made us write some short programs in machine language[2] first so that we would appreciate SOAP 2 when we learned it. [2] Yes, that was cruelty to children. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
